e-Xpert Solutions Lausanne
Auteur : Michael Molho
Date de publication : 9 septembre 2019 - Dernière mise à jour : 10 septembre 2019
De part sa grande popularité, voire même son monopole au sein des entreprises de toute taille et dans le monde entier, l’écosystème Microsoft fait l’objet d’une attention particulière de la part de la communauté des chercheurs en sécurité. En effet, les OS Windows ainsi que le monde « Active Directory » au sens large sont probablement les cibles les plus intéressantes et les plus visées aujourd’hui.
Pour s’en convaincre, il suffit de lire les derniers bulletins de patch Windows - « Patch Tuesday » :
Cela semble être un cercle sans fin entre la communauté immense des chercheurs d’un côté, et les ressources importantes de Microsoft (tout de même limitées) pour analyser, tester, corriger et distribuer les patchs.
Au milieu de ce raz-de-marée de nouvelles vulnérabilités, il est intéressant de se poser la question de la nature de ces vulnérabilités. Quelles sont celles qui sont les plus souvent exploitées dans la pratique ? Est-ce qu’au fond, les techniques d’attaques évoluent au fur et à mesure que Microsoft durcit sa sécurité, ou bien les anciennes méthodes restent les meilleures ?
Au sein de notre Team at-Defense, le SOC d’e-Xpert Solutions, nous côtoyons quotidiennement des tentatives d’attaques humaines, de Malwares, et d'APT que aussi bien celles de pentesters. Nous faisons également de la veille en sécurité afin de rester au fait des dernières recherches. Voici ce que nous pouvons observer, à notre niveau, concernant les attaques actuelles sur Microsoft et Active Directory.
L’attaque de type « Pass the Hash » est un grand classique qui date des années 2000. Probablement une des méthodes les plus utilisée pour faire du déplacement latéral sur un réseau Windows. Cette attaque utilise le fait que dans le monde Windows, « il n’est pas nécessaire d’avoir le mot de passe d’un utilisateur pour s’authentifier en tant que cet utilisateur, le hash du mot de passe suffit ». L’intérêt du hash, à la différence du mot de passe, est qu’il est stocké à différents endroits, et peut donc être dérobé sous réserve d’avoir les bons privilèges.
En effet, les hash des utilisateurs locaux sont stockés dans la « base SAM » locale des machines et les hash des utilisateurs de domaines connectés sur une machine sont stockées dans la mémoire du processus LSASS. Un attaquant obtenant les privilèges d’admin local d’une machine peut donc dérober ces hash et s’authentifier sur d’autres machines ou services en subtilisant l’identité et les permissions associées à ces utilisateurs.
Historiquement, il était possible, via un outil de type « Mimikatz », d’extraire les mots de passe en clair des utilisateurs connectés. Face à cela, Microsoft a développé le système « Credentials Guard » publié en Avril 2018 et activé par défaut à partir de Windows 8.1/Server 2012R2. Ce système permet une isolation complète du processus LSASS, et rend donc impossible (à ce jour …) l’extraction des mots de passe en clair.
Cependant, les attaques de type « pass the hash » ou « pass the ticket » sont aujourd’hui toujours fonctionnelles et activement utilisées.
L’attaque « NTLM Relay », à la différence du « Pass the Hash », ne nécessite d’aucun compte ni d’accès en particulier. Pour cette attaque, l’attaquant doit se positionner en « Man In the Middle » entre une victime et un serveur auquel la victime va se connecter. Pour obtenir cette position, la méthode classique est d’effectuer du spoofing LLMNR, protocole équivalent du DNS sur un LAN Microsoft. L’outil généralement utilisé pour effectuer ce type d’attaques est « theResponder ».
Une fois en position de "Man In the Middle", l’attaquant n’a plus qu’à relayer les messages d’authentification entre la victime et le serveur, comme le décrit le schéma ci-dessous :
La victime (à gauche) tout comme le serveur (à droite) ne savent pas qu’un attaquant est au milieu de leurs échanges. A la fin du processus (« Authentication OK »), l’attaquant est authentifié sur le serveur avec le compte de la victime.
Si la victime possède des droits élevés sur le serveur ou sur le domaine, l’attaquant hérite donc de ces privilèges. L’avantage de cette technique est qu’elle ne requière d'aucun compte à la base. Elle nécessite uniquement une présence physique ou logique dans le LAN.
Microsoft a atténué l’impact de cette attaque via deux correctifs :
- Le premier empêche de faire du NTLM relay dit « reflectif ». Dans ce cas, le serveur et la victime sont la même machine. Historiquement, il était possible de relayer l’authentification d’une machine sur elle-même. Ce n’est plus possible.
- Et ensuite, les contrôleurs de domaine ont maintenant la signature SMB activée par défaut, ce qui rend impossible le NTLM relay sur SMB vers des contrôleurs de domaines. Cependant, d’autres protocoles, tels que le HTTP, ne supportent pas la signature NTLM. Il est donc toujours possible de faire du NTLM relaying vers des domaines contrôleurs sur HTTP.
Malgré ces correctifs, les possibilités d’exploitation restent encore large et cette attaque est encore activement utilisée. Un grand classique étant d’utiliser « theResponder » pour la partie LLMNR spoofing et NTLM Relay. Ce qui permet de compromettre une ou plusieurs machines rapidement et simplement. Il est ensuite possible d’enchaîner avec du « Pass the Hash » depuis ces machines afin de compromettre plus largement le domaine. Ce combo, bien que légèrement plus limité par les derniers correctifs et durcissement de Microsoft, est toujours fonctionnel et utilisé de nos jours.
Bien que les anciennes techniques fonctionnent encore souvent, il devient de plus en plus difficile pour un attaquant d’obtenir rapidement des privilèges élevés au sein d’un domaine Active Directory.
Et heureusement 😊!
Credential Guard a notamment mis un grand coup de massue, en rendant impossible, même pour un Admin local, d’extraire les mots de passe en clair. Pendant longtemps, la recherche de vulnérabilités backend sur Microsoft s’est concentrée sur le périmètre SMB, DCE RPC, DCOM, SAMR interface etc … Pour simplifier : tout ce qui est derrière le port 445 ainsi que toute la partie authentification/SSO avec WinLogon/LSASS etc ... Naturellement, Microsoft a concentré ses efforts sur le durcissement de ces services, avec notamment la sortie de Credentials Guard.
Or aujourd’hui, on constate un élargissement du scope des recherches, avec notamment de plus en plus d’intérêt sur Kerberos. Benjamin Delpi (auteur de Mimikatz), que l’on peut pratiquement appeler "le père de la recherche en sécurité sur Windows", a d’ailleurs démarré un projet similaire à Mimikatz mais dédié à Kerberos : « Kekeo ».
Projet qui a été repris pour créer « Rubeus » ; un projet complet dédié aux attaques sur Kerberos !
Historiquement, Kerberos était un protocole complexe dans le contexte Microsoft, assez mal connu des chercheurs et des attaquants. Avec le développement de ces nouveaux projets, Kerberos se démocratise et des axes d’exploitation voient le jour. De plus, les besoins de Single-Sign-On en entreprise sont aujourd’hui courant et il devient habituel de trouver des implémentations de projets ou produits utilisant activement Kerberos dans ce but.
Au même titre que les hash NTLM, un ticket Kerberos peut être utilisé pour s’authentifier avec l’identité d’un utilisateur. Et au même titre que les hash, les tickets Kerberos peuvent être dérobés, sous réserve d’avoir les bonnes permissions. Et pour le coup, Credential Guards ne protège pas contre le vol de tickets Kerberos depuis des processus lancés par des utilisateurs lambda. Il protège uniquement le processus LSASS. Passer sur Kerberos est donc un bon moyen de faire un pied de nez à Credentials Guard, censé être la parade ultime contre le vol et la réutilisation de credentials.
L’attaque la plus simple et probablement une des plus anciennes sur Kerberos est le « Kerberoasting ». Le principe repose sur le fait que « n’importe quel utilisateur du domaine peut obtenir un ticket Kerberos (TGS) pour n’importe quel service Kerberos, indépendamment de ses droits d’accès au service ». Le ticket obtenu sera chiffré avec le mot de passe (ou plutôt le hash du mot de passe 😊) du compte associé au SPN du service Kerberos. N’importe quel utilisateur, quelque soit ses permissions, peut donc essayer de brute-forcer le mot de passe de ce compte, et ce, en offline, sans aucune interaction avec le domaine, sans aucun risque de bloquer le compte. Si le mot de passe de ce compte est faible, le brute-force sera un succès et l’attaquant pourra alors usurper l’identité de n’importe quel utilisateur de ce service en forgeant des tickets Kerberos valides. Si le service visé est l’ADFS ou un IDP SAML par exemple, les conséquences peuvent être très graves. Il est donc important de s’assurer que tous les comptes de services utilisés avec des SPN Kerberos ont des mots de passe forts.
Plus récemment (début 2019), une attaque puissante combinant à la fois le NTLM Relay et la délégation Kerberos sous contrainte a été publiée.
Cette technique permet à un attaquant présent physiquement sur le réseau, sans aucun accès particulier ni compte sur le domaine, d’obtenir rapidement des privilèges Admin local de n’importe quelle machine utilisateur du domaine. Cette attaque, relativement complexe dans son principe mais simple à mettre à œuvre grâce aux outils tels que Kekeo et Rubeus, montre bien l’intérêt certain de la communauté des chercheurs vers Kerberos et les mécanismes tels que le SSO et la délégation.
A la dernière conférence BlueHat à Tel Aviv, Benjamin Delpi a de plus présenté des attaques innovantes sur des protocoles peu connus tels que TSSP, le PKInitMustiness ainsi que sur Kerberos. Il a ainsi démontré la criticité et les faiblesses d’autres composants de l’environnements Microsoft, en dehors de SMB et du célèbre processus LSASS.
Avec le développement actuel des environnements cloud Azure et Azure AD, la surface d’exploitation augmente considérablement. La où il fallait que l’attaquant obtienne d’abord un premier accès physique ou logique au réseau pour pouvoir attaquer l'Active Directory, l’AD est maintenant publiquement exposé et accessible sur Internet.
Cependant, les technologies ne sont pas les mêmes dans Azure AD que dans un domaine Microsoft local. En effet, les pass the hash, NTLM relay ou même Kerberos ne fonctionnent pas dans le monde Azure. Azure repose entièrement sur un modèle d’autorisation OAuth 2.0. De la même manière que pour un hash NTLM ou un ticket Kerberos en local, usurper un token OAuth 2.0 revient à pouvoir s’authentifier sur Azure avec l’identité d’un utilisateur.
Tout naturellement, des nouvelles techniques d’attaques vers Azure AD se développent et plus particulièrement vers OAuth 2.0.
Une des techniques très efficace à ce jour est basée sur une variante de phishing particulièrement redoutable. De la même manière que pour Kerberos, des outils de plus en plus aboutis et simples à utiliser voient le jour.
Même si le scénario exact varie, la technique principale repose très souvent sur le fait d’induire un utilisateur à autoriser une application tierce (malveillante) à accéder à ses données personnelles Azure. Si le scénario est bien fait, il est très difficile pour l’utilisateur de savoir qu’il s’agit d’un piège. L’utilisateur peut par exemple recevoir un email semblant provenir de Microsoft l’invitant à valider le nouveau service de « Account Verification » via un lien du type :
Ce lien est un vrai lien pointant vers le site légitime Microsoft. Aucune raison donc de se méfier … En suivant le lien, l’utilisateur voit alors les écrans suivants :
Tous ces écrans proviennent du site réel de Microsoft « login.microsoftonline.com ». Ils semblent donc légitimes. Seulement, à la seconde où l’utilisateur clique sur « Accept », l’attaquant peut alors obtenir un token OAuth 2.0 au nom de la victime et ainsi usurper ses privilèges au sein de l’Azure AD et de l’écosystème Azure, et ce, sans aucune nouvelle interaction de la part de l’utilisateur et sans moyen simple pour l’utilisateur de bloquer la suite de l’attaque.
En effet, même si l’utilisateur change son mot de passe par la suite, le token OAuth 2.0 reste valide pendant sa durée de vie et peut continuer à être utilisé par l’attaquant.
Dans le même principe que pour les hash NTLM ou les tokens Kerberos, il existe également certaines situations ou les tokens OAuth 2.0 sont stockés sur les postes utilisateur. Là encore, aujourd’hui Credential Guards ne protège pas ces données. Elles peuvent donc être dérobées par un attaquant ayant obtenu des privilèges d’admin local.
Même si les attaques "historiques" de type "Pass the Hash", "Pass the Ticket", "NTLM Relay" etc ... ont encore quelques beaux jours devant eux, Credentials Guard a et va continuer à limiter les possibilités d’extraction et de relaying des credentials au sens large. De plus, les équipes Microsoft se montrent efficaces dans le développement et le déploiement de très nombreux patchs de sécurité ciblés sur des failles spécifiques.
Cependant, on observe une ouverture des méthodes d'exploitation au sein de la communauté des chercheurs mais aussi des attaquants. En effet, face aux moyens de hardening mis en place par Microsoft, ceux ci se dirigent maintenant vers d'autres horizons, en explorant par exemple les mécanismes sur Kerberos, IPv6, le TSSP ou encore le PKInitMustiness. De plus, l'explosion actuelle d'Azure AD ouvre encore plus le champ des possibilités, avec un Active Directory accessible depuis Internet et utilisant d'autres méthodes d'authentification et de SSO.
Au sein de l'équipe SOC eXpert Solutions, nous sommes toujours à l'écoute de ces nouveautés et veillons à aligner en permanence nos capacités de détection et de réponse sur les techniques d'attaques les plus récentes.
Events
Archives