OSCI-Transport Library 1.2 for German e-Government versions 1.8.1 and below suffer from an insecure cryptographic implementation and signature bypass vulnerabilities.
7d8dfcb6bbea4a458be7237a76e44121A 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