# Ataques SAML
## Ataques SAML
Aprende hacking en AWS de cero a h茅roe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF**, consulta los [**PLANES DE SUSCRIPCI脫N**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colecci贸n de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **脷nete al** 馃挰 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **s铆gueme** en **Twitter** 馃惁 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
## Informaci贸n B谩sica
{% content-ref url="saml-basics.md" %}
[saml-basics.md](saml-basics.md)
{% endcontent-ref %}
## Gr谩fico de Ataques
![](<../../.gitbook/assets/image (535) (1) (1) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (13).png>)
## Herramienta
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Una herramienta que puede tomar una URL o lista de URL y devuelve la URL de consumo de SAML.
## Viaje de ida y vuelta en XML
En XML, la parte firmada del XML se guarda en memoria, luego se realiza alguna codificaci贸n/decodificaci贸n y se verifica la firma. Idealmente, esa codificaci贸n/decodificaci贸n no deber铆a cambiar los datos, pero bas谩ndose en ese escenario, **los datos que se est谩n verificando y los datos originales podr铆an no ser los mismos**.
Por ejemplo, revisa el siguiente c贸digo:
```ruby
require 'rexml/document'
doc = REXML::Document.new <]>
XML
puts "First child in original doc: " + doc.root.elements[1].name
doc = REXML::Document.new doc.to_s
puts "First child after round-trip: " + doc.root.elements[1].name
```
Ejecutar el programa contra REXML 3.2.4 o versiones anteriores resultar铆a en la siguiente salida en su lugar:
```
First child in original doc: Y
First child after round-trip: Z
```
As铆 es como REXML vio el documento XML original del programa anterior:
![](<../../.gitbook/assets/image (561).png>)
Y as铆 es como lo vio despu茅s de una ronda de an谩lisis y serializaci贸n:
![](<../../.gitbook/assets/image (562).png>)
Para m谩s informaci贸n sobre la vulnerabilidad y c贸mo explotarla:
* [https://mattermost.com/blog/securing-xml-implementations-across-the-web/](https://mattermost.com/blog/securing-xml-implementations-across-the-web/)
* [https://joonas.fi/2021/08/saml-is-insecure-by-design/](https://joonas.fi/2021/08/saml-is-insecure-by-design/)
## Ataques de Envoltura de Firma XML
Los documentos XML que contienen Firmas XML t铆picamente se **procesan en dos pasos independientes**: **validaci贸n de firma** y **invocaci贸n de funci贸n** (l贸gica de negocio). Si ambos m贸dulos tienen diferentes perspectivas sobre los datos, existe una nueva clase de vulnerabilidades llamadas ataques de Envoltura de Firma XML (XSW).\
En estos ataques, el **adversario** **modifica** la **estructura del mensaje** **inyectando** elementos **falsificados que no invalidan la Firma XML**. El objetivo de esta alteraci贸n es cambiar el mensaje de tal manera que la **l贸gica de la aplicaci贸n y el m贸dulo de verificaci贸n de la firma usen diferentes partes del mensaje**. En consecuencia, el receptor verifica la Firma XML con 茅xito pero la l贸gica de la aplicaci贸n procesa el elemento falso. El **atacante as铆 elude la protecci贸n de la integridad** y la autenticaci贸n de origen de la Firma XML y puede inyectar contenido arbitrario.
Del pedido SAML:
![](<../../.gitbook/assets/image (537).png>)
### XSW #1
Un atacante puede **a帽adir un nuevo elemento ra铆z donde se encuentra la firma**. Por lo tanto, cuando el validador verifica la integridad de la firma, puede notar que ha **verificado** la **integridad** de **Response -> Assertion -> Subject**, y podr铆a confundirse con la **nueva ruta maliciosa Response -> Assertion -> Subject** en rojo y usar sus datos.
![](<../../.gitbook/assets/image (538).png>)
### XSW #2
La diferencia con el #1 es que el tipo de Firma utilizada es una **firma desligada** donde XSW #1 us贸 una firma envolvente.\
Nota c贸mo la nueva estructura maliciosa es la misma que antes tratando de confundir la l贸gica de negocio despu茅s de que se realiz贸 la verificaci贸n de integridad.
![](<../../.gitbook/assets/image (539).png>)
### XSW #3
En este ataque se crea una **Assertion maliciosa al mismo nivel** que la original para intentar confundir la l贸gica de negocio y usar los datos maliciosos.
![](<../../.gitbook/assets/image (540).png>)
### XSW #4
XSW #4 es similar al #3, excepto que en este caso la **Assertion original se convierte en hija** de la Assertion copiada.
![](<../../.gitbook/assets/image (541).png>)
### XSW #5
En XSW #5 la Firma y la Assertion original no est谩n en una de las tres configuraciones est谩ndar (envuelta/envolvente/desligada). En este caso, la Assertion copiada envuelve la Firma.
![](<../../.gitbook/assets/image (542).png>)
### XSW #6
XSW #6 inserta su Assertion copiada en la misma ubicaci贸n que los n煤meros 4 y 5. Lo interesante aqu铆 es que la Assertion copiada envuelve la Firma, que a su vez envuelve la Assertion original.
![](<../../.gitbook/assets/image (543).png>)
### XSW #7
XSW #7 inserta un elemento **Extensions** y a帽ade la **Assertion** copiada como **hija**. Extensions es un elemento XML v谩lido con una **definici贸n de esquema menos restrictiva**. Los autores de este [white paper](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf) desarrollaron este m茅todo en respuesta a la biblioteca OpenSAML. OpenSAML utilizaba la validaci贸n de esquema para comparar correctamente el ID utilizado durante la validaci贸n de la firma con el ID de la Assertion procesada. Los autores encontraron que en casos donde las Assertions copiadas con el mismo ID de la Assertion original eran hijas de un elemento con una definici贸n de esquema menos restrictiva, lograron eludir esta contramedida en particular.
![](<../../.gitbook/assets/image (544).png>)
### XSW #8
XSW #8 utiliza otro elemento XML **menos restrictivo** para realizar una variaci贸n del patr贸n de ataque utilizado en XSW #7. Esta vez, la Assertion original es la hija del elemento menos restrictivo en lugar de la Assertion copiada.
![](<../../.gitbook/assets/image (545).png>)
### Herramienta
Puedes usar la extensi贸n de Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para analizar el pedido, aplicar cualquier ataque XSW que elijas y lanzarlo.
![](<../../.gitbook/assets/image (546).png>)
### Paper Original
Para m谩s informaci贸n sobre este ataque lee el paper original en [https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)
## XXE
Si no sabes qu茅 tipo de ataques son XXE, por favor lee la siguiente p谩gina:
{% content-ref url="../xxe-xee-xml-external-entity.md" %}
[xxe-xee-xml-external-entity.md](../xxe-xee-xml-external-entity.md)
{% endcontent-ref %}
Debido a que las Respuestas SAML son documentos XML deflactados y codificados en base64, podemos probar **XXE** manipulando el documento XML enviado como la Respuesta SAML. Ejemplo:
```markup
]>
...
...
...
[...]
```
### Herramienta
Tambi茅n puedes usar la extensi贸n de Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para generar el POC a partir de una solicitud SAML para probar posibles vulnerabilidades XXE.
Consulta tambi茅n esta charla: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## XSLT a trav茅s de SAML
Para m谩s informaci贸n sobre XSLT, visita:
{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %}
[xslt-server-side-injection-extensible-stylesheet-language-transformations.md](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md)
{% endcontent-ref %}
La Transformaci贸n de Lenguaje de Hojas de Estilo Extensible (XSLT) es un lenguaje completo de Turing para transformar documentos XML en otros tipos de documentos como HTML, JSON o PDF. Un aspecto importante a tener en cuenta aqu铆 es que **el ataque no requiere una firma v谩lida para tener 茅xito**. La raz贸n de esto es que **la transformaci贸n XSLT ocurre antes de que la firma digital sea procesada para su verificaci贸n**. B谩sicamente, necesitamos una Respuesta SAML firmada para realizar el ataque, pero la firma puede ser auto-firmada o inv谩lida.
![xslt](https://epi052.gitlab.io/notes-to-self/img/saml/xslt.png)
Aqu铆 puedes encontrar un **POC** para comprobar este tipo de vulnerabilidades, en la p谩gina de hacktricks mencionada al principio de esta secci贸n puedes encontrar payloads.
```markup
...
...
```
### Herramienta
Tambi茅n puedes usar la extensi贸n de Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para generar el POC a partir de una solicitud SAML para probar posibles vulnerabilidades XSLT.
Consulta tambi茅n esta charla: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## Exclusi贸n de Firma XML
La Exclusi贸n de Firma se utiliza para probar c贸mo se comporta la implementaci贸n de SAML cuando **no hay un elemento Signature**. Cuando un elemento Signature est谩 **ausente**, el **paso de validaci贸n de la firma puede omitirse completamente**. Si la firma no se valida, entonces cualquier contenido que t铆picamente estar铆a firmado puede ser alterado por un atacante.
![](<../../.gitbook/assets/image (547).png>)
### Herramienta
La exclusi贸n de firma comienza interceptando la Respuesta SAML y luego haciendo clic en `Remove Signatures`. Al hacerlo, se eliminan **todos** los elementos Signature.
![sig-exclusion](https://epi052.gitlab.io/notes-to-self/img/saml/sig-exclusion.png)
Con las firmas eliminadas, permite que la solicitud proceda al destino. Si la firma no es requerida por el Servicio
## Falsificaci贸n de Certificados
La falsificaci贸n de certificados es el proceso de probar si el Proveedor de Servicios **verifica que un Proveedor de Identidad de confianza firm贸 el Mensaje SAML.** La relaci贸n de confianza entre SP e IdP se establece y **debe ser verificada** cada vez que se recibe un Mensaje SAML. Esto se reduce a usar un certificado **auto-firmado** para firmar la Respuesta SAML o la Afirmaci贸n.
### Herramienta
Se va a utilizar la extensi贸n de Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e).\
Para falsificar un certificado, comienza interceptando la Respuesta SAML.\
Si hay una firma incluida en la Respuesta, usa el bot贸n `Send Certificate to SAML Raider Certs`.
![send-cert](https://epi052.gitlab.io/notes-to-self/img/saml/send-cert.png)
Despu茅s de enviar el certificado, deber铆amos ver un certificado importado en la pesta帽a Certificados de SAML Raider. Una vez all铆, destacamos el certificado importado y presionamos el bot贸n `Save and Self-Sign`.
![sent-cert](https://epi052.gitlab.io/notes-to-self/img/saml/sent-cert.png)
Al hacerlo, se genera un clon auto-firmado del certificado original. Ahora es el momento de volver a la solicitud interceptada que a煤n se mantiene en el Proxy de burp. Primero, selecciona el nuevo certificado auto-firmado del men煤 desplegable de Firma XML. Luego usa el bot贸n `Remove Signatures` para eliminar cualquier firma existente. Finalmente, usa el bot贸n **`(Re-)Sign Message`** o `(`**`Re-)Sign Assertion`** (**cualquiera** que sea **m谩s** **apropiado** en tu situaci贸n dada).
![remove-sig](https://epi052.gitlab.io/notes-to-self/img/saml/remove-sig.png)
Despu茅s de firmar el mensaje con el certificado auto-firmado, env铆alo. Si nos autenticamos, sabemos que podemos firmar nuestros Mensajes SAML. La capacidad de firmar nuestros Mensajes SAML significa que podemos cambiar valores en la Afirmaci贸n y ser谩n aceptados por el Proveedor de Servicios.
## Confusi贸n del Destinatario del Token / Confusi贸n del Objetivo del Proveedor de Servicios
La Confusi贸n del Destinatario del Token / Confusi贸n del Objetivo del Proveedor de Servicios **prueba si el Proveedor de Servicios valida el Destinatario**. Esto significa que, **si la respuesta estaba destinada a un Proveedor de Servicios diferente**, el Proveedor de Servicios **actual** deber铆a notarlo y **rechazar la autenticaci贸n**.\
El campo **Recipient** es un atributo del elemento **SubjectConfirmationData**, que es hijo del elemento Subject en una Respuesta SAML.
> El elemento SubjectConfirmationData especifica datos adicionales que permiten confirmar al sujeto o restringen las circunstancias bajo las cuales puede tener lugar el acto de confirmaci贸n del sujeto. La confirmaci贸n del sujeto tiene lugar cuando una parte confiable busca verificar la relaci贸n entre una entidad que presenta la afirmaci贸n (es decir, la entidad que atestigua) y el sujeto de las reclamaciones de la afirmaci贸n.
El atributo Recipient encontrado en el elemento **SubjectConfirmationData es una URL que especifica la ubicaci贸n a la que se debe entregar la Afirmaci贸n**. Si el Recipient es un Proveedor de Servicios diferente al que lo recibe, la Afirmaci贸n no deber铆a ser aceptada.
### C贸mo hacerlo
La Confusi贸n del Destinatario del Token SAML (SAML-TRC) tiene algunas condiciones previas para que intentemos la explotaci贸n. Primero, **necesitamos** tener una **cuenta leg铆tima en un Proveedor de Servicios**. Segundo, **SP-Target debe aceptar tokens emitidos por el mismo Proveedor de Identidad que sirve a SP-Legit**.
El ataque es relativamente simple si las condiciones son verdaderas. Nos **autenticamos** en **SP-Legit** a trav茅s del Proveedor de Identidad compartido. Luego **interceptamos la Respuesta SAML en su camino desde el IdP a SP-Legit**. Una vez interceptada, enviamos la **Respuesta SAML que estaba destinada a SP-Legit a SP-Target en su lugar.** Si **SP-Target acepta la Afirmaci贸n**; nos encontraremos conectados con el mismo nombre de cuenta que tenemos para SP-Legit y obtendremos acceso a los recursos correspondientes de SP-Target.
## XSS en la funcionalidad de Cierre de Sesi贸n
(Accede a la [investigaci贸n original aqu铆](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/))
Despu茅s de realizar el fuerza bruta de directorios encontr茅 la siguiente p谩gina:
```
https://carbon-prototype.uberinternal.com:443/oidauth/logout
```
Es una p谩gina de cierre de sesi贸n, abr铆 el enlace anterior y me redirigi贸 a la siguiente p谩gina
```
https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1
```
El par谩metro base est谩 tomando una URL, as铆 que 驴qu茅 tal si lo reemplazamos con el cl谩sico `javascript:alert(123);` para desencadenar un XSS.
### Explotaci贸n Masiva
Usando [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) que puede tomar una lista de URLs y luego devolverte la URL de callback (consumo de SAML), decid铆 alimentar la herramienta con todos los subdominios de `uberinternal.com` para ver si hay otros dominios que usen la misma biblioteca y los hab铆a.
Lo que hice a continuaci贸n fue crear un script que llama a la p谩gina vulnerable `oidauth/prompt` y probar el XSS y si mi entrada se refleja, me da un bonito mensaje de vulnerabilidad.
```python
import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
from colorama import init ,Fore, Back, Style
init()
with open("/home/fady/uberSAMLOIDAUTH") as urlList:
for url in urlList:
url2 = url.strip().split("oidauth")[0] + "oidauth/prompt?base=javascript%3Aalert(123)%3B%2F%2FFady&return_to=%2F%3Fopenid_c%3D1520758585.42StPDwQ%3D%3D&splash_disabled=1"
request = requests.get(url2, allow_redirects=True,verify=False)
doesit = Fore.RED + "no"
if ("Fady" in request.content):
doesit = Fore.GREEN + "yes"
print(Fore.WHITE + url2)
print(Fore.WHITE + "Len : " + str(len(request.content)) + " Vulnerable : " + doesit)
```
## Referencias
Los ataques se obtuvieron de [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/)\
Puedes encontrar recursos adicionales y write-ups en [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/)
Aprende hacking en AWS de cero a h茅roe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** revisa los [**PLANES DE SUSCRIPCI脫N**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colecci贸n de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **脷nete al** 馃挰 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **s铆gueme** en **Twitter** 馃惁 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).