Voici Silver SAML: Golden SAML dans le cloud

Principales conclusions

• Golden SAML, une technique d'attaque qui exploite le protocole d'authentification unique SAML, a été utilisée en tant qu'exploit post-fraude, aggravant l'attaque dévastatrice de SolarWinds en 2020 - l'une des plus grandes brèches du 21e siècle.
• L'attaque de la chaîne d'approvisionnement de SolarWinds a touché des milliers d'organisations dans le monde entier, y compris le gouvernement américain, en déployant un code malveillant dans le logiciel de gestion et de surveillance informatique Orion de la société.
• À la suite de cette attaque, les experts de la CISA et de la cybersécurité ont encouragé les organisations disposant d'environnements d'identité hybrides à transférer l'authentification SAML vers un système d'identité en nuage tel qu'Entra ID.
• Les chercheurs de Semperis Tomer Nahum et Eric Woodruff ont découvert une nouvelle application de Golden SAML, qui peut être exploitée même dans les organisations qui ont suivi les recommandations de sécurité antérieures destinées à se défendre contre Golden SAML.
• La nouvelle technique d'attaque, baptisée Silver SAML, permet d'exploiter SAML pour lancer des attaques à partir d'un fournisseur d'identité comme Entra ID contre des applications configurées pour l'utiliser pour l'authentification, comme Salesforce.
• À la connaissance de Semperis, aucune attaque utilisant Silver SAML n'a été signalée.
• Les chercheurs de Semperis estiment que cette vulnérabilité présente un risque MODÉRÉ pour les organisations. En fonction du système compromis, si Silver SAML est utilisé pour obtenir un accès non autorisé à des applications et systèmes critiques, le risque est SEVERE.

Golden SAML est une technique d'attaque connue, découverte par CyberArk et publiée par Shaked Reiner. Depuis des années, Golden SAML est connu pour son extraction de certificats de signature des services de fédération Active Directory (AD FS) et son utilisation de ces certificats pour falsifier les réponses d'authentification SAML. Aujourd'hui, nous présentons une nouvelle application de Golden SAML dans Microsoft Entra ID et sans l'utilisation d'AD FS. Voici Silver SAML.

Qu'est-ce que Silver SAML ?

Aujourd'hui, de nombreuses organisations utilisent Entra ID comme fournisseur d'identité (IdP) pour les applications SaaS (Software-as-a-Service) et LOB (Line-of-Business). SAML est le principal moyen d'authentification pour ces applications.

Dans Entra ID, Microsoft fournit un certificat auto-signé pour la signature des réponses SAML. Les entreprises peuvent également choisir d'utiliser un certificat généré en externe. Cette option présente toutefois un risque pour la sécurité.

Tout attaquant qui obtient la clé privée d'un certificat généré à l'extérieur peut forger n'importe quelle réponse SAML qu'il veut et signer cette réponse avec la même clé privée que celle détenue par Entra ID. Avec ce type de réponse SAML falsifiée, le pirate peut alors accéder à l'application comme n'importe quel utilisateur.

La preuve de concept discutée dans ce billet se concentre sur Entra ID. Mais cette attaque peut tirer profit de n'importe quel IdP qui permet l'importation de certificats de signature SAML générés en externe.

Pour les besoins de cette preuve de concept, Semperis a construit et publié un nouvel outil, appelé SilverSAMLForger, qui peut être utilisé pour falsifier les réponses SAML signées. Vous pouvez trouver SilverSAMLForger sur GitHub.

Contexte : SAML, Golden SAML et l'attaque de SolarWinds

SAML est un élément essentiel de l'authentification moderne. Par exemple, 63 % des applications Entra ID Gallery s'appuient sur SAML pour l'intégration. Les intégrations multi-cloud avec Amazon Web Services (AWS), Google Cloud Platform (GCP) et d'autres reposent sur SAML. Et de nombreuses organisations continuent d'investir dans SAML pour les applications SaaS et LOB en raison de la simplicité de sa mise en œuvre.

