Certiﬁcations have two main differences to signatures. First, each PDF can have only one certiﬁcation and must be the ﬁrst in the document. Second, certiﬁcations deﬁne permissions that allow certain changes to the certiﬁed document. As depicted in the table below, certiﬁcations deﬁne a more ﬂexible way to handle Incremental Updates, and allowed Incremental Update do not lead to a warning. The certiﬁer chooses between three different permission levels (P) to allow different modiﬁcations.
|Incremental Update||Signature||Certification: P1||Certification: P2||Certification: P3|
|Add/change visible content||❌||❌||❌||❌|
|Fill out form inputs||❗||❌||✅||✅|
✅ - Modiﬁcation allowed
❌ - Modiﬁcation not allowed
❗ Only allowed when adding a signature at the same time
‼️ Leads to warnings in most PDF applications
At the beginning of our analysis, we investigated which modiﬁcations can be included or removed within certiﬁed documents with respect to the deﬁned modiﬁcation permissions (i.e., P1, P2, and P3). Without any surprises, annotations are allowed only in certiﬁed documents with P3 and form modiﬁcations – in P2 and P3. We determined three different categories with respect to possible changes on the document.
Changing Static Content: Independent of the deﬁned 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 speciﬁcation, it is only allowed to modify the value of the form ﬁeld. The modiﬁcation 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 speciﬁcation, there is no restriction on the type of annotation. In contrast to the speciﬁcation, our analysis reveals that not all annotations are allowed.
We estimated the danger level for each modiﬁcation and deﬁne four levels: High, Medium, Low, and None.
The idea of the Evil Annotation Attack (EAA) is to show arbitrary content in a certiﬁed document by abusing annotations for this purpose. Since P3 certiﬁed document allow to add annotations, EAA breaks the integrity of the certiﬁcation.
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 certiﬁed document and inject malicious content.
In addition, 11 out of 28 annotations are classiﬁed as medium since an attacker can hide content within the certiﬁed document.
The danger level of the remaining annotations is classiﬁed as low or none since such annotations are either quite limited or not allowed in certiﬁed documents.
According to our attacker model, the attacker possesses a validly certiﬁed document allowing the insertion of annotations. To execute the attack, the attacker modiﬁes a certiﬁed document by including the annotation with the malicious content at a position of attacker’s choice. Then, the attacker sends the modiﬁed file to the victim who veriﬁes 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.
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 speciﬁed /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 unspeciﬁed value, whereby both cases are not prohibited according to the speciﬁcation, the PDF viewer is unable to assign the annotation. In summary, the annotation is indistinguishable from the original content.
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 certiﬁed 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 ﬁeld. 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 ﬁeld. By inserting a signature ﬁeld, the signer can deﬁne the exact position of the ﬁeld, and additionally its appearance and content. This ﬂexibility 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 ﬂexibility to stealthy manipulate the document and insert new content.
The attacker modiﬁes a certiﬁed document by including a signature ﬁeld 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 certiﬁcate for SSA is sufﬁcient.
The only restriction is that the attacker needs to sign the document to insert the malicious signature ﬁeld. 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 ﬁle can get suspicious and refuse to accept the document, even though the certiﬁcation is valid.
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:
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 veriﬁed 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 certiﬁed document is opened in a common PDF application, signatures can only be added to free signature ﬁelds provided by the certiﬁer.
Adding empty signature ﬁelds is normally no longer possible within the application. However, the speciﬁcation does not prohibit adding empty signature ﬁelds to a certiﬁed document. By using frameworks like Apache PDFBox, empty signature ﬁelds can be placed anywhere in the document and filled with arbitrary content.