Piratage Solarwinds : quelles sont les conséquences pour la sécurité de la gestion des accès ?

En décembre 2020, FireEye a découvert une attaque sophistiquée à grande échelle ayant un impact sur le gouvernement américain et de nombreuses entreprises privées. Cela a entraîné la fuite de messages de Microsoft 365 (le nouveau nom d'Office 365). Début janvier, il a été signalé que 3 000 boîtes du ministère de la Justice des États-Unis avaient été compromises de cette manière.

L'un des vecteurs de cette attaque remonte au logiciel Orion de la société SolarWinds. Cette référence au soleil dans la dénomination sociale de l'entreprise a donné lieu à de nombreux noms pour l'attaque et ses différents vecteurs : Solorigate, SolarStorm, Sunburst, etc. Afin de ne pas incriminer un éditeur victime, nous parlerons dans cet article de Sunburst attack, bien que le terme ne fasse pas référence à l'attaque dans son ensemble, mais à l'un de ses vecteurs.

A voir aussi : 4 raisons d’adopter un VPN

L'attaque est complexe et consiste en une longue chaîne de des compromis qui conduisent finalement à un vol d'identité impliquant des solutions de gestion des accès Microsoft : ADFS et Azure AD.

On peut se poser la question suivante : s'agit-il d'un problème limité à Microsoft ou est-ce que l'usurpation d'identité aurait été possible avec d'autres solutions d'authentification ?

A lire en complément : Les étapes à suivre pour restaurer la sécurité de votre site WordPress après un piratage

Avant de répondre à la question, nous commençons par expliquer comment les boîtes ont été piratées pour revenir progressivement au début de l'attaque. Il est précisé qu'il s'agit d'une interprétation de notre part en fonction des informations rendues publiques à la date de publication.

Authentification Microsoft 365

Pour se connecter à l'e-mail de leur victime, les attaquants ne connaissaient pas leur mot de passe car ils n'en avaient pas besoin. Tout ce qu'ils avaient à faire était de créer un jeton d'identité frauduleux contenant l'identité de leur cible et de le présenter à Microsoft 365 qui l'accepté.Pour le comprendre, partons du fonctionnement normal (ici simplifié pour plus de clarté) .Pour accéder à M365, un utilisateur est d'abord dirigé vers Azure AD pour l'authentification. Azure AD génère ensuite un jeton avec l'identité de l'utilisateur et le signe avec sa clé privée. L'utilisateur est renvoyé vers M365 avec ce jeton (nous en diagrammes ici — des mécanismes sont en place pour sécuriser ce transfert) .Microsoft 365 vérifie ensuite la validité du jeton en vérifiant sa signature avec la clé publique Azure AD. Il finit par extraire l'identité de l'utilisateur et lui donner accès au service.

Authentification Microsoft 365

Accéder aux e-mails Microsoft 365 de quelqu'un d'autre

Les attaquants ont pu s'insérer en amont de l'authentification de la cinématique et faire générer un jeton par Azure AD sans que l'utilisateur soit authentifié. Ce jeton true-faux est alors légitimement accepté par Microsoft 365. Pour ce faire, deux méthodes ont été employées• Pour les organisations disposant d'un ADFS, une clé privée a été volée sur le réseau local. C'est le scénario cauchemardesque où l'attaque devient imparable et indétectable.• En l'absence d'ADFS, les attaquants ont obtenu un accès administrateur à la console Azure AD et ont ajouté la fédération à leur propre serveur d'authentification. Cela fonctionne tout aussi bien, mais c'est plus visible puisque les modifications de configuration sont visibles par les administrateurs

Usurpation d'identité avec la clé privée ADFS

Les organisations déploient un fournisseur d'identité ADFS afin que les utilisateurs accèdent à Microsoft 365 via une authentification Active Directory interne. Azure AD n'effectue plus d'authentifications en direct mais est configuré pour rediriger les demandes d'authentification vers ADFS, qui vérifie le mot de passe sur l'AD. Le résultat est ensuite retracé jusqu'à Azure AD sous la forme d'un jeton qui sert de base à la génération d'un autre jeton qui est finalement transmis à M365.

Authentification M365 à AD avec ADFS

Avec Sunburst, l'attaquant a exploité une faiblesse du SAML protocole, dans sa configuration standard dans l'authentification cloud. Cette cinématique indique que le jeton est directement présenté par l'utilisateur, qui y a accès et peut le manipuler. En étant capable de voler la clé privée ADFS, l'attaquant crée facilement un faux jeton SAML de haut en bas. Il place notamment l'identité de la boîte dont il souhaite lire les messages. Il signe ensuite le jeton avec la clé volée et le présente à Azure AD (nous le diagrammes évidemment un peu). Azure AD fait confiance à ADFS, de sorte que le jeton est accepté. L'agresseur est reconnu comme sa victime. Azure AD génère un jeton final valide, toujours avec l'identité de la victime. Ce jeton est transmis à Microsoft 365 qui doit d'abord le valider. Et comme il a été signé avec la clé Azure AD légitime, le jeton passe toutes les vérifications de Microsoft 365 malgré sa falsification. Cela donne donc accès à la boîte de la victime et l'attaquant peut récupérer discrètement toutes les informations souhaitées.

Accès à M365 après le vol de la clé privée ADFS

L'attaque est rendue possible par le vol de la clé privée, qui se produit en se connectant au serveur en tant qu'administrateur. Une fois cet accès obtenu, la procédure est alors très simple, car la clé est récupérée par une simple commande d'administration.La condition, il est donc d'être sur le réseau local et d'avoir un accès administrateur. Avant d'expliquer comment les attaquants ont procédé pour l'obtenir, nous décrivons la deuxième méthode d'accès à une boîte, par le biais du courtage d'identité, et pour laquelle l'accès administrateur était tout aussi nécessaire.

Passer à un autre par courtage d'identité

Le principe du courtage d'identité est le chaînage des serveurs d'identité. En cinématique normale, une application délègue son authentification à un fournisseur d'identité (abrégé en « IdP »). Dans notre cas, Office 365 demande à Azure AD (qui joue le rôle de fournisseur d'identité) d'effectuer l'authentification pour celui-ci. Ensuite, Azure AD demande à l'utilisateur pour leur mot de passe et le vérifie. Vous pouvez créer une chaîne en configurant Azure AD pour ne pas demander le mot de passe lui-même, mais pour accéder à un autre fournisseur d'identité, qui le fera avec votre propre annuaire (différent d'Azure AD). Comme nous l'avons vu plus haut, c'est exactement comme cela que fonctionne Azure AD lorsqu'Azure AD traite des fichiers ADF.Étant donné qu'une relation d'approbation a été établie entre le fournisseur délégué et Azure AD, ce dernier accepte l'authentification et génère un jeton vers Microsoft 365, sur la base des informations transmises par le serveur authentifié L'important est évidemment la relation de confiance, qui se matérialise par des échanges d'informations et vérifiée par des certificats et des secrets. Si l'attaquant parvient à obtenir les droits d'administrateur Azure AD, il peut définir une relation de confiance avec un serveur d'identité qu'il installe pour l'occasion et c'est ainsi qu'il est en plein contrôle. Il intègre l'identité de sa victime, avec un mot de passe qu'il définit lui-même. Microsoft 365, qui l'envoie d'abord à Azure AD. Il saisit un identifiant qui déclenche la redirection vers son serveur d'identité. Il s'authentifie avec le mot de passe qu'il s'est attribué et le serveur génère un jeton contenant l'identité de la victime. Grâce à la relation de confiance établie, Azure AD accepte le jeton et génère à son tour un jeton d'accès à Microsoft, qui contient l'identité tirée du jeton initial, celui de la victime. Un véritable jeton, généré par Azure AD, qui passe toutes les vérifications, mais contient une identité usurpée. Nous avons donc un vrai faux jeton.

Ajout d'une délégation d'authentification frauduleuse

La différence avec le vol de la clé privée est que la configuration configurée est visible pour les administrateurs légitimes qui pourront se rendre compte que leur système a été compromis. Mais comme la création d'une fédération est un événement très rare, il n'est pas étonnant que personne n'en ait vu N'importe quoi. Pour que cette attaque fonctionne, vous avez toujours besoin du mot de passe d'un administrateur Azure AD. Dans l'affaire Sunburst, il a été récupéré sur le réseau local, dans lequel l'attaquant a fait irruption.

Obtenir un accès administrateur

Pour les deux types d'attaques observés, l'accès administrateur était essentiel et était obtenu à partir du réseau local.Dans le cas d'un vol de clé privée, l'attaquant s'est connecté au serveur ADFS et a pu obtenir un accès privilégié en volant un ticket Kerberos. Dans le cas du courtage d'identité, il a probablement récupéré un mot de passe administrateur non chiffré, qui était suffisant pour se connecter à Azure AD qui n'était pas protégé par MFA (authentification multifacteur). C'est que l'accès administrateur a été volé sur le réseau local, une fois l'accès obtenu. En contrôlant une machine Windows sur le réseau local, il existe plusieurs techniques pour récupérer le mot de passe en texte brut, soit un ticket ou un hachage pouvant être directement réutilisé. Ils sont basés sur le fait que Windows conserve ces informations en mémoire afin de pouvoir être réutilisées. Ce n'est évidemment pas à la portée de tout le monde, mais les assaillants en question n'étaient pas tout le monde ! Une fois qu'ils ont atteint le réseau local, les assaillants ont utilisé des mouvements latéraux et des mécanismes d'évasion pour atteindre leurs objectifs.

Entrez dans le réseau local

Pour accéder au réseau local, les attaquants ont commencé par s'attaquer à SolarWinds, qui publie la plate-forme de gestion des systèmes d'information Orion. Ils ont réussi à introduire des logiciels malveillants dans le code logiciel (par un moyen non encore élucidé à ce jour), qui a ensuite été distribué à tous les clients de la solution lors d'une mise à jour automatique.Une fois la mise à jour installée, le malware qu'elle intègre active et contacte le centre de contrôle et de commande (C&C) de les attaquants qui ont pu manœuvrer à distance. Pour ce faire, ils ont simulé des requêtes DNS. Un second malware a ensuite été installé pour mettre en veille leur accès initial et le préserver en cas de découverte.

Compromis par contamination des mises à jour logicielles

Des conséquences qui auraient pu être dévastatrices

Début janvier 2021, l'ampleur exacte de l'attaque attribuée aux acteurs gouvernementaux russes n'est pas encore connue. Les conséquences semblent limitées pour le moment, mais c'est probablement parce que l'objectif était centré sur le gouvernement. Américain. On estime que 18 000 organisations ont installé le composant compromis d'Orion. En ces temps de ransomware, si la motivation des attaquants avait été pécuniaire, les dégâts auraient été bien plus importants. Ils se sont concentrés sur leur objectif final, par exemple en volant simplement des éléments utiles dans ce contexte (outils offensifs FireEye, code source Microsoft et Cisco), alors qu'ils auraient pu gagner de l'argent en pillant le patrimoine informatique des nombreuses entreprises compromises.

Bonne nouvelle : Microsoft 365 et Azure AD ont un haut niveau de sécurité

L'attaque suscite évidemment de nombreux questions sur la vulnérabilité de tous les systèmes d'information, mais nous allons ici nous concentrer sur ce que cela nous apprend sur les risques liés à la gestion des accès.La première constatation qui peut être faite est l'ampleur des efforts qui ont dû être déployés pour ouvrir finalement quelques milliers de boîtes aux lettres dans Cloud. Suivant la chronologie, SolarWinds a été compromis en septembre 2019, les versions modifiées d'Orion datent de mars 2020 et l'attaque a été détectée début décembre 2020 lorsque des acteurs malveillants ont volé des outils d'attaque sophistiqués de FireEye en utilisant la même porte d'entrée. Nous pouvons évidemment penser que ces outils allaient être utilisés pour attaquer des cibles gouvernementales protégées. Nous sommes donc confrontés à une attaque à long terme, impliquant de nombreuses étapes pour voler des messages électroniques sans être remarqués. La première chose que nous pouvons noter est que les deux méthodes utilisées sont basées sur des prérequis. • Le vol de la clé privée SAML nécessite que l'organisation cible délègue l'authentification à un ADFS qui utilise un cinématique où le jeton passe par l'utilisateur• L'authentification directe vers la console d'administration Azure AD aurait été plus compliquée si l'authentification multifacteur (MFA) avait été déployéeIl est alors noté que pour accéder aux boîtes aux lettres, les attaquants n'utilisaient pas de méthodes plus directes de compromission des informations d'identification, telles que brute pulvérisation forcée ou de mot de passe sur la page de connexion Azure AD. Il faut également dire qu'il est probable que l'objectif des attaquants n'était pas simplement d'accéder aux boîtes aux lettres, mais d'atteindre d'autres ressources plus confidentielles sur les réseaux locaux. Le piratage des e-mails était peut-être tout simplement opportuniste, mais avec les sauvegardes Azure AD, la force brute, la pulvérisation de mots de passe ou les méthodes de spear phishing nécessitent beaucoup d'énergie pour chaque boîte. En les utilisant, il aurait été difficile d'atteindre des centaines de milliers de boîtes compromises sans être détectées. Toutefois, ce type de méthode reste valable pour les attaques hautement ciblées. Ils ont en fait été utilisés par les assaillants, afin de pénétrer le réseau local de certaines victimes lorsque le vecteur Sunburst n'était pas possible. C'est alors l'accès à distance (du type bureau distant) qui a été ciblé.

L'accès administrateur a donné plus de possibilités sur les serveurs internes que sur Office 365

Le point clé de l'attaque a été d'obtenir un accès administrateur. Les attaquants l'avaient, selon les organisations ciblées, pour les serveurs ADFS internes ou pour l'interface d'administration Azure AD. La compromission du serveur ADFS interne a permis de falsifier les jetons SAML avec un faible encombrement. Microsoft indique que la clé privée ADFS est volée par une requête LDAP sur Active Directory (entrée CryptoPolicy dans l'unité d'organisation ADFS). Il faudrait donc surveiller l'accès à cette entrée, ce qui n'a pas été fait pour les organisations compromises et ce qui n'est fait par pratiquement personne. La probabilité est donc élevée que le vol ait lieu subrepticement. La séquence des opérations (contrefaçon de jetons) est totalement indétectable. Une fois la clé privée acquise, l'attaque devient indétectable. La surveillance de l'origine des connexions à Azure AD n'aurait rien donné, car les attaquants avaient la capacité d'agir à partir du réseau local. administrateurs avertis. L'attaque peut donc être découverte à tout moment.

La gestion des accès de Microsoft a été compromise, qu'est-il advenu des autres solutions ?

L'attaque Sunburst a ciblé ADFS et Azure AD, en raison du rôle central que jouent ces systèmes dans l'accès à Microsoft 365. Nous pouvons nous demander si les conséquences auraient été différentes si les attaquants étaient tombés sur un IdP différent (fournisseur d'identité), ou si la fédération avec Azure AD avait été réalisée par OpenID Connect au lieu de SAML.Trois situations seront étudiées ici, prises dans un contexte général, sans aller dans les détails de chaque implémentation : • Prise de contrôle du serveur hébergeant un IdP• Accès administrateur à la console d'administration d'un IdP• Le vol de la clé privée d'un OpenID Connect/OAuth 2 IdP

Le rachat du serveur hébergeant le fournisseur d'identité est catastrophique

Les attaquants ont réussi à prendre le contrôle de l'ADFS interne. Mais les mêmes techniques (ou techniques similaires) auraient pu être utilisées pour s'en prendre à un autre fournisseur d'identité, toujours avec des droits. Ils auraient eu accès à la configuration pour la modifier, ce qui est discuté dans le prochain chapitre.Ils auraient certainement pu voler toutes les clés privées, avec les mêmes conséquences en SAML et avec des conséquences dans OIDC/OAuth 2 dont nous discutons ci-dessous. accès au répertoire, soit en consultant les journaux qui donnent la liste des identifiants, soit en récupérant les informations de connexion dans l'IdP (en déchiffrant le mot de passe ou par un autre moyen) .Mais ils auraient également pu modifier la source code de l'IdP et a rendu le vol d'identité difficile à détecter. Tout ce que vous avez à faire est d'ajouter un faux code pour que, lorsqu'un identifiant inventé est saisi, l'authentification soit validée sans condition et des jetons soient générés avec une identité usurpée transmise par exemple dans le champ mot de passe.

Corruption du code source d'un IdP

La modification du code source est souvent simple à faire, tant que vous avez accès en écriture au système de fichiers. Certaines solutions gratuites sont développées en Perl. Le code est donc clair et les modifications sont prises en compte à la volée, sans même avoir à redémarrer le service.La plupart des IdP sont en Java. Il nous est arrivé de récupérer des fichiers the.class, de les décompiler, de modifier le code, puis de les recompiler. Ensuite, vous devez redéployer la webapp, ce qui est facile à faire. Mais parfois, c'est plus facile. Avec Shibboleth, nous avons modifié le comportement de l'IdP et créé l'emprunt d'identité en ajoutant simplement du code Java dans les pages JSP mises à disposition pour personnaliser la page d'authentification. Critique.

Protéger l'accès à la console d'administration du fournisseur d'identité

Lorsque l'organisation cible ne disposait pas d'ADFS, les attaquants pouvaient utiliser un Active Directory mot de passe récupéré sur le réseau local pour se connecter à l'interface d'administration Azure AD. Cela a été possible car la plupart du temps, le répertoire cloud est synchronisé avec l'annonce interne.Si la solution de gestion des accès est installée localement, l'attaquant a montré qu'il avait les moyens de prendre le contrôle du serveur et de modifier la configuration directement dans les fichiers, voire d'aller plus loin en retouche le code source pour laisser moins de traces. Il n'a donc pas beaucoup d'intérêt à se connecter à la console d'administration. En revanche, si la gestion des accès se fait dans le cloud, le fait d'avoir le mot de passe pour accéder à la console d'administration est le moyen le plus efficace de le compromettre, à condition que le MFA ne soit pas déployé (ou soit facilement contourné) .Toutefois, si l'accès à la console d'administration repose sur Active Directory, l'attaquant pourra pour appliquer les mêmes méthodes que pour la compromission Sunburst et récupérer un mot de passe administrateur qui fonctionnera pour Azure AD. Azure AD lors de la configuration d'une délégation à un pirate idp.Il faut alors s'assurer qu'il peut utiliser cette délégation parasite sans être remarquée, c'est-à-dire sans qu'elle soit visible par les utilisateurs finaux qui doivent continuer à s'authentifier directement.Les écrans d'authentification ne doivent pas être modifiés, tout en laissant la possibilité à l'attaquant de déclencher un contournement leur hacker IdP. Selon les solutions de gestion des accès et selon la façon dont elles sont utilisées, ce sera plus ou moins facile.Si l'authentification se fait en deux pages (le login puis le mot de passe), il est probable que personne ne s'en rendra compte. En saisissant un identifiant dans le domaine de son IdP, le système provoquera le routage souhaité par défaut. De leur côté, les utilisateurs normaux continuent de s'authentifier dans leur domaine, on leur demandera toujours leur mot de passe dans le même deuxième écran.Si l'authentification se fait sous une seule forme (login et mot de passe sur la même page), il sera encore souvent possible d'ajouter à la page en question un bouton invisible, y compris l'emplacement sera connu uniquement des assaillants, et qui déclenchera le passage à leur ID.Ainsi, il sera souvent possible de mener des attaques similaires à celles qui ont été observées avec Sunburst, sans éveiller les soupçons.

Est-ce qu'OpenID Connect et OAuth 2 sont moins vulnérables ?

Il n'est jamais inutile de rappeler les différences entre OpenID Connect et OAuth 2, ce que nous allons faire ici de manière très résumée. Les deux protocoles n'ont pas la même portée. L'un concerne les applications et l'autre les API. Cependant, ils sont souvent utilisés conjointement, d'abord OpenID Connect pour authentifier les utilisateurs, puis OAuth 2 lorsque l'application a besoin d'accéder aux données utilisateur. OpenID Connect fournit un jeton d'identité pour authentifier les applications Web. OAuth 2 génère un jeton d'accès qui ouvre l'accès aux services Web (via une application Web ou une application native) et qui peut transmettre l'identité de l'utilisateur final. Pour schématiser, le jeton d'identité OpenID Connect est utilisé directement par l'application qui l'obtient (souvent exécuté sur un serveur), tandis que le Le jeton d'accès OAuth 2 sert de méthode indirecte : il est récupéré par une application qui le présente à une API. Si un attaquant vole la clé privée de l'IdP, a-t-il les mêmes possibilités dans OIDC/OAuth 2 que ce que nous avons vu pour SAML ? En d'autres termes, est-il possible de générer un jeton d'identité ou un jeton d'accès et de le présenter pour obtenir un accès indu ?

OpenID Connect comble les failles de sécurité SAML

OpenID Connect et son jeton d'identité n'ont vraiment de sens que pour les applications dites confidentielles, c'est-à-dire hébergées sur un serveur. L'autre type d'application est appelé client public, essentiellement des applications monopage (applications monopage exécutées dans un navigateur) et des applications mobiles. Un client public peut difficilement se fier à des identités pour sa propre sécurité. Un SPA sécurisé est un oxymore, car il fonctionne dans un environnement (le navigateur) où la sécurité ne peut être garantie. Ce que vous devez protéger dans le contexte d'un SPA, c'est l'accès au backend, qui contient les données. applications confidentielles, avec OpenID Connect, le jeton d'identité est échangé directement entre les serveurs, sans jamais passer par le navigateur (du moins si la cinématique implicite obsolète est effectivement interdite). Il convient de noter que le risque le plus important couvert par cet appareil est le vol du jeton dans le navigateur plutôt que la falsification des jetons, qui est plus compliquée à effectuer. OpenID Connect a donc capitalisé sur l'expérience SAML pour offrir une cinématique plus sécurisée. Il convient toutefois de noter que SAML a fourni un mode de fonctionnement similaire pour l'échange de jetons entre serveurs, appelé liaison d'artefact, mais qui n'est pas très répandu.

OpenID Connect protège le jeton

OAuth 2 doit être implémenté correctement dans les cas d'utilisation où il s'applique

Avec OAuth 2, la situation ressemble parfois à celle qui permettait la présentation de faux jetons SAML.

N'oubliez pas que le protocole effectue l'autorisation d'une API (un service Web) appelée par une application.

Si l'API est conçue pour être appelée uniquement par des applications exécutées sur des serveurs (applications confidentielles), les meilleures pratiques recommandent que l'accès à l'API ne soit possible que par des applications dûment autorisées. La connexion à l'API ne devrait être possible qu'après authentification de l'application, ou après des protections au niveau du réseau, ou par les deux mesures si possible. Un attaquant devra donc vaincre ces appareils pour réussir à présenter un faux jeton.

Cependant, de plus en plus d'API sont publiées sur Internet, pour être appelées à partir d'un navigateur (SPA) ou d'une application mobile.

Il n'est alors plus possible d'identifier le client qui se connecte et de restreindre efficacement l'accès au service Web. Un attaquant a toutes les latitude pour présenter le jeton qu'il veut.

Le jeton sera-t-il accepté comme c'est le cas avec SAML ? Cela dépend de la façon dont il est validé. La norme OAuth 2 ne donne pas de détails sur les mécanismes à mettre en œuvre, laissant le choix d'effectuer une vérification de signature ou une vérification d'introspection, qui consiste à connecter l'API au fournisseur d'identité pour lui présenter le jeton et vérifier sa validité.

Nous comprenons immédiatement la valeur de cette dernière façon de procéder, puisqu'un jeton falsifié par un attaquant ne sera pas accepté, alors qu'il sera accepté par une API qui effectue une simple vérification de signature.

De plus, les meilleures pratiques OAuth 2 stipulent que le jeton doit être de type opaque (illisible et donc non signé) avec une validation introspective.

Si ces recommandations sont suivies, le vol de la clé privée est neutralisé.

Notez que le jeton opaque reste vulnérable au vol et doit toujours être correctement protégé dans l'application. Cela est réalisable pour les applications mobiles, mais pratiquement impossible pour les SPA.

Quelques réflexions suscitées par l'attaque

Le L'attaque Sunburst est très inhabituelle par son ampleur et sa complexité. Il nous permet de réfléchir à ce qu'un acteur gouvernemental est capable de réaliser, avec tout ce que cela implique en termes de ressources et de persévérance, de sorte qu'il pose des questions sur des questions de sécurité qui, jusqu'à récemment, étaient considérées comme minimes en termes de probabilité d'occurrence.

La difficulté de protéger les secrets

Une grande partie de la sécurité du système repose sur l'existence et la protection de secrets qui garantissent l'authentification et la confidentialité des échanges : mots de passe, clés privées, etc.Ces secrets sont saisis par des opérateurs (authentification d'un visiteur d'un site web par exemple), car ils sont également utilisés directement par les systèmes : connexion à une base de données, cryptage des échanges entre modules, etc. partager et être soigneusement protégés : au mieux conservés dans des coffres-forts (magasins de clés) et au pire cryptés dans des fichiers de configuration. Mais comme il doit être récupéré automatiquement, un acteur qui a pris le contrôle du système avec des droits élevés la plupart du temps, être capable de suivre le chemin emprunté par les applications pour obtenir ou utiliser le secret. En raison de ce que l'application peut accomplir, un acteur externe ayant les mêmes droits sera généralement en mesure de le faire également. Par exemple, le cryptage des mots de passe dans le fichier de configuration est utile. Mais comme l'application doit avoir accès à la clé pour les déchiffrer, un acteur contrôlant le serveur peut faire de même et déchiffrer les mots de passe. Il faut savoir qu'un acteur malveillant qui a pris le contrôle d'une machine sera capable de faire exactement les mêmes choses que les applications qu'il héberge sont capables de faire : avoir le mot de passe pour se connecter à un système protégé (base de données, répertoire, API, etc.), signer des documents ou chiffrer des fichiers. Cependant, il est toujours possible de protéger les clés de signature et de cryptage privées et d'empêcher leur vol comme c'était le cas avec Sunburst. Les HSM sont des équipements conçus à cet effet : ils stockent des clés, les utilisent pour effectuer eux-mêmes des opérations de cryptographie et il est impossible d'en extraire les clés. Mais ce sont des systèmes onéreux. Le budget mensuel d'un HSM AWS à Paris est d'environ 1300€. Il protège les clés, mais pas les mots de passe. Un mot de passe de base de données chiffré par HSM et stocké dans un fichier de configuration est vulnérable à un attaquant qui a obtenu suffisamment de droits pour accéder à l'API HSM. Cela ne signifie évidemment pas que toute tentative de protection des secrets doit être abandonnée. Le cryptage des mots de passe dans un fichier de configuration est toujours nécessaire pour empêcher leur exploitation en cas de fuite du fichier (dépôt accidentel dans un dépôt Git par exemple).

Alors, qu'en est-il de l'authentification MFA ?

L' authentification forte est le réflexe automatique de l'ingénieur en sécurité novice, qui déclare que le mot de passe mourra d'ici un an et recommande que toute authentification se fasse par biométrie, clé sécurisée ou après confirmation sur un téléphone portable. Le monde sera alors sauvé. De toute évidence, la réalité est bien plus contrastée ; L'AMF est souvent souhaitable mais sa généralisation est parfois impossible et, dans certains cas, contre-productive. Il faut en faire bon usage. Mais il ne s'agit pas ici de ratiociner les moyens de mettre en place une authentification parfaite, un équilibre fragile entre sécurité et facilité d'utilisation pour tout le monde.L'attaque Sunburst suscite encore quelques réflexions sur l'authentification MFA.La première est que dans sa variante ADFS, Sunburst bat tous les mécanismes de sécurisation authentification. La falsification des jetons SAML contourne complètement la phase même d'authentification qui devient totalement inutile. À l'inverse, l'authentification forte est réaffirmée dans son rôle de protection des consoles d'administration cloud. S'il avait été implémenté, la récupération du mot de passe administrateur à partir du réseau local n'aurait pas suffi à se connecter à Azure AD afin de modifier sa configuration. Enfin, nous pouvons dire que les mêmes techniques qui ont permis le vol de clés privées ADFS peuvent être utilisées pour vaincre l'authentification forte en volant le les secrets qui y sont liés. Nous rappelons que RSA a dû remplacer tous les jetons SecurID après le vol d'une clé racine au début des années 2010. De plus, les attaquants de Sunburst ont attaqué les secrets d'une authentification MFA. Les enquêteurs de Volexity ont déterminé que les boîtes aux lettres étaient accessibles par Outlook Web Access (OWA) alors qu'elles étaient protégées par un appareil Duo. Les attaquants avaient réussi à voler une clé du serveur OWA leur permettant de générer un cookie confirmant faussement une authentification forte inexistante lors de la connexion à la boîte aux lettres.

Les bonnes pratiques de sécurité sont essentielles

Il est trop tôt pour tirer les leçons de cette attaque de grande envergure sans précédent, alors que de nouvelles révélations continuent de tomber chaque jour. Cela montre cependant qu'un acteur motivé peut se frayer un chemin quand il en a le temps. Les organisations compromises sont reconnues pour être bien protégées. Ils ont certainement dû passer des dizaines de tests de pénétration. Mais un test de pénétration ne dure que quelques jours, alors que les acteurs derrière Sunburst ont eu de nombreux mois pour compromettre des systèmes d'information entières.Sunburst a également mis en évidence la fragilité des mécanismes d'authentification, lorsque toutes les précautions ne sont pas prises. Les développeurs, qui l'utilisent pour sécuriser des applications de type SPA, en conjonction avec OAuth 2 (mais pas toujours) .Cependant, le dernier les innovations ne sont pas toujours les plus appropriées. Dans de nombreux cas, l'utilisation d'OAuth 2 pour protéger un backend réduit le niveau de sécurité. Sunburst montre qu'il est possible (même si c'est difficile) de falsifier un JWT. Ce qui est relativement facile à faire, c'est de voler un jeton existant et de le rejouer. Il est donc important dans OAuth 2 d'appliquer correctement les recommandations de sécurité. Cependant, nous ne devons pas perdre de vue le fait que, pour des raisons de sécurité, nous barrons fréquemment une porte déjà difficile d'accès tout en laissant une fenêtre ouverte. Ainsi, dans notre exemple, un jeton d'accès dans une application SPA est relativement facilement volé, tandis qu'un cookie est bien mieux protégé. Nous aurons donc un intérêt — si le contexte le permet — de s'appuyer sur des sessions HTTP, certes anciennes et moins à la mode, mais plus sécurisées, car elles vous permettent de protéger les jetons OAuth 2 (si vous en avez besoin) sur un serveur.

Auteur : Marc (Directeur technique)