On 22 July 2020, a team of security researchers investigating issues relating to PDF encryption and digital signatures, announced a novel series of vulnerabilities which they coined the PDF Shadow Attacks. These findings follow their earlier results from 2019, when they announced the discovery of shortcomings in PDF signature validations in PDF processing software. We addressed these findings, and how to avoid the vulnerabilities with iText in this blog post. Unlike the earlier vulnerabilities, the shadow attacks aren’t of a cryptographic nature, but are situated in the visual realm of PDF.
First things first, even though the overall situation isn’t too pretty, we can now safely say that our products aren’t affected by these new Shadow Attacks. We invited Michael Klink, independent PDF expert and top StackOverflow contributor @mkl, on board as a technical consultant to vet our current product offering in the light of this new research. Suffice it to say that we got a clean bill of health.
As a result of iText’s collaboration with Michael Klink we are publishing a blog post series dedicated to PDF Shadow Attacks. In particular, we want to highlight how iText can be turned into an invaluable asset for doing defense in depth. We’ll be showing you how to develop detection heuristics for use in your document workflows in the light of these attacks.
Breaking PDF signatures revisited
The attacks from 2019 required an attacker to somehow intercept a document that has previously been signed. The researchers demonstrated methods for manipulating PDFs without the documents being reported as tampered with.
As an analogy, you could compare the previous attacks to invoice mail fraud, where fraudsters intercept a legitimate invoice, only to meticulously change the payment details. The victim is then tricked into believing the invoice is authentic, only to pay the attacker instead of the seller. Similarly, with the attacks on digital signatures from 2019, a hacker had to get a hold of a PDF document that had already been signed in order to change it after the fact.
Now you see it… now you don’t
Whereas the attacks from 2019 exploited weaknesses in the signature validation algorithms of PDF viewers, the 2020 attacks take aim at the algorithms for analyzing changes between document revisions. In this blog post we’ll take a look at the presentational tricks involved in the PDF Shadow Attacks. We’ll look at the different ways PDFs can be altered after signing to trick PDF viewers into displaying content that looks different to the one that was signed. With iText being at the other end of the PDF spectrum from viewers, the question of vulnerability is not really at stake for iText 7—it’s simply not vulnerable to this class of attacks.
With these new vulnerabilities, attackers are now able to craft tailor-made documents for tricking their unwitting victims into signing something one thing, while in fact, they might be signing something else entirely.
In essence, the Shadow Attacks allow actors with malicious intent to use a presentational sleight of hand: what a user appears to sign at first sight only corresponds to the visible contents of the PDF document. However, some additional elements of the document, which at this point in time are invisible to the unwitting user, also get signed together with the rest of the document. Since all that remains for an attacker is to tweak the visual appearance after it has been signed, their life is made much easier.
The researchers identified three distinct methods for falsifying documents, all of them relying on quirks in the presentational aspects of PDF. Previously invisible content inside of the signed document can be made visible afterwards by manipulating the document to hide content or to replace content, or through a combination of both. In this way, a victim can be led to believe that they have agreed to something other than what they originally signed.
Three approaches to such attacks were presented by the researchers and are aptly referred to as “Hide”, “Replace”, and “Hide and Replace”.
Hide
In the case of the “Hide” attack, the content the attacker wants to eventually show is actually already drawn on the page of the original document, but is then covered by something else, e.g. a bitmap image. The after-signing manipulation then causes the image to no longer be displayed, causing the previously hidden content to become visible. Depending on how the researchers did that, multiple viewers did not recognize a relevant change to report.
Replace
In the case of the “Replace” attack, new objects are appended to the signed document which are considered harmless by validators, but which indirectly cause the displayed content to change.
For example, text form fields have both a value stored internally and an appearance definition for actually displaying a value. In an attack scenario the attacker can prepare the original document with an appearance definition that displays a different value than is stored internally. The signer sees the value from the appearance and signs. Later, the attacker appends a new appearance definition showing the internally stored value. As this new appearance shows the internally stored value, this change by some viewers is considered harmless.
The researchers observed that Adobe Acrobat Reader acted cautiously in the case of this type of attack, but was vulnerable in the end. Finding a new appearance definition appended to the signed document, Adobe Reader didn’t trust it but instead created yet another one based on the internally stored value. Since this value had been set as part of the original attack preparation, Adobe Reader then also displayed the internally stored value the signer never wanted to sign, without any warning.
Hide and Replace
Finally, in the case of the “Hide and Replace” attack, the attacker prepares the original document to contain two different versions of the same object, e.g. a page object. Which version a PDF viewer will show, depends on which version is referenced from the cross reference mapping of the PDF: Herein the object numbers used in the PDF are mapped to offsets in the file where a PDF viewer shall look for the actual details of that object.
Thus, the signer only sees the contents of the object version which is referenced from the cross references of the original document. The attack now merely adds a new cross reference mapping to the document, this time referencing the other version of the targeted object. As the now referenced object also is in the original, signed document revision and has the correct object number, many viewers saw no reason to display a warning, even though the different object versions may cause the document to look very different after manipulation
Conclusion
This concludes our first post in this series looking into the PDF Shadow Attacks. We’ve given a brief overview of the different types of shadow attacks discovered by the researchers, as well as touched upon their visual nature. This is essentially what sets the shadow attacks apart from the earlier set of cryptographic vulnerabilities. In the next post in this series, we’ll take a closer look at incremental updates, a feature of PDF that is instrumental in the execution of these attacks. Additionally, we’ll look into building a heuristic for detecting potentially malicious documents with hidden or manipulated content in the back. Stay tuned for more!
