Read stuff with me: January 2024

Sunday, January 28, 2024

Probing For XML Encryption Weaknesses In SAML With EsPReSSO

Security Assertion Markup Language (SAML) is an XML-based standard commonly used in Web Single Sign-On (SSO) [1]. In SAML, the confidentiality of transferred authentication statements against intermediaries can be provided using XML Encryption [2]. However, implementing XML Encryption in a secure way can be tricky and several attacks on XML Encryption have been identified in the past [3] [4]. Therefore, when auditing a SAML endpoint, one should always consider testing for vulnerabilities in the XML Encryption implementation.

This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.

Weaknesses of XML Encryption

Implementations of XML Encryption can be vulnerable to adaptive chosen ciphertext attacks. This is a class of attacks in which the attacker sends a sequence of manipulated ciphertexts to a decryption oracle as a way to gain information about the plaintext content.

Falsely implemented XML Encryption can be broken using:

an attack against the CBC-mode decryption (quite similar to a padding oracle attack) [3] or
a Bleichenbacher attack against the RSA-PKCS#1 encryption of the session key [4].

SAML makes use of XML Encryption and its implementations could, therefore, also be vulnerable to these attacks.

XML Encryption in SAML

To support confidential transmission of sensitive data within the SAML Assertion, assertions can be encrypted using XML Encryption. An EncryptedAssertion is shown in the abridged example below.

The EncryptedAssertion contains an EncryptedData element, which in turn is the parent of the EncryptionMethod, KeyInfo, and CipherData elements. SAML makes use of what is referred to as a hybrid encryption scheme. This is done using a session key which symmetrically encrypts the payload data (the example uses AES-128 in CBC mode), resulting in the ciphertext contained in the EncryptedAssertion/EncryptedData/CipherData/CipherValue child element. The session key itself is encrypted using an asymmetric encryption scheme. In our example, RSA-PKCS#1.5 encryption is used with the public key of the recipient, allowing the contents of the the EncryptedKey child element to be derived from the KeyInfo element.

Encryption Attacker

Our BurpSuite extension EsPReSSO can help detect vulnerable implementations with the newly integrated Encryption Attacker within EsPReSSO's SAML module.

Once a SAML response which contains an EncryptedAssertion has been intercepted, open the SAML tab, select the Attacks pane, and choose Encryption from the dropdown menu. This works in Burp's Proxy, as well as in the Repeater tool, and is depicted below.

As sketched out above, the symmetric session key is encrypted using the recipient's public key. Since the key is public, anybody can use it to encrypt a selected symmetric key and submit a valid encryption of arbitrary messages to the recipient. This is incredibly helpful because it allows us to produce ciphertexts that decrypt the chosen plaintexts. To accomplish this, one can purposefully send invalidly padded messages, or messages containing invalid XML, as a method to trigger and analyze the different reactions of the decryption endpoint (i.e, turning the endpoint into a decryption oracle). To facilitate these investigations, the new Encryption Attacker makes this process dead simple.

The screenshot above shows the essential interface of the new encryption tab:
At the top, the certificate used to encrypt the symmetric session key can be pasted into the text field. This field will be pre-filled automatically if the intercepted SAML message includes a certificate in the KeyInfo child element of the EncryptedData element. The Update Certificate checkboxes above the text area can be used to include the certificate in the manipulated SAML message.
In the Symmetric Key text field, the hexadecimal value of the symmetric session key can be set. Choose the asymmetric algorithm from the dropdown menu and click Encrypt key -- this will update the corresponding KeyInfo elements of the intercepted SAML message.

The payload in the text area labeled XML data can now be entered. Any update in the XML data field will also be reflected in the hexadecimal representation of the payload (found on right of the XML data field). Note that this is automatically padded to the blocklength required by the symmetric algorithm selected below. However, the payload and the padding can be manually adjusted in the hex editor field.

Eventually, click the Encrypt content button to generate the encrypted payload. This will apply the changes to the intercepted SAML message, and the manipulated message using Burp's Forward or Go button can now be forwarded, as usual.

Probing for Bleichenbacher Oracles

Bleichenbacher's attack against RSA-PKCS1 v1.5 encryption abuses the malleability of RSA to draw conclusions about the plaintext by multiplying the ciphertext with adaptively chosen values, and observing differences in the received responses. If the (error-) responses differ for valid and invalid PKCS1 v1.5 ciphertexts, Bleichenbachers' algorithm can be used to decrypt the ciphertext without knowing the private key [6].

