XML Signature Wrapping: Difference between revisions

From Single Sign-On Attacks
Jump to navigation Jump to search
(Created page with "=Attack description= =Attack subtypes= =Prerequisites for attack= =Graphical representation of attack= =Attack example= =Attack mitigation / countermeasures= =Prac...")
 
No edit summary
Line 1: Line 1:
=Attack description=
=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)''.




Line 6: Line 13:


=Prerequisites for attack=
=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=
=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.
[[File:XML_Signature_Wrapping.jpg|centre]]
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=
=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=
=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.


=Practical Attack Examples=


[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]


=References=
=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).
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). <br>
[https://hgi.rub.de/media/nds/veroeffentlichungen/2011/10/22/AmazonSignatureWrapping.pdf 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.] <br>
[https://www.nds.rub.de/media/nds/veroeffentlichungen/2012/08/22/BreakingSAML_3.pdf 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.]

Revision as of 21:33, 7 January 2016

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.