Direito - Unip - DNA 2,03/08

Direito Unip - DNA 2,3/08 · às 8/26/2020

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042, CVE-2018-18688, CVE-2018-18689.

Full results are available in the master thesis of Karsten Meyer zu Selhausen, in our security report, and on our website.

Digitally Signed PDFs? Who the Hell uses this?

Maybe you asked yourself, if signed PDFs are important and who uses them.
In fact, you may have already used them.
Have you ever opened an Invoice by companies such as Amazon, Sixt, or Decathlon?
These PDFs are digitally signed and protected against modifications.
In fact, PDF signatures are widely deployed in our world. In 2000, President Bill Clinton enacted a federal law facilitating the use of electronic and digital signatures in interstate and foreign commerce by ensuring the validity and legal effect of contracts. He approved the eSign Act by digitally signing it.
Since 2014, organizations delivering public digital services in an EU member state are required to support digitally signed documents, which are even admissible as evidence in legal proceedings.
In Austria, every governmental authority digitally signs any official document [§19]. In addition, any new law is legally valid after its announcement within a digitally signed PDF.
Several countries like Brazil, Canada, the Russian Federation, and Japan also use and accept digitally signed documents.
According to Adobe Sign, the company processed 8 billion electronic and digital signatures in the 2017 alone.

Crash Course: PDF and PDF Signatures

To understand how to spoof PDF Signatures, we unfortunately need to explain the basics first. So here is a breef overview.

PDF files are ASCII files. You can use a common text editor to open them and read the source code.

PDF header. The header is the first line within a PDF and defines the interpreter version to be used. The provided example uses version PDF 1.7.

PDF body. The body defines the content of the PDF and contains text blocks, fonts, images, and metadata regarding the file itself. The main building blocks within the body are objects. Each object starts with an object number followed by a generation number. The generation number should be incremented if additional changes are made to the object.

In the given example, the Body contains four objects: Catalog, Pages, Page, and stream. The Catalog object is the root object of the PDF file. It defines the document structure and can additionally declare access permissions. The Catalog refers to a Pages object which defines the number of the pages and a reference to each Page object (e.g., text columns). The Page object contains information how to build a single page. In the given example, it only contains a single string object "Hello World!".

Xref table. The Xref table contains information about the position (byte offset) of all PDF objects within the file.

Trailer. After a PDF file is read into memory, it is processed from the end to the beginning. By this means, the Trailer is the first processed content of a PDF file. It contains references to the Catalog and the Xref table.

How do PDF Signatures work?

PDF Signatures rely on a feature of the PDF specification called incremental saving (also known as incremental update), allowing the modification of a PDF file without changing the previous content.

As you can see in the figure on the left side, the original document is the same document as the one described above. By signing the document, an incremental saving is applied and the following content is added: a new Catalog, a Signature object, a new Xref table referencing the new object(s), and a new Trailer. The new Catalog extends the old one by adding a reference to the Signature object. The Signature object (5 0 obj) contains information regarding the applied cryptographic algorithms for hashing and signing the document. It additionally includes a Contents parameter containing a hex-encoded PKCS7 blob, which holds the certificates as well as the signature value created with the private key corresponding to the public key stored in the certificate. The ByteRange parameter defines which bytes of the PDF file are used as the hash input for the signature calculation and defines 2 integer tuples:
a, b : Beginning at byte offset a, the following b bytes are used as the first input for the hash calculation. Typically, a 0 is used to indicate that the beginning of the file is used while a b is the byte offset where the PKCS#7 blob begins.
c, d : Typically, byte offset c is the end of the PKCS#7 blob, while c d points to the last byte range of the PDF file and is used as the second input to the hash calculation.

According to the specification, it is recommended to sign the whole file except for the PKCS#7 blob (located in the range between a b and c).

Attacks

During our research, we discovered three novel attack classes on PDF signatures:

Universal Signature Forgery (USF)
Incremental Saving Attack (ISA)
Signature Wrapping Attack (SWA)

In this blog post, we give an overview on the attacks without going into technical details. If you are more interested, just take a look at the sources we summarized for you here.

