I’m writing this quickpost just in case you hadn’t figured this out for yourself: the techniques I described to protect machines from the .LNK vulnerability also help you mitigate the DLL preloading issue.
The .LNK vulnerability mitigation examples I gave with Ariad (no file execute) and SRP prevent loading of DLLs from untrusted locations (USB sticks, network drives, …). These will also prevent DLLs from loading from untrusted sources in the case of DLL Preloading exploits.
I updated my .LNK template with info I got from comments from WndSks and Forrest Gump. This new version identifies well-known Shell GUIDs:
Microsoft has issued an emergency patch (MS10-046) for the .LNK file vulnerability (CVE-2010-2568).
I’m releasing two small tools I developed to help me investigate this vulnerability.
First one is a 010 Editor template file for the .LNK binary file format.
Second one is a ClamAV signature file to find all .LNK shortcuts that load a DLL (malicious or benign).
To scan your drive C, issue command
clamscan.exe -d LNK-CPL-CVE-2010-2568.ndb -l scan.log -r c:\
As I’ve used Software Restriction Policies (SRP) on several occasions in my blogposts, and several people have suggested using SRP to protect against .LNK exploitation as an alternative to Ariad, I’ll describe how to configure SRP for the first time on a workstation that is not a member of a domain. For domain members, you have to configure SRP in the GPO on the domain controller.
Start the Local Security Policy manager from Control Panel / Administrative Tools:
Software Restriction Policies need to be defined the first time:
We exclude our system drive (C:) from being restricted (add other drives if you have more):
To protect against .LNK exploitation, we need to restrict DLLs too, not only EXEs:
And finally, switch from blacklisting to whitelisting:
After configuring SRP, execute a logoff/logon to apply them immediately.
From now on, only executables on your C: drive will be allowed to run.
.LNK exploitation from removable media is blocked:
Today I tested @Ivanlef0u ‘s .LNK PoC with my latest Ariad tool.
I adapted the PoC to work on a CD-ROM for drive D. When you load the CD-ROM with the PoC (I use an ISO file inside a VM) and take a look at DbgView’s output, you’ll notice that payload gets executed:
With Ariad installed on the machine in its default configuration (just block \autorun.inf), the PoC still works:
But configuring Ariad to block access to executables (this includes .LNK) prevents the PoC from executing:
Access to the .LNK file is denied, and Windows Explorer can’t start the payload.
And configuring Ariad to prevent files to be mapped in memory (this is something done by Windows with executables) also prevents the PoC from executing:
This time, access to the .LNK file is not denied, but dll.dll is prevented from loading into memory, thus again preventing the payload from executing.
You can use Ariad if you want to mitigate attacks with these shortcut links until Microsoft releases a patch. As it is expected that Microsoft will not release a patch for Windows XP SP2, Ariad can offer permanent mitigation.
Be sure to read Ariad‘s documentation before using it.
Adobe has released a new Adobe Reader version with a fix for my /Launch action PoC PDF.
Before version 9.3.3:
Since version 9.3.3:
Not only is the dialog box fixed, but the /Launch action is also disabled by default.
The JavaScript Blacklist Framework is a security feature Adobe released with Adobe Reader and Acrobat versions 8.1.7 and 9.2.
When you’re in a case where you need to use Adobe Reader and you can’t disable JavaScript, the JavaScript Blacklist Framework can help you mitigate zero-days in JavaScript API functions by disabling the vulnerable functions.
I produced a video where I disable util.printf:
Notice that when I blacklist util.printf, the script still executes until the blacklisted function util.printf is called. At that moment, the script is cancelled and the user is warned.
On Windows, you can blacklist functions by adding them to registry value tBlackList (HKLM\SOFTWARE\Policies\Adobe\product\version\FeatureLockDown\cJavaScriptPerms\tBlackList). To blacklist more than one function, use the same registry value and separate the functions by the pipe-character (e.g. Util.printf|Collab.getIcon). Pay attention to the fact that the framework is case-sensitive (e.g. Util.printf is correct, util.printf is not correct).
The framework is impervious to bypassing with some basic obfuscation techniques found in malicious PDFs (eval(“util.printf… ; x = util.printf; x(“… ).
It’s too bad that blacklisting is limited to the JavaScript API; the functions to blacklist must be in the form <object-name>.<function-name>. Otherwise we would be able to blacklist some global functions of the JavaScript language that are often used in malicious PDF files, like unescape. According to the ECMAScript specification, unescape is a member function of the Global Object. I tried several ways to blacklist it (unescape, .unescape, this.unescape, Doc.unescape, …), but failed.
If you really want to disable unescape, you could do this by patching the JavaScript plugin EScript.api. Maybe I’ll post a method to do this in-memory with my basic process manipulation tool kit.
The Extensible Metadata Platform is an Adobe standard to represent metadata with XML.
More than a year ago, I added an XML-bomb to XMP-data inside a PDF document:
As this made Adobe Reader 8 & 9 crash, I reported it to Adobe. It has been fixed with the last patch cycle.
Why do I disclose the details of this vulnerability? Because XMP is not only intended to be used in PDF documents, but many other file formats. So be sure to check your software for this vulnerability.
PDFiD is updated to detect the latest Adobe 0day, CVE-2009-3459.
I’ll provide more details in an upcoming post, just now for know that PDFiD detects a /Colors name followed by a very big number (larger than 2^24 or 16777216).
You can download PDFiD here.
Another very effective way to prevent malicious documents from infecting PCs, is to prevent vulnerable applications from starting other applications. As almost all shellcode found in malicious documents in-the-wild (again, I’m excluding targeted attacks) will ultimately start another process to execute the trojan, blocking this will prevent the trojan from executing.
This is an old idea you’ll find implemented in many sandboxes and HIPS. I added a new DLL to my basic process manipulation tool kit to prevent applications from creating a new process. Loading this DLL inside a process will prevent this process from creating a new process. I’ll explain the technique used in my DLL and how to load it in vulnerable applications in upcoming blogposts, but I want to start with showing how it prevents malicious documents from infecting a PC.
When the DLL is loaded inside a process, it will patch the Create Process API to intercept and block calls to it:
As a first test, we’ll use my eicar.pdf document.
Clicking the button will save the eicar.txt file to a temporary folder and launch the editor.
Adobe Acrobat reader will warn you when an application is to be launched:
But when you accept, the editor will be prevented to execute:
That’s because the DLL intercepted and blocked the Create Process call:
As a second test, let’s use a real malicious PDF document. The hooks installed by the DLL prevent it from executing the trojan:
Adobe Reader starts and then just crashes, without spawning another process:
When opening the same malicious PDF, but without the protecting DLL, the machine gets trojaned (execution of 1.exe and Internet Explorer):
This simple way of preventing applications from launching other applications comes with some drawbacks. For example, the Check Update function in Adobe Reader will not function anymore.
When you have a sandboxing system of HIPS installed on the machines you manage, check if you can use it to prevent vulnerable applications from starting other applications. If it doesn’t provide such a feature, try the new DLL I’ll be posting in the new version of bpmtk.
