Une technique d’attaque, nommée « Golden SAML » a été documentée récemment à travers un article publié sur le blog de CyberArk. Bien que nouvelle par son implémentation, l’attaque ainsi présentée reprend un principe déjà bien connu.
Ce vecteur d’attaque est applicable à tous les services utilisant une solution de SSO basée sur le protocole SAML2 (hors implémentation HSM).
Explication du Golden SAML
Le titre du billet n’est pas anodin puisque le « Golden SAML » s’apparente au « Golden Ticket » qui frappe le protocole Kerberos. Comme le Golden Ticket, le Golden SAML permet à un attaquant d’accéder à des ressources protégées par des agents SAML (exemples : Azure, AWS, vSphere, Okta, Salesforce, …) avec des privilèges élevés grâce à un « ticket en or ». Elle permet en outre à l’attaquant d’agir dans l’ombre sans se faire repérer, puisque suite à l’attaque les jetons peuvent être générés hors du SI sans sollicitation du fournisseur d’identité (IDP).
Dans une cinématique standard SAML :
- Le client tente d’accéder à une application (Service Provider).
- L’application génère une requête « SAML AuthRequest » afin d’authentifier l’utilisateur.
- Le fournisseur d’identité (Identity Provider ou IDP) authentifie l’utilisateur et envoie à l’utilisateur une réponse « SAML response » qu’il peut utiliser pour accéder à des ressources exposées par un fournisseur de service (Service Provider ou SP).
- Le SP vérifie la réponse et identifie l’utilisateur qui est désormais habilité à utiliser le service.
L’attaque repose sur la falsification de la réponse SAML qui permet d’identifier et d’authentifier l’utilisateur. La réponse est signée par la clé privée du fournisseur d’identité et éventuellement chiffrée, selon l’implémentation. En vérifiant l’intégrité de la réponse SAML grâce à sa signature, l’application s’assure que celle-ci a bien été forgée par le fournisseur d’identité et n’a pas été modifiée durant son transit.
Afin de falsifier la réponse, plusieurs informations sont nécessaires :
- La clé privée du fournisseur d’identité ;
- Le certificat public du fournisseur d’identité ;
- Le nom du fournisseur d’identité ;
- Le nom du rôle à usurper (exemple : administrateur).
La seule information réellement complexe à obtenir est la clé privée de signature des réponses SAML. Les trois autres sont des données facilement accessibles, notamment dans les réponses.
Il est possible d’exporter la clé privée en accédant à l’IdP avec un compte admin AD FS. Une première attaque sur ce compte est donc nécessaire.
Une fois ces informations collectées, l’attaquant peut alors librement générer des réponses valides en dehors du domaine sans être repéré. La mise en place d’une authentification forte sur les comptes visés ne protège pas d’avantage de l’attaque puisque la preuve de cette authentification reste portée par la réponse SAML qui peut désormais être falsifiée.
Tant que le certificat de l’IdP n’est pas modifié et que ce changement n’est pas pris en compte sur l’ensemble des fournisseurs de services, l’attaque peut perdurer.
Décryptage de l’attaque
Malgré le ton alarmiste du billet, la vulnérabilité décrite peut tout au plus être assimilée à un choix de conception discutable du protocole SAML 2 qui utilise des jetons signés, mais non à une faille réelle de sécurité. En effet, la condition nécessaire est d’avoir compromis un compte administrateur AD FS pour récupérer la clé privée du domaine. Cependant, l’impact est fort puisque l’attaquant peut, de manière illimitée et hors domaine, accéder à des services protégés par des agents SAML faisant confiance au domaine. La récupération du compte IdP peut être détectée mais les falsifications de réponse peuvent se faire en toute discrétion a posteriori.
En outre, si la compromission d’un compte d’administrateur IdP est détectée, le changement de mot de passe de ce compte ne rendra pas la confidentialité de la clé privée et ne permettra pas de contrer le Golden SAML. Ainsi, la seule solution pour bloquer l’attaquant est de changer la clé privée, ce qui peut avoir un impact fort pour les fournisseurs de service faisant confiance à l’IdP à savoir le rejet temporaire des réponses signées avec la nouvelle clé.
En définitive, le vol de clé privée permet de rendre vulnérable la fédération d’identité et ceci n’est pas nouveau. Les IdP SAML sont concernés comme tout protocole de sécurité émettant des documents signés (OpenID Connect, PKI …)
Comment se prémunir ?
La sécurité des jetons SAML reposant avant tout sur celle de la clé privée de l’IdP, il est impératif de mettre en œuvre tous les moyens nécessaires pour la protéger.
Deux approches sont possibles pour stocker et utiliser cette clé : la solution logicielle et la solution matérielle.
Solution logicielle
Dans le premier cas, la clé est stockée sur un serveur qui porte la responsabilité de la conserver secrète et de réaliser les opérations de signature des réponses. On devra ainsi s’assurer que la machine et son environnement soient bien protégés. Pour cela, il est recommandé d’appliquer certaines recommandations habituelles de sécurité à savoir : isoler cette machine sur un VLAN d’administration, restreindre son accès aux opérateurs essentiels à son fonctionnement, sécuriser ─ via une authentification forte ─ les comptes à privilège permettant d’accéder à la clé, appliquer régulièrement les correctifs de sécurité sur la machine, journaliser les accès, mettre en place des règles SIEM appropriées à l’IdP pour détecter les intrusions, etc.
Si ces mesures de préventions permettent de limiter les risques de compromission de la clé, elles ne peuvent garantir de manière certaine que celle-ci n’ait pas été ou ne sera pas exfiltrée. Il est donc souhaitable que le certificat de l’IdP et sa clé privée puissent être renouvelés à intervalles réguliers, ou en cas de doute sur le maintien de sa confidentialité. Suite au renouvellement du certificat de l’IdP, il sera nécessaire que les fournisseurs de service puissent accepter les jetons sans interruption des accès; en s’assurant qu’ils soient en capacité de récupérer le certificat de manière synchrone et d’accepter les jetons signés par cette clé tout en rendant l’ancien certificat invalide. Cela pourra se faire en exposant le nouveau certificat sur une ressource dédiée.
Toutefois, il est souvent constaté que des effets de bords apparaissent lors d’une rotation de clés (exemple : impacts sur le Service Provider). De même, il est rare qu’un Service Provider puisse supporter une révocation de clé via CRL.
Solution matérielle
La solution matérielle, qui repose sur l’utilisation d’un HSM (Hardware Security Module), est bien plus robuste car elle garantit l’inviolabilité de la clé de signature. Le module se charge de protéger la clé et de réaliser l’ensemble des opérations cryptographiques nécessaires à la signature des réponses. La clé ne sort donc jamais du HSM et une génération de jeton à l’extérieur du SI devient impossible.
Cependant, l’IdP devra protéger le secret lui permettant d’interroger le HSM en suivant les recommandations usuelles exposées précédemment. Si ce secret est compromis, il pourra être généré de nouveau sans impacter les fournisseurs de service.
