Apprenez et pratiquez le hacking AWS :<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Apprenez et pratiquez le hacking GCP : <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
[**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.
Dans XML, la partie signée de l'XML est sauvegardée en mémoire, puis un certain encodage/décodage est effectué et la signature est vérifiée. Idéalement, cet encodage/décodage ne devrait pas changer les données, mais basé sur ce scénario, **les données vérifiées et les données originales pourraient ne pas être les mêmes**.
Dans les **attaques par enveloppement de signature XML (XSW)**, les adversaires exploitent une vulnérabilité qui survient lorsque les documents XML sont traités à travers deux phases distinctes : **validation de signature** et **invocation de fonction**. Ces attaques impliquent de modifier la structure du document XML. Plus précisément, l'attaquant **injecte des éléments falsifiés** qui ne compromettent pas la validité de la signature XML. Cette manipulation vise à créer une discordance entre les éléments analysés par la **logique d'application** et ceux vérifiés par le **module de vérification de signature**. En conséquence, bien que la signature XML reste techniquement valide et passe la vérification, la logique d'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**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **et** [**ce document**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf). Consultez-les pour plus de détails.
* **Implication** : Le validateur peut être confus entre le "Response -> Assertion -> Subject" légitime et le "mauvais nouveau Response -> Assertion -> Subject" de l'attaquant, entraînant des problèmes d'intégrité des données.
* **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.
Vous pouvez utiliser l'extension Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) pour analyser la requête, appliquer toute attaque XSW de votre choix et la lancer.
Les réponses SAML sont des **documents XML décompressés et encodés en base64** et peuvent être susceptibles 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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) pour générer le POC à partir d'une requête SAML afin de tester d'éventuelles vulnérabilités XXE et vulnérabilités SAML.
Les Transformations de Langage de Feuille de Style Extensible (XSLT) peuvent être utilisées pour transformer des documents XML en divers formats comme 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 suffit pour procéder.
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.
Vous pouvez également utiliser l'extension Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) pour générer le POC à partir d'une requête SAML afin de tester d'éventuelles vulnérabilités XSLT.
L'**Exclusion de la signature XML** observe le comportement des implémentations SAML lorsque l'élément Signature est absent. Si cet élément est manquant, **la validation de la signature peut ne pas se produire**, rendant le système 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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). Interceptez la réponse SAML et cliquez sur `Remove Signatures`. Ce faisant, **tous** les éléments 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 d'utiliser 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](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) :
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 original.
4. Retournez à la requête interceptée dans le Proxy de Burp. Sélectionnez le nouveau certificat auto-signé dans le menu déroulant de la signature XML.
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 d'éventuelles vulnérabilités dans le processus de validation des messages SAML.
## Confusion du destinataire de jeton / Confusion de cible de fournisseur de services <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
La confusion du destinataire de jeton et la confusion de cible de 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 **Recipient**, 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 de destinataire de jeton SAML (SAML-TRC) soit réalisable, certaines conditions doivent être remplies. Tout d'abord, il doit y avoir un compte valide sur un Fournisseur de services (appelé SP-Légitime). Deuxièmement, le Fournisseur de services ciblé (SP-Cible) doit accepter des 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 l'acceptation de l'assertion par SP-Cible, accordant l'accès aux ressources sous le même nom de compte utilisé pour SP-Légitime.
Cela a révélé que le paramètre `base` accepte une URL. En tenant compte de cela, l'idée est née de substituer l'URL par `javascript:alert(123);` dans une tentative d'initier une attaque XSS (Cross-Site Scripting).
L'outil [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) a été utilisé pour analyser les sous-domaines de `uberinternal.com` pour les 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 pour XSS (Cross-Site Scripting) en saisissant des données et en vérifiant si elles sont reflétées dans la sortie. Dans les cas où l'entrée est effectivement reflétée, le script signale la page comme vulnérable.
Apprenez et pratiquez le hacking AWS :<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Apprenez et pratiquez le hacking GCP : <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop)!
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.