To determine whether or not a SAML endpoint is vulnerable to Bleichenbacher's Attack, we simply need to check if we can distinguish those responses received when submitting ciphertexts that are decrypted into invalidly formatted PKCS1 v1.5 plaintexts, from the responses we receive when sending ciphertexts that are decrypted into validly formatted plaintexts.

Recall that PKCS1 v1.5 mandates a certain format of the encrypted plaintext, namely a concatenation of a BlockType 00 02, a randomized PaddingString (PS) that includes no 00 bytes, a 00 (NULL-byte) as delimiter, and the actual plaintext message. The whole sequence should be equal in size to the modulus of the RSA key used. That is, given the byte length k of the RSA modulus and the message length |m|, PS has the length |PS| = k - 3 - |m|. Furthermore, PKCS1 v1.5 demands that |PS| to be at least eight bytes long [5].

In SAML, the recipient's public key is usually known because it is published in the metadata, or even included in the EncryptedAssertion. For this reason, we do not need to fiddle around with manipulated ciphertexts. Instead, we simply submit a validly formatted RSA-PKCS1 v1.5 encrypted message and an encrypted message which deciphers into an invalidly formatted plaintext. As an example, assume an RSA public key of 2048 bits which we want to use to encrypt a 16 byte session key `01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` (hexadecimal representation). |PS|$ is $2048/8 - 3 - 16 = 237, so a valid PKCS1 v1.5 plaintext, ready to be encrypted using `AA` for all 237 padding bytes, could look like the listing shown below.

00 02 AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10

In the Encryption attack pane of EsPReSSO, ensure that the correct public key certificate has been added to the Certificate field. Insert a valid plaintext, such as the one above, into the Symmetric Key field and select Plain RSA encryption from the Algorithm drop down menu. Click the Encrypt button to compute the RSA transformation and apply the new EncryptedKey element to the intercepted SAML message. Now, submit the message by clicking Burp's Go or Forward button and carefully inspect the response.

Next, repeat the steps outlined above, but this time submit an invalid PKCS1 v1.5 message. For example, consider using an invalid BlockType of `12 34` instead of `00 02`, or replace the `00` delimiter so that the decryptor is unable to determine the actual message after decrypting the ciphertext. If you are able to determine from the recieved responses whether or not the submitted ciphertext decrypted into a valid PKCS1 v1.5 formatted plaintext, chances are high that the decryptor can be used as a Bleichenbacher oracle. Don't forget to take into account the actual XML data, i.e., the assertion encrypted with the new session key; by submitting valid or invalid XML, or by removing signatures from the SAML message or the assertion you may increase your chances of detecting differences in the returned responses.

Probing for Oracles in CBC-Mode Decryption

Another known attack on XML Encryption is aimed at the Cipher Block Chaining (CBC) mode, which can be used with the block ciphers AES or 3DES [2]. The attack is described in detail in this referenced paper [3] and is quite similar to Padding-Oracle attacks on CBC mode; the malleability of CBC mode encryption enables the attacker to perform a bytewise, adaptive manipulation of the ciphertext blocks which are subsequently sent to the decryptor. In most cases, the manipulated ciphertext will not decrypt to valid XML and an error will be returned. Sometimes, however, the plaintext will be parsed as valid XML, in which cases an error is thrown later on at the application layer. The attacker observes the differences in the responses in order to turn the decryptor into a ciphertext validity oracle which can be used to break the encryption. Due to some particularities of the XML format, this attack can be very efficient, enabling decryption with about 14 requests per byte, and it is even possible to fully automate the process [7].

In order to determine if a particular SAML service provider is vulnerable to this attack, we can avoid the cumbersome ciphertext manipulation, if we are in possession of the decryptor's public key:
In the Encryption Attacker tab of EsPReSSO, add the public key certificate to the Certificate field (if necessary) and insert a symmetric key of your own devising into the Symmetric Key text field. Select an appropriate RSA encryption method and click the Encrypt button to apply the new EncryptedKey element to the original SAML message.

