1 Trillion USD Refund! (PDF Enclosed)

Security researchers have found that it is possible to alter a digitally signed PDF without invalidating its signatures. To demonstrate it, they produced a fake document “refund order” of $1,000,000,000,000 dollars, with a valid signature from Amazon. This sparked my attention, since I was quite sure that they didn’t use some sort of quantum device to break the cryptography involved in the signing process. So what exactly is going on?

The researchers claim to found at least three different ways to, in their words:

… use an existing signed document (e.g., amazon.de invoice) and change the content of the document arbitrarily without invalidating the signatures. Thus, we can forge a document signed by invoicing@amazon.de to refund us one trillion dollars.

That’s not good news if you take into account that the main purpose of digitally signing a document is, well, prevent unauthorized changes in that document. The good news is that you can update your software to fix this flaws because of this research; the main PDF readers companies were given time to fix the issues. The bad news is that if you rely on the signature verification for any sensitive process, you likely want to go back and see if you were using vulnerable software previously and check that documents were correctly validated. I’m thinking about government institutions, banks, insurance companies and so on.

The implications are yet to be seen and probably won’t even be fully known.

There are three classes of attacks that work on different software. I’ll try to go into each one from what I could tell from reading the research.

Universal Signature Forgery (USF)

This attack works by manipulating the signature object inside the PDF file. This object contains the information needed to validate the signature and has inside, among other fields, the offsets of the bytes used to compute the hash of the signature. The hack here is to add content to an already signed PDF but to either remove this range or change it to an invalid value. The result is a PDF that has a valid signature inside but an invalid signature object. The validation logic in some of the tested software defaults to displaying that the signature is valid and drops any warnings about not being able to calculate the hash of the signature.

Incremental Saving Attack (ISA)

In its original form this is more a feature than an attack. PDF allows for incremental saving, that is, adding content to an already existing PDF file. By taking a signed PDF and adding unsigned content, the reader software should notice that the added part is not signed and present a warning. But it is possible to add content in a way that is not compliant to the PDF specification and make the reader not notice that there was content added in the first place when it comes to signature checking and still render the content on-screen.

Signature Wrapping (SWA)

This last attack is arguably the most interesting. Instead of invalidating the byte range offset as in the USF attack, the attacker manipulates a signed PDF file byte ranges field in a way that he can insert content between the signature and the end of file. This makes the software properly calculate the signature hash but it skips the added part since it was not referenced in the byte ranges.

Researchers Conclusions

From the 22 tested desktop readers and seven online validation services, all except three were vulnerable to at least one variation of these attacks. That’s around 90% so your favourite PDF reader is most likely on that list. Of course, maybe you don’t even use the signature verification directly. But your bank might.

Unfortunately, most of the reader software is closed-source, and without access to the source code of the readers, it’s harder for researchers to pinpoint what causes this wrong behaviour. From what they could figure, there are probably two main causes:

The specification is very vague about signatures and especially how to validate them.
The analysed readers are very tolerant about opening, validating and showing malformed PDF files.

It is interesting to see that, in the context of vague specifications, the same errors were being made by many different implementations and companies. The last conclusion seems a bit obvious. Fault tolerant software can be good in many situations but not in signature validation.

This is a scenario where software should definitely not be tolerant at all.

5 thoughts on “1 Trillion USD Refund! (PDF Enclosed)

  1. At the end of paragraph 7:
    “This makes the software to properly calculate the signature hash but it skips the added part since it was not referenced in the byte ranges.”

    I assume this should read ‘this makes the software properly calculate….’

  2. meh. this is sort of a known issue. or at least we knew about it in the early 2000’s when we (government) asked Adobe to come up with a formal spec for ensuring this wouldn’t happen. their response was “meh. we have a bazillion people using PDFs, we’re not going to change it,” so we came up with our own specs and published them somewhere (i think in a NIST 800 document or in a reference to an 800 document) but no one implemented them.

    sic transit gloria mundi – if you do stupid things that people tell you are stupid, you get stupid results.

    1. A proof-of-concept hack is often worth more than a few official government reports. Add in some bad publicity to the mix, and you might be able to make even Adobe come around. It worked here.

      That said, between Flash and Acrobat vulnerabilities, Adobe is probably responsible for half of the bad hacks between 2003 and 2010 (arbitrary numbers, completely made up). They knew it, and they didn’t seem to care.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.