Golden SAML et Solorigate

Dans le cadre de l'attaque de la chaîne d'approvisionnement mondiale contre SolarWinds (alias Solorigate), Golden SAML a été l'un des vecteurs d'attaque les plus innovants des attaquants.

Les attaquants ont obtenu un accès initial à SolarWinds en insérant un code malveillant dans la plate-forme Orion de la société, utilisée pour la surveillance de l'infrastructure et la gestion informatique. Plus tard, les attaquants ont utilisé cet accès pour se déplacer latéralement dans l'environnement AD FS. De là, ils ont volé la clé privée utilisée pour signer les réponses SAML.

À la suite de cette attaque Golden SAML, de nombreuses organisations ont donné la priorité à la migration des applications vers Entra ID pour l'authentification SAML. Ce changement a supprimé la nécessité de gérer une infrastructure Tier 0 complexe, et les clés de signature SAML ne peuvent pas être exportées à partir d'Entra ID. Même la CISA recommande aux organisations ayant des environnements d'identité hybrides de déplacer l'authentification SAML vers des systèmes d'identité en nuage tels qu'Entra ID.

Le problème avec SAML et les certificats de signature

Malheureusement, de nombreuses entreprises gèrent mal les certificats de signature et affaiblissent la sécurité SAML en utilisant des certificats générés en externe. D'après nos observations, les entreprises ont tendance à.. :

• Générer des certificats de signature auto-signés sur un système client
• Générer des certificats de signature par l'intermédiaire d'une infrastructure à clé publique (PKI) d'entreprise, telle que Active Directory Certificate Services (AD CS).
• Obtenir et utiliser des certificats de signature d'une autorité de certification (AC) externe

Pour ajouter au problème, nous voyons ensuite des organisations qui prennent ces certificats générés à l'extérieur et.. :

• Envoyer des fichiers PFX de certificats et des mots de passe par le biais de canaux non sécurisés tels que Teams ou Slack.
• Générer des certificats sur les machines clientes, en laissant les certificats disponibles pour l'exportation dans le magasin de certificats local des machines.
• Générer des certificats sur des serveurs web, généralement des serveurs Microsoft Internet Information Services (IIS), en laissant les certificats disponibles pour l'exportation dans le magasin de certificats local de la machine.

Même pour les organisations qui utilisent des services tels que Azure Key Vault - une méthode plus sûre pour la gestion des secrets et des certificats - des vecteurs d'attaque peuvent exister. (Nous aborderons ces vecteurs dans la section suivante).

L'utilisation d'un certificat externe pour la signature des réponses SAML augmente la surface d'attaque de tout IdP, y compris Entra ID. Nous avons observé plusieurs leçons communes dans les organisations qui génèrent et gèrent les certificats de signature SAML à l'externe, plutôt que directement dans Entra ID.