Universal Signature Forgery (USF)

The main idea of Universal Signature Forgery (USF) is to manipulate the meta information in the signature in such a way that the targeted viewer application opens the PDF file, finds the signature, but is unable to find all necessary data for its validation.

Instead of treating the missing information as an error, it shows that the contained signature is valid. For example, the attacker can manipulate the Contents or ByteRange values within the Signature object. The manipulation of these entries is reasoned by the fact that we either remove the signature value or the information stating which content is signed.
The attack seems trivial, but even very good implementations like Adobe Reader DC preventing all other attacks were susceptible against USF.

Incremental Saving Attack (ISA)

The Incremental Saving Attack (ISA) abuses a legitimate feature of the PDF specification, which allows to update a PDF file by appending the changes. The feature is used, for example, to store PDF annotations, or to add new pages while editing the file.

The main idea of the ISA is to use the same technique for changing elements, such as texts, or whole pages included in the signed PDF file to what the attacker desires.
In other words, an attacker can redefine the document's structure and content using the Body Updates part. The digital signature within the PDF file protects precisely the part of the file defined in the ByteRange. Since the incremental saving appends the Body Updates to the end of the file, it is not part of the defined ByteRange and thus not part of the signature's integrity protection. Summarized, the signature remains valid, while the Body Updates changed the displayed content.
This is not forbidden by the PDF specification, but the signature validation should indicate that the document has been altered after signing.

Signature Wrapping Attack (SWA)

Independently of the PDFs, the main idea behind Signature Wrapping Attacks is to force the verification logic to process different data than the application logic.

In PDF files, SWA targets the signature validation logic by relocating the originally signed content to a different position within the document and inserting new content at the allocated position. The starting point for the attack is the manipulation of the ByteRange value allowing to shift the signed content to different loctions within the file.

On a very technical level, the attacker uses a validly signed document (shown on the left side) and proceeds as follows:

Step 1 (optional): The attacker deletes the padded zero Bytes within the Contents parameter to increase the available space for injecting manipulated objects.
Step 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.
Step 3: The attacker creates a new Xref table pointing to the new objects. It is essential that the byte offset of the newly inserted Xref table has the same byte offset as the previous Xref table. The position is not changeable since it is refer- enced by the signed Trailer. For this purpose, the attacker can add a padding block (e.g., using whitespaces) before the new Xref table to fill the unused space.
Step 4: The attacker injects malicious objects which are not protected by the signature. There are different injection points for these objects. They can be placed before or after the malicious Xref table. If Step 1 is not executed, it is only possible to place them after the malicious Xref table.
Step 5 (optional): Some PDF viewers need a Trailer after the manipulated Xref table, 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.
Step 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. Noteworthy is the fact that the manipulated PDF file does not end with %%EOF after the endstream. The reason why some validators throw a warning that the file was manipulated after signing is because of an %%EOF after the signed one. To bypass this requirement, the PDF file is not correctly closed. However, it will be still processed by any viewer.

Evaluation

In our evaluation, we searched for desktop applications validating digitally signed PDF files. We analyzed the security of their signature validation process against our 3 attack classes. The 22 applications fulfill these requirements. We evaluated the latest versions of the applications on all supported platforms (Windows, MacOS, and Linux).

Authors of this Post

Vladislav Mladenov
Christian Mainka
Karsten Meyer zu Selhausen
Martin Grothe
Jörg Schwenk

Acknowledgements

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

Continue reading

Direito Unip - DNA 2,3/08 · às 8/26/2020

Recently, the theoretical and practical analysis of secure instant messenger protocols received much attention, but the focus of prior evaluations mostly lay in one-to-one communication. In this blog post we want to presents the results of our work that focuses on group chat protocols of three major instant messenger applications; namely Signal, WhatsApp, and Threema.

In this blog post, we aim to focus on the practical impact and the found weaknesses identified by our analysis. The interested reader may also look into our paper for more details.

Our Aim and What We Were Looking For

