I updated my .LNK template with info I got from comments from WndSks and Forrest Gump. This new version identifies well-known Shell GUIDs:
Quickpost info
Wednesday 18 August 2010
Sunday 8 August 2010
Quickpost: 2 .LNK Tools
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:\
Quickpost info
Tuesday 20 July 2010
Mitigating .LNK Exploitation With SRP
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:
Sunday 18 July 2010
Mitigating .LNK Exploitation With Ariad
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.
Tuesday 29 June 2010
Quickpost: No Escape From PDF
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.
Quickpost info
Monday 11 January 2010
Adobe Reader JavaScript Blacklist Framework
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.
Adobe Reader JavaScript Blacklist Framework
Monday 2 November 2009
CVE-2009-2979 Or The XML-Bombed PDF
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.
Tuesday 13 October 2009
Update: PDFiD Version 0.0.9 to Detect Another Adobe 0Day
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.
Monday 5 October 2009
Preventing Applications From Starting (Malicious) Applications
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.
Wednesday 6 May 2009
A Very Brief History of Foxit Reader and JavaScript
As I often read questions about Foxit Reader and JavaScript support, I decided to write down this very brief history.
Foxit Reader is a lightweight PDF reader, it consist of exactly one EXE file.
Up to Foxit Reader version 2.1, there was no built-in support for JavaScript. If you needed JavaScript, you had to install a plugin (this was actually just a DLL).
Version 2.1 came with builtin JavaScript support. No more plugin, the DLL was merged into the EXE. But the Foxit developers made a design decision with important security implications: you couldn’t disable JavaScript support. Uptil version 2.1, it was easy to disable JavaScript: don’t install the plugin. But with version 2.1, JavaScript was embedded.
Version 2.2 and 2.3 didn’t change this, that’s what prompted me to publish a hack to disable JavaScript.
We had to wait for version 3.0 to be able to disable JavaScript:
But at least, this preference was implemented as it should. Once you disable JavaScript, you get no warnings you’ve disabled JavaScript. This is unlike Adobe Reader:
If you disable JavaScript in Adobe Reader, you’ll be proposed to re-enable it each time you open a PDF document with JavaScript. This is extremely confusing for the average user.
Foxit has started to provide an iFilter. I hope Foxit will never integrate this iFilter in their Foxit Reader setup program, because iFilters increase the attack surface.
