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.