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 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://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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
