« Halte aux attaques Pass-the-Hash »- Étude des limites de Remote Credential Guard

employees-working

Microsoft a récemment lancé Remote Credential Guard afin de réduire le risque de vol d’informations d’identification sur les machines accessibles via RDP. Cette fonctionnalité permet essentiellement d’établir des connexions RDP sans laisser les informations d’identification sur les serveurs cibles. Les informations d’identification restent sur la machine source et la cible demande des tickets de service à la source au besoin.

Bien qu’il s’agisse d’une mesure de contrôle utile, un attaquant peut néanmoins résider sur une machine cible, attendre une connexion entrante et, au lieu de pirater les informations d’identification, demander simplement à la source les tickets dont il a besoin. Par conséquent, même sans informations d’identification, tant que la session est ouverte, l’adversaire peut usurper l’identité de l’utilisateur doté de privilèges (par exemple, en dérobant les tickets de service générés ou en piratant le jeton d’accès de la victime).

Ce blog examine certaines des modalités d’exécution possibles de ce vecteur d’attaque.

Remote Credential Guard

L’année dernière, Microsoft a introduit la fonction de sécurité Credential Guard dans Windows 10 Entreprise et Windows Server 2016. Credential Guard a recours à la virtualisation pour réduire le risque de vol d’informations d’identification de domaine dérivées après une compromission et limiter ainsi l’efficacité des attaques sur Kerberos, telles que « Overpass-the-Hash » et « Pass-the-Ticket ». Récemment, Microsoft a publié la mise à jour Anniversaire et, avec elle, Remote Credential Guard, fonction de sécurité qui vise à protéger les informations d’identification sur les connexions Bureau à distance (RDP) en générant les tickets de service nécessaires à partir de la machine source plutôt qu’en copiant les informations d’identification (valeurs de hachage et tickets TGT) sur la machine cible.

w

Source : https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard

Cette fonction a été conçue pour permettre aux administrateurs de se connecter en toute sécurité à des serveurs distants non fiables (« présomption de violation ») sans laisser les informations d’identification à privilèges sur ces serveurs. Elle semble remplacer le mode d’administration restreinte, fonctionnalité introduite dans Windows 8.1/2012 R2, puis rétroportée sur Windows 7/8/2008 R2/2012. Le mode d’administration restreinte visait à sécuriser les informations d’identification à privilèges en remplaçant la session RDP par une session d’administration locale pour empêcher le vol d’informations d’identification de domaine à privilèges. Le principal avantage de Remote Credential Guard par rapport au mode d’administration restreinte est que la connexion RDP est une connexion entièrement interactive (au lieu d’une connexion réseau), permettant l’accès à des services à distance à partir de la session RDP exempte d’informations d’identification.

Lorsqu’un utilisateur se connecte via une connexion RDP à une machine sur laquelle la fonction Remote Credential Guard est activée, aucun des SSP (Security Support Providers) en mémoire ne stocke le mot de passe en texte clair ou la valeur de hachage du mot de passe de l’utilisateur. Par conséquent, si un attaquant a piraté la machine cible et tente de vider les valeurs de hachage, il n’en trouve aucune à vider sur la machine.

1-hashes

Un attaquant ne peut donc plus exécuter une attaque « Pass-the-Hash » ou « Overpass-the-Hash » (alias « Pass-the-Key ») pour usurper l’identité de l’utilisateur distant. Est-ce donc la fin des attaques par vol d’informations d’identification ?

Les tickets de service sont toujours là

Notez que les tickets Kerberos restent en mémoire pour permettre d’établir des connexions interactives (et SSO) avec le serveur cible (appelé en mode Bureau à distance). Le vidage des tickets Kerberos mis en mémoire cache montre que la clé de session du ticket TGT (Ticket Granting Ticket), qui a été déléguée par la fonction Credential Guard de la machine cliente, est chiffrée, ce qui la rend inutilisable pour une attaque « Pass-the-Ticket ».

2-tickets

Cependant, étant donné que les tickets de service (Ticket Granting Service) ne sont pas chiffrés, il reste possible de les exploiter pour accéder à des services spécifiques (SPN). La portée de l’accès et les possibilités d’escalade dépendent ici des tickets de service pouvant être extraits.

