L'infrastructure à clé publique (PKI) est une technologie fondamentale pour la plupart des entreprises lorsqu'il s'agit de maintenir la sécurité. Mais c'est aussi une technologie qu'il est trop facile de déployer et d'exécuter en arrière-plan sans se préoccuper des mises à jour ou des améliorations permanentes.
Comment s'assurer que le site PKI continue à répondre aux normes en vigueur ? Et quels sont les problèmes qui peuvent survenir si vous n'adoptez si vous n'adoptez pas cette approche proactive ?
C'est ce qui a motivé notre conversation avec Chris Hickman, responsable de la sécurité à Keyfactor, et Will Schroeder et Lee Christensen, architectes techniques chez SpecterOps, un fournisseur de cybersécurité axé sur l'adversaire qui aide à défendre les attaques avancées. contre les attaques avancées.
Plus récemment, Will et Lee ont mis en lumière cette préoccupation en publiant un nouveau basé sur des recherches qu'ils ont effectuées sur Microsoft Active DirectoryCe livre blanc présente un large éventail de configurations erronées courantes dans l'implémentation de Microsoft PKI , qui peuvent être exploitées. Voici quelques points saillants de notre discussion.
Quelles sont les principales conclusions du rapport ?
Lee : Ce qui nous a vraiment frappé avec les services de certificats Active Directory, c'est qu'ils sont omniprésents dans les réseaux d'entreprise. Mais il est également ancien et n'est pas très bien compris. Dans l'ensemble, il n'y a pas beaucoup de considérations de sécurité autour de lui, même s'il est utilisé partout et qu'il est essentiel à l'authentification et au fonctionnement du réseau. Cela en fait une cible de choix pour les attaquants.
Will : Ce qui est intéressant dans cette recherche, c'est qu'étant donné que les services de certificats Active Directory sont si étendus et si intégrés dans Active Directory, il n'y avait pas qu'une seule faille ou qu'un seul moyen d'escalade. Nous l'avons décomposé en plusieurs façons de voler des certificats ou d'enrôler des certificats de manière malveillante à des fins de vol d'informations d'identification et de persistance de la machine. Nous avons fini par tout codifier en vol d'informations d'identification, escalade de domaine et persistance de domaine, qui sont tous très étendus et intéressants en soi.
Lee : La question de l'escalade des domaines est également devenue très opportune ces derniers temps. À la fin du mois de juillet, on a beaucoup parlé d'un nouveau type d'attaque par relais NTLM appelée PetiPotam. nouveau type d'attaque par relais NTLM appelée PetiPotam. La vulnérabilité de base de cette attaque est le service de certification d'Active Directory, qui permet à un utilisateur non privilégié d'obtenir des droits d'administrateur de domaine sur le réseau Windows.
Un autre point important est d'examiner comment un attaquant peut obtenir ou persister dans un réseau en utilisant les services de certificats Active Directory. Un bon exemple est celui de la connexion à un réseau Windows à l'aide de votre nom d'utilisateur et de votre mot de passe. Avec les services de certification Active Directory, vous pouvez vous connecter à l'aide d'un certificat totalement indépendant de votre mot de passe. Mais de nombreux défenseurs du réseau ne sont pas au courant de cette possibilité. Dans ce cas, même s'ils effacent la machine ou réinitialisent le mot de passe d'un utilisateur compromis, si le pirate possède le certificat de cet utilisateur ou de cet ordinateur, il peut toujours se connecter en tant qu'utilisateur ou accéder à cet ordinateur. Il s'agit là d'un angle mort majeur du point de vue de la détection et de la réponse aux incidents dont les défenseurs doivent être conscients.
Quel est l'impact sur ces vulnérabilités du fait que de nombreuses organisations ne se rendent pas nécessairement compte qu'elles utilisent des certificats à de nombreux endroits différents ?
Will : Les certificats sont omniprésents et si les gens ne comprennent pas les implications en matière de sécurité, il est extrêmement facile d'inverser un bit dans un modèle de certificat et de compromettre l'ensemble du réseau. Nous avons constaté une méconnaissance générale des services de certification Active Directory.
Lee : L'autre chose à noter, c'est que les services de certification Active Directory ont été créés en 2001 et qu'ils ont évolué au fil des ans. Étant donné qu'il est présent dans les organisations depuis si longtemps, il est facile d'effectuer une mauvaise configuration ou d'activer des éléments qui peuvent entraîner une configuration non sécurisée. Il est important que les équipes effectuent des opérations de maintenance et vérifient l'état de la situation.
Quels sont les risques liés à cette méconnaissance du programme ?
Chris : Ce que nous avons constaté, c'est que les gens modifient leur configuration par nécessité. Ils trouvent un article sur la façon de procéder et cela fonctionne, mais ils ne comprennent pas pleinement les implications en aval, et ces changements apparemment mineurs ont un impact sur la confiance que vous accordez à cette infrastructure au fil du temps. Elles ouvrent une boîte de Pandore de vulnérabilités.
Will : Nous aimons bien l'expression "dette de mauvaise configuration". Ces petits changements effectués par quelqu'un qui essaie simplement de faire son travail s'accumulent au fil du temps. Nous avons beaucoup d'empathie pour les administrateurs système, car il est très facile de mal configurer accidentellement ces systèmes de manière profonde.
Chris : D'après mon expérience, il faut replacer les choses dans leur contexte. Les services de certification Active Directory sont une autorité de certification. Un site PKI est une infrastructure complète qui implique une autorité de certification et de nombreux autres éléments. C'est comme avoir un moteur, un volant et quatre pneus - cela n'en fait pas nécessairement une voiture. C'est la façon dont tous ces systèmes fonctionnent ensemble qui vous donne la confiance nécessaire pour conduire à grande vitesse.
Beaucoup de gens regardent les services de certification et disent que c'est un bon PKI comme un autre, alors qu'en fait, l'infrastructure complète n'est pas là pour en faire le bon système pour une organisation. Il ne dispose pas de toutes les fonctions de sécurité et de tous les contrôles compensatoires dont vous avez besoin pour reconnaître la dette technique que vous construisez et, plus important encore, la dette de risque qui la sous-tend.
Y a-t-il des tendances que vous observez et qui conduisent à des situations où les services de certificats Active Directory sont négligés ou mal configurés ?
Will : Nous constatons souvent qu'il n'y a pas assez de pollinisation croisée entre les équipes de sécurité et les autres équipes qui gèrent Active Directory, ce qui fait qu'il est facile de négliger ces problèmes. Ou si les organisations n'ont jamais mené d'évaluation PKI , elles peuvent ne pas savoir quels sont les problèmes.
Lee : Il est surprenant de constater que ces vulnérabilités sont le résultat d'un grand nombre de documents fournis par les fournisseurs. Plusieurs produits ont suggéré d'activer des paramètres de noms alternatifs de sujets (SAN) qui peuvent conduire à un état très peu sûr de PKI. C'est complexe, et même les vendeurs ne réalisent pas exactement ce qu'ils doivent faire.
Il est également très difficile dans les environnements Active Directory, et dans les grands réseaux en général, de comprendre les implications des changements. Que se passe-t-il si je modifie tel paramètre ou si j'ajoute un utilisateur à tel groupe ? Cela permettra-t-il à quelqu'un d'escalader ses privilèges ? Notre objectif est d'accroître cette visibilité.
Chris : Je suis d'accord pour dire que la visibilité est un élément essentiel. C'est l'une des raisons pour lesquelles la plateforme KeyfactorLa plateforme Command offre une visibilité sur les certificats déployés et sur les raisons de leur déploiement, afin de pouvoir détecter ces anomalies et d'appliquer une politique cohérente à chaque certificat émis. Vous pouvez ainsi détecter les vulnérabilités ou les mauvaises configurations avant qu'elles ne deviennent un problème.
L'autre point que j'ajouterai est que lorsque vous mettez en œuvre quelque chose de gratuit, il est difficile d'expliquer aux dirigeants qu'il y a un coût associé à la gestion de sa complexité à long terme. La plupart des organisations ne sont tout simplement pas équipées pour s'occuper de ce que devient PKI à la fin de la journée.
Si l'on considère les points sur lesquels PKI peut se tromper, y a-t-il quelque chose que vous rencontrez souvent ?
Chris : Les plus grosses erreurs sont parfois les plus faciles à commettre. Dans le cas présent, il s'agit d'appuyer sur un bouton qui permet d'insérer arbitrairement des noms alternatifs dans les certificats. Dans l'ensemble, la recherche met en évidence certains des dangers liés au fait que les services de certification Active Directory ont été configurés il y a 20 ans et qu'ils n'ont pas nécessairement évolué à la même vitesse ou avec la même réactivité en matière de sécurité que certains autres produits.
Will : Il y a eu une mauvaise configuration particulière que nous couvrons dans le rapport et que nous avons appelé l'escalade huit. Les sept premiers sont des problèmes où les gens ont dû mal configurer les choses après l'installation. La huitième escalade est un problème de stock que nous aimerions que Microsoft corrige.
Lee : Dans ce cas, il existe un rôle de serveur supplémentaire qui est souvent activé avec les services de certification Active Directory et qui vous permet de demander un certificat par HTTP.
Si cette option est activée, ce qui est souvent le cas, n'importe qui peut demander un certificat en utilisant le protocole HTTP. Le problème est que ce protocole utilise NTLM pour l'authentification par défaut. Il existe une attaque appelée relais NTLM qui permet aux attaquants d'usurper l'identité d'un utilisateur. Si Will essaie de se connecter à ma machine, je peux me faire passer pour lui, puis me connecter aux services de certification Active Directory et demander un certificat en son nom. Il existe également des outils tels que PetitPotam ou SpoolSample qui me permettent de contraindre un ordinateur arbitraire du réseau à se connecter à moi. Je peux ensuite me faire passer pour ce contrôleur de domaine en utilisant le relais NTLM et demander un certificat aux services de certification d'Active Directory à partir de ce point HTTP. Je peux obtenir ce certificat et me connecter en tant que contrôleur de domaine, ce qui me donne accès aux mots de passe des utilisateurs et à leurs hachages.
Elle peut être utilisée pour compromettre un réseau, en allant d'un privilège faible jusqu'à l'administrateur de la forêt. Il s'agit d'une vulnérabilité que nous voyons constamment dans les environnements.
Ce n'est pas seulement théorique. Vous avez réussi à trouver un compromis en utilisant cette méthodologie ?
Will : C'est exact. Les fournisseurs et les organisations hésitent parfois à déployer des efforts pour résoudre des problèmes considérés comme théoriques. Nous essayons de le faire dans le respect de l'éthique, mais nous avons constaté que les choses ne changent pas tant que les gens ne voient pas que les attaques sont réelles.
Lee : Nous avons utilisé tous les scénarios d'escalade que nous avons identifiés, et même tous les métiers que nous avons identifiés. Il s'agit de choses réelles que les malfaiteurs peuvent faire dans votre réseau. En réponse, nous avons mis au point un ensemble d'outils défensifs pour que les gens puissent commencer à s'intéresser à ce genre de choses. L'un de ces outils est PSPKIAuditqui permet d'identifier ces problèmes avec les services de certificats Active Directory.
Nous avons également un produit appelé Bloodhound qui dispose d'une version open-source et d'une version entreprise. Nous travaillons activement à l'intégration des détections de ces vulnérabilités dans ce produit également, afin que les utilisateurs puissent les repérer et les corriger dans leur environnement.
Quelles sont vos recommandations aux architectes de PKI pour remédier à ces vulnérabilités ?
Volonté : Des outils comme PSPKIAudit énumèrent les mauvaises configurations dont nous avons connaissance et vous permettent ensuite d'essayer de les corriger, mais gardez à l'esprit qu'il n'est pas possible de se contenter de "corriger cette chose-là". Vous devez comprendre quels sont les paramètres et pourquoi ils sont utilisés afin de ne pas briser les fonctionnalités existantes.
En outre, il est important d'envisager les services de certificats du point de vue de la sécurité de la réponse instantanée, c'est-à-dire que si quelqu'un compromet un compte ou un système, avez-vous un moyen d'identifier les certificats émis par cet utilisateur ? C'est un problème auquel il est très difficile de répondre pour de nombreuses organisations, car la mise en œuvre des services de certificats Active Directory ne dispose pas de fonctions de gestion vraiment efficaces.
Chris : L'autre chose à noter est qu'il est très difficile de revenir en arrière sur PKI une fois que la confiance est établie. Si vous avez des certificats avec des SAN arbitraires et qu'il n'y a aucun moyen de les trouver et de les révoquer, vous pouvez modifier les paramètres de configuration, mais cela ne remédie pas nécessairement aux problèmes. Il est difficile de remettre les chevaux dans l'étable proverbiale.
Vous souhaitez en savoir plus sur les vulnérabilités des services de certificats Active Directory et sur ce que votre organisation peut faire pour y remédier ? Cliquez ici pour regarder l'intégralité de la discussion avec Chris, Will et Lee.
