Cryptographic Vulnerabilities In German E-government Library

XML SIGNATURE WRAPPING

In 2017 SEC Consult discovered that the request and response signature verification of the OSCI-Transport library was vulnerable to an XML signature wrapping attack. Such an attack tricks the parser into verifying the signature against one part of the message while the data that is processed comes from another part of the message. For example, an OSCI-Transport message may contain an XML element soap:Body that contains the transmitted payload. Consider an attacker inserts multiple body elements and manages to trick the parser into using one body for signature verification and another body to obtain the payload. The attacker could in this case provide a correctly signed element for signature verification while providing another body containing manipulated data that is then processed by the application.

The previously identified vulnerability has since been fixed. However, another approach for an XML signature wrapping attack was identified:

<soap:Envelope> <soap:Header> ... <osci:ClientSignature> <ds:Signature> <ds:SignedInfo> <ds:Reference URI="#body"> ... <ds:DigestValue>(digest value of _original_ body)</ds:DigestValue> </ds:Reference> ... </ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:Reference URI="#body"> ... <ds:DigestValue>(digest value of _new_ body)</ds:DigestValue> </ds:Reference> </ds:Signature> </osci:ClientSignature> ... </osci:Header> <soap:Body Id="body">(modified content here)</soap:Body> </soap:envelope>

Unlike the previous attack, this attack does not inject an additional body element. Instead, another Reference element is introduced.

Reference elements are used to tie an XML element to their expected hash values (e.g. a Referenceelement that refers to the body contains the hash value of the body element and its children). These Reference elements are normally stored in a SignedInfo element. The actual signature is verified against the SignedInfo element and all its children. If a referenced element’s contents were modified, the parser would detect it because the hash value in the Reference element no longer matches the calculated hash value of the element.

Also, the OSCI-Transport library seems to accept Reference elements outside of a SignedInfo element for hash verification. If multiple Reference elements refer to the same element, only the last reference is processed. An attacker could therefore manipulate the body and insert an additional Reference element after the SignedInfo element containing the modified hash value of the body. As the SignedInfoelement has not been modified, the signature still verifies as correct.

CBC Mode Weaknesses

Another identified vulnerability results from the usage of the CBC encryption mode for the request and response encryption. The W3C strongly recommends using more secure modes instead of the CBC mode. Therefore, the maintainer of the OSCI-Transport standard (KoSIT) is in the process of replacing the legacy CBC mode with the more secure GCM mode. This transition is expected to finalize in November 2019. Right now, the OSCI-Transport library still supports the CBC mode, though SEC Consult is unaware of how many organisations still use it.

In 2017 researchers at SEC Consult were able to demonstrate a padding oracle attack against the CBC mode as it was used by the OSCI-Transport library for request and response encryption. This vulnerability has since been fixed, but due to the known weaknesses of the CBC mode, a modification of the original attack is still viable.

In order to exploit the weaknesses of CBC, an attacker needs to find a way to get the server to behave differently depending on the contents of the decrypted message. For example, a padding oracle attack exploits the fact that a difference in behavior can be observed depending on whether the decrypted padding bytes are valid.

The new attack abuses the fact that the encrypted message is a MIME object. The following shows an example of such a MIME object:

MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary_9MnMkzyjeaR9bguP9KZvpdeoY1GEChQI; type=text/xml --MIME_boundary_9MnMkzyjeaR9bguP9KZvpdeoY1GEChQI Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <osci@message> Content-Length: 123 ... --MIME_boundary_9MnMkzyjeaR9bguP9KZvpdeoY1GEChQI--

In order for this attack to work it was necessary to find a part of the MIME message that elicits a difference in attacker-observable behavior based on its content. The part we chose was the MIME header, specifically the colon character in the header line. Consider the following example:

SomeHeader123!"%:test
SomeHeader123!"%_test

The first line is parsed as a valid MIME header while the second line, due to the absence of a colon character, results in the message being rejected with an error message – that is perfect for an attack.

In this example we know that the last byte of the decrypted block 2 is a colon character. It is also known that the last character of the encrypted block 1 is “X”. Due to the structure of the CBC mode, the last byte for the block cipher decryption function for block two can be deducted. Now it is known that

