L’authentification multifacteur (MFA) est depuis longtemps devenue une pratique de sécurité standard. Avec un large consensus sur sa capacité à repousser plus de 99 % des attaques de prise de contrôle de compte, il n’est pas étonnant que les architectes de sécurité le considèrent comme un incontournable dans leurs environnements. Cependant, ce qui semble moins connu, ce sont les limites de couverture inhérentes aux solutions MFA traditionnelles. Bien que compatible avec la connexion RDP et les connexions de bureau locales, ils n’offrent aucune protection aux outils d’accès à distance en ligne de commande tels que PsExec, Remote PowerShell et autres.
En pratique, cela signifie que les postes de travail et les serveurs restent aussi vulnérables aux mouvements latéraux, à la propagation des ransomwares et aux autres menaces d’identité malgré la présence d’une solution MFA entièrement fonctionnelle. Pour l’adversaire, il suffit de prendre le chemin de la ligne de commande au lieu du RDP pour se connecter comme s’il n’y avait aucune protection installée. Dans cet article, nous allons explorer cet angle mort, comprendre sa cause profonde et ses implications, et voir les différentes options que les équipes de sécurité peuvent surmonter pour maintenir la protection de leurs environnements.
L’objectif principal de MFA : empêcher les adversaires d’accéder à vos ressources avec des informations d’identification compromises
MFA la mesure de sécurité la plus efficace à nouveau la prise de contrôle de compte. La raison pour laquelle nous avons MFA en premier lieu pour empêcher les adversaires d’accéder à nos ressources avec des informations d’identification compromises. Ainsi, même si un attaquant pouvait s’emparer de notre nom d’utilisateur et de notre mot de passe – ce qui est un scénario plus que plausible – il ne pourra toujours pas les exploiter pour un accès malveillant en notre nom. C’est donc la dernière ligne de défense ultime contre la compromission des informations d’identification, qui vise à annuler ce compromis de tout gain.
L’angle mort : MFA n’est pas pris en charge par les outils d’accès à la ligne de commande dans l’environnement Active Directory
Bien que MFA puisse couvrir entièrement l’accès aux applications SaaS et Web, il est beaucoup plus limité en ce qui concerne l’environnement géré par Active Directory. En effet, les principaux protocoles d’authentification utilisés dans cet environnement, NTLM et Kerberos, ont été écrits bien avant l’existence de MFA et ne le prennent pas en charge de manière native. Cela signifie que chaque méthode d’authentification qui implémente ces protocoles ne peut pas être protégée par MFA. Cela inclut tous les outils d’accès à distance basés sur CMD et PowerShell, dont les plus importants sont PsExec et Remote PowerShell. Ce sont les outils par défaut que l’administrateur utilise pour se connecter à distance aux machines des utilisateurs à des fins de dépannage et de maintenance, et se trouvent donc dans pratiquement tous les environnements AD.
Les implications en matière de cybersécurité : les mouvements latéraux et les attaques de ransomware ne rencontrent aucune résistance.
Ce chemin de connexion à distance grand public n’est, par définition, pas protégé contre un scénario d’informations d’identification compromises et, par conséquent, il est utilisé dans la plupart des attaques de mouvement latéral et de propagation de ransomware. Peu importe qu’il existe une solution MFA qui protège la connexion RDP et les empêche d’être abusés. Pour un attaquant, passer de la machine patient zéro à d’autres postes de travail dans l’environnement avec PsExec ou Remote PowerShell est aussi simple qu’avec RDP. C’est juste une question d’utiliser une porte au lieu de l’autre.
Êtes-vous aussi protégé que vous devriez l’être ? Il est peut-être temps pour vous de réévaluer votre MFA. En guise de suivi, explorez cet eBook pour apprendre en savoir plus sur l’approche de protection unifiée de l’identité de Silverfort en matière de MFA et découvrez comment évaluer vos protections existantes et l’exposition relative aux risques.
La dure vérité : une protection MFA partielle n’est pas une protection du tout
Ainsi, si vous avez eu la peine d’installer des agents MFA sur tous vos serveurs et postes de travail critiques, il y a de fortes chances que vous n’ayez pas réussi à les protéger des menaces d’identité. C’est l’un des cas où vous ne pouvez pas faire la moitié du chemin. C’est soit vous êtes protégé, soit vous ne l’êtes pas. Quand il y a un trou dans le fond du bateau, peu importe que tout le reste soit en bois massif. Et de la même manière, si les attaquants peuvent se déplacer latéralement dans votre environnement en fournissant des informations d’identification compromises aux outils d’accès à la ligne de commande, il n’est plus important que vous disposiez d’une protection MFA pour RDP et la connexion au bureau.
Les limitations MFA dans l’environnement sur site mettent également vos ressources cloud en danger
Malgré le passage au cloud, plus de 90 % des organisations maintiennent une infrastructure d’identité hybride avec à la fois des stations de travail et des serveurs gérés par AD, ainsi que des applications SaaS et des charges de travail cloud. Ainsi, non seulement les principales ressources sur site telles que les applications héritées et les partages de fichiers sont exposées à l’utilisation d’informations d’identification compromises en raison de l’absence de protection MFA, mais également les applications SaaS.
La pratique courante aujourd’hui consiste à synchroniser les mots de passe entre toutes ces ressources, de sorte que le même nom d’utilisateur et le même mot de passe sont utilisés pour accéder à la fois à un serveur de fichiers sur site et à une application SaaS organisationnelle. Cela signifie que toute attaque sur site qui inclut la compromission et l’utilisation des informations d’identification des utilisateurs peut facilement pivoter pour accéder aux ressources SaaS directement à partir des machines attaquées.
Le changement de paradigme : de la MFA traditionnelle à la protection unifiée de l’identité
L’écart que nous avons décrit découle de la façon dont l’authentification MFA traditionnelle est conçue et mise en œuvre. La principale limitation est que les solutions MFA d’aujourd’hui se connectent au processus d’authentification de chaque ressource individuelle, donc si le logiciel qui effectue cette authentification ne prend pas en charge la MFA – comme dans les outils d’accès à la ligne de commande AD – il ne peut y avoir de protection à blanc.
Cependant, il existe aujourd’hui une nouvelle approche qui déplace l’attention de placer MFA sur chaque ressource individuelle vers le répertoire, surmontant ainsi complètement la barrière.
Silverfort est le pionnier de la première plate-forme de protection unifiée de l’identité qui peut étendre la MFA à n’importe quelle ressource, qu’elle prenne en charge nativement la MFA ou non. Utilisant une technologie sans agent et sans proxy, Silverfort s’intègre directement à AD. Avec cette intégration, chaque fois qu’AD reçoit une demande d’accès, il attend son verdict et le transmet à Silverfort. Silverfort analyse ensuite la demande d’accès et, si nécessaire, défie l’utilisateur avec MFA. Sur la base de la réponse de l’utilisateur, Silverfort détermine s’il faut ou non faire confiance à l’utilisateur et transmet le verdict à AD qui accorde ou refuse l’accès, respectivement.
L’innovation dans cette approche est qu’il n’a plus d’importance si cette demande d’accès a été faite via RDP ou en ligne de commande et si elle prend en charge MFA ou non. Tant qu’il a été fait à AD, AD peut le passer à Silverfort. Ainsi, en passant de la protection MFA au niveau des ressources à la protection MFA au niveau du répertoire, l’angle mort dont les adversaires abusent depuis des années est enfin résolu et sécurisé.
Vous souhaitez en savoir plus sur la manière d’appliquer la MFA à toutes vos ressources ? Rendez-nous visite au https://www.silverfort.com/
