I’ve developed a new tool to triage PDF documents, PDFiD. It helps you differentiate between PDF documents that could be malicious and those that are most likely not. I’ve kept the design very simple (it’s not a parser, but a string scanner) to be fast and to avoid exploitable bugs.
VirusTotal will included it if Julio Canto is satisfied with the tests 🙂 .
OK, after getting side-tracked by /JBIG2Decode PDFs, let’s get back on the smartcard and RFID track.
The Poken is a little USB stick you keep on your keychain. You link it to your online identities. To befriend other Poken owners, you just have to hold your Pokens together for a second, and they’ll exchange IDs through RFID. The Poken is popular in The Netherlands, not only among children, but adults too. No more need to exchange business cards.
My 2 guinea pig Pokens were delivered last week. If you want to meet them in person, come to Brucon for my workshop.
When plugged into a PC, the Poken simulates a USB memory stick containing 3 files:
Start_Poken.html (started by autorun.inf or by you) will navigate to the Poken website and automatically login to your Poken account. It contains a URL with the necessary data to identify you to the Poken website. Having your Poken lost or stolen is an issue (as explained in the Poken FAQ), because of the auto-login feature.
But loosing physical control over your Poken is not the only way to get your account compromised. The URL is actually the only thing needed to gain access to your account. And because this URL uses the HTTP protocol (the Poken site doesn’t support HTTPS), it’s easy to intercept on insecure networks. Insecure networks are not the only issue. Because all the data is in the URL, it will also leave a copy of the URL in different systems on a network, for example in proxy logs.
To prevent unwanted access to your account, disable auto-login for your account (it was enabled by default for my account).
I was told by the Poken help-desk that they will support HTTPS in the future. But the current Pokens are hard-coded to use HTTP.
When I read the Poken FAQ stating that your data is protected by a “very advanced encryption method” (sic), I interpret that all the data is encrypted with a cipher like AES.
But this isn’t the case. Not all the data is encrypted. Your Poken ID (a 4-byte integer that uniquely identifies your Poken) is not encrypted. And neither are the IDs of the Pokens you befriend. Your personal account data entered on the Poken site is not stored on your Poken. The link between a Poken ID and an account is kept in the database of the Poken web site and is visible for its owner.
The data of a Poken is stored in the URL in file Start_Poken.html:
URL=http://p.poken.ch/u/ABCDEFGH...
The path (ABCDEFGH…) is encoded in BASE64 (more precisely, a BASE64 variant compatible with URL encoding). I’ve identified the purpose of some of the first 96 bytes of data. It contains your Poken ID and various counters. 2 4-byte integers are changing with each use and appear to be random. These could be a (cryptographic) hash to guarantee the authenticity of the Poken data.
The rest of the data is used to store the IDs of the Pokens you befriended. There is room for 64 records (friends) of 16 bytes each. If you befriend more than 64 Pokens without connecting to the Poken site, the old records get overwritten by new records (like in a circular buffer) and you lose friends.
I’ve a tip for you: if you can’t connect to the Poken web site while befriending more than 64, connect your Poken to your laptop and backup file Start_Poken.html. Later, when you’ve access to the Poken site, open the backuped files in the order you backed them up. Each file will update your data. And after that, use your Poken.
The 16 byte record contains the befriended Poken ID, a status byte (discreet befriending), 3 bytes that look like a timestamp and 8 bytes that appear to be random. These 8 bytes could be a (cryptographic) hash to guarantee the authenticity of befriended Poken data and prevent spoofing or replaying.
So not all the data is encrypted: the Poken IDs are in cleartext. As the link between a Poken ID and the account is safely protected by the Poken web site, even if your data is stolen or intercepted, not much would be disclosed. Traffic analysis could be applied if data of several Pokens is intercepted during an event. Since most people make their friend list public, they shouldn’t care about the interception of the Poken IDs they befriended anyways.
And how about the strenght of the encryption? Well, contrary to what is stated in the Poken FAQ, I don’t believe it is state of the art. Modern, secure ciphers like AES work with blocks of at least 128 bits (16 bytes). In the Poken data, we have blocks of maximum 64 bits (8 bytes). 64 bit encryption is not state of the art anymore. For comparison, DES (and 3DES) work on 64 bits block. You shouldn’t use DES anymore, because it can be brute-forced, although that’s still not trivial to do.
Conclusion: the biggest risk of using a Poken is getting your account compromised, but this can be mitigated. And the encryption of the data on a Poken is not designed to protect your data, but to prevent fraud with the befriending process. The cipher isn’t AES or an equivalent cipher. Yet it is possible to build a small USB device that uses AES to encrypt all data: the YubiKey does it.
Here’s a 25 35 year old puzzle (it’s not mine). I’m curious if you’ll find the solution without using Google.
First one to post a comment with the solution gets a sticker (and I’ll have “PDF – Penetration Document Format” stickers soon). But play fair and don’t post your solution if you just Googled the bit sequence.
00000010101010000000000001010000 01010000000100100010001000100101 10010101010101010101001001000000 00000000000000000000000000000001 10000000000000000000110100000000 00000000000110100000000000000000 01010100000000000000000011111000 00000000000000000000000000000110 00011100011000011000100000000000 00110010000110100011000110000110 10111110111110111110111110000000 00000000000000000001000000000000 00000100000000000000000000000000 00100000000000000000111111000000 00000001111100000000000000000000 00011000011000011100011000100000 00100000000010000110100001100011 10011010111110111110111110111110 00000000000000000000000001000000 11000000000100000000000110000000 00000000100000110000000000111111 00000110000001111100000000001100 00000000000100000000100000000100 00010000001100000001000000011000 01100000010000000000110001000011 00000000000000011001100000000000 00110001000011000000000110000110 00000100000001000000100000000100 00010000000110000000010001000000 00110000000010001000000000100000 00100000100000001000000010000000 10000000000001100000000011000000 00110000000001000111010110000000 00001000000010000000000000010000 01111100000000000010000101110100 10110110000001001110010011111110 11100001110000011011100000000010 10000011101100100000010100000111 11100100000010100000110000001000 00110110000000000000000000000000 00000000001110000010000000000000 01110101000101010101010011100000 00001010101000000000000000010100 00000000000011111000000000000000 01111111110000000000001110000000 11100000000011000000000001100000 00110100000000010110000011001100 00000110011000010001010000010100 01000010001001000100100010000000 01000101000100000000000010000100 00100000000000010000000001000000 00000000100101000000000001111001 111101001111000
My previous blogpost showed how minimal user interaction can still get a malicious PDF document to infect a machine. Remembering F-Secure’s misadventure with .WMF and Google Desktop Search, I took some time to look at Windows Indexing Service. The news is not good. This time, I can get a PoC PDF document to trigger the /JBIG2Decode bug without any user interaction whatsoever. And the bug happens in a process running with Local System rights!
On a Windows XP SP2 machine with Windows Indexing Services started and Adobe Acrobat Reader 9.0 installed, there is absolutely no user interaction required to trigger the /JBIG2Decode vulnerability. When the PoC PDF file is on the disk, it will be indexed by Windows Indexing Services and the buggy /JBIG2Decode code will be executed.
When Adobe Acrobat Reader 9.0 is installed, it also installs an IFilter (AcroRdIF.dll). This COM object extends the Windows Indexing Service with the capability to read and index PDF documents. When the Windows Indexing Service encounters a PDF file, it will index it. The content indexing daemon (cidaemon.exe) calls the Acrobat IFilter (AcroRdIF.dll) which loads the Acrobat PDF parser (AcroRD32.dll). If the PDF document contains a malformed /JBIG2Decode stream object, it will result in an access violation in the instruction at 0x01A7D89A.
In other words, if you’ve a malicious PDF document on a machine with Windows Indexing Services, it can infect your machine. And you don’t need a user to open or select the PDF document.
The good news is that Windows Indexing Services is not started on a default Windows XP SP2 install. Update: Although Windows Indexing Services is not on by default, after you’ve executed a search as local admin, you’ll be asked if you want “to make future searches faster”. If you answer yes, Windows Indexing Services will be automatically started.
The bad news is that Windows Indexing Services runs under the local system account on Windows XP SP2. This results in a privilege escalation.
Consider a Windows machine with Windows Indexing Services running, Adobe Acrobat reader installed and a file sharing service (FTP/IIS/P2P/…). Uploading a specially crafted PDF document to this machine will give you a local system shell.
To disable Windows Indexing Services’ capability to index PDF documents, unregister the IFilter: regsvr32 /u AcroRdIf.dll
But IFilters are also used by other software:
My PoC PDF file also triggers in /JBIG2Decode in Windows Desktop Search (I tested version 4.0). But Windows Desktop Search has a better security architecture than Windows Indexing Service. Although the service runs under the Local System account, the actual calling of the IFilters is done in a separate process that runs under the Local Service account (this account has less privileges and can’t take full control of the machine).
I’ve not analyzed other applications using IFilters. If you use ScarePoint (that’s how my wife, who has to work with it, calls it) or another IFilter supporting application and you want to be safe, unregister the Acrobat IFilter.
And don’t forget that, depending on your Windows version and CPU, you’re also protected by technologies like DEP and ASLR.
Google Desktop Search doesn’t use IFilters, unless you’ve installed this plugin to add IFilter support to Google Desktop Search.
Sometimes a piece of malware can execute without even opening the file. As this is the case with the /JBIG2Decode vulnerability in PDF documents, I took the time to produce a short video showing 3 ways the vulnerability can trigger without even opening the PDF document.
The first 2 demos use a “classic” /JBIG2Decode PDF exploit, the third demo uses a new PoC /JBIG2Decode PDF exploit I developed. This PDF document has a malformed /JBIG2Decode stream object in the metadata instead of the page. All PDF documents used have just a malformed /JBIG2Decode stream object, they don’t include a payload (shellcode), neither a JavaScript heap spray.
So how is it possible to exploit this vulnerability in a PDF document without having the user open this document? The answer lies in Windows Explorer Shell Extensions. Have you noticed that when you install a program like WinZip, an entry is added to the right-click menu to help you compress and extract files? This is done with a special program (a shell extension) installed by the WinZIp setup program.
When you install Adobe Acrobat Reader, a Column Handler Shell Extension is installed. A column handler is a special program (a COM object) that will provide Windows Explorer with additional data to display (in extra columns) for the file types the column handler supports. The PDF column handler adds a few extra columns, like the Title. When a PDF document is listed in a Windows Explorer windows, the PDF column handler shell extension will be called by Windows Explorer when it needs the additional column info. The PDF column handler will read the PDF document to extract the necessary info, like the Title, Author, …
This explains how the PDF vulnerability can be exploited without you opening the PDF document. Under the right circumstances, a Windows Explorer Shell Extension will read the PDF document to provide extra information, and in doing so, it will execute the buggy code and trigger the vulnerability. Just like it would when you would explicitly open the document. In fact, we could say that the document is opened implictly, because of your actions with Windows Explorer.
So let me demo 3 circumstances under which a PDF Shell Extension will act and thereby trigger the vulnerability. One important detail before I do this: when the exception occurs in the Adobe Acrobat code, it is trapped by Windows Explorer without any alert. That’s why in the demos, I attached a debugger (ODBG) to Windows Explorer to intercept and visualize this exception. So each time the vulnerability triggers, the view switches to the debugger to display the exception.
In the first demo, I just select the PDF document with one click. This is enough to exploit the vulnerability, because the PDF document is implicitly read to gather extra information.
In the second demo, I change the view to Thumbnails view. In a thumbnail view, the first page of a PDF document is rendered to be displayed in a thumbnail. Rendering the first page implies reading the PDF document, and hence triggering the vulnerability.
In the third demo, I use my special PDF document with the malformed stream object in the metadata. When I hover with the mouse cursor over the document (I don’t click), a tooltip will appear with the file properties and metadata. But with my specially crafted PDF document, the vulnerability is triggered because the metadata is read to display the tooltip…
So be very careful when you handle malicious files. You could execute it inadvertently, even without double-clicking the file. That’s why I always change the extension of malware (trojan.exe becomes trojan.exe.virus) and handle them in an isolated virus lab. Outside of that lab, I encrypt the malware.
YouTube, Vimeo and hires Xvid.
Today I took a closer look at the PDF code of the /JBIG2Decode vulnerability. It doesn’t have to be an XObject, just a stream object with a /JBIG2Decode filter:
This indirect object is all I have to include in my basic PDF document to get a PoC PDF document to crash Adobe Acrobat Reader 9:
On Virustotal, this PoC PDF document is only detected by ClamAV, but it’s no surprise, as most signatures also look for JavaScript and/or a payload. When I use name or stream obfuscation, ClamAV is also bypassed.
You can download my Python program to generate these PoC PDF documents here, it needs the mPDF module of my PDF-tools. Use it to developed better signatures or to test your defenses.
You’re most likely aware of the latest PDF vulnerability in JBIG2 image encoding, more specifically /JBIG2Decode.
Signatures have been released to identify PDF documents exploiting this vulnerability, many of which scan for the /JBIG2Decode string. Remember the canonicalization issue with PDF names I mentioned in a previous PDF post. There are alternate ways to write /JBIG2Decode, for example /JBIG#32Decode is also a valid representation. But many signatures will not match this variant, because the matching engine doesn’t reduce the name to a canonical form (e.g. replace the hexadecimal representation #32 by ASCII character 2) before matching the pattern.
I took this JBIG2 PoC exploit from Milw0rm and let Virustotal take a look at it. Now don’t be mislead by the 5/39 ratio, this doesn’t necessarily mean that most AV products will not protect you from this PoC.
The same PDF document, with /JBIG#32Decode (and some updates to adjust for the increased length), gets 2 detections (SecureWeb-Gateway uses the Avira engine on VT, so both detections are actually from the same engine).
But Avira doesn’t use /JBIG2Decode in its signature (when I replace /JBIG2Decode with /AAAAAAAAA, the PoC still gets detected).
So it looks like the AV engines on Virustotal don’t reduce PDF names to a canonical form.
Didier Stevens 