Voici Silver SAML, une variante de Golden SAML dans le cloud

Tribune rédigée par Tomer Nahum et Eric Woodruff, Semperis

Golden SAML est une technique d’attaque notoire, découverte par CyberArk et documentée par Shaked Reiner. Depuis des années, Golden SAML est connue pour extraire des certificats de signature à partir de Microsoft Active Directory Federation Services (AD FS) qu’elle utilise pour falsifier les réponses d’authentification SAML (Security Assertion Markup Language). Les chercheurs en sécurité de Semperis ont découvert une nouvelle variante de Golden SAML — dans Microsoft Entra ID et en l’absence d’utilisation d’AD FS. Ils l’ont baptisée Silver SAML.

Qu’est-ce que Silver SAML ?

À l’heure actuelle, nombre d’entreprises utilisent Entra ID comme fournisseur d’identités pour les applications SaaS (Software-as-a-Service) et métier. SAML est le principal moyen d’authentification de ces applications.

Dans Entra ID, Microsoft propose un certificat auto-signé pour la signature des réponses SAML. Sinon, les entreprises peuvent choisir d’utiliser un certificat généré en externe, sachant que cette option présente un risque en termes de sécurité.

Tout pirate parvenant à se procurer la clé privée d’un certificat généré en externe peut falsifier la réponse SAML de son choix en la signant avec la même clé privée que celle détenue par Entra ID. Ce type de réponse SAML falsifiée lui permet alors d’accéder à l’application comme n’importe quel utilisateur.

La démonstration de faisabilité exposée dans cet article concerne Entra ID. Mais cette attaque peut cibler n’importe quel fournisseur d’identités autorisant l’importation de certificats de signature SAML générés de manière externe.

Aux fins de cette démonstration de faisabilité, Semperis a élaboré et publié un nouvel outil, baptisé SilverSAMLForger, utilisable pour falsifier des réponses SAML signées. SilverSAMLForger est disponible sur GitHub.

Rôle de Golden SAML dans l’attaque contre SolarWinds

Mais revenons d’abord en arrière. Le protocole SAML est l’une des bases de l’authentification moderne. Par exemple, 63 % des applications de la Galerie Entra ID s’en remettent à lui pour l’intégration. Les intégrations multicloud avec Amazon Web Services, Google Cloud Platform et autres font appel à ce standard. Et nombre d’entreprises continuent à investir dans le protocole SAML pour les applications SaaS et métier pour sa simplicité de mise en œuvre.

Faisant partie intégrante du piratage portant sur la chaîne mondiale d’approvisionnement de SolarWinds, Golden SAML en était l’un des vecteurs d’attaque les plus innovants.

Les pirates sont parvenus à accéder, dans un premier temps, à SolarWinds en injectant du code malveillant dans la plateforme Orion de l’entreprise, utilisée pour la surveillance des infrastructures et la gestion des ressources IT. Plus tard, ils ont mis à profit ce point d’appui pour se déplacer latéralement dans l’environnement AD FS. Ensuite, ils ont dérobé les clés privées servant à la signature des réponses SAML.

Du fait de cette attaque Golden SAML post-intrusion, nombre d’entreprises ont privilégié le transfert des applications vers Entra ID pour l’authentification SAML. Ce changement les a dispensées de gérer une infrastructure de niveau 0 complexe, tout en interdisant l’exportation de clés de signature SAML depuis Entra ID. Même la CISA (Cybersecurity and Infrastructure Security Agency), aux États-Unis, recommande que les entreprises dotées d’environnements d’identité hybrides transposent l’authentification SAML vers des systèmes d’identité cloud comme Entra ID.

Le problème que posent le protocole SAML et les certificats de signature

Malheureusement, nombre d’acteurs gèrent mal leurs certificats de signature et fragilisent la sécurité SAML en recourant à des certificats générés à l’extérieur. Les grandes entreprises génèrent, en général, des certificats auto-signés sur un système client ou via une infrastructure à clé publique (PKI) comme Active Directory Certificate Services (AD CS), ou alors se procurent des certificats de signature auprès d’une autorité de certification externe.

Pour compliquer encore la donne, les entreprises se servent de ces certificats générés de manière externe pour communiquer des fichiers PFX et des mots de passe via des canaux non sécurisés tels que Teams ou Slack. Elles peuvent également générer des certificats sur des serveurs web, exécutant le plus souvent Microsoft Internet Information Services (IIS), ou sur des postes clients, laissant alors les certificats à disposition dans le magasin de certificats en local pour exportation.

Une méconnaissance

