he media surrounding the effectiveness of Windows Vista's new security features has (in my opinion) just begun. Microsoft's reach is well beyond that of any other software vendor in the world, and with this achievement comes fame, power, and a corporate life under a microscope. To honor this tradition, I previously posted
an entry about the effects of malicious code executed under a default Vista environment; if you haven't read it, you are certainly encouraged to. This research has now been completed and this new entry should serve as a compliment to my previous post. A paper detailing the full research has been made available
here.
The outcome of the research:
In my previous blog, I mentioned that about seventy percent of the malicious code executed under Vista loaded successfully and executed without a crash or runtime error. After completing the research, and increasing the number of binaries, the percentage slightly decreased to 58 percent. The term Successful Execution simply means the binary was mapped into memory by the Windows loader and began executing instructions at the derived entry point. It does not, however, indicate the malicious code successfully compromised the system's integrity. Table 1 illustrates the classifications used along with the results of the research in no particular order.
Table 1: Result statistics
The table's structure consists of five columns: column one indicates the threat classification, column two contains the total number of binaries derived for this particular class, column three indicates the number of binaries that successfully began execution, column four indicates the number of binaries that failed to execute completely, and column five contains the number of binaries that successfully survived a reboot from the total number of execution attempts.
From the results, we were able to identify which security components of Vista may be subverted to perform operations specifically disallowed. One example is Vista’s firewall, by default it is configured to disallow all third party and untrusted network communications unless the user clicks the unblock button. This feature, if slightly enhanced, poses a great limitation for malicious code looking to back door a host. Unfortunately, the unblock button may be accessed with the same privilege level as a standard user. This configuration of privileges creates a point of vulnerability that undermines the effectiveness of the firewall’s policy in Windows Vista. In effect, malicious code can automate the unblock process by simply sending a message to the firewall pop-up dialog box via the SendMessage API call. A second example deals with surviving a system restart, and is discussed in the full research paper referenced above.
Other security concerns exist, however they are not explicitly said to be prohibited by Vista, for example by default, UAC allows a standard user to call the following functions, which may allow an attack to perform keylogger and sniffer-like operations.
SetWindowsHookEx, made available in earlier versions of Windows, allows applications to hook other API calls at runtime by injecting a user-specified call into a hook chain. Thus, allowing an attacker to hijack sensitive information from a user’s active desktop session. However, an attacker may only infect processes running under the UAC environment.
GetAsyncKeyState, when used in conjunction with DLL injection methods, may allow an attacker to monitor keystrokes and other interactive activity on a desktop. Again, the same restriction applies to this method where an attacker can only infect the current user.
Previous related work:
Although no analogous research has been done, in an interview by IT Pro, Sana Security was quoted for claiming that 38 percent of the malicious software currently in circulation is already Vista-compatible. Considering 38 percent is a feasible subset of the 58 percent total obtained by our testing, Sana Security's claims are within reasonable range. It is, however, unclear how Sana Security defines "Vista-compatible" code.
Future work:
Currently, there are some limitations in the framework that I would like to address before a second iteration of these tests. The most important feature I'd like address is the ability to segregate the virtual machine instance for the execution of each binary, essentially returning the environment to a previously known state. Too, the framework has no feasible way of detecting user-mode hooks or stopping a process from rebooting the virtual machine. This would allow us to identify general eavesdropping utilities and would stop any malicious code from disrupting our monitoring. I would also really like to do away with the virtual machine dependency.
Further reading:
Orlando Padilla, "The Impact of Malicious Code on Windows Vista":
http://www.symantec.com/avcenter/reference/Impact_of_Malicious_