Attack description

Usually the data signed is embedded within the SOAP Body and is referenced via the "Id" attribute. The signed data is contained in a Simple Ancestory Context - that is why we refer to this attack subtype as "XML Signature Wrapping - Simple Context"
During signature validation the validator resolves the reference within the <Reference> element and verifies the signature, returning a boolean value. In case of a positive signature verification, the application logic starts processing the SOAP message. In case of a negative signature verification the the message gets discarded. Under regular circumstances manipulation of the signed data always gets detected.

However, it is possible to change the content of the signed data without invalidating the signature.
Refer to the example below for a detailed attack description.

Note: Make sure to read the prerequisites of the attack to understand in what scenarios this attack works.

Attack subtypes

There are no attack subtypes for this attack.

Prerequisites for attack

In order for this attack to work the attacker has to have knowledge about the following things:

Attacker knows endpoint of web service. otherwise he is not able to reach the web service.

Attacker knows that the web web service processes the security header and the "signature" element. If the web service doens't "expect" a signed part, it just discards the signature and the attack doesn't work.

Attacker can reach endpoint from its location. Access to the attacked web service is required. If the web service is only available to users within a certain network of a company, this attack is limited.

Signed data is a mandatory element outside of the Security Header.

Graphical representation of attack

Red = attacked web service component

Black = location of attacker

Blue = web service component not directly involved in attack.

Attack example

All examples taken from[1].
Listing 1 shows a valid unmodified SOAP message. The entire SOAP Body is signed, as shown by the line <ds:Reference URI="#theBody"> within the SOAP Header.

The XML Signature verification algorithm starts looking for the element with the id "theBody", as stated in the <Reference> element.

Eventually it will find the <soap:Header> Element wrapped within the <wrapper> element. The "real" <soap:Body>, outside of the <soap:Header>, gets ignored since it has the wrong "id".

Signature verification will be performed on the <soap:Header> within the <wrapper> element. signature verification will be positive, since it contains the original SOAP Body that got signed by the sender.

The SOAP message gets passed to the application logic. The application logic only processes the SOAP Body that is directly placed under the SOAP Header. All other SOAP Body elements are just ignored.

Practical attacks were shown by Somorovsky et al.[2], who showed how to attack cloud interfaces of Amazon and Eucalyptus cloud providers. This enabled them to execute arbitrary methods on cloud interfaces.

Attack mitigation / countermeasures

The attack worked because of two major flaws:

The position of the signed data was not fixed within the XML document. Horizontal and vertical movement within the XML document was possible without invalidating the signature.

XML Signature Verification and processing by the application logic are two different processes that validate/process data according to their one point of views.

Various countermeasures were proposed. Strategies to defend the against this specific scenario, with the SOAP Body signed, are as follows:

Strategy:define a strict security policy

the element specified by /soap:Envelope/soap:Body must be signed using WSS with XML Signature, and

the associated signature verification key must be provided by an X.509v3 certificate issued by one of a set of trusted Certificate Authorities (CAs) (this part is not Signature Wrapping specific!)

NOTE: These countermeasures only apply to this specific attack scenario. Make sure that your scenario matches the scenario described abve.
Otherwise your application might be vulnerable.

Attack categorisation

Categorisation by violated security objective

The attack aims at exhausting the system resources, therefore it violates the security objective Availability.