Note : Cet article a été publié pour la première fois dans le numéro de juillet 2021 de la lettre d'information mensuelle Network Security, et est reproduit ici avec l'autorisation de l'éditeur.ici avec l'autorisation de l'éditeur.
Revenir 21 ans en arrière, au tournant du millénaire, serait une expérience
étrange, compte tenu du monde dans lequel nous vivons aujourd'hui. Même si l'on met de côté la pandémie de Covid-19
et ses conséquences encore inconnues, la vie a énormément changé
au cours des deux dernières décennies.
En 2000, Spotify, Facebook, Instagram et Uber n'existaient pas, tandis que Netflix (vous vous souvenez des locations de DVD et de CD par abonnement ?) et Amazon étaient tout nouveaux. L'internet était encore un peu nouveau et l'iPhone ne verrait le jour que dans sept ans. La liste est encore longue, mais ce qu'il faut retenir, c'est que le développement technologique dans le monde de l'informatique s'est accéléré de manière exponentielle au cours des 20 dernières années environ.
Malgré cette évolution, une innovation fondamentale a prévalu, largement inchangée, tout au long de cette période.
Lecture associée
Point de douleur
Dans les années 1990, les annuaires constituaient un problème informatique administratif majeur pour les entreprises. Le monde du travail s'appuyait sur une série de petits répertoires qui rendaient le partage des données et des fichiers clés délicat et laborieux. Pour accéder aux fichiers partagés, les utilisateurs devaient se connecter à chaque système de fichiers individuel, ce qui nécessitait divers identifiants, logiciels et applications.
Avec l'introduction de Windows NT au milieu des années 1990, Microsoft a déjà aidé de nombreuses entreprises à adopter le concept de "domaine", permettant à plusieurs systèmes d'être réunis dans un cercle de confiance, réduisant ainsi efficacement la segmentation des identités des utilisateurs dans des répertoires distincts. Mais si Windows NT a permis à Microsoft d'entrer avec succès dans les centres de données des entreprises, les limites inhérentes à l'évolutivité des domaines Windows NT signifiaient que plusieurs annuaires de domaines devaient être construits et gérés dans différentes zones géographiques, avec des liens de confiance entre eux pour partager l'accès pour les différents utilisateurs d'une entreprise. Cette tâche est devenue de plus en plus difficile à mesure que les entreprises, mais aussi leurs systèmes informatiques, prenaient le train de la mondialisation.
C'est là qu'intervient Microsoft Active Directory (AD), qui était à l'époque une technologie révolutionnaire, lancée à l'origine avec le système d'exploitation Windows 2000, et qui continue à soutenir une grande partie du monde du travail hyperconnecté dans lequel nous vivons à l'ère moderne.
Il s'agissait à bien des égards d'une innovation. Les entreprises mondiales pouvaient faire évoluer leurs annuaires et ne plus dépendre d'un grand nombre de domaines de petite taille et difficiles à gérer. En effet, d'autres annuaires se battaient pour offrir les mêmes avantages aux entreprises. Novell eDirectory, par exemple, était largement utilisé. Cependant, Microsoft AD s'est imposé à tous les autres pour une raison essentielle : il était ouvert.
Ouvert ou sécurisé ?
Dans le cas des services d'annuaire, "ouvert" signifie "lisible par n'importe qui", ce qui est encore aujourd'hui la valeur par défaut de toute configuration AD, du moins pour l'utilisateur authentifié, c'est-à-dire tout utilisateur connecté à un ordinateur à l'aide de son compte AD. Novell a choisi une voie plus sûre avec eDirectory, exigeant des administrateurs qu'ils accordent spécifiquement des autorisations de lecture à chaque section requise pour les utilisateurs et les applications, ce qui ajoute un obstacle opérationnel à l'adoption et à l'intégration de nouvelles applications.
Cette ouverture, qui était la plus grande force de Microsoft Active Directory il y a 21 ans, est devenue depuis sa plus grande faiblesse.
Lors de son lancement, il a été très apprécié pour sa capacité à s'intégrer facilement aux applications et à fournir une authentification unique dans un environnement professionnel complet, réduisant ainsi les tracas liés à la gestion des mots de passe et à la gestion des répertoires grâce à une authentification de grande envergure. C'est grâce à cette ouverture et à cette facilité d'intégration que l'AD reste un élément fondamental de l'infrastructure de 90 % des entreprises. En effet, il est utilisé à une telle échelle que la plupart des applications professionnelles d'aujourd'hui n'ont même pas leur propre annuaire, s'appuyant plutôt sur l'utilisateur pour être authentifié par Windows.
Cependant, cette ouverture a également créé des vulnérabilités.
Délégation sans contrainte
Prenons par exemple les fonctions spécifiques de Kerberos. Kerberos est un protocole d'authentification de réseau informatique qui fonctionne sur la base d'une structure de tickets permettant aux nœuds communiquant sur des réseaux d'entreprise de s'identifier les uns les autres de manière sécurisée. Il s'agissait d'un protocole très sûr pour l'époque, comme le souligne la signification de son nom : Dans la mythologie grecque, Kerberos est un chien à trois têtes qui garde les portes des Enfers pour empêcher les morts d'en sortir.
Kerberos offrait une capacité spéciale, la délégation, qui permettait de garantir qu'un utilisateur accédant à une application sur un système ne pourrait accéder qu'à des informations spécifiquement partagées (souvent un fichier ou des données spécifiques dans une base de données) avec cette application sur un autre système, tout en empêchant l'accès à d'autres données. D'un point de vue technique, l'application se faisait passer pour l'utilisateur pendant qu'elle accédait à l'autre service au nom de l'utilisateur. L'application - ou plutôt le serveur hébergeant l'application - était "déléguée" pour utiliser l'authentification Kerberos de quelqu'un d'autre, c'est-à-dire qu'elle avait le droit de transmettre le ticket Kerberos de l'utilisateur à un autre système, comme si l'utilisateur accédait directement à cet autre système. Avec l'introduction d'AD en 2000, il était possible de configurer la délégation Kerberos uniquement de manière "non contrainte", ce qui signifie que l'application pouvait transmettre le ticket Kerberos de l'utilisateur à n'importe quel autre système.
Aujourd'hui, cette pratique a été rendue obsolète par des méthodes de partage des données beaucoup plus sûres et transparentes. Mais les paramètres de délégation sans contrainte sont encore répandus sur un grand nombre de systèmes, souvent parce que l'impact potentiel n'est pas compris par les opérateurs d'AD ou les propriétaires de l'objet serveur spécifique choisi pour être configuré de cette manière. Les pirates d'aujourd'hui peuvent utiliser ces paramètres pour usurper l'identité de n'importe quel utilisateur AD sur n'importe quelle autre machine. Si l'on ajoute à cela le fait qu'un pirate peut utiliser n'importe quel compte AD non privilégié pour lire presque tous les attributs et objets d'AD, y compris leurs autorisations, ce qui lui permet de trouver des comptes d'ordinateur dans n'importe quel domaine d'une forêt AD configuré avec une délégation sans contrainte, on comprend pourquoi l'ouverture par défaut d'AD est devenue une vulnérabilité.
Dans le pire des cas, l'intrus pourrait accéder à un tel système et découvrir que vos contrôleurs de domaine ont toujours le service d'impression (spooler) en cours d'exécution. Le service d'impression est toujours activé par défaut sur n'importe quel serveur Windows. Ildevrait être désactivé par les administrateurs informatiques sur tout serveur qui n'en a pas besoin, mais nombreux sont ceux qui ne le font pas. Dans notre scénario, un pirate peut alors demander à un contrôleur de domaine de s'authentifier auprès de l'ordinateur bénéficiant de la délégation sans contrainte et utiliser le "bogue de l'imprimante" pour demander une authentification du contrôleur de domaine auprès de l'ordinateur capturé. Bien qu'il n'y ait rien à imprimer, grâce à ce processus, un acteur de la menace peut sécuriser le ticket Kerberos d'un contrôleur de domaine et aura ainsi compromis votre domaine et votre forêt AD.
La délégation restreinte est un peu plus sûre, mais elle reste attaquable.
Opportunité pour les acteurs de la menace
D'autres exemples montrent que le chien à trois têtes a perdu de sa force protectrice au fil du temps. De plus en plus de vecteurs d'attaque ont été découverts et documentés publiquement, ce qui a permis aux cybercriminels de les utiliser dans leur stratégie d'attaque contre AD.
Un autre bon exemple est celui des noms des principaux services (SPN), qui permettent à un client Kerberos d'identifier de manière unique une instance d'un service pour un ordinateur cible Kerberos donné (par exemple, une base de données SQL) et de localiser le compte de service correspondant (par exemple, le compte de service SQL), qui est utilisé par le service lui-même pour s'authentifier auprès d'AD.
Ce mécanisme permet aux utilisateurs d'utiliser Kerberos pour s'authentifier auprès d'une base de données SQL plutôt que d'utiliser le protocole NTLM, moins sûr, et est devenu la norme pour l'intégration de l'authentification AD dans les implémentations SQL dans la plupart des entreprises. L'inconvénient est que les chercheurs en sécurité ont découvert que les SPN eux-mêmes étaient facilement attaquables par le biais des informations qu'ils transmettent lors de l'authentification Kerberos au service - à savoir le hachage du mot de passe du compte de service lui-même - même si le demandeur ne procède pas à l'authentification au service.
Ce hachage fait désormais l'objet de tentatives de craquage hors ligne, auxquelles divers outils accessibles au public, tels que John the Ripper, se prêtent volontiers.
En raison de l'ouverture d'AD, un intrus peut facilement trouver des SPN privilégiés dans l'environnement (pensez à un SPN attaché à un compte d'administrateur de domaine), créant ainsi un autre vecteur d'attaque facile à manipuler pour obtenir des privilèges élevés et une visibilité totale. Cette combinaison de contrôle et de visibilité peut être incroyablement dangereuse. Lorsque vous disposez des autorisations les plus élevées, vous avez le contrôle total et pouvez faire tomber une entreprise et demander une rançon.
Mais vous pouvez également l'utiliser pour une reconnaissance préalable. "Quels sont les comptes privilégiés ? Quelles sont les vulnérabilités que je peux exploiter ?" Pour les acteurs de la menace, Active Directory agit comme une carte, mettant en évidence les points faibles de l'environnement. Une fois dans votre réseau, un pirate utilisera AD pour rechercher et cibler vos données importantes, les extraire, les chiffrer et vous demander une rançon. Et de nombreuses entreprises ne sont tout simplement pas préparées à une telle éventualité. Cela crée un conflit. Disposez-vous des sauvegardes adéquates pour récupérer rapidement l'ensemble de votre entreprise, y compris votre Active Directory, sans avoir à payer de rançon ?
Pour beaucoup, la réponse est non - ils sont contraints de payer la rançon et les pirates passent à une autre cible non préparée, créant ainsi un cercle vicieux.
L'exemple de SolarWinds
Quelle est donc la fréquence de l'utilisation d'AD par les acteurs de la menace ? La brèche de SolarWinds, alias Solorigate, est l'un des exemples récents les plus tristement célèbres, où AD a joué un rôle déterminant dans une attaque à grande échelle de la chaîne d'approvisionnement qui a touché des dizaines de milliers d'organisations de premier plan, y compris des organismes gouvernementaux américains. SolarWinds est elle-même un fournisseur mondial de premier plan de solutions informatiques, son outil de gestion de réseau Orion étant l'un des principaux logiciels utilisés par ces organisations pour sécuriser, maintenir et protéger leurs propres réseaux. Dans l'attaque de SolarWinds, les pirates ont réussi à injecter un cheval de Troie dans le logiciel Orion, qui s'est ensuite propagé via un mécanisme de téléchargement périodique que les clients de l'entreprise avaient installé. Lancée dès mars 2020, cette attaque parrainée par l'État et son cheval de Troie n'ont été découverts qu'en décembre de la même année.
Il s'agit d'une attaque extrêmement malveillante qui a touché d'innombrables entreprises du classement Fortune 500 et des organismes gouvernementaux d'importance vitale aux États-Unis. Mais comment une attaque aussi puissante de la chaîne d'approvisionnement a-t-elle pu se produire ? C'est là que l'AD et les fuites sur site entrent en jeu.
SolarWinds avait mis en place un service de fédération entre ses propres services d'annuaire sur site et le cloud, où il gérait le code de son logiciel Orion. Dans ce type de configuration, le nuage fait entièrement confiance au service de fédération pour prouver correctement l'identité d'un utilisateur, ce qui vous permet de vous connecter avec votre identité sur site, souvent associée à une solution d'authentification multifactorielle (MFA) d'une tierce partie.
En s'inscrivant de cette manière et en recevant un jeton de fédération correctement signé, votre fournisseur de services en nuage vous fait confiance pour l'authentification et autorisera alors les utilisateurs authentifiés en leur donnant accès aux ressources en nuage demandées.
Dans le cas de l'attaque de SolarWinds, les intrus ont pu utiliser cette fédération à leur avantage pour accéder furtivement au code source d'Orion hébergé dans le nuage en volant le certificat de signature du jeton. Il s'agit de la première attaque de ce type à utiliser un langage de balisage d'accès sécurisé doré (SAML). La fédération se fait par l'intermédiaire de protocoles tels que SAML, utilisés pour transmettre un jeton de sécurité à la partie de confiance. Mais comment l'intrus a-t-il obtenu ce certificat de signature de jeton ?
Nous revenons à l'endroit où la violation s'est produite : le certificat de signature de jeton était sécurisé par le compte de service pour les services de fédération AD, qui est hébergé comme n'importe quel autre compte dans l'AD sur site. Une fois que les acteurs de la menace ont eu accès à l'AD sur site et au compte de service ADFS, ils ont pu lire le certificat et l'utiliser pour créer leur propre jeton SAML afin d'accéder aux ressources en nuage de SolarWinds. Par conséquent, la chaîne des événements montre que la sécurité de l'Active Directory était l'une des principales faiblesses sur le chemin de l'attaque de cette violation majeure.
En effet, il s'agit d'un excellent exemple d'une entreprise qui croyait que ses systèmes en nuage étaient sécurisés alors qu'ils ne l'étaient pas, en raison d'AD et de sa dépendance à l'égard des systèmes sur site. Alors que le nuage était séparé, la confiance entre les systèmes vulnérables sur site et le nuage permettait d'accéder au réseau, créant ainsi un pont que les acteurs de la menace pouvaient utiliser pour s'introduire dans les ressources du nuage de l'entreprise.
Relever les défis
Du point de vue de la sécurité, AD est la source de nombreux maux de tête. Microsoft n'a pas investi dans une mise à jour de sécurité pour AD depuis 2016, alors que ce système d'identité central est encore utilisé par 90 % des entreprises aujourd'hui.
La solution la plus simple serait d'éradiquer AD, mais cela n'arrivera pas. Il s'agit d'une solution ancienne, mais elle n'est pas près de disparaître, car de nombreuses entreprises et des centaines de milliers d'applications métier dépendent encore de cette technologie. Cela dit, ce n'est pas une cause perdue et les entreprises peuvent prendre certaines mesures pour se protéger.
En effet, il s'agit d'un processus - la mise en œuvre de protocoles de protection adéquats - qui commence par la reconnaissance et la compréhension des vulnérabilités potentielles. Organisez une séance de brainstorming et posez-vous la question suivante : "Que se passerait-il si les systèmes critiques tombaient en panne ?".
Les entreprises peuvent faire face aux pannes en utilisant deux centres de données ou une solution hybride de centre de données et d'informatique dématérialisée, mais elles doivent aller plus loin et envisager ce qui pourrait se passer si un système critique comme la gestion des identités était compromis. Prenez le temps de comprendre les dépendances de toutes vos applications professionnelles. Et explorez les dépendances entre votre processus d'authentification et le cloud. Avec un système d'authentification basé sur la fédération, vous pourriez rapidement vous retrouver dans l'eau chaude.
Une fois que vous avez compris ces dépendances, vous pouvez commencer à identifier, à comprendre et à hiérarchiser les vulnérabilités à traiter. Il doit s'agir d'un processus holistique qui ne néglige aucune piste pour parvenir à une préparation complète. Si un bateau fuit et que vous ne disposez pas de l'équipement nécessaire pour réparer la fuite, le bateau va couler. De même, si vous ne repérez qu'un seul des nombreux trous qui fuient, le bateau coulera quand même.
Il est essentiel qu'une entreprise comprenne parfaitement toutes les vulnérabilités potentielles afin de les traiter et de s'y préparer si nécessaire. L'attaque de SolarWinds constitue une courbe d'apprentissage importante, démontrant les effets catastrophiques qui peuvent se produire lors d'une attaque basée sur AD. Compte tenu de la complexité croissante de l'environnement des menaces, il n'a jamais été aussi important qu'aujourd'hui de s'attaquer aux vulnérabilités liées à l'AD.
