OSCI-Transport Library 1.2 1.8.1 Insecure Crypto / Signature Bypass

`A blog post with further information has been released on this topic as well:  
https://r.sec-consult.com/osci  
  
  
SEC Consult Vulnerability Lab Security Advisory < 20190205-0 >  
=======================================================================  
title: Multiple vulnerabilities  
product: OSCI-Transport Library 1.2 for German e-Government  
vulnerable version: <=1.8.1  
fixed version: 1.8.3  
CVE number: -  
impact: low - critical  
(highly dependent on the usage scenario)  
homepage: http://www.xoev.de  
found: 2018-09  
by: W. Ettlinger (Office Vienna)  
SEC Consult Vulnerability Lab  
  
An integrated part of SEC Consult  
Europe | Asia | North America  
  
https://www.sec-consult.com  
  
=======================================================================  
  
Vendor description:  
-------------------  
(German)  
"Mit der Spezifikation des Protokolls OSCIaTransport in der Version 1.2 wird ein  
sicheres, herstellerunabhA$?ngiges und interoperables Datenaustauschformat  
beschrieben.  
  
Um die Implementierung fA1/4r Anwender in der APffentlichen Verwaltung sowie der  
Fachverfahrenshersteller zu erleichtern, wird die OSCI 1.2 Bibliothek angeboten:  
  
Die Bibliothek implementiert OSCIaTransport in der Version 1.2 und ist damit  
unabhA$?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://www.sec-consult.com/en/blog/2017/06/german-e-government-details-vulnerabilities/  
  
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:  
- no colon character is in the header: the tested byte did not produce a  
colon character; remove the tested byte value as a candidate  
- 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:  
----- snip -----  
<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>  
----- snip -----  
  
The following shows the structure of a modified document with a valid signature:  
----- snip -----  
<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>  
----- snip -----  
  
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.  
  
  
Vendor contact timeline:  
------------------------  
2018-09-17: Contacting CERT-Bund, asking for help with coordination  
2018-09-17: CERT-Bund: advisory has been sent to vendor; offer to exchange  
contact information to directly coordinate with vendor  
2018-09-17: Providing contact information  
2018-09-28: Asking for contact information  
2018-09-28: CERT-Bund: vendor did not respond to vulnerability report yet  
2018-10-10: Asking for update  
2018-10-12: CERT-Bund: asked vendor again; still no response  
2018-10-16: Asking CERT-Bund to relay that we are considering a non-coordinated  
release around 2018-11-06  
2018-10-17: CERT-Bund: Deadline has again been communicated to vendor  
2018-10-23: No response from vendor; setting release date to 2018-11-29  
2018-10-24: CERT-Bund: Response from vendor: patched version available  
2018-10-25 (Java), 2018-11-05 (.Net); KoSIT asks to delay release  
of the advisory to 2019  
2018-10-25: CERT-Bund: KoSIT proposed release date 2019-02-01  
2018-10-25: Setting release date 2019-02-05  
2019-01-16: Call with Governikus regarding upcoming coordinated advisory release  
2019-01-22: Sending blog post draft to Governikus  
2019-01-24: Received blog post feedback and statements by KoSIT that are to be  
released  
2019-01-29: Sending feedback to KoSIT's statements  
2019-02-05: Public release of the advisory  
  
  
Solution:  
---------  
Upgrade to the latest version of the library (1.8.3).  
  
  
Workaround:  
-----------  
None  
  
  
Advisory URL:  
-------------  
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html  
  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
SEC Consult Vulnerability Lab  
  
SEC Consult  
Europe | Asia | North America  
  
About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It  
ensures the continued knowledge gain of SEC Consult in the field of network  
and application security to stay ahead of the attacker. The SEC Consult  
Vulnerability Lab supports high-quality penetration testing and the evaluation  
of new offensive and defensive technologies for our customers. Hence our  
customers obtain the most current information about vulnerabilities and valid  
recommendation about the risk profile of new technologies.  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://www.sec-consult.com/en/career/index.html  
  
Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://www.sec-consult.com/en/contact/index.html  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
Mail: research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: http://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult  
  
EOF W. Ettlinger / @2019  
  
`