An XML message can now be inserted into the XML data text field. Select a CBC mode encryption algorithm and click Encrypt to apply the changes. As in the example above, press Burp's Go or Forward button to send the message and carefully inspect the response. Try sending invalid XML, e.g., by not closing a tag or using the `&` character without a valid entity and keep an eye open for differences in the returned responses. To manipulate the padding, the text field on the right side shows the hexadecimal representation of the plaintext, including the CBC padding. If you send a single block and set the last byte, which indicates the padding length to the blocksize, i.e. 16 or 0x10 for AES, the ciphertext should decrypt into an empty string and is generally considered "valid" XML.

Please refer to the original paper for more details, tips, and tricks for performing the actual attack [3].

Summary

The new XML Encryption attacker included in EsPReSSO can help security auditors to quickly assess if a SAML endpoint is vulnerable to known attacks against XML Encryption. To this end, the decryptor's public key is used in order to send suitable test vectors that can be provided in plaintext. Ciphertext manipulation is, therefore, not required. The actual process of decrypting an intercepted SAML message is, however, considered out of scope and not implemented in EsPReSSO.

In case you wonder how XML Encryption can be used in a secure fashion, here are some considerations [6]:

Always use an authenticated encryption mode such as AES-GCM instead of the CBC-mode encryption.
Using RSA-PKCS1 v1.5 within XML Encryption is particularly difficult to do in a secure manner, and it is recommended to use RSA with Optimal Asymmetric Encryption Padding (OAEP) instead [2].
Apply a digital signature over the whole SAML response, and ensure it is properly validated before attempting to decrypt the assertion. This should thwart the attack as a manipulated response can be recognized as such and should be rejected.

----------

[1] https://www.oasis-open.org/standards#samlv2.0
[2] https://www.w3.org/TR/xmlenc-core/
[3] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption/
[4] https://www.nds.ruhr-uni-bochum.de/research/publications/breaking-XML-Encryption-pkcs15/
[5] https://link.springer.com/chapter/10.1007%2FBFb0055716
[6] http://www.w3.org/2008/xmlsec/papers/xmlEncCountermeasuresW3C.pdf
[7] https://web-in-security.blogspot.com/2015/05/how-to-attack-xml-encryption-in-ibm.html

Nemesis: A Packet Injection Utility

"Nemesis is a command-line network packet injection utility for UNIX-like and Windows systems. You might think of it as an EZ-bake packet oven or a manually controlled IP stack. With Nemesis, it is possible to generate and transmit packets from the command line or from within a shell script. Nemesis attacks directed through fragrouter could be a most powerful combination for the system auditor to find security problems that could then be reported to the vendor(s)." read more...

Website: http://www.packetfactory.net/projects/nemesis

Related links

Saturday, January 27, 2024

Shadow Attacks: Hiding And Replacing Content In Signed PDFs

Last year we presented How to Spoof PDF Signatures. We showed three different attack classes. In cooperation with the CERT-Bund (BSI), we contacted the vendors of affected PDF applications to inform them about the vulnerabilities and to support them in developing countermeasures. Most vendors reacted promptly and closed the reported vulnerabilities promptly.

One of those three attack classes was Incremental Saving Attacks (ISA). The proposed countermeasures aimed to distinguish PDF objects appended to the file via updates into dangerous and non-dangerous. In other words, black and whitelisting approaches were used.

Naturally, this countermeasure succeeds as long as the PDF update contains evil objects. So we came up with the idea to attack PDFs with only non-dangerous updates. We achieve this by adding invisible, malicious content when creating the PDF document (before it is signed) and to reveal them after signing.

Today, we present Shadow Attacks! Our evaluation of 28 PDF applications reveals that 15 of them, including Adobe Acrobat and Foxit Reader, are vulnerable.

We responsibly disclosed all affected vendors. Together with the CERT-Bund (BSI), we supported the vendors in developing suitable countermeasures. The attacks are documented in CVE-2020-9592 and CVE-2020-9596.

Full results are available in our vulnerability report and on our website.

What are PDF signatures used for and what is the legal status?

PDFs can be secured against manipulations by using digital signatures. This feature enables use-cases such as signing contracts, agreements, payments, and invoices. Regulations like the eSign Act in the USA or the eIDAS regulation in Europe facilitate the acceptance of digitally signed documents by companies and governments. Asian and South American countries also accept digitally signed documents as an equivalent to manually signed paper documents. Adobe Cloud, a leading online service for signing PDF documents, provided 8 billion electronic and digital signature transactions in 2019. The same year, DocuSign processed 15 million documents each day.

