Hacking SAML Part: 4

Continuing with XML Signature Wrapping (XSW)…

XML Signature Wrapping (XSW) :

Description : XML Signature Wrapping (XSW) is a well-known attack vector that targets XML-based applications, particularly those utilizing XML Signature for securing messages, such as in web services or SAML (Security Assertion Markup Language) systems. This attack exploits vulnerabilities in the XML structure and signature verification process, allowing an attacker to tamper with critical data without invalidating the XML Signature.

In an XSW attack, the attacker exploits the fact that many XML parsers process and resolve the structure of XML documents in an insecure way. The attacker manipulates the document by duplicating or reordering XML elements, effectively tricking the application into validating a benign part of the document while executing maliciously altered content elsewhere.

Overview and the steps in an XSW Attack :

Locate Signed Element: The attacker identifies an XML element that is signed and has critical security or application data.
Duplicate the Signed Element: The attacker creates a duplicate of the signed element and places it elsewhere in the document structure.
Modify the Duplicate: The attacker changes the data in the duplicate element, which is not directly referenced by the Reference tag in the “SignedInfo” section.
Redirect Application Logic: By exploiting weaknesses in how the application processes XML, the attacker ensures that the modified, unsigned element is used during execution while the original signed element is used for signature verification.
Pass Signature Validation: Since the signature verification process only checks the original signed element, the signature appears valid, even though the application is acting on tampered data.

Types of XSW Attack :

We can classify our XSW Attack in 3 major types :

Simple Signature Wrapping: In a basic signature-wrapping attack, an attacker manipulates the XML document by adding or altering elements while keeping the original signature intact. The goal is to trick the system into accepting unauthorized changes without invalidating the signature. For example, consider an XML document for a fund transfer that contains a valid signature. The attacker inserts a new section, such as "transfer" with modified transaction details but leaves the original signature untouched. If the system doesn’t properly validate the entire XML structure, it could process the altered transaction in the malicious section, leading to unauthorized actions.

      <transfer>
        <amount>100</amount>
        <accountInfo>
             <To>1234</To>
             <From>9876</Form>
        </accountInfo>
        <signature>.....................</signature>
      </transfer>
      // Malicious data injected by attacker
      <transfer>
        <amount>9000</amount>
        <accountInfo>
             <To>1234</To>
             <From>9876</Form>
        </accountInfo>
      </transfer>

Wrapped Signature Key: In this type of attack, the attacker encloses the original XML signature along with a tampered version of the data, effectively "wrapping" it in a new structure. The goal is to deceive the system into validating the wrapped signature, which leads to accepting unauthorized changes. For instance, the attacker places the original XML signature and a new section, inside a “signaturewrapper” element. If the system fails to properly validate the structure or ensure the signature applies only to the intended data, it might process the unauthorized changes in the malicious section.

      <transfer>
        <amount>100</amount>
        <accountInfo>
             <To>1234</To>
             <From>9876</Form>
        </accountInfo>
        <signaturewrapper> <!--Started-->
         <signature>.....................</signature>
          <amount>9000</amount>
           <accountInfo>
             <To>1234</To>
             <From>9876</Form>
           </accountInfo>
       </signaturewrapper> <!--End of signature wrapping-->
       </transfer>

Multi-Reference Attack: In a multi-reference attack, the attacker adds multiple references to the XML signature, each pointing to different parts of the document. This tactic aims to confuse the validation process and make the system accept unauthorized changes. For example, the attacker includes references to both an “amount” section and a “attacker” section within the XML signature. If the system doesn’t handle multiple references correctly, it might only validate certain parts of the document while overlooking others, allowing the malicious changes to go through undetected.

      <transfer>
        <amount>100</amount>
        <accountInfo>
             <To>1234</To>
             <From>9876</Form>
        </accountInfo>
         <signature>
           <Ref uri = "#amount">
           <Ref uri = "#attacker">  <!--refering to the malicious XML input-->
         </signature>
       </transfer>
      <attacker>
        <amount>9000</amount>
        <accountInfo>
             <To>1234</To>
             <From>9876</Form>
        </accountInfo>
       </attacker>

Remediation :

Strict ID Reference Validation: Ensure that referenced elements match the signed elements exactly, both in content and location.
Canonicalization Best Practices: Use proper canonicalization methods to ensure that the signed data is unambiguously identified.
Signature Validation Libraries: Use well-audited XML signature libraries and frameworks.
Input Validation: Validate the entire XML document structure before processing, rejecting documents with duplicated or unexpected elements.
Unique IDs: Enforce strict uniqueness for ID attributes in XML documents.
XML Schema Validation: Validate the XML against a secure schema that restricts unexpected structures.

*Happy Hacking ……………………………………………. SAML ….*🎉..🚀..🔒..💻

Hacking SAML Part: 4

Let's hack it..............................................

XML Signature Wrapping (XSW) :