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.
In search of a new trick for that Windows 7 Launch Party you’re invited to? 
Here’s one:
You can download a beta version of my UserAssist tool here. Soon I’ll be posting a final version with details and source code.
I’ve updated my WhoAmI? Firefox add-on for Firefox version 3.5.
You can download it here or get it from the Mozilla site. I’ve nominated it to leave the Sandbox. If you use it, please post a review on the Mozilla page to help it on its way out of the the Sandbox (or keep it there if it’s too buggy).
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.
I wasn’t going to mention SAFER to restrict the rights of an application, because Software Restriction Policies can be bypassed. But a Tweet by Edi Strosar made me review my viewpoint. In this particular case, bypassing SRP is a non-issue, because the user is already local admin!
Software Restriction Policies allow you to force specific applications to run with a restricted token. As Michael explained it with AD GPOs, I’ll show it with local policies.
Enable SAFER policies for SRPs by adding DWORD registry key Levels (value 0×31000) to HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers:
Start the Local Security Policy administration tool and go to the Software Restriction Policies. You’ll have to create new policies if this is the first time you configure SRPs.
Create a new rule in Additional Rules. We’ll identify the application to restrict by its path and name, so create a Path Rule:
For the security level, select Basic User:
If you have no Basic User option, you forgot to update the registry before launching the administration tool:
Select the application to restrict:
This rule will force Adobe Reader to run with a restricted token:
Writing to SYSTEM32 is denied:
Almost all shellcode I see in malicious documents (PDF, Word, Powerpoint, …) found “in the wild” does the following:
This infection method only works if the user is local admin. If the exploited program has no rights to write to SYSTEM32, the shellcode will just fail and the trojan will not infect the machine.
To protect yourself and/or your users against this type of attack (I’m not talking about targeted attacks), restrict the user rights. Windows Vista and later versions do this for you with UAC, even if you’re an administrator.
On Windows XP, you have to use a normal user account in stead of an admin account to achieve this. But running non-admin on Windows XP is not always easy. If you really need to allow admin rights on Windows XP, you can still prevent high-risk applications (like Adobe Acrobat and Microsoft Office) from having full control over the system by restricting their rights. This is done by using a restricted token for the processes of these applications.
There are 2 popular tools to launch programs with a restricted token:
Both tools create a restricted token (by removing privileges and denying groups that provide local admin rights) and then launch the target program with this restricted token.
It’s not always easy to launch a program with DropMyRights, as there are many ways a program can be launched on Windows. For example with a file-type association or from a browser. To help you configure Windows to always restrict the rights of a specific program, StripMyRights also support the “Image File Execution Options” method with the /D option. The “Image File Execution Options” is designed to allow you to launch a program automatically inside a debugger. In the “Image File Execution Options” registry key, you specify the debugger to use. But this can really be any executable.
Example: to restrict the rights of Adobe Reader, add StripMyRights to the AcroRd32.exe Image Execution path like this:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\acrord32.exe] "Debugger"="StripMyRights.exe /D /L N"
This way, each time AcroRd32.exe is executed, StripMyRights executes first, creates a restricted token and then launches AcroRd32.exe with this restricted token.
But executing StripMyRights before executing the target application doesn’t always yield satisfactory results, sometimes it breaks the application, because of the broken process tree.
That’s why I developed an alternative, LowerMyRights.dll, to be presented in an upcoming blogpost.
This is a little project I’m working on for Brucon:
This is an Arduino with a WiFi adapter (WiShield), an LCD and a gas sensor (senses gases like ethanol).
What it does: the Arduino reads the sensor (uncalibrated for the moment), displays its value on line 1 of the LCD and also servers it on a web page (with an embedded webserver connecting to the WiFi network via the WiShield).
If the sensor read-out is 900 or more, a LED is turned on.
And I can send a message via the webserver to line 2 of the LCD.
The problem I had to solve: the LCD didn’t work when the WiShield was operating.
The cause: the WiShield library and the LCD library use some common pins.
Solution: change the pin assignment in the LCD library code (LCD4Bit.cpp):
// --------- PINS -------------------------------------
//is the RW pin of the LCD under our control? If we're only ever going to write to the LCD, we can use one less microcontroller pin, and just tie the LCD pin to the necessary signal, high or low.
//this stops us sending signals to the RW pin if it isn't being used.
int USING_RW = false;
//RS, RW and Enable can be set to whatever you like
int RS = 1;
int RW = 11;
int Enable = 0;
//DB should be an unseparated group of pins - because of lazy coding in pushNibble()
int DB[] = {3, 4, 5, 6}; //wire these to DB4~7 on LCD.
//--------------------------------------------------------
And don’t forget to delete LCD4Bit.o before recompiling the code. The Arduino IDE doesn’t check dependencies of libraries when compiling.
And yes, once calibrated, you should be able to use this alcohol gas sensor to prevent drunk e-mailing But you’ll need to add a sensor to verify you’re actually blowing into the alcohol gas sensor. For example a gas pressure sensor.
I know, I love a bit of mischief
Wim renamed his “old” Twitter account @domgingelom to the “new” @wimremes. And then I promptly registered @domdingelom…
Did some Tweeting under an assumed name…
And then gave the “new” @domdingelom to Wim.
Here’s one way to solve the Brucon WiFi Puzzle: open the capture file with Wireshark.
The capture file contains one beacon frame for the brucon09wifi network. If you’re a bit familiar with beacon frames, one tag will stand out: the vendor specific tag which Wireshark can’t interpret because it’s from a vendor it doesn’t know.
The hidden data is inside the vendor specific tag. Select it and export the selected bytes:
How do you decode this data? You can try all types of encoding and encryption schemes, but to prevent you from wasting time trying countless possibilities, I’ve given you a hint in the name of the vendor: XortecOy. The data is XOR-encrypted. And the key is tecOy.
Open the saved bytes with Cryptool:
And apply XOR-decryption with key tecOy:
Et voilà!
