Didier Stevens

Wednesday 6 May 2009

A Very Brief History of Foxit Reader and JavaScript

Filed under: PDF,Vulnerabilities — Didier Stevens @ 23:45

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:

20090507-010837

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:

20090507-013043

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.

Shellcode 2 VBScript

Filed under: Hacking,My Software — Didier Stevens @ 9:06

I had not posted my Python script to convert shellcode to VBScript, so here it is.

Download:

shellcode2vbscript_v0_1.zip (https)

MD5: AAB0431127C657C9A3EF67E1C73E6711

SHA256: D1CDDAFCB734EC3F35E558DECFF2EDB73DC0C394936814B602B605F09DE4A5E5

Monday 4 May 2009

Quickpost: Using Your Poken as a Lowcost LF RFID Detector

Filed under: Hardware,Quickpost,RFID — Didier Stevens @ 0:01

Here’s an alternate use for your Poken: use it to detect 125 kHz RFID readers. Its led will blink red when you bring it next to a LF RFID reader (125 kHz). It will not react with a 13.56 MHz reader; and I haven’t tested with a 134.2 kHz reader.

20090503


Quickpost info


Wednesday 29 April 2009

Quickpost: Disarming a PDF File

Filed under: My Software,PDF,Quickpost — Didier Stevens @ 16:52

This is a beta release of my new version of PDFiD tool because Adobe recommends disabling JavaScript to protect yourself against the new vulnerabilities in JavaScript functions getAnnots() and spell.customDictionaryOpen().

PDFiD version 0.0.6 has several new features which I’ll explain in a later post. Now I want to explain the disarm feature. Disarm will disable JavaScript inside the PDF document.

Command “PDFiD -d document.pdf ” will analyze the PDF document and generate a new version called document.disarmed.pdf.

In this new version, names /AA, /OpenAction, /JS and /JavaScript have their case swapped (/aa, /oPENaCTION, /jsand /jAVAsCRIPT). As the PDF language is case sentitive, these new names have no meaning and therefor the automatic actions and scripts are effectively disabled. All PDF readers I’ve used just ignore unknown names, they don’t generate and error or stop rendering the document.

This substitution trick will not work if the actions and scripts are hidden in object streams (/ObjStm) and could render a document unreadable if encryption is used.


Quickpost info


Monday 27 April 2009

Quickpost: Black Hat Europe 2009

Filed under: Hacking,Quickpost — Didier Stevens @ 5:46

Black Hat Europe 2009 is over for more than a week now, and my laptop has undergone yet another lobotomy.

My training by Saumil Shah was excellent! Highly recommended if you want to learn exploit development without reversing.

I didn’t attend a lot of briefings, the subjects were less interesting to me than past years. But I did a lot of networking, I met many interesting people. I had lunch with Moxie Marlinspike, the author of SSLStrip. He has interesting viewpoints: did you know he started to develop SSLStrip in 2002? It’s only because he was done experimenting with it that he decided to disclose! And we share a common interest in CRASS.

Thanks to everybody I met at BH, the networking was excellent! I estimate I distributed 50 of my PDF stickers 😉 . You gave me a lot of ideas that will require even more time to develop. Like past years, I got a new stego idea but this time, I’m reserving it for Brucon‘s hacker challenge. You’ll have to wait for October for the disclosure.

This was the last Black Hat Europe in Amsterdam, next edition will be in Barcelona (Ero’s town). Did you know that regular security bloggers can get press access?

This year was also the first time I had a 2D-barcode on my badge:

bh2009-pdf417

The above picture doesn’t actually show my real barcode, but one I made for this post. My real barcode contains my business coordinates. A hint if you want to find out what’s on this one: it’s a PDF417 barcode (this PDF stands for Portable Data File, not Portable Document Format).

Tuesday 21 April 2009

PDFiD On VirusTotal

Filed under: Malware,My Software,PDF — Didier Stevens @ 16:59

I know my posts here are rather emotionless, and that’s how I prefer them for this blog.

But this time, I’m very proud and I’m not hiding it: my PDFiD tool is now running on VirusTotal!

Thanks for your work Julio!

PDFiD will give you statistics of some very basic elements of the PDF language. This helps you decide if a PDF could be malicious or not.

pdfid-virustotal

Sunday 19 April 2009

Update: XORSearch V1.4.0

Filed under: My Software,Update — Didier Stevens @ 16:43

Miles Wolbe was looking for some strings in a Dell BIOS update; it took him some time to figure out they are ROT-1 encoded.

I updated my XORSearch tool to support ROT encoding.

Tuesday 31 March 2009

PDFiD

Filed under: Malware,My Software,PDF — Didier Stevens @ 7:08

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 🙂 .

20090330-214223

Thursday 26 March 2009

Poken Peek

Filed under: Encryption,My Software,RFID — Didier Stevens @ 7:35

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.

20090325-175438

When plugged into a PC, the Poken simulates a USB memory stick containing 3 files:

  • autorun.inf
  • help.txt
  • Start_Poken.html

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).

20090325-180505

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.

20090325-175502

Monday 23 March 2009

35 Year Old Puzzle

Filed under: Puzzle — Didier Stevens @ 17:26

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
« Previous Page — Next Page »

Blog at WordPress.com.