Endpoint Protection

The media surrounding the effectiveness of Windows Vista's newsecurity features has (in my opinion) just begun. Microsoft's reach iswell beyond that of any other software vendor in the world, and withthis achievement comes fame, power, and a corporate life under amicroscope. To honor this tradition, I previously posted an entryabout the effects of malicious code executed under a default Vistaenvironment; if you haven't read it, you are certainly encouraged to.This research has now been completed and this new entry should serve asa compliment to my previous post. A paper detailing the full researchhas been made available here.

The outcome of the research:

In my previous blog, I mentioned that about seventy percent of themalicious code executed under Vista loaded successfully and executedwithout a crash or runtime error. After completing the research, andincreasing the number of binaries, the percentage slightly decreased to58 percent. The term Successful Execution simply means thebinary was mapped into memory by the Windows loader and began executinginstructions at the derived entry point. It does not, however, indicatethe malicious code successfully compromised the system's integrity.Table 1 illustrates the classifications used along with the results ofthe research in no particular order.

Table 1: Result statistics

The table's structure consists of five columns: column one indicatesthe threat classification, column two contains the total number ofbinaries derived for this particular class, column three indicates thenumber of binaries that successfully began execution, column fourindicates the number of binaries that failed to execute completely, andcolumn five contains the number of binaries that successfully surviveda reboot from the total number of execution attempts.

From the results, we were able to identify which security componentsof Vista may be subverted to perform operations specificallydisallowed. One example is Vista’s firewall, by default it isconfigured to disallow all third party and untrusted networkcommunications unless the user clicks the unblock button. This feature,if slightly enhanced, poses a great limitation for malicious codelooking to back door a host. Unfortunately, the unblock button may beaccessed with the same privilege level as a standard user. Thisconfiguration of privileges creates a point of vulnerability thatundermines the effectiveness of the firewall’s policy in Windows Vista.In effect, malicious code can automate the unblock process by simplysending a message to the firewall pop-up dialog box via the SendMessageAPI call. A second example deals with surviving a system restart, andis discussed in the full research paper referenced above.

Other security concerns exist, however they are not explicitly saidto be prohibited by Vista, for example by default, UAC allows astandard user to call the following functions, which may allow anattack to perform keylogger and sniffer-like operations.

SetWindowsHookEx, made available in earlier versions ofWindows, allows applications to hook other API calls at runtime byinjecting a user-specified call into a hook chain. Thus, allowing anattacker to hijack sensitive information from a user’s active desktopsession. However, an attacker may only infect processes running underthe UAC environment.

GetAsyncKeyState, when used in conjunction with DLL injectionmethods, may allow an attacker to monitor keystrokes and otherinteractive activity on a desktop. Again, the same restriction appliesto this method where an attacker can only infect the current user.

Previous related work:

Although no analogous research has been done, in an interviewby IT Pro, Sana Security was quoted for claiming that 38 percent of themalicious software currently in circulation is alreadyVista-compatible. Considering 38 percent is a feasible subset of the 58percent total obtained by our testing, Sana Security's claims arewithin reasonable range. It is, however, unclear how Sana Securitydefines "Vista-compatible" code.

Future work:

Currently, there are some limitations in the framework that I wouldlike to address before a second iteration of these tests. The mostimportant feature I'd like address is the ability to segregate thevirtual machine instance for the execution of each binary, essentiallyreturning the environment to a previously known state. Too, theframework has no feasible way of detecting user-mode hooks or stoppinga process from rebooting the virtual machine. This would allow us toidentify general eavesdropping utilities and would stop any maliciouscode from disrupting our monitoring. I would also really like to doaway with the virtual machine dependency.

Further reading: