SUMMARY & RECOMMENDATIONS

We have evaluated over 300,000 URLs with our client honeypot Capture-HPC. Several different types of input URLs were inspected by our client honeypot. All input URL categories did contain malicious URLs putting any user accessing the web is at risk. As in real life, some “neighborhoods” are more risky than others, but even users that stay clear of these areas can be victimized. We make a few recommendations to reduce the risk of successful attack by a malicious web server. We acknowledge that there is no silver bullet in this effort, but rather our recommendations are designed to reduce the risks to more acceptable levels.

The first recommendation is to reduce the likelihood that a successful attack will do harm. An attack on your browser will inevitably occur, and there are several measures that can make this attack hit a brick wall even if your browser is vulnerable and the attack succeeds. Using the browser as a non-administrator user or within a Sandbox will not allow malware to install itself on the machine. This is already the default on a Windows Vista and Internet Explorer 7 installation, but there are several products freely available for older versions as well, such as AMUST Defender or Sandboxie.

Further, we recommend using a host-based firewall that blocks inbound and outbound connections per application. Many firewalls support a learning mode that dynamically configures the firewall via prompting the user to accept/reject a connection. As users tend to accept the prompts without much consideration, we believe this might result in an insecure configuration of the firewall, and should rather be configured by an expert after the installation. Running a host based firewall would restrict malware from performing its malicious deeds. The malware pushed by the Keith Jarrett site, for instance, could not send the collected user data to a malicious data collection server if a host-based firewall is installed. The outgoing connection would have been blocked based on the fact that the malware application wasn’t authorized to make an outbound connection on port 80. Inbound connection blocking is also important. If malware starts a service that allows the attacker to remotely connect to the machine, for instance via a remote desktop software, the firewall could successfully prevent inbound connections from being established. While malware is able to disable such a firewall once it has gained control of the machine, we did not observe such behavior on our client honeypots.

Second, we are recommending methods that stop the attack. We have shown that blacklisting is an effective technique. Since the landscape of malicious servers is quite dynamic, it is important to update such a blacklist on a regular basis just as one updates antivirus signatures. Alternatively, one can use one of the many browser toolbars that make a safety assessment of the site. Patching is the other mechanism that can prevent attacks. Of course, this only works on attacks for which patches are readily available. We recommend patching not only the operating system and browser, but also plug-ins and non-browser applications. As the exploit found on the Keith Jarrett site has shown, attacks also target applications that one might have not think about patching, such as Winzip. Since it is quite difficult to determine whether insecure and unpatched software is running on a system, several tools exist that make this assessment easier. One of these tools is the Secunia Software Inspector that performs an online scan of the machine to determine whether unpatched software is running. Disabling JavaScript might be another very effective method to stop attacks. Most attacks we observed did need JavaScript to be enabled. Disabling JavaScript, however, might not be feasible as it would severely impact the functionality of many legitimate web sites. Some tools address this problem by globally disabling JavaScript, but selectively enabling it for certain trusted site. NoScript for the Firefox browser is an example of such a tool.

When choosing a search engine to access sites, ensure that you use one that assesses the safety of the sites in its index. Google for instance, displays warning messages on the search results page next to sites that are not safe. While Google’s internal blacklist is probably also not complete, it provides another protection layer that might prevent a successful compromise on the machine you are using.

Finally, we make a recommendation on the software to use. Attackers are criminals that would like to attack as many people as possible in order to get the largest return on their investment. As such, they target popular, homogenous systems. The tests we conducted show that a simple but effective way to remove yourself as a targeted user is to use a non-mainstream application, such as Opera. As mentioned above, despite the existence of vulnerabilities, this browser didn’t seem to be a target.

We have just listed a few recommendations that would allow you to reduce the risk of falling victim to an attack by a malicious web server. Implementing such measures does not guarantee full protection, but it does lower the risk. One should practice security in breadth and depth and there are additional measures one can take that are beyond the scope of this paper, such as measures that would detect a successful compromise. To best secure your operating system and browser we suggest contacting your vendor directly for specific instructions on configuration or patching against client-side attacks. You can reference our paper directly with them and inquire as to their specific instructions for mitigating these types of attacks with their software.

The data that we have generated and collected that we reference in this study is available for download from our web site at http://newzealand.honeynet.org/kye/mws/complete_data_set.zip.