SAML Attacks
Last updated
Last updated
SAMLExtractor : Un outil qui peut prendre une URL ou une liste d'URL et renvoyer l'URL de consommation SAML.
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 :
L'exécution du programme contre REXML 3.2.4 ou une version antérieure donnerait plutôt le résultat suivant :
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érialisation :
Pour plus d'informations sur la vulnérabilité et comment l'exploiter :
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.
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.
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é.
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.
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.
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.
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.
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.
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.
Vous pouvez utiliser l'extension Burp SAML Raider pour analyser la requête, appliquer l'attaque XSW de votre choix et la lancer.
Si vous ne savez pas quels types d'attaques sont les XXE, veuillez lire la page suivante :
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 :
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
Pour plus d'informations sur XSLT, rendez-vous sur :
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.
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
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.
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.
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.
Les étapes suivantes décrivent le processus en utilisant l'extension Burp SAML Raider :
Interceptez la réponse SAML.
Si la réponse contient une signature, envoyez le certificat à SAML Raider Certs en utilisant le bouton Send Certificate to SAML Raider Certs.
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.
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.
Supprimez toutes les signatures existantes avec le bouton Remove Signatures.
Signez le message ou l'assertion avec le nouveau certificat en utilisant le bouton (Re-)Sign Message ou (Re-)Sign Assertion, selon le cas.
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.
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.
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.
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 à :
Lors de l'accès à ce lien, une redirection s'est produite vers :
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).
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.
