SAML : sécurité et attaques sur l'authentification

SAML (Security Assertion Markup Language) est un standard XML ouvert permettant l'échange d'assertions d'authentification et d'autorisation entre un Identity Provider (IdP) et un Service Provider (SP). La sécurité de SAML repose sur la signature numérique XML des assertions, garantissant leur intégrité et leur origine. Dans un flux SSO typique, l'IdP émet une assertion signée après vérification des credentials. Le SP valide cette signature avant d'accorder l'accès. Ce mécanisme est massivement déployé dans les environnements cloud et on-premise, notamment via ADFS, Azure AD, Okta ou Shibboleth. Sa criticité en cybersécurité est élevée : une assertion forgée ou manipulée accorde un accès légitime sans connaissance du mot de passe cible. Les failles exploitables touchent la validation de la signature XML, la gestion des conditions temporelles de l'assertion, et la confiance aveugle accordée aux attributs déclarés par l'IdP. SAML est distinct d'OAuth 2.0 et d'OpenID Connect, bien qu'il coexiste souvent avec eux dans les architectures hybrides modernes.

La détection d'abus SAML côté Blue Team repose sur plusieurs sources de logs complémentaires. Sous ADFS, les journaux 'Security' et 'AD FS/Admin' consignent chaque émission d'assertion (Event ID 1200, 1202, 4625). Un pic d'assertions émises en dehors des horaires habituels ou pour des comptes à privilèges élevés est un signal fort. L'Event ID 1007 d'ADFS indique un échec de validation de token. Dans Azure AD, les logs de connexion (SignInLogs) exposent les authentifications via SAML fédéré avec le champ 'authenticationProtocol'. Une authentification SAML réussie sans MFA associée sur un compte admin doit alerter immédiatement. L'indicateur classique du Golden SAML est une connexion réussie à un service cloud sans activité préalable de l'utilisateur dans l'IdP source sur la même période. Les outils SIEM comme Splunk ou Microsoft Sentinel permettent de corréler ces événements. Surveiller les modifications des certificats de signature de l'IdP (Event ID 4670 sur le DC, changements dans ADFS via PowerShell) est également critique, car un attaquant ayant compromis les clés de signature peut forger des assertions indétectables au niveau applicatif.

L'attaque Golden SAML, popularisée lors de compromissions de grande envergure, consiste à extraire la clé privée de signature de l'IdP (ADFS par exemple) pour forger des assertions arbitraires. L'outil AADInternals permet d'automatiser cette extraction et la génération d'assertions falsifiées. L'attaque XML Signature Wrapping (XSW) exploite les parseurs XML laxistes du SP : l'attaquant insère un élément XML malveillant autour de la signature valide, trompant le SP sur le contenu réellement signé. Des variantes XSW1 à XSW8 existent, testables avec des frameworks comme SAML Raider (extension Burp Suite). La technique de rejeu d'assertion cible les SP ne vérifiant pas l'attribut 'NotOnOrAfter' ou l'unicité de l'assertion via son ID. Côté durcissement, les contre-mesures essentielles incluent la rotation régulière des certificats de signature ADFS, l'activation du chiffrement des assertions (en plus de la signature), la validation stricte des conditions temporelles côté SP, et l'application du principe de moindre privilège sur les comptes de service ADFS. L'activation des logs d'audit détaillés sur l'ensemble du pipeline SAML et la supervision des accès aux clés privées de l'IdP via un HSM réduisent significativement la surface d'attaque.