Le serveur cible retire un ticket de service demandé par l’utilisateur via la machine source (appelant en mode Bureau à distance). Si la session RDP implique l’exécution de tâches administratives ou l’accès à des ressources critiques, elle mettra probablement en mémoire cache les tickets de service juteux qui pourraient être exploités à des fins d’exécution à distance et d’exfiltration de données. Par conséquent, bien que les valeurs de hachage de mot de passe et les tickets TGT soient effectivement plus exposés et donc plus vulnérables que les tickets de service, il n’en reste pas moins que ces tickets de service peuvent être eux-mêmes très utiles.

Néanmoins, les tickets de service sont limités. Et si l’attaquant n’est pas satisfait de ce qu’il a obtenu et souhaite accéder à d’autres cibles plus lucratives ? Après tout, même si le compte de la victime possède les autorisations adéquates pour une escalade, compter sur l’utilisateur pour demander les tickets de service permettant l’élévation effective peut ne pas fonctionner.

Emprunt du jeton d’accès

Bien que les informations d’identification de la victime soient isolées par Credential Guard sur la machine source, le jeton d’accès du compte de la victime reste sur le serveur piraté tant que la session RDP est active. En récupérant ce jeton d’accès, un attaquant se trouvant sur un serveur piraté peut exécuter du code dans le contexte du compte de la victime. Même si le ticket TGT de la victime est protégé, Remote Credential Guard redirigera toutes les demandes Kerberos vers la machine source et la machine source sera amenée par la ruse à octroyer des tickets de service.

3-token-elevation

Des tickets de service seront générés et des autorisations seront accordées pour le jeton du client RDP et le jeton malveillant dupliqué en fonction des privilèges du compte authentifié. Même si la fenêtre d’attaque est étroite, il est possible de demander rapidement des tickets arbitraires au nom de la victime et de les utiliser ultérieurement sur une autre machine. Par défaut, la durée de vie des tickets de service est de 10 heures, ce qui laisse suffisamment de temps à l’attaquant pour planifier le prochain mouvement.

Une question de temps ou de compétences

Le vecteur d’attaque mentionné implique deux conditions préalables : une machine avec un accès administratif et un utilisateur qui est connecté (ou qui vient de se connecter) à ce serveur piraté. La première condition peut être remplie en exploitant une vulnérabilité ou une mauvaise configuration, alors que la deuxième exige un travail d’ingénierie sociale ou un peu de chance. La première chose à faire après le piratage d’un serveur est de vérifier l’existence d’une session de terminal active ou de tickets Kerberos en mémoire cache. En l’absence d’informations d’identification et si le temps n’est pas un problème, il est possible de résider sur la machine et d’attendre des connexions entrantes ou peut-être d’en provoquer une à l’aide d’une ancienne astuce : amener un administrateur à établir une connexion RDP avec la machine en créant un problème ne pouvant être résolu qu’avec des privilèges plus élevés.

Résumé

Remote Credential Guard a été conçu pour empêcher la divulgation des informations d’identification de domaine à privilèges lors d’une connexion RDP établie avec un serveur distant, mais les informations d’identification dérivées ne se limitent pas aux valeurs de hachage NTLM et aux tickets TGT de Kerberos. Du point de vue de l’attaquant, peu importe la quantité de dérivés d’informations d’identification piratés si l’un d’eux permet d’obtenir un accès suffisant. Bien que limitant dans une certaine mesure l’exposition potentielle des informations d’identification, Remote Credential Guard ne protège pas totalement contre le risque de vol d’informations d’identification par un adversaire déterminé qui a déjà piraté la machine cible et attend juste qu’une session à privilèges morde à l’hameçon.

Recommandations

Compte tenu des limites de Remote Credential Guard, que peut-on faire d’autre pour empêcher le vol d’informations d’identification dérivées ? Voici quelques mesures à prendre et quelques règles à appliquer pour pallier certaines des lacunes de Remote Credential Guard :

  • Établir si possible des connexions à distance en utilisant une connexion réseau au lieu d’une connexion interactive.
  • Configurer et restreindre l’accès administratif par niveaux (Modèle par niveaux) ; par exemple, les comptes d’administrateur de forêt ou domaine ne sont utilisés que pour administrer Active Directory.
  • Réduire l’exposition des informations d’identification au privilège minimal requis pour la tâche en question.
  • Imposer la suppression des informations d’identification après la déconnexion.