Regarding "Drive-By Pharming" and Honeyclients

Recently Symantec has posted information about a new threat which they are calling Drive-By Pharming. The threat is the use of JavaScript as an attack platform, and is the evolution of work pioneered and presented by Jeremiah Grossman at BlackHat USA 2006 (PDF of slides here). Grossman's presentation, titled "Hacking Intranet Websites from the Outside", details a number of ways that JavaScript can be used from a client's web-browser to do things like scanning a corporate internal network to see which machines are up, perform Cross-Site Scripting (XSS) attacks, and even log in to devices that have http interfaces and default passwords and change settings… Thus, since I had forgot that last point, upon re-familiarizing myself with the presentation and looking through the Symantec Whitepaper it's clear that Drive-By Pharming is not exactly new, but rather is the reapplication of Grossman's techniques specifically targeting home-users of wireless access points/switches/routers rather than corporate. This is also acknowledged in the main Symantec link, but I mention it because no other site I had seen talk about it had mentioned it.

In any case, an interesting fact struck me when thinking about the attacks and whether our current Honeyclients could detect them. In the current architecture (see the first picture in the UserGuide), when a Honeyclient Agent goes to spider a new URL, it first sends a SOAP message back to the Manager. The Manager then sends a SOAP message to the Firewall, telling it to open up port 80 or 443 for that Agent to that website's IP(s). What this means is that, if I tell it to go to http://www.cnn.com then I only want it to get html/images/etc from the IPs associated with www.cnn.com. I don't want the Firewall to let in/out any content from or requests to IPs associated with images.cnn.com, ads.cnn.com, or i.a.cnn.net which might all be embedded in the HTML for the front page, and therefore a browser will automatically request. This is because we want strict control over what is given to the Agent and when, so that we can identify the point of exploit easier.

If I can digress for a second, you might think that this could stop some exploits because any given page will not include possibly malicious inline images, IFRAME links to external content, etc. However this is not the case because when the browser it set to go to www.cnn.com, we first use the perl LWP::UserAgent module to pull a copy of www.cnn.com's HTML which we parse to find all the links, and then collect the links into a hash to be spidered later. (LWP is also set up to mimic browser HTTP request headers, and ignore both HTTP redirect messages and META REFRESH tags which might redirect us so that we actually get some other HTML which isn't at the exact URL we requested.) We use LWP in front of the browsers because browsers are not easily configured to not automatically follow redirects or pull down the content for all links on a given page. But after the LWP link collection has been done, we can then tell the browser to visit the site. It will happily request all the URLs on the page, but any off-site content will simply fail to load in the browser as it has been blocked by the Firewall.

The Firewall, however, is keeping a log of access attempts which are made but which are denied by the current rules. This was originally intended to serve as a defense-in-depth measure, whereby, if some malicious application was able to run and begin making requests to the internet (for instance to download the second stage of a trojan) it would be denied and we would have record of it right away (possibly to trigger detection of a compromised VM…though we do not do this in the current versions due to it's innate propensity for false-positives which we have yet to work on eliminating). In the context of JavaScript malware, where there are no other processes, filesystem, or registry changes to work as detection parameters, unless JavaScript-specific checks are incorporated, this then becomes the primary detection mechanism. In the trivial case, where the JavaScript is only making requests to private IP address space (10/8, 172.16/12, 192.168/16) the attack now becomes vulnerable to a trivial heuristic of checking the Firewall log for such requests.

While the recommendation of Symantec to stop these attacks is simply for home-users to set a non-trivial, non-default password on their devices, it is certain that most people will not have heard of this type of attack or recommendation, and will continue to run with default passwords. Therefore it's good to know that Honeyclients can already detect this type of attack if we ever come upon it in the wild.