L’utilisation d’un certificat généré en externe pour la signature de la réponse SAML augmente la surface d’attaque à laquelle est exposé tout fournisseur d’identités, y compris Entra ID. Dans les entreprises qui génèrent et gèrent leurs certificats de signature SAML en externe, et non dans Entra ID directement, les enseignements à en tirer sont les suivants : l’absence de chaîne de confiance avec les certificats auto-signés de Entra ID, l’incapacité à tirer parti de la révocation des certificats au moyen de certificats auto-signés et la nécessaire application à l’aveugle de la charte d’entreprise définie pour la gestion des certificats.

Certaines entreprises entendent appliquer à leurs certificats de signature SAML une durée de vie supérieure à celle spécifiée par défaut dans Entra ID. Elles émettent des certificats externes, alors qu’il leur suffit de produire de nouveaux certificats dans Entra ID et de les configurer pour en étendre la durée de vie.

Nombre d’entreprises ne saisissent pas les subtilités inhérentes aux certificats applicables aux signatures SAML ; les certificats de signature sont simplement noyés dans des directives et règles globales de gestion des certificats. Même s’il importe d’uniformiser les pratiques applicables au cycle de vie et à la gestion des certificats dans de nombreux types de systèmes, celles-ci ne sauraient s’appliquer à ceux employés pour la signature SAML.

Une chaîne de confiance n’a pas lieu d’être dans le domaine SAML. La plupart des fournisseurs d’identités et des prestataires de services l’ignorent, quelle qu’elle soit. Contrairement au scénario serveur/client typique des navigateurs web, un administrateur est concrètement un maillon essentiel de la chaîne de confiance dans les configurations SAML. Il doit configurer et spécifier le certificat de signature auquel se fier, en particulier dans l’application.

De même, la révocation de certificat n’est pas une pratique à retenir avec le protocole SAML. Si un certificat de signature est compromis, l’administrateur doit faire tourner (autrement dit, remplacer) ce certificat au niveau du prestataire de services et du fournisseur d’identités. La version 1.0 du profil d’interopérabilité des métadonnées OASIS SAML 2.0 recommande spécifiquement de s’abstenir d’utiliser les listes de révocation, le protocole OCSP (de vérification de certificat en ligne) ou d’autres mécanismes de validation clés. Au lieu de cela, le fournisseur d’identités devrait supprimer les clés compromises des métadonnées SAML.

Quid d’Azure Key Vault ?

Même les entreprises qui utilisent des services comme Azure Key Vault, méthode mieux sécurisée pour la gestion des secrets et des certificats, ne sont pas forcément épargnées par les vecteurs d’attaque, qui permettent à un pirate d’extraire des clés.

Azure Key Vault est une solution de gestion des clés de chiffrement prisée, proposée par Microsoft, offrant un emplacement sur lequel des certificats auto-signés pourraient être stockés. Comme la plupart des services cloud, Key Vault dispose de deux plans qui régissent l’accès et la gestion : le plan de contrôle et le plan de données.

À l’aide des droits impartis au plan de données sont définis les utilisateurs ou les principaux de service autorisés à effectuer des opérations en lecture et en écriture vers/depuis le coffre de clés. La possibilité de lire des clés privées de certificats en fait partie, ce qui pose problème si ces clés sont utilisées pour la signature de réponses SAML.

Les autorisations concernant Key Vault peuvent être octroyées via un contrôle des accès basé sur les rôles (RBAC) ou des règles d’accès à Key Vault.

Avec le modèle RBAC, un administrateur, agent des certificats ou administrateur de l’accès aux données Key Vault peut récupérer un certificat dans le coffre de clés. Bien que dépourvue d’autorisations pour accéder aux secrets et certificats contenus ce dernier, toute personne détenant le rôle de contributeur Key Vault peut néanmoins les extraire si des règles d’accès sont utilisées. Les coffres de clés sont également accessibles via des comptes Automation et des identités managées dotées des autorisations nécessaires.

Dans le modèle des autorisations régissant les règles d’accès à Key Vault, vous pouvez également octroyer des règles d’accès Key Vault à un utilisateur, service ou groupe.

Tout pirate prenant le contrôle d’un utilisateur, d’un principal de service ou d’un groupe autorisé à extraire le fichier PFX servant à la signature des assertions ou réponses SAML pour le prestataire de services ciblé — via la méthode RBAC ou les règles d’accès à Key Vault — peut lancer une attaque Silver SAML à l’encontre de ce prestataire.

SAML et Entra ID

Le protocole SAML, dans son actuelle version 2.0, a près de 20 ans. Nombre d’entreprises l’ont adopté pour l’authentification fédérée et l’authentification unique (SSO) via le web. Ce protocole, dans sa mise en œuvre principale (et son utilisation au sein d’Entra ID), met à profit le profil SSO des navigateurs web.

