For a few days, the security ecosystem has been focusing on the Stuxnet malware and its innovative propagation method using a previously unknown 
vulnerability in the way Windows handles icons in LNK files. In Windows 7, using AppLocker helps mitigates the flaw.
In a LNK file, it is possible to point an icon resource to a malicious DLL. When the Windows shell will display the icon, it will load the DLL and execute the code in its main function. Unfortunately, Microsoft recommendations are either not applicable (disable all shortcut icons!), or only cover one exploitation vector (disabling the WebDAV client, which doesn’t prevent the vulnerability from being exploited by USB drives or remote SMB shares).
Some suggested to use SRP to restrict the execution of binaries (EXE and DLL) to the C: drive. This is better, but can block legitimate binaries executed from other drives (which is likely to happen in a corporate environment). Of course, it is possible to whitelist other drives as well, but this reopens the SMB and WebDAV exploitation vectors…
That’s why it seems that the best solution to protect against this vulnerability would be to block every unknown DLL, which is exactly what AppLocker was designed for. However, there is a huge counterpart: this only works on Windows 7 and 2008 R2 (using SRP can thus be useful on older systems).
AppLocker is an evolution of SRP which can be used to block PE binaries, MSI installers and VBS scripts (among others), with customizable rules. The advantage of AppLocker over SRP is its ability to write rules specific to DLLs, without tempering with the execution of traditional EXE binaries, which perfectly matches our case.
After running the “Application identity” service required to apply the rules, DLL rules have to be explicitly allowed by checking the following checkbox (and bypassing warnings…):
Default rules can then be applied to protect the system; don’t forget to remove the last rule as it allows any administrator to load any DLL. From now on, DLLs can only be loaded from C:\Windows and C:\Program Files.
After a (now unsuccessful) attempt to exploit the vulnerability, a 8004 event appears in Applications and services log -> Microsoft -> Windows -> AppLocker, indicating that the DLL has been blocked:
This solution is not perfect as legitimate DLLs can no longer be loaded from other directories, including remote ones. However, it is expected that this drawback has less consequences than blocking every remote EXE.
View full post on CERT-LEXSI Weblog
