In this blog post we will go into some of the technical details of the vulnerabilities we identified in the OSCI Library version 1.6.1.

German readers can find a less-technical version of the article here.

The OSCI-transport protocol is used for data exchange between public agencies. It is the obligatory communication protocol for public administrations and therefore the basis for e-government in Germany [1]. It attempts to provide a secure channel [2] for communication between government agencies [3]. Right now the protocol is used in many different areas such as the population registration [4], the public health system [5] and the justice system (currently migrating to version 2.0) [6]. OSCI-transport claims to provide confidentiality, integrity, authenticity and non-repudiation for content exchanged even over insecure channels such as the Internet [1]. This, among other things, means that an attacker should not be able to read or manipulate messages.

A commonly used implementation of this protocol is the “OSCI-Transport” Java library [1]. It is mantained by the publisher of the protocol. This library has existed at least since 2004 [8].

In our latest advisory [9] we describe how we broke some of the security claims of the OSCI library. We demonstrate that an attacker can conduct an external XML Entity Injection (XXE) attack that allows him/her to read local files from systems of the communication partners. Moreover, an attacker with access to the communication channel can decrypt certain parts of a message and under specific circumstances potentially even forge messages. A full security audit has not been performed and it cannot be excluded that further vulnerabilities exist.

The OSCI protocol

In order to understand the vulnerabilities, we have to go a little into the technical details of the OSCI communication.

The OSCI protocol (version 1.2) is an XML-based protocol that is typically transferred over HTTP. It is a content-agnostic transport protocol for communication between government agencies. The communication is always routed through a central component called the Intermediary. In order to communicate, a Sender has to send a message to the Intermediary. In order for this message to then reach the Recipient, two scenarios are defined:

The Intermediary actively transmits the message to the server ( passive recipient ).

). The server connects to the Intermediary to collect its messages (active recipient).

To protect the transmitted messages, the OSCI protocol defines the following mechanisms:

The payload (the actual content of the message) is signed ( content signature ) with the author’s private key. This allows the recipient to verify the authenticity of the message.

) with the author’s private key. This allows the recipient to verify the authenticity of the message. The payload is encrypted ( content encryption ) with the final recipient’s public key. This assures that the payload can only be read by the actual recipient (not by the intermediary).

) with the final recipient’s public key. This assures that the payload can only be read by the actual recipient (not by the intermediary). The OSCI message including the payload is signed ( order signature ) using the sender’s (or the Intermediary’s) private key. This allows the intermediary or recipient to authenticate the sender and confirm that the message and metadata has not been altered.

) using the sender’s (or the Intermediary’s) private key. This allows the intermediary or recipient to authenticate the sender and confirm that the message and metadata has not been altered. The signed OSCI message is encrypted (order encryption) with the public key of the communication partner the message is directly sent to (i.e. the Intermediary or the final recipient). This assures that the communication between the sender and the intermediary or the Intermediary and the recipient cannot be read by an attacker.

All of these security mechanisms are optional.

Test setup

We conducted our tests against the version 1.6.1 of the Java OSCI library. This library’s source code can be obtained freely from the vendor page [10]. Unfortunately, this library does not contain all code necessary to create a complete test setup (i.e. the code for the Intermediary is not included). We therefore had to write dummy code to model the missing component. We tested our attacks against a slightly modified1 sample implementation of a passive recipient that is also provided with the library ( de.osci.osci12.samples.PassiveRecipient ).

SEC Consult did not test production systems or applications using OSCI. Mitigating factors might exist in some environments. We did not conduct a full security review but rather a superficial check. We therefore cannot rule out that further vulnerabilities or attack scenarios exist.

Vulnerabilities

From the point of view of an attacker, there are two main approaches for an attack:

Attacks against the communication partners: An attacker tries to send manipulated OSCI-messages to the communication partners in order to compromise them.

Attacks on the communication: An attacker has access to the encrypted and signed OSCI-messages. An attacker tries to decrypt or manipulate them.

SEC Consult found vulnerabilities in version 1.6.1 of the OSCI-transport library. These vulnerabilities were verified in at least one OSCI communication scenario4. Since the vulnerabilities may affect critical e-Government infrastructure, we will refrain from providing exploit code.

