Social engineering for malware – a bright future

Some time ago I wrote a post in which I pondered the deficiencies of the “executable file” definition and the implications for whitelisting products. The problem is that “data” files can also result in actions being taken (and we don’t even need arbitrary code execution type of vulnerabilities for that). The particular example given the post is the one of installer (MSI) files, however here is an other one: VBScripts.

cscript.exe is included in all recent version of Windows by default, so using a simple VBScript which I found via this article we can produce the following elevation prompt:

Observe how any detail which could help us identify the actual script is utterly missing, and also how everything seems to indicate the trustworthiness of the application (after all, it is a “verified” Microsoft program). You can do the same thing with JScript or PowerShell, which is included by default in Windows 7 (yes, I’m running it in a VM, and yes, it is annoying as hell!). Something like Symantec’s UAC extension might help you, since it has the ability to show the command line, but the fraction of people to take a look at it and be able to make a judgment call is very, very small.

In conclusion: UAC made most of the existing malware obsolete, but it is just a question of (little) time until we will see malware adapted to Windows Vista / Windows 7. UAC will improve the code quality somewhat (unfortunately most programmers will think of it the “how to avoid triggering UAC and work around its quirks” way, rather than “how to ensure that our application only uses a minimal set of privileges”), but in the long run it won’t solve the malware problem (or even make a considerable dent in it), just like other technologies won’t. To Microsoft’s credit, they said this, but I’m not sure that all people got the message (and there is also the fact that in many places, Microsoft or not, UAC is listed as something which will make you “more secure”). The remaining role of the UAC will be that IT people can say to their users: “it is your fault! you have been asked if you want to rung the program!”.

PS. And getting by the kernel-mode restrictions is as easy as installing a new root certificate, which is trivial if you have administrative privileges... This means that it will be business as usual, for rootkit writers also.

Update: After poking around with the Symanted UAC tool, it seems that it too is susceptible to a similar attack, and it is maybe worse (because it displays more "green checkboxes" indicating that the command you are about to run is safe).