• Absence de chaîne de confiance avec les certificats auto-signés d'Entra ID
• Impossibilité de tirer parti de la révocation des certificats avec des certificats auto-signés
• Nécessité d'appliquer aveuglément une politique d'entreprise définie à la gestion des certificats (généralement sur la base de l'une ou des deux raisons précédentes)
• Le sentiment subjectif que les certificats auto-signés sont "moins sûrs"

De plus, certaines organisations veulent maintenir une durée de vie du certificat de signature SAML plus longue que la durée par défaut d'Entra ID. Ces organisations émettent des certificats externes, sans réaliser qu'elles peuvent simplement émettre de nouveaux certificats à partir d'Entra ID et configurer ces certificats pour qu'ils aient une durée de vie plus longue.

De nombreuses organisations ne comprennent pas les nuances de l'utilisation des certificats pour la signature SAML ; les certificats de signature sont simplement intégrés dans leurs directives et politiques générales de gestion des certificats. Bien que les pratiques communes de gestion et de cycle de vie des certificats soient importantes pour de nombreux types de systèmes, elles ne s'appliquent pas et ne devraient pas s'appliquer aux certificats utilisés pour la signature SAML.

Une chaîne de confiance n'est pas pertinente dans SAML. La plupart des IdP et des applications des fournisseurs de services (SP) ignorent toute chaîne de confiance. Contrairement au scénario serveur/client que l'on rencontre dans les navigateurs web, l'administrateur est effectivement un élément essentiel de la chaîne de confiance dans les configurations SAML. L'administrateur doit configurer et spécifier le certificat de signature auquel il faut faire confiance, en particulier dans l'application.

La révocation des certificats n'est pas non plus une pratique pertinente avec SAML. Si un certificat de signature est compromis, un administrateur doit effectuer une rotation (c'est-à-dire remplacer) ce certificat dans le SP et l'IdP. La version 1.0 du profil d'interopérabilité des métadonnées SAML 2.0 de l'OASIS indique spécifiquement qu'il faut s'abstenir d'utiliser des listes de révocation, le protocole OCSP (Online Certificate Status Protocol) ou d'autres mécanismes pour la validation des clés. Au lieu de cela, vous devez demander à l'IdP de supprimer les clés compromises des métadonnées SAML.

Importation de certificats externes

Comme le montre la figure 1, vous pouvez configurer des certificats auto-signés sur une application d'entreprise (Okta, dans cet exemple) dans le centre d'administration d'Entra via les paramètres Manage > Single sign-on > SAML > SAML Certificates de l'application.

Dans le volet Certificat de signature SAML, vous pouvez importer votre propre certificat pour signer la réponse SAML ou les assertions(Figure 2).

Qu'en est-il d'Azure Key Vault ?

Nous devons prendre un moment pour parler d'Azure Key Vault : l'un des endroits où les certificats auto-signés peuvent être stockés. Nous voulions déterminer si un attaquant pouvait extraire des clés de Key Vault. Spoiler : C'est possible. (Si votre organisation n'utilise pas Key Vault, n'hésitez pas à passer à la section suivante).

Azure Key Vault est une solution populaire de gestion des clés fournie par Microsoft. Key Vault vous permet de stocker et de gérer en toute sécurité des secrets, des clés de chiffrement et des certificats.

Comme la plupart des services en nuage, Key Vault comporte deux plans qui régissent l'accès et la gestion : le plan de contrôle et le plan de données.

• Plan de contrôle. Les rôles et les autorisations attribués au plan de contrôle sont associés à des tâches administratives et à des paramètres de configuration du coffre-fort. Les utilisateurs, les groupes ou les responsables de service auxquels sont attribuées des autorisations au niveau du plan de contrôle peuvent configurer des stratégies d'accès, créer des espaces de stockage de clés et effectuer d'autres tâches de gestion. Les droits peuvent être accordés de manière granulaire à un coffre-fort individuel, mais ils sont souvent accordés au niveau du groupe de ressources, de l'abonnement ou du groupe de gestion.
• Plan de données. Le plan de données concerne les données réelles stockées dans un coffre-fort à clés : secrets, clés et certificats. Les droits attribués sur le plan de données déterminent quels utilisateurs ou responsables de service peuvent lire et écrire des données cryptographiques dans le coffre-fort et à partir de celui-ci. Ces droits incluent la possibilité de lire les clés privées des certificats, ce qui pose un problème si ces clés sont utilisées pour la signature des réponses SAML.

Les autorisations relatives à la chambre forte peuvent être accordées par le biais d'un contrôle d'accès basé sur les rôles (RBAC) ou de stratégies d'accès à la chambre forte.

Le modèle de permissions RBAC

Avec le modèle RBAC(figure 3), tout utilisateur qui détient l'un des rôles RBAC suivants peut récupérer le certificat d'un coffre-fort à clés.

