Multiple Vulnerabilities In OSCI-transport Library 1.2 For German E-government

A blog post with further information has been released on this topic as well: https://r.sec-consult.com/osci

Vendor Description

(German)
“Mit der Spezifikation des Protokolls OSCI–Transport in der Version 1.2 wird ein sicheres, herstellerunabhängiges und interoperables Datenaustauschformat beschrieben.

Um die Implementierung für Anwender in der öffentlichen Verwaltung sowie der Fachverfahrenshersteller zu erleichtern, wird die OSCI 1.2 Bibliothek angeboten:

Die Bibliothek implementiert OSCI–Transport in der Version 1.2 und ist damit unabhängig von Fachinhalten. Sie ist Bestandteil der OSCI-Transport Infrastruktur. Die OSCI-Transport-Bibliothek soll in Fachverfahren (auf Verwaltungsseite) oder Clientsystemen (auf Kundenseite) implementiert werden.”

Source: https://www.xoev.de/die_standards/osci_transport/osci_transport_1_2/osci_1_2_bibliothek-2310

Business Recommendation

The OSCI 1.2 Transport Library is intended to provide a secure message exchange channel over an untrusted network (i.e. the Internet) for German government agencies.

In 2017 SEC Consult found several critical security vulnerabilities in the OSCI 1.2 Transport library version 1.6.1. These vulnerabilities have been addressed in version 1.7.1. Further details to these vulnerabilities can be found here:https://r.sec-consult.com/osci

In 2018 SEC Consult identified vulnerabilities in this library again. An attacker could use these vulnerabilities to forge signatures of request-and-response-signed and request-and-response-encrypted messages. Whether there is an impact to the content-signature and content-encryption was not fully examined!

As the newly identified vulnerabilities are similar to the vulnerabilities identified in 2017 and due to high complexity of this library, SEC Consult suspects further vulnerabilities that have not yet been discovered.

Therefore, SEC Consult, strongly recommends KoSIT and its partners to conduct a full security audit of the software component.

Vulnerability Overview / Description

1) Insecure Cryptographic Algorithm

KoSIT is in the process of replacing legacy encryption algorithms with AES-GCM. Currently, the OCSI 1.2 Transport library still supports the following legacy encryption algorithms:

• http://www.w3.org/2001/04/xmlenc#tripledes-cbc
• http://www.w3.org/2001/04/xmlenc#aes128-cbc
• http://www.w3.org/2001/04/xmlenc#aes192-cbc
• http://www.w3.org/2001/04/xmlenc#aes256-cbc

All of these algorithms are no longer recommended by the W3C:
“Note: Use of AES GCM is strongly recommended over any CBC block encryption algorithms as recent advances in cryptanalysis […] have cast doubt on the ability of CBC block encryption algorithms to protect plain text when used with XML Encryption” (https://www.w3.org/TR/xmlenc-core1/)

Although these have been marked as deprecated, AES256-CBC is still used by default (see Constants.DEFAULT_SYMMETRIC_CIPHER_ALGORITHM).

The Padding Oracle attack that was demonstrated previously by SEC Consult was found to be no longer exploitable trivially. However, another approach was found that allows an attacker to bypass transport encryption.

This attack abuses the fact that the server leaks whether a decrypted string contains a colon (more specifically whether it is a valid MIME-Header in the form of <name>:<value>).

By sending multiple requests and observing whether the decrypted string contains a colon, an attacker can narrow down the possible values for a single plain text character. When the number of possible values is one, the plain text byte is known. The attacker can use this approach to decrypt all characters of a given cipher text.

2) Signature Bypass

SEC Consult previously demonstrated an XML Signature Wrapping attack. While this exact attack is no longer possible, another similar attack was identified. XML signatures are constructed as follows:

• an element “SignedInfo” contains multiple “Reference” elements, each referring to a signed element. The contents of each element that is to be signed is hashed. This hash is then recorded in a Reference element. Any modification of a signed element would result in a modified hash, thus invalidating the signature.
• A cryptographic signature is calculated over the whole SignedInfo element.

When the library checks the signature, it not only considers “Reference” elements in the “SignedInfo” element but also “Reference” elements that occur anywhere in the document. When checking the cryptographic signature, only the “SignedInfo” element is considered. An attacker can therefore introduce a new “Reference” element into an existing document with a valid signature. Any element that this unsignend “Reference” refers to is considered to be signed.

Proof Of Concept

1) Insecure Cryptographic Algorithm

The content of an request-and-response-encrypted message is formated as a MIME object. When an attacker modifies the encrypted message in a specific way, he can cause a header in the MIME message to become invalid. This occurs if the colon used to separate the header name from the header value is not found in the header. In this case the library responds with an error 9202.

An attacker can replace the encrypted block that contains the colon character in the decryption with different encrypted blocks. In this case three cases are possible (X represents random characters):

1. Content-TypeXXXXXXXXXXXXtext/xml
2. Content-TypeXXXXX:XXXXXXXtext/xml
3. Content-TypeXXXXX\r\nXXXXXXXtext/xml

In case 1 and 3, the library responds with an error. In case 2, no error occurs. Case 3 can, to some degree, be ignored as it is less likely that two characters (\r\n) take on those specific values.

An attacker is therefore able to find out whether the blocks inserted decrypt to a text that contains a colon character.

The attacker can insert 3 blocks into a MIME header:

1. test block: initialized with random data; for each iteration one byte is specifically chosen.
2. target block: part of the message that should be decrypted; goal is to find the output of the decryption function that is produced for this input block.
3. suffix block: random data

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

1. Set 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. From the server response we learn:
   1. no colon character is in the header: the tested byte did not produce a colon character; remove the tested byte value as a candidate
   2. a colon character was found: we learn nothing
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 characters that could produce a colon character 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, with the information gathered, should contain a colon character. This is to check for false positives (e.g. when \r\n was produced).

2) Signature Bypass

The following shows the structure of an unmodified message:

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

The following shows the structure of a modified document with a valid signature:

<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>

The parser first finds the original Reference element to the original body and stores the found digest value. When the inserted Reference element is encountered, this digest value is overwritten.

When the Body element is verified, the modified digest (supplied by the attacker) is compared to the actual digest of the Body element.

When the SignedInfo element is verified against the SignatureValue value, the inserted Reference is not considered. The verification therefore only considers the unmodified original SignedInfo element.

Vulnerable / Tested Versions

The version 1.8.1 was found to be vulnerable. This version was the latest at the time of discovery.