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.
- 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).
- 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.
- 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
- 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.
The following section refers to version 1.6.1 of the OSCI-transport Java library.
Attacking OSCI servers
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
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.
Demonstration of an optimized padding oracle attack script.
Bypassing order signature verification
OSCI uses XML signatures to provide authenticity. In the past, the go-to attack against XML signatures has been XML signature wrapping. Naturally, this was the first attack we tried.
To do so, we first examined which parts of the XML content are signed and how the verifying application accesses signed content. If the recipient application can be tricked into verifying one part of the XML message, while actually using another part for further processing, it is vulnerable to XML signature wrapping. The OSCI library uses a plain SAXParser, which means that a lot of parsing logic is implemented by the library itself. This might provide more flexibility and better performance, but this approach is also prone to implementation errors.
The following shows a schematic representation of a signed OSCI order:
<soap:Envelope>
<soap:Header>
<osci:ControlBlock>...</osci:ControlBlock>
<osci:ClientSignature>
<ds:Signature>
<ds:Reference URI="#body">...</ds:Reference>
</ds:Signature>
</osci:ClientSignature>
<osci:DesiredLanguages />
<osci:processDelivery />
<osci:IntermediaryCertificates>...</osci:IntermediaryCertificates>
<osci:NonIntermediaryCertificates>...</osci:NonIntermediaryCertificates>
</osci:Header>
<soap:Body Id="body">(original content here)</soap:Body>
</soap:envelope>
The message header contains an XML signature (the ds:Signature element). The ds:Reference element's URI attribute describes which parts of the XML document are signed. In this case it refers to the element with the id "body" which is in this case the soap:Body element. To forge the contents of the SOAP Body we need to create a request with two SOAP Bodies. We need to make sure the parser checks the signature of the original SOAP body while the code that actually processes the contents of the SOAP Body uses our second manipulated body.
The library shows the following behavior:
- All elements underneath the SOAP header except for the ClientSignature element3 have to be signed.
- The SOAP Body has to be signed too.
- The library is supposed to check that IDs within the document are unique - there is a bug that renders this check ineffective. In practice this means that the last element with a given ID is used for signature verification.
- For further processing the SOAP Body is expected to be just below the SOAP Envelope element. For signature verification, the SOAP Body can be anywhere in the document.
We were able to abuse this bug to successfully conduct an XML signature wrapping attack.
How these vulnerabilities affect OSCI security
As we have shown, we were able to completely circumvent the security mechanisms on the order level (order signature, order encryption). If all OSCI security measures are used, an attacker could decrypt the order data (metadata) and use a signature wrapping attack to modify orders (metadata).
However, if certain OSCI security features are not used, we found several scenarios with a high security impact:
- If content signature is not used, an attacker could exchange encrypted payload with different encrypted payload while preserving the validity of the original signature. The attacker is able to create encrypted content, because asymmetric encryption is used and the public key certificate of the recipient is included in the message. This applies similarly to order encryption. We have verified this fictitious attack scenario to work with the sample passive recipient provided with the OSCI library.
- If content encryption is not used, an attacker could retrieve the plaintext payload after using padding oracle to bypass order encryption.
- If a communication scenario only relies on order level security features, an attacker could retrieve and modify any transferred payload.
SEC Consult does not have quantitative data on how OSCI is used in practice (communication scenarios, utilized security features). We therefore are unable to estimate the practical impact.
Who is affected?
According to KoSIT, the OSCI-transport protocol is the technical foundation of e-government in Germany and was made an obligatory standard for electronic transactions in federal administration [1]. Due to a federal regulation, it is extensively used and the basis of multiple successful projects in Germany's e-government [1].
Due to the role of this protocol in Germany's e-government strategy, we assume that multiple administrations use OSCI-transport and the affected library.
The XOEV website lists public standards, some of which use OSCI-transport 1.2, for example:
- XÖGD (public health care)
- Xpersonenstand (civil status of persons)
- Xhoheitliche Dokumente (sovereign documents)
- XMeld (population registration)
- XJustiz (electronic legal data-exchange) (currently migrating to OSCI 2.0)
SEC Consult does not have precise data about the exact use of the OSCI transport library in practice4.
Recommendations
KoSIT informed affected users of the library. SEC Consult does not have information on the patching process.
SEC Consult coordinated the release of the advisory with KoSIT, Governikus KG and the BSI. KoSIT, BSI, Governikus KG and SEC Consult recommend all affected parties to upgrade the OSCI library as soon as possible.
Moreover, SEC Consult recommends to encapsulate OSCI communication in well established and secure transport protocols (e.g. IPSec, TLS).
Since the first version of the library has been released in 2004 [8], SEC Consult assumes that vulnerable versions of the OSCI library have been used for quite a while. SEC Consult recommends to gather evidence of a potential compromise through a forensic analysis. SEC Consult does not have any information on whether attacks have already happened.
*****