Un flux type de profils SAML comporte trois composantes : le prestataire de services, ou l’application, qualifiés de partie de confiance dans l’écosystème Microsoft : le fournisseur d’identités, en l’occurrence Entra ID dans notre démonstration de faisabilité ; et l’agent de l’utilisateur, le plus souvent le navigateur web du client (de l’utilisateur final).

Les utilisateurs interagissent avec les applications à des fins d’authentification de diverses manières, selon que ces applications sont configurées pour ou gèrent des flux initiés par le prestataire de services ou le fournisseur d’identités.

Le contenu d’une assertion SAML comporte plusieurs éléments d’information sur l’utilisateur final, ou sujet, dans une série de paires clé-valeur. Ces informations, souvent qualifiées de déclarations SAML, comprennent les éléments suivants :

• Sujet. L’application utilise ce composant obligatoire comme identifiant unique de l’utilisateur. Dans nombre d’implémentations, le sujet correspond au nom principal de l’utilisateur (UPN) ou à son adresse e-mail.
• Attributs. Ces informations peuvent comprendre le prénom de l’utilisateur, son nom, son adresse e-mail et son nom d’utilisateur. L’appartenance à un groupe ou les rôles endossés sont souvent communiqués de sorte que l’application puisse valider les autorisations et les droits assignés à l’utilisateur.
• Autres informations contextuelles relatives à l’authentification. Ces informations peuvent comprendre le type d’authentification utilisée, l’émetteur et l’audience, ainsi que des indications d’horodatage précisant la fenêtre de validité pour la réponse SAML.

Entra ID prend en charge à la fois la signature de la réponse SAML et celle de l’assertion SAML. L’intérêt d’une signature, tant au niveau de la réponse que de l’assertion, consiste à vérifier que le contenu de la réponse n’est pas falsifié et que l’application peut se fier aux informations qui y sont communiquées. Celle-ci se sert de la signature pour valider que la réponse a été générée par le fournisseur d’identités, détenteur de la clé privée employée à cet effet.

Raison pour laquelle le vol de la clé privée de signature pose un problème fondamental. Avec la clé de signature entre les mains, un acteur malveillant peut contrefaire une réponse SAML, et lancer ainsi une attaque Silver SAML.

Lancer une attaque Silver SAML

Pour tester la théorie selon laquelle la technique d’attaque Golden SAML peut se retourner contre Entra ID, Semperis a conçu l’outil SilverSAMLForger. Cet outil génère une réponse SAML qui duplique une réponse Entra ID, en la signant avec un certificat fourni.

La démonstration de faisabilité Silver SAML part du principe qu’une entreprise utilise un certificat de signature généré en externe, qu’un pirate s’est procuré. Les flux initiés par le prestataire de services comme par le fournisseur d’identités sont tous deux exposés à d’éventuelles attaques.

Par exemple, Semperis a analysé une attaque Silver SAML utilisant Entra ID comme fournisseur d’identités et Okta comme prestataire de services. Pour lancer cette attaque dans le cadre d’un flux déclenché par un prestataire de services, les chercheurs devaient intercepter la requête SAML et remplacer le contenu de la réponse SAML par la réponse SAML falsifiée qu’ils ont créée. Ils sont parvenus à accomplir aisément ces tâches en utilisant Burp Suite.

Pour cet exemple, ils se sont efforcés de falsifier une réponse SAML pour l’utilisateur oktaAdministrator@xd6z7.onmicrosoft.com. Cet utilisateur est un super-administrateur dans Okta. Ils ne disposaient, ni du mot de passe de cet utilisateur, ni de son appareil connecté à l’authentification multifactorielle (si une configuration était effectuée en ce sens).

Dans un premier temps, les chercheurs ont eu besoin de certains des attributs énoncés dans les déclarations SAML cadrant avec ceux utilisés lors du référencement de l’application par le fournisseur d’identités ; par exemple, l’UPN, le nom de famille, le prénom, le nom d’utilisateur et l’identifiant d’objet. Un pirate peut facilement trouver ces attributs dans le centre d’administration Entra ou en utilisant l’API Microsoft Graph.

Ils devaient également connaître le destinataire et l’audience. Ces informations étaient accessibles dans le centre d’administration Entra, dans le panneau d’authentification unique de l’application.

L’exécution de SilverSAMLForger.exe avec les paramètres requis ayant produit une chaîne codée en base64 et en URL, l’équipe a pu copier cette réponse SAML contrefaite.

