<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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).
[**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.
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**.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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:
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.
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.
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.
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.
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.
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.
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.
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`.
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).
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 <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
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.
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.
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.
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/)
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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).
