Message-ID: <da8c634a-7bdf-4f30-7f68-a5b6d73557cc@sec-consult.com>
Date: Tue, 5 Feb 2019 12:12:29 +0100
From: SEC Consult Vulnerability Lab <research@...-consult.com>
To: <bugtraq@...urityfocus.com>, <fulldisclosure@...lists.org>
Subject: SEC Consult SA-20190205-0 :: 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


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


Download attachment "smime.p7s" of type "application/pkcs7-signature" (3995 bytes)

Powered by blists - more mailing lists