Attack description

The idea of XML Signature Wrapping (XSW) is to exploit the separation between SSO Verificator and SSO Processor. In case both logics have different "views" of the same document, XSW can be applicable. The goal is to force the SSO Verificator to use different elements than the SSO Processor.

The attack targets the discrepancy in the program logic of SSO Verificator and SSO Processor. The latter should extract and forward only exactly the data verified by the former to Authorization & Access Management (AAM).

Attack subtypes

Prerequisites for attack

The attacker needs access to a valid token. For this attack to work, the attacker modifies the contents of the token by injecting malicious data without invalidating the signature.

Graphical representation of attack

The authentication token is signed for a user Bob. Via XSW the attacker can inject a second Assertion containing another identity (e.g. admin). The verification logic will verify the Assertion pointed by the Ref, which is valid. The business logic (SSO Processor) will process the injected (malicious) Assertion.

The SSO Verificator will verify the signature based on the contents of the original Assertion, which is selected by ID. However, if the SSO Processor’s program logic automatically process the first Assertion found within the token, an attacker can bypass the integrity protection and enforce the processing of unverified data on the SaaS-CP.

Attack example

The attacker manipulates his token by injecting malicious contents, for example, the identity I of other users. As a result, the attacker can log into arbitrary user accounts and gain unauthorized access to their data.

Attack mitigation / countermeasures

The countermeasure approach would be to enhance the interface between the signature verification function and the business logic. In this approach, the signature verification returns some sort of position description of the signed data, next to a Boolean value. The business logic may then decide if the data about to be processed has been signed or not.

Practical Attack Examples

In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Zoho, Clarizen, SAManage, Instructure, AppDynamics, Panopto, TimeOffManager, HappyFox, SpringCM, ScreenSteps Live and LiveHive.

References

C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).
Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, and Luigi Lo Iacono. All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces. In The ACM Cloud Computing Security Workshop (CCSW), October 2011.
Juraj Somorovsky, Andreas Mayer, Jörg Schwenk, Marco Kampmann, and Meiko Jensen. On breaking saml: Be whoever you want to be. In 21st USENIX Security Symposium, Bellevue, WA, August 2012.