Skip to content
Naked Security Naked Security

PDF encryption standard weaknesses uncovered

Researchers have discovered weaknesses in PDF encryption which could be exploited to reveal the plaintext contents of a file to an attacker.

You would be forgiven for thinking that encrypting PDFs, before they are stored or sent via email, keeps their contents away from prying eyes.

But according to researchers in Germany, it might be time to revisit that assumption after they discovered weaknesses in PDF encryption which could be exploited to reveal the contents of a file to an attacker.

Dubbed ‘PDFex’ (PDF exfiltration), the weaknesses documented in Practical Decryption exFiltration: Breaking PDF Encryption by researchers from Ruhr University Bochum and the Münster University of Applied Sciences, offer two attack methods, each with three variants that depend on which PDF viewer is used to open a target document.

Attack #1 – direct exfiltration

The PDF standard ships with native AES symmetric encryption which secures documents using a password communicated to the recipient (arguably a weakness in itself) or, in some installations, through public key encryption.

However, the researchers quickly discovered a hole in this method, so glaringly obvious that it’s surprising nobody’s noticed it before. The PDF standard allows for partially encrypted documents that include a mix of both encrypted and unencrypted sections, and does not include integrity checking. This means an attacker can add additional sections or interactive Actions to an encrypted PDF without raising any alarms, said the researchers in their overview:

The most relevant object for the attack is the definition of an Action, which can submit a form, invoke a URL, or execute JavaScript.

Actions can be set to run when a document is opened or something within the document is clicked on, and send the decrypted contents to an attacker’s server.

Although conceptually simple, using something like PDF form submission or JavaScript to do this turns out to be complex.

First, the attacker would need to intercept or obtain a copy of the PDF in order to insert the pointers, and would need a channel through which to exfiltrate the stolen data without that being noticed, detected or blocked.

Another unpredictable limitation is the way numerous different PDF viewers process things like JavaScript in order to enforce security.

Attack #2 – CBC gadgets

Because not all PDF viewers support unencrypted content in PDFs, the researchers tried a more involved technique that exfiltrates plaintext by manipulating the PDF’s cipher block chaining (CBC) encryption format using something called ‘malleability gadgets’.

In this attack, the researchers exploit the lack of integrity protection to modify the encrypted contents directly:

…an attacker can stealthily modify encrypted strings or streams in a PDF file without knowing the corresponding password or decryption key. In most cases, this will not result in meaningful output, but if the attacker, in addition, knows parts of the plaintext, they can easily modify the ciphertext in a way that after the decryption a meaningful plaintext output appears.

Fortunately – from an attacker’s point of view – the PDF AESV3 (AES256) specification defines 12 bytes of known plaintext…

The researchers tested both techniques against 27 popular PDF viewers and editors to see how successful they would be under real-world conditions, finding a surprising amount of variation between programs.

Nevertheless, all 27 were vulnerable to at least one variant on either attack method, including Adobe Acrobat, Foxit Reader, Evince, Okular, Chrome, and Firefox.

What does this mean?

As with other formats that share some of the PDF’s security characteristics (XML, S/MIME, and ePub for instance), there is clearly some work to do in terms of AES-CBC’s integrity protection.

This must be fixed in future PDF specifications and any other format encryption standard, without enabling backward compatibility that would re-enable CBC gadgets.

Thanks to the widespread use of TLS encryption, it would be difficult for attackers to intercept and modify PDFs as they move across a network or the internet, whether the documents themselves are encrypted or not. However, PDFs at rest have been shown to be vulnerable.

If you think it’s worth encrypting your PDFs and you want to be sure they haven’t been tampered with, use a respected third party encryption tool, like GPG.

3 Comments

Does this mean Sophos is going to move away from this method for encrypting PDF documents for their secure email solutions? Whole lot of PDF’s chilling in external mailboxes from our company for starters.

Adobe scores again! Sure, other developers took a hit, but PDF was Adobe’s baby and I’m sure most of the code for the other products was based on reverse engineering.

As far as I know, that “12 bytes of known plaintext” is derived from Algorithm 10 as defined in the specification. It applies to how the /Perms field in the Encryption dictionary is constructed starting with the /P value. I’d like to see a PoC regarding Attack #2 before I buy into being able to just arbitrarily manipulate encrypted data until you get some meaningful plaintext. Because if the only meaningful plaintext you can get is from the /Perms field…. who cares?

Comments are closed.

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?