En tant que catégorie de sécurité relativement nouvelle, de nombreux opérateurs et dirigeants de sécurité que j’ai rencontrés nous ont demandé : « Quels sont ces outils de validation automatisée de la sécurité (ASV) ? » Nous avons abordé ce sujet de manière assez approfondie dans le passé, donc aujourd’hui, au lieu de couvrir le « Qu’est-ce que l’ASV ? » Je voulais aborder le « Pourquoi ASV ? » question. Dans cet article, nous aborderons quelques cas d’utilisation courants et des idées fausses sur la façon dont les gens abusent et comprennent mal les outils ASV au quotidien (car c’est beaucoup plus amusant). Pour commencer, il n’y a pas de point de départ comme au début.
Les outils automatisés de validation de sécurité sont conçus pour fournir une évaluation continue et en temps réel des défenses de cybersécurité d’une organisation. Ces outils sont continus et utilisent l’exploitation pour valider les défenses telles que EDR, NDR et WAF. Ils sont plus approfondis que les scanners de vulnérabilités car ils utilisent des tactiques et des techniques que vous verrez dans les tests d’intrusion manuels. Les scanners de vulnérabilités ne relayeront pas les hachages ni ne combineront les vulnérabilités pour d’autres attaques, ce qui est là où les ASV brillent. Leur but est dans le nom : « valider » les défenses. Lorsque des problèmes ou des lacunes sont résolus, nous devons valider qu’ils sont réellement résolus.
Pourquoi l’ASV est-il nécessaire ?
Et cela nous amène au montrant une partie de cela, et notre professeur pour cela est Ésope, le conteur grec qui a vécu vers 600 avant JC. Il a écrit une histoire intitulée Le garçon qui criait au loup que vous avez déjà entendue, mais je la partagerai à nouveau au cas où vous auriez besoin d’un rappel :
La fable raconte l’histoire d’un jeune berger qui continue de tromper le village en lui faisant croire qu’il a vu un loup. S’il était motivé par l’attention, la peur ou une vue épouvantable ? Je ne sais pas. Le fait est qu’il agite ses mains en l’air à plusieurs reprises et crie « Loup ! » quand il n’y a pas de loup en vue. Il fait cela si souvent qu’il désensibilise les habitants à ses appels, de sorte que lorsqu’il y a vraiment un loup, la ville ne le croit pas et le berger se fait manger. C’est une histoire très réconfortante, comme la plupart des contes grecs.
L’administrateur système qui a pleuré a été corrigé
Dans la cybersécurité moderne, le faux positif équivaut à « crier au loup ». Il s’agit d’un problème courant, dans lequel les menaces sont alertées alors qu’elles n’ont aucune chance d’être exploitées. Mais repensons à cette histoire, car la seule chose pire qu’un faux positif est un faux négatif.
Imaginez, si au lieu de « crier au loup » alors qu’il n’y avait pas de loup, le garçon disait « tout est clair », sans jamais se rendre compte que le loup se cachait parmi les moutons. C’est un faux négatif, ne pas être alerté lorsqu’une menace prévaut. Une fois que le garçon a installé les pièges, il était convaincu qu’il n’y avait plus de menace, mais il n’a pas validé que les pièges fonctionnaient réellement pour bloquer le loup. Ainsi, la version redimensionnée de Crying Wolf ressemblait à ceci :
« Ah, je pensais qu’il y avait un loup qui rôdait dans les parages. Je vais m’en occuper », dit le garçon.
Le berger suit donc les instructions : il installe des pièges à loups, achète un outil de sécurité pour tuer les loups, il installe même un objet de stratégie de groupe (GPO) pour faire sortir ce loup de son champ. Puis il se rend en ville fier de son travail.
« On m’a dit qu’il y avait un loup, alors je m’en suis occupé », raconte-t-il à ses amis bergers en buvant une bière à la taverne du coin.
Pendant ce temps, la réalité est que le loup est capable d’éviter les pièges, de contourner l’outil de destruction de loups mal configuré et de définir de nouvelles politiques au niveau de l’application afin qu’il ne se soucie pas du GPO. Il capture un ensemble d’informations d’identification d’administrateur de domaine (DA) de la ville, les relaie, se déclare maire, puis soumet la ville à une attaque de ransomware. Avant qu’ils ne s’en rendent compte, la ville doit 2 Bitcoins à un loup, sinon ils perdront leurs moutons et un camion chargé de PII.
Ce que le berger a fait s’appelle un faux négatif. Il pensait qu’il n’y avait pas de loup vivant dans un faux sentiment de sécurité alors que la menace n’était jamais vraiment neutralisée. Et il est désormais tendance sur Twitter pour toutes les mauvaises raisons.
L’heure d’un scénario réel !
Les loups constituent rarement une menace pour la sécurité des informations, mais savez-vous qui le constitue ? Ce mauvais acteur avec une porte dérobée, un pied dans votre réseau, à l’écoute des informations d’identification. Tout cela est rendu possible grâce à leurs très bons amis, les anciens protocoles de résolution de noms.
Les attaques d’empoisonnement par résolution de nom sont un bug difficile à éliminer en termes de remédiation. Si votre DNS est mal configuré (ce qui est étonnamment courant) et que vous n’avez pas désactivé les bons vieux protocoles LLMNR, NetBIOS NS et mDNS utilisés dans les attaques de l’homme du milieu via GPO, des scripts de démarrage ou le vôtre sauce spéciale, alors vous pourriez avoir des ennuis. Et là où le loup aurait pu se servir d’un verre de lait, votre attaquant se servira lui-même de données sensibles.
Si un attaquant renifle les informations d’identification et que la signature SMB n’est pas activée et requis sur toutes les machines jointes à votre domaine (si vous vous demandez si c’est le cas, alors ce n’est probablement pas le cas), alors cet attaquant peut relayer le hachage. Cela permettra d’accéder à la machine jointe au domaine sans même casser le hachage capturé.
Ouais !
Maintenant, votre sympathique pentester du village découvre ce problème et dit à l’administrateur système, AKA notre berger, d’effectuer l’un des correctifs susmentionnés pour empêcher toute cette série d’attaques. Il y remédie au mieux de ses capacités. Ils installent les GPO, ils obtiennent les outils sophistiqués, ils font TOUTES les choses. Mais le loup mort a-t-il été vu ? Savons-nous que la menace a été corrigée ?
Grâce à un ensemble de cas de coin dignes d’un montage, l’attaquant peut toujours entrer, car il y aura presque toujours des cas de coin. Vous aurez un serveur Linux qui n’est pas joint au domaine, une application qui ignore le GPO et diffuse quand même ses informations d’identification. Pire encore (*frissons*), un outil de découverte d’actifs utilisant une énumération authentifiée qui fait confiance au réseau dans son ensemble et envoie les informations d’identification DA à tout le monde.
Fausses alarmes corrigées
C’est pourquoi les cyber-dieux nous ont donné l’ASV, parce que l’ASV est le bûcheron déchiré de la ville avec une agitation secondaire en tant que fantôme de loup. Il se comportera comme un loup. Il reniflera les informations d’identification, récupérera le hachage et le transmettra à la machine jointe au domaine afin que l’administrateur système puisse trouver le serveur embêtant qui n’est pas joint au domaine et n’écoute pas le GPO.
Ramenons tout cela à la maison. Il y a certaines choses qui ont du sens. Vous ne qualifieriez pas un loup de mort avant de l’avoir vu, et sans aucun doute, vous ne qualifieriez pas quelque chose de corrigé avant de l’avoir réellement validé. Alors, ne devenez pas « l’administrateur système qui a pleuré corrigé ».
Cet article a été rédigé par Joe Nay, architecte de solutions chez Pentera.
Pour en savoir plus, visitez pentera.io.