What could a Simple Signing Process look like?
The process of digitally signing a contract involves multiple entities and can look as follows: The PDF contract is prepared by the collaborators. The collaborators can be lawyers, designers, typewriters, or members of different companies. Finally, the contract is digitally signed.

PDF Structure and Signature Basics

A PDF consists of three parts: Body, Xref table, and Trailer

The PDF is a platform-independent document format. It starts with a Header, to set the version, and is followed by three main parts, as depicted in the figure.
The first part defines the PDF Body. It contains different objects, which are identified by its object number. The most important object is the root object, which is called the Catalog. In the figure, the Catalog has the object identifier 1 0. The Catalog defines the whole PDF structure by linking to other objects in the Body. In the example given, the Catalog links to form object AcroForm, to some PDF MetaData, and to actual PDF Pages. The latter can reference multiple Page objects, which in turn reference, for example, the actual Content, Font, and Images.
The second part of the PDF is the Xref table. It contains references to the byte positions of all objects used in the PDF Body.
The third part is the Trailer. It consists of two further references: one to the byte position at which the Xref table starts, and another link to the identifier of the root object (1 0).

Incremental Updates and Digitally Signing a PDF

The content of a PDF may be updated for different reasons, for example, by adding review comments or by filling out PDF forms. From a technical perspective, it is possible to add this new content directly into the existing PDF Body and add new references in the Xref table. However, this is not the case according to the PDF specification. Changes to a PDF are implemented using Incremental Updates. An Incremental Update adds new objects into a new PDF Body, which is directly appended after the previous Trailer as shown in the figure to the right. To adequately address the new objects, a new Xref table and Trailer are also appended as well for each Incremental Update. Summarized, a PDF can have multiple Bodies, Xref tables, and Trailers, if Incremental Update is applied.

For protecting the integrity and the authenticity of a PDF, digital signatures can be applied. For this purpose, a Signature object is created and appended to the PDF by using Incremental Update. It is also possible to sign a PDF multiple times (e.g., a contract), resulting in multiple Incremental Updates. The Signature object contains all relevant information for validating the signature, such as the algorithms used and the signing certificate. Once a PDF containing a PDF Signature is opened, the viewer application automatically validates the signature and provides a warning if the content has been modified.

Shadow Attacks

The main idea of the attacks is that the attackers prepare a PDF document containing invisible content. Afterward, the document is sent to a signing entity like a person or a service which reviews the document, signs it and sends it back to the attackers. Despite the integrity protection provided by the digital signature, the attackers can make modifications to the document and change the visibility of the hidden content. Nevertheless, the manipulation is not detected. The digital signature remains valid. Finally, the attackers send the modified signed document to the victim. Although the document is altered, the signature validation is successful, but the victims see different content than the signing entity.

Do the Attacks match a Real-World Scenario?

Of course! In companies and authorities, relevant documents like contracts or agreements are often prepared by the employees who take care of most of the details and technicalities. The document is then signed by an authorized person after a careful review. Another scenario is the signing process of a document within a consortium. Usually, one participant creates the final version of the document, which is then signed by all consortium members. Considering the given examples, an employee or consortium member acting maliciously can hide invisible shadow content during the editing. Consequentially, this content will be signed later.

Additionally, multiple cloud signing services like Adobe Cloud, DocuSign, or Digital Signature Service exist. Among other functionalities, such services receive a document and sign it. This process can also be used also to sign shadow documents.

Different Attack Classes of Shadow Attacks

Shadow Attacks can be divided into the three attack classes Hide, Replace, and Hide-and-Replace, as shown in the figure below. Each class offers the possibility of taking a significant influence on the content of a signed PDF document. In the following, we describe the functionality of the individual classes in more detail.

Shadow Attack: Hide

The concept of this class of shadow attacks is to hide the content relevant for the victims behind a visible layer. For example, the attackers can hide the text "You are fired!" behind a full-page picture showing "Sign me to get the reward!". Once the attackers receive the signed document, they manipulate the document in such a way that the picture is no longer rendered by the viewer application. Hide attacks have two advantages from the attackers' perspective:

