Technical details of the attacks

We developed three classes of attacks on PDF Signatures. Each attack class abuses a missing signature verification step.

Attack 1: Universal Signature Forgery (USF)

The main idea of USF is to disable the verification by providing invalid content within the signature object or removing the references to the signature object. Thus, despite the fact that the signature object is provided, the validation logic is not able to apply the correct cryptographic operations. Nevertheless, it could be possible that a viewer shows some signature information although the verification is being skipped.

Technically, each PDF Signatures is defined in a PDF signature object, e.g., 5 0 obj. Without going into too much details, this object contains all information necessary to validate the signature. Most importantly for out attacks, the signature object contains a /ByteRange entry, which defines the offsets of the bytes used to compute the hash of the signature. The signature itself is then stored in a /Contents entry as a PKCS7 blob (in most cases).

The USF attack manipulates those entries in the signature obj to confuse the signature validation logic, as shown in the picture below.

USF

If the attack is successful, the view application (or the online validation logic) will display a panel that the signature in the contained PDF is valid and belongs to a specific person or entity.

Attack 2: Incremental Saving Attack (ISA)

This class of attack relies on the PDF feature incremental saving (incremental update). The idea of the attack is to make an incremental saving on the document by redefining the document's structure.

In a legitimate use-case, incremental saving is used, for example, to add annotations to a PDF. The annotations itself are incrementally saved after the original content of the PDF as a new PDF body. Incremental saving is also used for signing a PDF: the signature object is simply appended to the original file content.

The idea of ISA is the following:

The attacker takes a signed PDF. He adds new content (pages, annotations, etc.) and stores them at the end of the file using incremental saving. This is basically not an attack, but a feature of PDF. A vulnerability appears once the signature validation logic does not notice that the file content has been updated, i.e., that new, unsigned content has been added to the file. To achieve this behavior, we identified multiple variants of the attacks as shown below:

USF

Please note that Variant 1 itself is not a real attack vector. It is the intended file structure of a signed PDF that has been updated using incremental saving. Variants 2-4 are not compliant to the PDF specification, e.g., they do not define a new xref or trailer, but PDF applications are error tolerant and display the content anyway.

In total, the ISA attack is successful if:

  1. the new Content (Body Updates) is shown and
  2. the application does not notice that the document has been modified or updated.

Attack 3: Signature Wrapping (SWA)

The SWA introduces a novel technique to bypass signature protection without using incremental saving.

The main idea is to move the second part of the signed /ByteRange to the end of the document while reusing the xref pointer within the signed trailer to an attacker manipulated xref. To avoid any processing of the relocated second part, it can be optionally wrapped by using a stream object or a dictionary. In the picture below, two documents are depicted. On the left side, a validly signed PDF file is depicted. On the right side, a manipulated PDF file is generated by using SWA.

USF

The attack works as follows:

  1. (optional): The attacker deletes the padded zero Bytes within the Contents parameter to increase the available space for injecting manipulated objects.

  2. The attacker defines a new /ByteRange [a,b,c,d]* by manipulating the c value, which now points to the second signed part placed on a different position within the document.

  3. The attacker creates a new xref pointing to the new objects. It is essential that the byte offset of the newly inserted xref has the same byte offset as the previous xref. The position is not changeable since it is referenced by the signed trailer For this purpose, the attacker can add a padding block (e.g., using whitespaces) before the new xref to fill the unused space.

  4. The attacker injects malicious objects which are not protected by the signature. There are different injection points for these objects. %If Step 1 is executed, we can place the malicious object before the malicious xref. They can be placed before or after the malicious xref. If Step 1 is not executed, it is only possible to place them \emph{after} the malicious xref.

  5. Some PDF viewers need a trailer after the manipulated xref; otherwise they cannot open the PDF file or detect the manipulation and display a warning message. Copying the last trailer is sufficient to bypass this limitation.

  6. The attacker moves the signed content defined by c and d at byte offset c*. Optionally, the moved content can be encapsulated within a stream object.

Evaluation

We evaluated our attacks against two types of applications. The typically known desktop applications everyone uses on a daily bases and online validation services. The last one is often used in the business world to validate the signature of a PDF document returning a validation report as a result.

During our research, we identified 21 out 22 desktop viewer applications and 5 out of 7 online validation services vulnerable against at least one of our attacks.

You can find the detailed results of our evaluation on the following web pages:

  1. Desktop Viewer Applications
  2. Online Validation Services

What is the root cause of the problem?

Due to the reason that most analyzed software ist closed source we can only guess, but in our opinion there are 2 main reasons for the successfull attacks:

  1. The specification is very vague about signatures and especally how to validate them.
  2. The analyzed reader are very tolerant about opening, validating and showing malformed PDF files.

Acknowledgements

We would like to thanks the CERT-Bund team for their great support during the responsible disclosure process. We also want to acknowledge the vendor teams which reacted to our report and fixed the vulnerable implementations.

Florian Zumbiehl

We would like to acknowledge Florian Zumbiehl who found an interesting attack related to pdf signatures in PDF viewer back in 2010.

DocuSign researcher

We want to acknowledge the research of John Heasman and his team @ DocuSign for finding one variant of the Signature Wrapping attack independently of our research. They tested and reported their attack against the following products:

PDF association

The association responsible for the standardization of the Portable Document Format issued a statement regarding our findings.