# Attaques SAML
## Attaques SAML
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* 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).
## Informations de base
{% content-ref url="saml-basics.md" %}
[saml-basics.md](saml-basics.md)
{% endcontent-ref %}
## Graphique des attaques
 (1) (1) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (6).png>)
## Outil
[**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.
## 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 :
```ruby
require 'rexml/document'
doc = REXML::Document.new <]>
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 :
.png>)
Et voici comment il l'a vu après une série d'analyses et de sérialisations :
.png>)
Pour plus d'informations sur la vulnérabilité et comment l'exploiter :
* [https://mattermost.com/blog/securing-xml-implementations-across-the-web/](https://mattermost.com/blog/securing-xml-implementations-across-the-web/)
* [https://joonas.fi/2021/08/saml-is-insecure-by-design/](https://joonas.fi/2021/08/saml-is-insecure-by-design/)
## 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 :
.png>)
### 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.
.png>)
### 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.
.png>)
### 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.
.png>)
### XSW #4
XSW #4 est similaire à #3, sauf que dans ce cas, l'assertion d'origine devient un enfant de l'assertion copiée.
.png>)
### 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.
.png>)
### 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.
.png>)
### 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](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.
.png>)
### 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.
.png>)
### Outil
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.
.png>)
### 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](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](../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 :
```markup
]>
...
...
...
[...]
```
### Outil
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.
Consultez également cette présentation : [https://www.youtube.com/watch?v=WHn-6xHL7mI](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](../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.
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.
```markup
...
...
```
### Outil
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.
Consultez également cette présentation : [https://www.youtube.com/watch?v=WHn-6xHL7mI](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.
.png>)
### 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.
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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) 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`.
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
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](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/))
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**](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.
```python
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/](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/)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* 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).