• Administrateur de la chambre forte
• Responsable des certificats de la chambre forte
• Administrateur de l'accès aux données du coffre-fort. Ce rôle vous permet de gérer l'accès en ajoutant ou en supprimant des attributions de rôles. Par conséquent, vous pouvez attribuer le rôle d'administrateur de chambre forte ou de responsable des certificats de chambre forte à n'importe quelle entité.
• Contributeur au coffre-fort. Ce rôle n'accorde pas d'autorisations sur le plan des données, mais permet de mettre à jour la politique d'accès au coffre-fort si le modèle d'autorisation des politiques d'accès est également utilisé.

La figure 4 présente un exemple d'autorisations accordées à l'administrateur de la chambre forte.

Une personne ayant le rôle de contributeur au coffre-fort, qui n'a pas d'autorisation de plan de données pour accéder aux secrets et aux certificats du coffre-fort, peut quand même les extraire si des stratégies d'accès sont utilisées. Ce rôle dispose de l'autorisation de plan de contrôle Microsoft.KeyVault/*. Cette autorisation peut être traduite en Microsoft.KeyVault/vaults/accessPolicies/write, ce qui permet au titulaire d'écrire des politiques d'accès au coffre-fort et d'extraire des secrets du coffre-fort.

Si vous pouvez ajouter des autorisations RBAC au niveau du groupe de ressources ou de l'abonnement, en prenant le contrôle d'un compte de propriétaire de groupe de ressources ou d'un compte d'utilisateur disposant de l'autorisation RBAC Role Based Access Control Administrator ou de tout utilisateur disposant de l'autorisation Microsoft.Authorization/roleAssignments/write, vous pouvez ajouter des autorisations au niveau du coffre-fort de clés. Le coffre-fort de clés héritera alors de ces autorisations. Comme indiqué précédemment, certains rôles RBAC peuvent également modifier directement les politiques d'accès à la chambre forte.

Les comptes d'automatisation et les identités gérées disposant des autorisations nécessaires permettent également d'accéder aux coffres-forts des clés.

Le modèle d'autorisation des politiques d'accès à la chambre forte

Dans ce modèle, vous pouvez également accorder des autorisations d'accès à la chambre forte à un utilisateur, à un service ou à un groupe. Vous avez le choix entre les autorisations de clés, les autorisations de secrets et les autorisations de certificats(figure 5).

Vous pouvez ajouter des stratégies d'accès dans le volet Stratégies d'accès au coffre-fort de clés(figure 6).

Tout attaquant qui prend le contrôle d'un utilisateur, d'un principal de service ou d'un groupe autorisé à récupérer le fichier PFX utilisé pour signer les assertions ou les réponses SAML pour le PS attaqué - par le biais de politiques d'accès RBAC ou Key Vault - peut effectuer une attaque Silver SAML sur ce PS.

SAML et Entra ID

SAML, dans sa version actuelle 2.0, a presque 20 ans. L'OASIS a publié le protocole en mars 2005. Depuis, de nombreuses entreprises ont adopté SAML pour l'authentification fédérée et les solutions SSO basées sur le web. La principale mise en œuvre du protocole - et le cas d'utilisation au sein d'Entra ID - consiste à tirer parti du profil SSO du navigateur Web.

Un flux de profil SAML typique comporte trois éléments principaux :

• Le fournisseur de services (SP), ou l'application ; également communément appelé "relying party" (RP) dans l'écosystème Microsoft.
• Le fournisseur d'identité (IdP), qui, dans notre démonstration de concept, est Entra ID
• L'agent utilisateur, généralement le navigateur web d'un client (utilisateur final)

Les utilisateurs interagissent avec les applications pour l'authentification de plusieurs manières, selon que l'application est configurée pour ou prend en charge les flux initiés par le SP ou par l'IdP.
Dans un flux initié par le SP(figure 7), la séquence suivante se produit :

1. L'utilisateur accède à l'URL de l'application (SP).
2. Le SP génère une demande SAML(figure 8) et redirige l'utilisateur vers Entra ID (IdP).
3. Entra ID consomme la demande SAML.
4. Si l'utilisateur ne s'est pas encore authentifié auprès d'Entra ID, il est invité à le faire.
5. L'utilisateur s'authentifie avec succès à Entra ID.
6. Entra ID génère une réponse SAML(Figure 9) et redirige l'utilisateur vers le SP.
7. Le prestataire de services vérifie la réponse SAML.
8. L'utilisateur reçoit l'accès à l'application.

Dans un flux initié par l'IdP(figure 10), la séquence suivante se produit :

1. L'utilisateur se rend sur myapps.microsoft.com.
2. Si l'utilisateur ne s'est pas encore authentifié auprès d'Entra ID, il est invité à le faire.
3. L'utilisateur s'authentifie avec succès à Entra ID.
4. Entra ID fournit une liste d'applications disponibles pour l'utilisateur dans myapps.microsoft.com.
5. L'utilisateur sélectionne l'application cible.
6. Entra ID génère une réponse SAML et redirige l'utilisateur vers le SP.
7. Le prestataire de services vérifie la réponse SAML.
8. L'utilisateur reçoit l'accès à l'application.

Le contenu d'une assertion SAML comprend plusieurs informations sur l'utilisateur final, ou sujet, dans une série de paires clé-valeur. Ces informations sont souvent appelées "revendications SAML" et comprennent des informations telles que :

• Le sujet. L'application utilise ce composant obligatoire comme identifiant unique de l'utilisateur. Dans de nombreuses applications, le sujet est le nom principal de l'utilisateur (UPN) ou l'adresse électronique de l'utilisateur.
• Informations sur les attributs. Ces informations peuvent inclure le prénom, le nom, l'adresse électronique et le nom d'affichage de l'utilisateur. L'appartenance à un groupe ou les rôles sont souvent fournis afin que l'application puisse prendre des décisions d'autorisation concernant les droits de l'utilisateur.
• Autres informations contextuelles d'authentification. Ces informations peuvent inclure le type d'authentification utilisé, l'émetteur et l'audience, ainsi que des informations d'horodatage indiquant la fenêtre de validité de la réponse SAML.

Comment s'assurer que la réponse SAML, qui est traitée par l'utilisateur, n'a pas été altérée ? C'est là que la signature entre en jeu.

Entra ID prend en charge la signature des réponses et des assertions SAML. À un niveau élevé, l'objectif de la signature de la réponse et de l'assertion est de vérifier que le contenu de la réponse n'a pas été altéré et que l'application peut faire confiance à l'information contenue dans la réponse. L'application utilise la signature pour valider que la réponse a été générée par l'IdP, qui détient la clé privée utilisée pour signer la réponse.

C'est pourquoi le vol de la clé privée de signature est un problème critique. Avec la clé de signature en main, un acteur de la menace peut falsifier une copie d'une réponse SAML, réalisant ainsi une attaque Silver SAML.

Exécution d'une attaque Silver SAML

Pour tester la théorie selon laquelle la technique d'attaque Golden SAML peut être retournée contre Entra ID - dans ce que nous avons appelé une attaque Silver SAML - nous avons construit l'outil SilverSAMLForger. Cet outil génère une réponse SAML qui duplique une réponse d'Entra ID, signant cette réponse avec un certificat fourni.

Notre démonstration de faisabilité de Silver SAML part du principe qu'une organisation utilise un certificat de signature généré en externe, qu'un pirate a obtenu en utilisant l'une des méthodes décrites précédemment. Nous envisageons d'appliquer Silver SAML à la fois aux flux initiés par le SP et aux flux initiés par l'IDP, car les deux sont susceptibles d'être attaqués.

Silver SAML dans un flux initié par un prestataire de services

Attaque SAML en argent utilisant Entra ID comme IdP et Okta comme SP. Pour lancer l'attaque dans un flux initié par le SP, nous avons dû intercepter la requête SAML et remplacer le contenu de la réponse SAML par la réponse SAML falsifiée que nous avons créée(Figure 11). Nous avons pu accomplir ces tâches facilement en utilisant Burp Suite.

Dans cet exemple, nous avons tenté de falsifier une réponse SAML pour l'utilisateur oktaAdministrator@xd6z7.onmicrosoft.com. Cet utilisateur est un super administrateur dans Okta. Nous ne disposons pas du mot de passe de l'utilisateur ni de son dispositif connecté MFA (s'il est configuré).

Tout d'abord, nous avions besoin de certains attributs dans les informations de réclamation SAML conformément à ce qui a été défini lorsque l'application a été enregistrée sur l'IdP. Par exemple, nous avons besoin de l'UPN, du nom de famille, du prénom, du displayName et de l'objectID. Un attaquant peut facilement trouver ces attributs dans le centre d'administration d'Entra ou en utilisant l'API Microsoft Graph.

Nous devions également connaître le destinataire et l'audience. Ces informations étaient disponibles dans le centre d'administration d'Entra, dans le panneau d'ouverture de session unique de l'application(Figure 12).

L'exécution de SilverSAMLForger.exe avec les paramètres requis produit une chaîne encodée en base64 et en URL(Figure 13). Nous pouvons maintenant copier cette réponse SAML falsifiée.

Nous avons copié la réponse SAML générée sur la requête HTTPS interceptée(Figure 14) et modifié la réponse en une réponse falsifiée(Figure 15).

Après avoir envoyé la réponse falsifiée, nous pouvons arrêter l'interception car nous sommes maintenant connectés en tant qu'utilisateur ciblé(Figure 16).

Attaque SAML en argent dans un flux initié par l'IdP

Les flux initiés par l'IdP présentent un risque beaucoup plus grand pour l'organisation car aucune interaction n'est requise avec Entra ID. Si l'application supporte les flux initiés par l'IdP, vous pouvez directement envoyer une réponse SAML à l'application(Figure 17).

Pour cette partie de la démonstration de faisabilité, nous avons essayé d'effectuer une attaque initiée par l'IdP contre Salesforce.

Nous avons ciblé l'utilisateur Patti Fernandez, en forgeant une réponse avec son UPN comme sujet. La réponse(Figure 18) a été signée à l'aide du même certificat de signature SAML que celui configuré pour Salesforce dans Entra ID.

En décodant cette réponse, vous pouvez voir qu'il s'agit d'une réponse falsifiée pour Patti(figure 19).

Dans Burp Suite, nous avons utilisé Repeater pour envoyer directement la réponse SAML falsifiée à notre instance de Salesforce(Figure 20).

En ouvrant la réponse dans un navigateur, nous avons vérifié que nous étions connectés à Salesforce en tant que Patti, sans aucune interaction avec Entra ID(figure 21).

Défense contre les attaques Silver SAML

Pour se protéger efficacement contre les attaques SAML de Silver dans Entra ID, votre organisation doit utiliser uniquement des certificats auto-signés Entra ID pour la signature SAML.

Les certificats de signature SAML sont stockés dans le principal de service pour une application SAML dans Entra ID. Vous pouvez utiliser l'API graphique pour voir les informations qui sont exposées sur la clé de signature. Il suffit d'envoyer une requête GET à l'URI suivante :

https://graph.microsoft.com/beta/servicePrincipals/{serviceprincipalobjectid}

La figure 22 montre un exemple des informations exposées. Notez que la clé privée n'est pas exportable, ce qui empêche les attaquants de rassembler les informations dont ils ont besoin pour lancer une attaque Silver SAML.

Les administrateurs globaux, les administrateurs d'applications, les administrateurs d'applications en nuage et tout utilisateur à qui l'on délègue la propriété d'une application peuvent modifier les clés de signature disponibles et peuvent importer une clé de signature externe. Bien que l'application associée doive être mise à jour, les organisations devraient limiter le nombre de personnes qui ont la propriété des applications dans Entra ID. À tout le moins, il faut surveiller les changements apportés aux clés de signature SAML, surtout si la clé n'est pas près d'expirer.

Les organisations peuvent auditer les principaux services existants qui sont configurés pour SAML et vérifier le nom d'affichage (displayName). Si le certificat utilisé est généré par Microsoft, il contiendra la valeur CN=Microsoft Azure Federated SSO Certificate. Cependant, rien n'empêche un attaquant d'importer un certificat externe ayant le même nom de sujet.

Les organisations peuvent également surveiller les journaux d'audit d'Entra ID pour les changements de PreferredTokenSigningKeyThumbprint sous ApplicationManagement. Vous devrez établir une corrélation entre ces événements et les événements Add service principal credential qui se rapportent au service principal. La rotation des certificats expirés étant un processus courant, vous devrez déterminer si les événements d'audit sont légitimes. La mise en œuvre de processus de contrôle des changements pour documenter la rotation peut aider à minimiser la confusion pendant les événements de rotation.
Si une application prend en charge à la fois SAML et OpenID Connect (OIDC) pour l'authentification, vous pouvez envisager de modifier l'intégration avec Entra ID pour utiliser OIDC, ce qui atténue cette attaque. La complexité du passage de SAML à OIDC dépend largement de la façon dont le développeur de l'application a mis en œuvre les normes.

Du côté des applications, les développeurs d'applications peuvent se protéger contre les attaques de plusieurs façons. (Vos options dépendront des méthodes et des bibliothèques utilisées dans votre implémentation SAML).

• Exiger des flux initiés par le SP, qui protègent contre les flux initiés par l'IdP - les types d'attaques les plus dangereux.
• Pour les flux initiés par le prestataire, il convient de respecter la spécification SAML et de veiller à ce que les réponses contiennent une valeur InResponseTo qui corresponde à une demande SAML associée.
• Observer le délai dans lequel l'application reçoit une réponse SAML. L'IdP indique une fenêtre de validité dans la réponse, mais les développeurs d'applications peuvent introduire d'autres limites logiques à la fenêtre acceptable pour la réception d'une réponse dans les flux initiés par le PS.
• Offrir le choix d'utiliser OIDC au lieu de SAML pour l'intégration.

Ne vous laissez pas surprendre par Silver SAML

Comme l'attaque Golden SAML, les attaques Silver SAML peuvent être légères ou dévastatrices. Comme l'adoption d'environnements d'identité en nuage et hybrides continue de croître, nous nous attendons à voir plus de menaces visant les IdP comme Entra ID. Ce billet montre comment Silver SAML est possible avec Entra ID, mais tout IdP qui vous permet d'utiliser des certificats auto-signés est susceptible d'être attaqué. Nous encourageons les organisations à prendre des mesures décisives dès maintenant pour combler les lacunes et les vulnérabilités dans ces environnements.

Divulgation

Ce problème a été signalé via le Microsoft Security Response Center (MSRC) le 2 janvier 2024. Microsoft a répondu le 26 février 2024 : "Après une enquête approfondie, ce cas a été évalué comme étant une erreur de conception et ne répond pas aux critères du MSRC pour une intervention immédiate. Cependant, nous avons partagé le rapport avec l'équipe responsable de la maintenance du produit ou du service. Ils prendront les mesures nécessaires pour assurer la protection des clients."

Chronologie

• 2 janvier 2024 : Création de l'affaire du CSEM
• Le 3 janvier 2024 : Le statut du dossier est passé à Examen/Reprod
• 17 février 2024 : Examen de l'article de recherche par le CSEM
• 26 février 2024 : Réception de la réponse du CSEM
• Le 29 février 2024 : Divulgation publique