Many viewers show warnings if new visible content is added using an Incremental Update. However, they do not warn in most cases if content is removed.
The objects are still accessible within the PDF. In the example above, the text "You are fired!" can still be detected by a search function. This might be important if an online signing service is used and it reviews the document by searching for specific keywords. We identified two variants of this attack class.

Hiding Content via Page.
This attack variant uses an Incremental Update to create a new Page object. It contains all previously used objects except for the overlay, for example, the image. This attack variant is depicted on the left side of figure above.

Hiding Content via Xref.
If the viewer application does not accept changes to PDF structuring objects, such as Page, Pages, or Contents, the second attack variant can be applied. This variant directly affects the overlay object. The simplest method for this is to create an Incremental Update, which only updates the Xref table by setting the overlay object to free. However, making this change is interpreted as a dangerous in many viewers (e.g., Adobe) and an error or a warning is thrown. For this reason, we use another approach: we use the same object ID within the Incremental Update, but we define it as a different object type. For example, we change the overlay type Image to XML/Metadata.
When opening this manipulated document, the overlay is hidden because Metadata cannot be shown. Since adding Metadata to a signed PDF using Incremental Update is considered harmless, the signature remains valid.

Shadow Attack: Replace

In this attack class, specific content of the PDF document is to be exchanged. The first variant uses the visual properties of text fields for this purpose. The second variant is based on a fatal misconception that fonts cannot be used for manipulation purposes.
Replace via Overlay.
This attack targets an interactive feature in PDFs: interactive forms. Forms support different input masks (e.g., text fields, text areas, radio/selection buttons) where users dynamically enter new content and store it in the PDF document. The main idea of the attack is to create a form, which shows one value before (PDF1) and after signing (PDF2), as illustrated on the leftside in the figure below. After the attackers manipulate the PDF and create PDF3, different values are shown in the form (and can be seen on the right side of the figure below). The attack abuses a special property of PDF text fields. A text field can show two different values: the real field value and an overlay value which disappears as soon as the text field is selected. The real value of a form field is contained in an object key named /V. The content of the overlay element is defined within a /BBox object. The /BBox object is comparable to the hint labels known from HTML forms; for example, the hint username to indicate that the username should be entered into a specific login field. In contrast to HTML, in PDF there is no visual difference between the hint and the actual value.

In summary, we can say that this variant allows attackers to manipulate the contents of the text fields for the visible layer arbitrary. As shown in the figure above, this can be used, for example, to maliciously redirect a payment.

Replace via Overwrite.

The main idea of this variant is to append new objects to the signed document which are considered harmless but directly influence the presentation of the signed content. As shown in figure of the three attack classes, the attackers prepare a shadow document that defines a font and includes its description into the document. The font is used for the presentation of specific content. After the document is signed, the attackers append a new font description and overwrite the previous description. The definition of new fonts is considered harmless, because of that, the applications verifying the signature do not show any warning regarding the made changes. For instance, the (re)definition of fonts does not change the content directly. However, it influences the view of the displayed content and makes number or character swapping possible.

Shadow Attack: Hide-and-Replace

In this attack class, the attackers create a shadow PDF document that is sent to the signers. The PDF document contains a hidden description of another document with different content. Since the signers cannot detect the hidden (malicious) content, they sign the document. After signing, the attackers receive the document and only append a new Xref table and Trailer. Within the Xref table, only one change takes place: the reference to the document Catalog (or any other hidden object), which now points to the shadow document.

In fact, the document contains two independent content paths. One path to show the signer harmless content, and one path with malicious content that replaces the first content after it is signed and activated by the attackers. The figure above visually illustrates the described relationships once again.
This attack variant is the most powerful one since the content of the entire document can be exchanged, including text content, forms, fonts, and annotations. The attackers can build a complete shadow document influencing the presentation of each page and each object.

Evaluation

Overall, 15 out of 28 PDF viewing applications were vulnerable to at least one presented attack. Surprisingly, for 11 PDF viewers, all three attack classes were successful. The Table shows that some applications have limited vulnerabilities. These applications respond to any type of Incremental Update with a post-signature modification note, including modifications that are allowed due to the specification. We have evaluated the latest (at the time of evaluation) available versions of the applications on all supported desktop platforms: Windows, macOS, and Linux.

Evaluation results.

Authors of this Post

Simon Rohlmann
Christian Mainka
Vladislav Mladenov
Jörg Schwenk

Acknowledgments

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

Read stuff with me