Elle a copié la réponse SAML ainsi générée dans la requête HTTPS interceptée, substituant à la réponse initiale la version falsifiée. Une fois celle-ci envoyée, l’équipe a pu cesser toute interception puisqu’elle était à présent connectée comme étant l’utilisateur ciblé.

Attaque Silver SAML dans un flux initié par un fournisseur d’identités

Les flux initiés par un fournisseur d’identités présentent des risques nettement plus importants pour l’entreprise étant donné qu’aucune interaction n’est requise avec Entra ID. Si l’application gère les flux de ce type, le pirate peut directement publier une réponse SAML dans l’application. Dans le cadre de sa démonstration de faisabilité, l’équipe Semperis est parvenue à déclencher une attaque initiée par un fournisseur d’identités à l’encontre de Salesforce en falsifiant une réponse avec l’UPN d’un utilisateur comme sujet. La réponse était signée au moyen du même certificat de signature SAML que celui configuré pour Salesforce dans Entra ID.

Dans Burp Suite, les chercheurs ont fait appel à Repeater pour poster directement la réponse SAML falsifiée dans leur instance Salesforce. En ouvrant la réponse dans un navigateur, ils ont vérifié qu’ils étaient bien connectés à Salesforce comme étant l’utilisateur ciblé, sans jamais interagir avec Entra ID.

Se défendre contre les attaques Silver SAML

Pour se prémunir efficacement contre les attaques Silver SAML dans Entra ID, les entreprises devraient utiliser exclusivement des certificats auto-signés Entra ID aux fins de signatures SAML.

Pour toute application SAML dans Entra ID, les certificats de signature SAML sont stockés dans le principal de service. L’API Graph peut être utilisée pour accéder aux informations exposées sur la clé de signature. Les éléments de clé privée ne sont pas exportables, empêchant les pirates de recueillir les informations indispensables au lancement d’une attaque Silver SAML.

Un administrateur général, un administrateur d’application, un administrateur d’application cloud ou un utilisateur à qui est déléguée la propriété d’une application est autorisé à modifier les clés de signature disponibles et à importer une clé de signature externe. Même s’il faudra mettre à jour l’application associée, les entreprises devraient limiter le nombre de propriétaires des applications dans Entra ID. Elles devraient tout au moins surveiller les changements apportés aux clés de signature SAML, surtout si la clé est encore loin de sa date d’expiration.

Les entreprises peuvent réaliser un audit des actuels principaux de service configurés pour SAML et vérifier le paramètre displayName. Si le certificat utilisé est généré par Microsoft, il comportera la valeur CN=Microsoft Azure Federated SSO Certificate. Pour autant, rien n’empêche un pirate d’importer un certificat externe possédant le même nom de sujet.

Les entreprises peuvent également traquer, dans les journaux d’audit Entra ID, les modifications apportées à la propriété PreferredTokenSigningKeyThumbprint sous ApplicationManagement. Elles devront mettre ces événements en corrélation avec ceux liés à l’ajout d’informations d’identification pour le principal de service. La rotation des certificats expirés étant un processus courant, elles devront se prononcer sur la légitimité des événements d’audit. La mise en œuvre de processus de contrôle des changements pour documenter cette rotation peut concourir à diminuer la plus possible la confusion lors d’événements s’y rapportant.

Si une application prend à la fois en charge les protocoles SAML et OIDC (OpenID Connect) pour l’authentification, les entreprises devraient envisager de modifier l’intégration avec Entra ID au profit d’OIDC afin d’atténuer les effets de cette attaque. La complexité du changement, de SAML vers OIDC, dépend essentiellement de la façon dont le développeur de l’application a appliqué les standards.

Côté applicatif, les développeurs d’applications peuvent se protéger contre les attaques de diverses manières, par exemple en imposant des flux initiés par le prestataire de services les mettant à l’abri de ceux initiés par le fournisseur d’identités, qui se trouvent être les types d’attaques les plus dangereux.

Ne laissez pas Silver SAML vous prendre par surprise

À l’instar de l’attaque Golden SAML, les attaques Silver SAML peuvent être modérées, ou dévastatrices. Alors que l’adoption des environnements d’identité cloud et hybrides continue d’avoir le vent en poupe, il faut s’attendre à ce que les menaces ciblant les fournisseurs d’identités comme Entra ID se multiplient. Cet article montre que si une attaque Silver SAML est possible avec Entra ID, tout fournisseur d’identités vous permettant d’utiliser des certificats auto-signés est exposé. Les entreprises doivent désormais prendre des mesures décisives pour colmater les failles et remédier aux vulnérabilités dans ces environnements.