Bit.ly boosts malware protection

December 1, 2009 – 6:09 PM

For the security-conscious, those shortened URLs on Twitter can be unnerving. After all, where is that shortened URL really taking you? This summer, security vendors documented how spammers and phishers were exploiting URL shortening services to try to trick users into visiting sketchy sites. On Monday, one URL shortening service provider, bit.ly, made an announcement that promises some security relief on this front: it plans to integrate security services from VeriSign, Websense, and Sophos to boost its defenses against malware and spam.

In a blog post, bit.ly said it will use VeriSign’s iDefense IP reputation service to detect URLs, domains and IP addresses that host malicious code. It will also use the Websense Threatseeker Cloud service to catch spam by analyzing bit.ly links in real time, and Sophos’ behavioral-analysis technology to fend off spam and malware.

According to a Websense blog post, bit.ly will use Websense’s security-as-a-service platform to scan both new and existing shortened links as users click on them. “Websense will conduct full content analysis for the IP sources, websites and Web content behind the bit.ly links, including categorization and reputation analysis of the URL, property type, lexical and search reputation, history, age, geography, neighboring properties and more. If the user attempts to click on a link leading to malicious code, spam or a known phishing site, bit.ly will display an alert describing the threat potential and give the user the option to safely navigate away,” Websense wrote.

Source:
http://itknowledgeexchange.techtarget.com/security-bytes/bitly-boosts-malware-protection/

The Penetration Testing Marketplace in 2010

December 1, 2009 – 10:01 AM

Vulnerability assessment vendor Rapid7 has announced the first of a series of steps to integrate its penetration testing and vulnerability assessment scanning products. The first step is a module that allows users of the Metasploit Framework, which Rapid7 acquired in October to natively import NeXpose scanner results and then take automated action against vulnerabilities MSF is capable of attacking.

This is not the forum for a discussion of product news. But the integration, modest as it currently is, speaks to some high level trends in the penetration testing space that I feel are of continuing interest to businesses that currently perform or are considering setting up the capability to perform penetration tests using an internal pen test team.

In a nutshell, users of MSF 3.3.1 console and NeXpose can control the latter from the former, start a scan, import into MSF and cross-reference available exploits to the results of the scan, then automatically exploit the matching vulnerabilities.

Source:
http://threatpost.com/en_us/blogs/penetration-testing-marketplace-2010-120109

DNS Rebinding – Explained

December 1, 2009 – 9:40 AM

Here is a great video from Robert “RSnake” Hansen explaining what DNS Rebinding actually is and shows some various attacks that may be performed as a result of it.  RSnake also explains what can be done to fix the problem and explains why it might not happen any time soon.

DNS Rebinding with Robert RSnake Hansen from Robert Hansen on Vimeo.

Trojan demands money for internet access

December 1, 2009 – 8:32 AM

There’s nothing new about Windows trojans resorting to a little blackmail, but Computer Associates has now observed a new twist; a trojan which blocks internet access until the user enters an activation code. This is activation code is obtained by sending an SMS containing a particular number to an expensive premium rate phone number – CA does not mention the sum involved.

The malware, dubbed ‘Win32/RansomSMS.AH’, infects computers by claiming to be the “uFast Download Manager” tool which, when run, accuses users (in Russian) of having breached their licence conditions. CA has kindly provided a free tool (via zip direct download) to enable users to generate the required code for themselves.

Source:
http://www.h-online.com/security/news/item/Trojan-demands-money-for-internet-access-873853.html

Clientless SSL VPN Vulnerability

December 1, 2009 – 6:47 AM

Web browsers enforce the same origin policy to prevent one site’s active content (such as JavaScript) from accessing or modifying another site’s data. For instance, active content hosted at http:///page1.html can access DOM objects on http:///page2.html, but cannot access objects hosted at http:///page.html. Many clientless SSL VPN products retrieve content from different sites, then present that content as coming from the SSL VPN, effectively circumventing browser same origin restrictions.

Clientless SSL VPNs provide browser-based access to internal and external resources without the need to install a traditional VPN client. Typically, these web VPNs are used to access intranet sites (such as an internal webmail server), but many have more capabilities, such as providing access to internal fileshares and remote desktop capabilities. To connect to a VPN, a web browser is used to authenticate to the web VPN, then the web VPN retrieves and presents the content from the requested pages.

Web VPN servers interact with clients using a process similar to what is described below:

1. The user presents credentials to the web VPN using a web browser. The authentication can be done through username and password submission, or can involve multi-factor authentication.
2. The web VPN authenticates the user and assigns an ID to the session, which is sent to the user’s browser in the form of a cookie.
3. The user can then browse internal resources, such as a webmail server or intranet webserver. URLs as viewed by the user’s web browser may be similar to https:///www.intranet.example.com

As the web VPN retrieves web pages, it rewrites hyperlinks so that they are accessible through the web VPN. For example, a link to http:///mail.html becomes https:///www.intranet.example.com/mail.html. Cookies set by the requested webserver are converted into globally unique cookies before being passed to the user’s browser, which prevents collision between two identically named cookies from different requested domains. For example, a sessionid cookie set by intranet.example.com could be renamed to intranet.example.com_sessionid before it is sent from the web VPN to the user’s browser . Additionally, the web VPN replaces references to specific HTML DOM objects, such as document.cookie. These DOM objects are replaced with script that returns the value for that DOM object as if it had been accessed in the context of the requested site’s domain.

If an attacker constructs a page that obfuscates the document.cookie element in such a way as to avoid being rewritten by the web VPN, then the document.cookie object in the returned page will represent all of the user’s cookies for the web VPN domain. Included in this document.cookie are the web VPN session ID cookie itself and all globally unique cookies set by sites requested through the web VPN. The attacker may then use these cookies to hijack the user’s VPN session and all other sessions accessed through the web VPN that rely on cookies for session identification.

Additionally, an attacker could construct a page with two frames: one hidden and one that displays a legitimate intranet site. The hidden frame could log all keys pressed in the second, benign frame and submit these keypresses as parameters to a XMLHttpRequest GET to the attacker’s site, rewritten in web VPN syntax.

Note that if the VPN server is allowed to connect to arbitrary Internet sites, these vulnerabilities can be exploited by any site on the Internet.

Source:
http://www.kb.cert.org/vuls/id/261869