Crash Course: PDF Certification
An example of a certified document with allowed changes is shown here by highlighting the text All partners after certification. The figure is divided into the structure (left side) and actual view (right side). Original PDF depicts the PDF document before it is certified.
Inc. Update 1 presents the PDF document after applying a certification.
Inc. Update 2 shows changes on the document made after its signing and appended at the end of the file.
Certifications have two main differences to signatures. First, each PDF can have only one certification and must be the first in the document. Second, certifications define permissions that allow certain changes to the certified document. As depicted in the table below, certifications define a more flexible way to handle Incremental Updates, and allowed Incremental Update do not lead to a warning. The certifier chooses between three different permission levels (P) to allow different modifications.
- P1: No modifications on the document are allowed.
- P2: Filling out forms, and digitally signing the document are allowed.
- P3: In addition to P2, annotations are also allowed.
| Incremental Update | Signature | Certification: P1 | Certification: P2 | Certification: P3 |
|---|---|---|---|---|
| Add/change visible content | ❌ | ❌ | ❌ | ❌ |
| Fill out form inputs | ❗ | ❌ | ✅ | ✅ |
| Multiple signatures | ✅ | ❌ | ✅ | ✅ |
| Add/change annotations | ‼️ | ❌ | ❌ | ✅ |
✅ - Modification allowed
❌ - Modification not allowed
❗ Only allowed when adding a signature at the same time
‼️ Leads to warnings in most PDF applications
Allowed and Prohibited Changes
At the beginning of our analysis, we investigated which modifications can be included or removed within certified documents with respect to the defined modification permissions (i.e., P1, P2, and P3). Without any surprises, annotations are allowed only in certified documents with P3 and form modifications – in P2 and P3. We determined three different categories with respect to possible changes on the document.
Changing Static Content: Independent of the defined permissions (P1, P2, P3), the static text content cannot be changed. This restriction includes changes such as adding/removing/switching pages, replacing fonts, and replacing the text or images within a page.
Changing Forms: We wondered which changes on forms are allowed if the permission is set to P2 or P3. According to the specification, it is only allowed to modify the value of the form field. The modification of its appearance, for example, its position, color, and font, must not be allowed. Forms can also be used to insert digital signatures.
Adding/Removing/Modifying Annotations: Annotations can be added if the permission is set to P3. According to the specification, there is no restriction on the type of annotation. In contrast to the specification, our analysis reveals that not all annotations are allowed.
Danger Level
We estimated the danger level for each modification and define four levels: High, Medium, Low, and None.
- High: The highest level results from the fact that the modification allows the insertion of text indistinguishable from the original one. Thus, a user opening a document cannot detect the inserted annotation and interprets the newly added content as part of the certified document.
- Medium: The level Medium covers modifications capable of hiding content. The user is then unable to detect that the modifications overlay some part of the document, for example, an important point of a contract.
- Low: Annotations with the level Low are potentially able to hide content of the original PDF, but the modification is visible for the user. For such modifications we abuse features like annotation icons shown in the PDF. Since the icon can be exchanged, one can define an icon overlaying content. Nevertheless, we could not find a way to change the icon without invalidating the certification. A residual risk remains, but we consider this to be low.
- None: All modifications which are not allowed to be used in certified documents have the level None.
Evil Annotation Attack (Specification Flaw: Breaking P3)
The idea of the Evil Annotation Attack (EAA) is to show arbitrary content in a certified document by abusing annotations for this purpose. Since P3 certified document allow to add annotations, EAA breaks the integrity of the certification.
We determined three annotations with a danger level high capable to hide and add text and images: FreeText, Redact, and Stamp. All three can be used to stealthily modify a certified document and inject malicious content.
In addition, 11 out of 28 annotations are classified as medium since an attacker can hide content within the certified document.
The danger level of the remaining annotations is classified as low or none since such annotations are either quite limited or not allowed in certified documents.
Attacking with Annotations: EAA
According to our attacker model, the attacker possesses a validly certified document allowing the insertion of annotations. To execute the attack, the attacker modifies a certified document by including the annotation with the malicious content at a position of attacker’s choice. Then, the attacker sends the modified file to the victim who verifies the digital signature.
The victim could detect the attack if it manually opens one of the side bars or clicks on the annotation. However, none of the tested PDF applications opened the side bars automatically. Additionally, the attacker can lock an annotation to disable clicking on it.
Improving the stealthiness of EAA
To improve the attack, we elaborated techniques to prevent the annotation’s visualization, so that it does not appear in any side bar. Surprisingly, we found a generic and simple bypass that can be applied to all annotations. PDF viewers identify annotations by their specified /Subtype. This /Subtype is also used by the viewer to assign the various editing tools, such as a text editor for FreeText comments. If the value of /Subtype is either missing or set to an unspecified value, whereby both cases are not prohibited according to the specification, the PDF viewer is unable to assign the annotation. In summary, the annotation is indistinguishable from the original content.
Sneaky Signature Attack (Specification Flaw: Breaking P2)
The idea of the Sneaky Signature Attack (SSA) is to manipulate the appearance of arbitrary content within the PDF by adding overlaying signature elements to a PDF document that is certified at level P2.
According to our analysis, the danger level of forms was none because the insertion of new form elements, customizing the font size and appearance, and removing form elements is prohibited. The only permitted change is on the value stored in the field. Thus, an attacker is not able to create forms which hide arbitrary content within the PDF document.
Surprisingly, these restrictions are not valid for the signature field. By inserting a signature field, the signer can define the exact position of the field, and additionally its appearance and content. This flexibility is necessary since each new signature could contain the signer’s information. The information can be a graphic, a text, or a combination of both.
Nevertheless, the attacker can misuse the flexibility to stealthy manipulate the document and insert new content.
Attacking with Forms: SSA
The attacker modifies a certified document by including a signature field with the malicious content at a position of attacker’s choice.
The attacker then needs to sign the document, but he does not need to possess a trusted key. A self-signed certificate for SSA is sufficient.
The only restriction is that the attacker needs to sign the document to insert the malicious signature field. This signing information can be seen by opening the PDF document and showing detailed information of the signature validation. In this case, the victim opening the file can get suspicious and refuse to accept the document, even though the certification is valid.
Improving the stealthiness of SSA
To circumvent this limitation, we found a bypass to hide this information in the signature panel. Thus, the victim is not able to determine the attacker’s manipulations.
Basically, we have three tasks to improve the attack execution:
- hide the signature information in the signature panel,
- skip the validation of attacker’s signature, and
- make the signature field read-only to make it indistinguishable from the text content.
To solve all tasks, we need to adjust one object – the one responsible for the appearance of the signature. It contains three relevant parameters: /P, /V, and /Ff.
The /P is a reference to the page where signature should be displayed. We found out that if this reference is not valid, the signature disappears from the signature panel, but the malicious content is still shown on the page.
A signature added to a PDF document is usually verified by processing its referenced signature data. If the stored cryptographic values are correct and the document is not manipulated within the signed area, the signature is technically valid.
The /V parameter references the signature value which needs to be validated. We found out that if this reference is also invalid, the signature validation is skipped.
Finally, we set the parameter /Ff to 1 which means that the content is read-only. If a certified document is opened in a common PDF application, signatures can only be added to free signature fields provided by the certifier.
Adding empty signature fields is normally no longer possible within the application. However, the specification does not prohibit adding empty signature fields to a certified document. By using frameworks like Apache PDFBox, empty signature fields can be placed anywhere in the document and filled with arbitrary content.