The following section refers to version 1.6.1 of the OSCI-transport Java library.

Attacking OSCI servers

The XML standard, which the OSCI message format is based on, includes a feature allowing the inclusion of external content (“external entities”). Parsers that have this feature turned on are usually vulnerable to external entity injection (XXE). The OSCI library has this feature explicitly enabled and is therefore vulnerable to this attack. Besides other security impacts such as denial-of-service, this vulnerability could allow an attacker to read files from the system. However, as with any XXE vulnerability there are restrictions: If the file contains specific characters (e.g. &, non-printable characters) an attacker cannot retrieve them.

For this attack to work, the attacker does not need to have access to an original message. For the passive recipient scenario, the attacker just needs to reach an OSCI participant over the network.

In order to conduct an XML External Entity Injection (XXE) attack we used the OSCI Challenge-Response feature. This feature allows a sender to specify an arbitrary value in the Challenge element. The recipient has to specify this value in the Response element of the OSCI response. Naturally, this behavior is perfect for in-band XXE attacks since we can use an external entity reference in the Challenge element and get the referenced data (e.g. a local file) in the Response element2.

In the passive recipient sample code, we verified that an attacker could send an unencrypted unsigned message to an OSCI service to read arbitrary files from the OSCI service’s file system.

One practical limitation we considered is that an OSCI service might respond with an error message if the incoming message is neither signed nor encrypted. If an unsigned message is received while a signed message was expected, the specification defines that the service has to respond with an error code 9600 [11]. However, when this error occurs, according to the specification, the service still has to respond to a Challenge element, therefore reflecting our external entity inclusion. The specification does neither specify that implementations should check whether the client chose to encrypt a message ([11] section 5) nor does it define an error code for this case. When the request is not encrypted, the library does not encrypt response messages. The attacker is therefore always able to read the response.

Moreover, an external entity resolving XML parser is also exposed in a Java deserialization gadget. This means that the XXE vulnerability might be exploitable through completely different channels. The requirements for an application to be vulnerable are:

that it deserializes data from untrusted sources and

that the vulnerable OSCI library is in the application’s classpath

If these conditions are met, an attacker could conduct an out-of-band XXE attack by sending crafted serialized data to the application. More information on vulnerable deserialization methods can be found here

Attacking OSCI messages

SEC Consult does not have a holistic view on the impact, since only the OSCI-transport library, but no applications using it were available for testing. Mitigating factors or even security features that we did not consider might exist in OSCI-applications or their infrastructure to prevent successful exploitation. However, we were able to verify the vulnerabilities using a slightly modified version1 of the passive recipient sample code. A full security audit has not been performed and it cannot be excluded that further vulnerabilities exist.

In this section, we describe a scenario where an attacker is able to sniff encrypted OSCI messages. Since the communication channel is considered to be insecure, this is a legitimate attack assumption.

The following diagram illustrates the attack scenario we refer to in this section:

Breaking order encryption

The first security layer to circumvent is the transport encryption. Let’s have a look at the supported encryption schemes:

3DES-CBC

AES-128-CBC

AES-192-CBC

AES-256-CBC

We can see that OSCI only supports block ciphers in CBC mode. When this mode is used incorrectly, several attacks are possible (the W3C no longer recommends to use those ciphers [7]). The most straight-forward attack against CBC is a padding oracle attack. To conduct such an attack the attacker has to send invalid encrypted data to the recipient. The recipient is vulnerable to padding oracle if it reveals whether the decrypted message has the correct format (i.e. has a valid padding). A successful exploitation would allow an attacker to decrypt any encrypted messages.

As the OSCI standard specifies and the OSCI library implements, there is a special error code for failed decryption (in this case indicating that the padding is invalid). So in order to break the transport encryption, we were able to implement a simple padding oracle attack.

Practical applicability

Since roughly 128 requests are required to decrypt a single byte, one might assume that this attack cannot be applied in practice. However, we have created an optimized version of this script that runs significantly faster: It prefers more common bytes (i.e. digits, letters, printable characters).

It tries to predict the contents of blocks based on previous blocks (e.g. the block xmlns:ds="http:/ is very likely followed by the block /www.w3.org/2000 ) In our test setup we were able to decrypt an OSCI processDelivery message on a local machine within half an hour.