Encrypted Block 1  XOR Decryption Function Output 2 = Decrypted Block 2

and therefore

Encrypted Block 1 (last byte)  XOR Decrypted Block 2 (last byte) = Decryption Function Output 2 (last byte)

In this case we can figure out that “X” XOR “:” = “b” – which is the last byte of the output of the block cipher decryption function for block 2.

When an attacker is able to figure out that a specific character in a decrypted text is a colon character, the corresponding byte of the decryption function output can be deducted. If the attacker manages to find all the bytes the decryption function produces for a message, the message can be decrypted easily.

Finding the Colon Character

In order to exploit this vulnerability, we replace the encrypted block of a header that contains the colon character with manipulated blocks. As the headers of an OSCI message are rather predictable, we can make a pretty good guess at which block number that is. When we send this message, three outcomes are possible (“X” represents random data other than ":", "\r" and "\n"):

Content-TypeXXXXXXXXXXXXXXXXtext/xml Content-TypeXXXXXXX:XXXXXXXXtext/xml Content-TypeXXXXXXX\r\nXXXXXXXtext/xml

In the first case, a parsing error would occur, as no colon character can be found in the manipulated header. In the second case, the header would be parsed and ignored – no error would occur. In the third case, a parsing error would occur. Note that the third case is rare, as two consecutive characters by chance would have to have specific values. We can therefore, for now, ignore this case.

Effectively, this means we have a way to figure out whether a decryption of a specific message fragment contains a colon character, even though we don’t know which character that is.

The Exploit

We have shown how leaked information about the plain text can allow an attacker to get the output of the decryption function. Futhermore, we have found a way to determine if the decryption of chosen cipher blocks contains a colon.  We can now piece those two facts together to write an exploit:

The exploit inserts 3 concatenated blocks into a MIME header (as described in the previous section). These three blocks are:

1. The test block: This block is initialized with random data. In each iteration one byte is specifically chosen to be modified.
2. The target block: The part of the original message that should be decrypted is inserted here.
3. The suffix block: This block contains random data.

The exploit conducts the following steps to decrypt a single byte:

1. Set the byte that should be decrypted to a known value in the test block (e.g. set the first byte to 0)
2. Send the blocks for decryption.
3. Because of the XOR operation of the CBC mode the byte in the test block influences the corresponding plain text byte in the decryption of the target block. From the server response we learn:
   1. If the server indicates that no colon character is in the header, it is certain that the tested byte did not produce a colon character in the decryption of the target block. We can remove one candidate for the plain text value.
   2. If the server indicates a colon character was found, we learn nothing – the colon character could occur in any decrypted block (e.g. also in the decryption of the test block or the suffix block).
4. The byte in the test block that was chosen in step 1 is changed to another value and execution continues at step 2.

After all possible byte values were tested, the set of possible plaintext characters has been reduced. Then, the test block and the suffix block are randomized and the process is started again. This operation is repeated until there is only one possibility left.

Lastly, several messages are sent that, based on the information gathered, should contain a colon character. If an error is recorded (i.e. the message contains no colon character) the whole process is restarted. This is to check for false positives (e.g. when \r\n was encountered at some point).

This process is repeated to gather all plaintext bytes of the message. This allows an attacker to bypass the request and response encryption of the OSCI-Transport protocol.

The Patch

The SEC Consult Vulnerability Lab reported the issues in September 2018 through CERT-Bund, who have been very helpful with coordinating vulnerabilities in the past. KoSIT and the software vendor Governikus then analyzed the vulnerabilities and privately provided a patch for the Java and .Net version to the affected organizations. In order to give affected parties enough time to apply the patch, SEC Consult has postponed the security advisory release to 5th February 2019.

It is strongly recommended to upgrade the OSCI-Transport Library to version 1.8.3 (Java or .Net). SEC Consult also highly recommends utilizing the GCM mode as soon as possible. For organizations that depend on the CBC mode it is highly recommended using TLS as an additional layer of security.

This research was conducted by Wolfgang Ettlinger (@ettisan) on behalf of SEC Consult Vulnerability Lab and has also been published as a security advisory.