* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) : Un outil qui peut prendre une URL ou une liste d'URL et renvoie l'URL de consommation SAML.
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**.
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.
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.
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.
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.
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 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 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](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf) 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 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.
Vous pouvez utiliser l'extension Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) pour analyser la demande, appliquer n'importe quelle attaque XSW que vous choisissez et la lancer.
Pour plus d'informations sur cette attaque, lisez le document original à l'adresse [https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)
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 :
Vous pouvez également utiliser l'extension Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) pour générer la preuve de concept à partir d'une requête SAML afin de tester les vulnérabilités XXE possibles.
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.
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.
Vous pouvez également utiliser l'extension Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) pour générer la POC à partir d'une demande SAML afin de tester les vulnérabilités XSLT possibles.
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.
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.
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.
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`.
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).
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 <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
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.
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.
En utilisant [**SAMLExtractor**](https://github.com/fadyosman/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.
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/](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/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/)
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