End-to-end encryption protects the confidentiality of communication that is forwarded via central servers to the designated receivers. As a consequence, neither parties on the network route of the messages, nor the provider of the central server (e.g. the WhatsApp server) should be able to read any information out of the observation of the communication. In particular, no other user of the application should have access to the communication. Further it might be desirable to require that also the messages' integrity is end-to-end protected and that a sender is informed about the delivery state of sent messages.

Delivery state information in Signal (upper screenshot) and WhatsApp (lower screenshot)

In a two party scenario, this analysis is rather fixed to two components of the protocol: the key establishment between both parties and the communication channel protection using the established key (mostly consisting of an encryption algorithm and a scheme for providing integrity like MACs or signature schemes).

Regarded attackers

In a group setting, the same attackers apply (network, provider, other users). However the requirements for secure communication differ. It is further necessary that only group members can write to and read content from the group. Additionally, only administrators of the group are able to add new members.

In addition to these standard requirements, we also evaluated the protocols' security guarantees if the client's secrets were revealed (forward secrecy and future secrecy).

Our Approach

We analyzed the mentioned protocols by reading the source code and debugging the apps. We also used alternative open source implementations of Threema and WhatsApp as a help and we traced the network traffic. When using alternative implementations, we only took incoming traffic into account, which was generated by official applications. Thereby we extracted the protocol descriptions and evaluated them regarding the defined requirements.

Our Findings

In WhatsApp and Threema, the provider was able to manipulate the set of members. Threema only allowed the provider to rewind the set of members to a previous state. As a consequence previously removed members could have been added to the group again. The WhatsApp provider is able to arbitrarily manipulate the member set. Thereby further members and administrators can be added to the group. Since the authenticity of group manipulation is not protected, the WhatsApp provider can set the real group administrator as the source of manipulation even though this administrator was not active.

Since Signal's key exchange protocol provides future secrecy, we also evaluated the protocol's ability to recover into a secure group state after a member's state was compromised. The essential weakness here is that a sender only needs to know the static group ID to send a message to the group. If a group member receives a message with the correct group ID, no verification regarding the current member set takes place but the message is directly added to the group communication. Consequently it is sufficient to retrieve the group ID in order to send messages to the group. Since Signal treats content messages the same way as messages for the manipulation of the group set, an attacker who knows the group ID can add herself to the group and thereby read the subsequent group communication.

In addition to this, in all cases the delivery state of sent messages was not securely provided. Threema's group chats do not inform the sender about the delivery state while Signal and WhatsApp do not protect the delivery information on the end-to-end layer. Therefore the central provider can forge this information and drop messages without letting the communicating parties detect this.

Also the order of messages was manipulable for the providers of the applications such that the provider is able to deliver the messages in a different order than they were sent. Threema's weakness of rewinding a group state results from missing replay attack protection.

Impact of Weaknesses

Even though end-to-end encryption is implemented in all analyzed applications, the central providers can largely manipulate the communication in groups and partially also read it.
In all applications, the provider can undetectably drop and reorder messages during the delivery and thereby manipulate the view of the communication such that further attacks can be obfuscated.
The central servers of WhatsApp can be used to add arbitrary users to groups and thereby receive their communication.
To achieve the same result for Signal, it suffices to retrieve the group ID. An earlier member who left the group once still knows this ID since it is static. However, in contrast to WhatsApp, the origin of the manipulation is correctly displayed in the Signal application (which was not the fact when we started our analysis).

As a result, the end-to-end protection of WhatsApp is not sufficient to reach confidentiality in groups. For Signal no future secrecy is reached in groups and Threema was vulnerable to replay attacks which resulted in further weaknesses.

Responsible Disclosure

We disclosed our findings to the developers and received varying response. Threema updated their protocol in version 3.14 such that our attacks are not feasible anymore. Moxie Marlinspike responded that Signal is "working on an entirely new group mechanism that we should be deploying soon". WhatsApp did not hold out the prospect of fixing the described vulnerabilities (Update 01/18: According to Facebook's Security Head, the invite links make a fix more difficult [1]; we proposed a way to solve this issue [2]).

[1] https://twitter.com/alexstamos/status/951169036947107840
[2] https://web-in-security.blogspot.de/2018/01/group-instant-messaging-why-baming.html