Tackle malicious Web code without infecting yourself

Malware defense efforts need to balance speed with risk, from using less-common browsers to full virtual machines

How do you investigate potentially malicious Web page code without infecting yourself?

As a computer security defender, I’m often in a position where I need to investigate a potentially malicious Web link. Maybe it arrived as a really legitimate-looking phish e-mail, in a new exploit announcement, or within embedded codes of some other media. Either way, either I’m not sure whether the link is really malicious or I’m sure the link is malicious, but I want to view the source or intended download.

The quickest investigation method -- but probably the least secure -- is to run an alternate browser that is not normally capable of automatically executing the malicious link or malware. For instance, because most browser threats are made for Microsoft’s Internet Explorer, I often use Mozilla Firefox or another browser. This usually works, but you never know when your alternate browser will be just as exposed to the malicious link or program that you are exploring.

Surprising to many people, Firefox has had just as many separately announced vulnerabilities as Internet Explorer throughout the past two years. It is not uncommon that a vulnerability announced for one affects the other; in fact, it happened last week (check out this advisory for Firefox and this one for IE). Although the malware I’m investigating can usually be run more safely in Firefox, I’m always aware that I'm taking a risk.

In that vein of thought, I often run less-popular browsers when investigating malware to decrease my chances of unintended malware activation. The Opera browser is a good choice with a multitude of platforms from which to choose -- Windows, Linux, BSD, Solaris, and so on -- and a much lower rate of announced exploits. Linux Konqueror is another safer browser choice.

Apple Safari’s three announced exploits makes it a viable choice, too. The only problem is you have to run OS X to get Safari. Some of the underlying open source components are available on other platforms, but Safari, itself, remains closed-sourced.

Malware analysts often prefer the even safer text-only browser Lynx. Its multiplatform support (DOS, Windows, Linux, VMS, and so on), cost (free), and lack of features often make it a smart and safe choice. Despite all this, it still frequently astounds me that even Lynx is susceptible to exploits -- including one buffer overflow.

If you don't want to press your luck with a less-used browser, many browser analysts use Web-based services that extract link information and source code and display it as data, decreasing the likelihood of it being executed. Wannabrowser and Web-Sniffer are great proxy agents for that type of code review. Just plug in the suspected link and the resulting HTML code will be displayed safely on your screen as text data. As far as I can tell, cross-site scripting attacks and the like don’t work using these services.

But any time you peruse malicious code or links through an online browser, you risk the possibility of accidentally executing remote malicious code. Many researchers, including myself, download the links and code using nonbrowser tools and open the resulting content in harmless text editors such as Microsoft’s Notepad, Unix’s Vi, or Linux’s Kedit programs.

Wget is an excellent HTML content downloading tool for doing just that. It runs in both Linux/Unix and Windows as a command-line tool. Running wget –r <url>, where <url> is the Web site address, Wget will download the entire Web site -- graphics and all -- to your local disk, where it can be examined in a text editor.

The safest and my recommended method for testing Web code, however, is to use a virtual machine. There are several virtualization software programs out there, including VMware, Virtual PC, Xen, and even User-Mode Linux.

Because all virtualization software can be detected and circumvented back to the host, it’s probably better to run VM software on a nonproduction machine when investigating malware. Still, even running a VM on your primary machine is preferable over blindly running malicious links on your host operating system.

VMs emulate your host environment as closely as they can. When clicking on malicious links or running malware, all the bad stuff executes in the virtual environment. In most cases (you can never be sure without a full malware code review), the malicious software's attempts to modify the local machine only alter the VM environment. Don’t like what it did or not sure what it did? Just reset the VM and voila, it’s like it never happened.

Even when running malware in a VM environment, you still need the tools that allow you to analyze the malware forensically. That means using one of the previously mentioned Web source code review tools or running other tools to look for system modification (such as Tripwire) or Sysinternals’ Regmon or Filemon.

When using VM environments, you still need to take special care to contain any malicious code or behavior within the VM environment. For example, if you run a network-based worm, it will still be capable of using the VM’s networked resources to spread beyond the VM environment, unless you disable networking or use an offsetting defense.

Of course, when analyzing malware, the investigator should use appropriate caution. But any of these methods beats clicking on the malicious link or content in IE and hoping nothing happens.