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:Body Id="body">(original content here)</soap:Body>
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 . Due to a federal regulation, it is extensively used and the basis of multiple successful projects in Germany’s e-government .
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:
SEC Consult does not have precise data about the exact use of the OSCI transport library in practice4.
KoSIT released a patched version (1.7.1) of the OSCI library on 2017-03-13. In the course of fixing the vulnerabilities we found, KoSIT released an update to the specification  that (among other changes) allows implementers to use more secure encryption algorithms.
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 , 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.
This research was done by Wolfgang Ettlinger (@ettisan) and Marc Nimmerrichter (@mnimmerrichter) on behalf of SEC Consult Vulnerability Lab.
1 We modified the sample passive recipient to accept content encrypted messages and to disallow unsigned orders.
2 Of course an out of band XXE attack can be conducted as well. Firewall rules, however, might block outgoing traffic.
3 This element is exempt from this rule since it contains the signature; signing it too would create a chicken-and-egg dilemma.
4 The OSCI-transport protocol can be used in different communication scenarios. During our research we only looked at one of them (passive recipient). Many of OSCI’s security features (e.g. content encryption) are optional.