Pass The Hash : Comment se protéger

Nous avons vu dans l’article précédent les risques associés à une attaque de type Pass The Hash (qu’on raccourcira en PtH par la suite.). Pour les personnes ne voulant pas relire tout le post, un rappel en deux lignes :

Une attaque Pass The Hash permet à un attaquant de se connecter sur une machine s’il connait uniquement le hash d’un compte de cette machine (ou d’un compte autorisé).

Dans le cas (très courant) où le mot de passe admin est identique à tous les postes, il suffit à l’attaquant d’obtenir un accès sur un seul ordinateur afin d’être administrateur de tous les postes.

En partant de ce constat, il est facile d’imaginer la suite : connexion à toutes les machines pour récupérer des comptes d’administrateurs du domaine, compromission de tout l’Active Directory, installation d’un ransomware, fin de la partie¹.

Très bien. Maintenant, la problématique est claire, cela dit la question n’est pas « Le risque est-il compris ? », mais « Comment supprimer ce risque ? » C’est ce que nous allons voir ici 🙂

Microsoft à la rescousse

L’idée

Afin de palier le problème, trois solutions sont envisageables :

• modifier le protocole afin de résoudre en profondeur le Pass The Hash
• ne plus utiliser le protocole NTLM en faveur de kerberos
• modifier les mots de passe d’administrateurs locaux sur chaque poste

La première solution est problématique : elle implique un changement total du protocole NTLM, et par conséquent un risque de casser l’interopérabilité, avec toutes les problématiques que cela pourrait engendrer en entreprise.

La deuxième solution est également difficile à mettre en œuvre car nombre d’applicatifs ne supportent pas Kerberos et ne pourront donc plus d’authentifier dans l’environnement Active Directory.

La dernière solution est plus « simple ». En effet, le problème peut être vu comme suit :

• pour utiliser une attaque Pass the Hash, un attaquant doit au préalable connaitre ledit hash
• ce hash est globalement récupérable à trois endroits :
  • sur les postes d’utilisateurs, auquel cas il faut déjà avoir un accès à un poste
  • sur un contrôleur de domaine, mais cela implique que le domaine a déjà été compromis
  • grâce au piratage d’utilisateurs privilégiés connaissant et utilisant le mot de passe d’administrateur local, donc des utilisateurs à privilèges piratés préalablement (on peut imaginer le support ou les administrateurs systèmes.)

Si le poste d’un utilisateur à privilèges est compromis, il existe très probablement de nombreuses manières autres que le Pass the Hash de devenir administrateur de domaine. Le risque de PtH n’est pas là : le danger provient du piratage d’un poste utilisateur. Ici encore, deux choses à prendre en compte :

• le compte de l’utilisateur est déjà piraté, son mot de passe (ou le hash) est connu. Il est de facto à considérer comme compromis, et pourra être utilisable ailleurs. Il est déjà trop tard pour ce compte.
• le hash du compte d’administrateur local est également compromis puisque l’attaquant a un accès à la machine. C’est donc uniquement dans ce cas qu’un risque existe.

Ainsi, si chaque poste de l’entreprise possède un compte d’administrateur local différent, un attaquant pourrait continuer à utiliser le compte de l’utilisateur sur le réseau (puisque celui-ci est déjà compromis), ou élever ses privilèges locaux sur le poste en question, mais ne pourrait pas réutiliser ce compte sur d’autres postes. L’idée serait donc comme ceci :

Une tentative de Pass the Hash échouée car les mots de passe administrateur sont différents

Le problème principal est qu’il est très compliqué de mettre ceci en œuvre au sein d’une entreprise. En effet, il faudrait une base de données listant les comptes de chaque poste, base qu’il faudrait partager avec le support et les administrateurs système, le tout de manière sécurisée et impossible à récupérer pour un attaquant… Et c’est ici que Microsoft intervient 🙂

LAPS

Utiliser une base de données ? Avec une gestion propre et centralisée des comptes pouvant y accéder ? Et si… Et si on utilisait directement la base Active Directory ?! Après tout, elle possède tous les prérequis nécessaires.

C’est exactement ce que Microsoft a fait !!
Le concept est simple², il suffit :

• d’enregistrer le mot de passe de l’administrateur local d’un ordinateur dans un attribut LDAP de cet ordinateur,
• de donner les droits en lecture et/ou écriture sur ce champ aux comptes ayant les autorisations nécessaires.

Ainsi, en utilisant cette solution, un poste pourra modifier le mot de passe d’administration locale et l’enregistrer sur un contrôleur de domaine, et le support pourra avoir un accès en lecture/écriture³ au mot de passe pour effectuer des actions d’administration sur ledit poste.
On peut résumer le fonctionnement via le schéma suivant :

Accès aux attributs LDAP de différents objets

Afin de mettre en place ce fonctionnement, Microsoft a donc mis au point un outil appelé LAPS, pour Local Administrator Password Solution, qui doit s’installer sur les machines à protéger (donc toutes les machines, aussi bien les postes que les serveurs).
Une fois l’installation effectuée, les postes pourront ainsi changer automatiquement et régulièrement leurs mots de passe d’administrateurs locaux. Le support, de son coté, pourra toujours récupérer les mots de passe via une recherche sur le poste dans l’Active Directory.

Les détails pratiques

Nous allons voir dans ce chapitre comment mettre en place LAPS. Je tiens à préciser que cette partie permet simplement d’expliquer les étapes à effectuer, pas la manière précise de les mettre en place. L’installation doit être faite par un administrateur connaissant la solution LAPS ainsi que l’architecture sur laquelle l’installer.

Extension du schéma Active Directory

Dans un premier temps, il est nécessaire d’étendre le schéma Active Directory, afin d’ajouter deux nouveaux champs permettant de stocker le mot de passe administrateur local, ainsi que sa date d’expiration. Les champs sont les suivants :

• ms-Mcs-AdmPwd : champ lié à un poste, qui permettra de stocker le mot de passe de l’administrateur local du poste en question⁴.
• ms-Mcs-AdmPwdExpirationTime : champ également lié à un poste, qui sauvegardera la date d’expiration du mot de passe, afin de le renouveler périodiquement.

Champs ajoutés lors de la modification du schéma AD

Cette extension doit s’accompagner d’une vérification/modification des groupes pouvant afficher ces informations. En effet, seules les personnes autorisées doivent pouvoir y accéder : si ce champ est lisible par tout le monde, la protection perd tout son sens.

Installation coté client

Dans un second temps, il est nécessaire d’installer un client sur chaque poste qui sera protégé par LAPS. Ce client va simplement installer une dll qui permettra la communication avec l’AD afin de modifier les 2 champs précédemment expliqués. Il est bien évidemment possible de l’installer via GPO 🙂

Installation du client LAPS

Afin que les postes puissent écrire sur ces champs, une modification doit être faite au niveau de l’Active Directory. Il est nécessaire d’exécuter le cmdlet Set-AdmPwdComputerSelfPermission qui donnera les autorisations nécessaires. Comme son nom l’indique, les machines auront l’autorisation de mettre à jour ces champs pour leur poste uniquement (heureusement 🙂 )

Installation coté serveur

Dans un troisième et dernier temps, des actions sont à effectuer sur la configuration coté serveur.

Une GPO doit être installée sur le parc, pour définir quelques options, comme la complexité du mot de passe ou le nom du compte à protéger. Ceci permettra aux postes de modifier le mot de passe en fonction des paramètres définis ici.

Options pour la GPO LAPS

Il est également possible d’installer un outil spécifique permettant de faciliter la vie du support technique. Il s’agit d’une simple interface graphique, ne nécessitant aucun prérequis à l’installation, permettant de lire le mot de passe en clair, et de modifier la date d’expiration de celui-ci pour le renouveler. Ce logiciel n’est pas obligatoire car il est possible de récupérer le champ nécessaire directement en se connectant sur l’AD, mais il a le mérite d’être simple et rapide à utiliser 🙂

Interface LAPS permettant d’afficher et modifier un mot de passe

Et voilà, une fois toutes ces actions effectuées, LAPS est installé, configuré, et utilisable !

Quelques notes et conseils

En vrac, il est nécessaire de vérifier quelques points (non exhaustifs) spécifiques à chaque environnement avant de mettre en œuvre l’installation de LAPS :

• Qui doit accéder à ce champ ? Une liste de groupes et utilisateurs doit être définie en avance de phase.
• Quelle est l’architecture Active Directory et les implications sur le changement de schéma AD ? Multi domaines, multi forêts, etc. Tous ces points doivent être pris en compte.
• Comment intégrer LAPS à l’image master ? Cette problématique doit être validée durant une phase de PoC.

De plus, quelques informations peuvent être utiles, et sont listées ici :

• Le mot de passe doit être en clair. Ce n’est pas une vulnérabilité puisqu’il est lisible uniquement par les personnes habilitées. De plus, s’il était chiffré, il serait forcément inutilisable et certaines actions d’administration ne seraient pas (aussi facilement) faisables par le support.
• Il ne faut pas modifier le mot de passe directement sur l’AD : dans ce cas, le mot de passe réel et celui renseigné sur l’AD seraient désynchronisés. S’il est nécessaire de changer le mot de passe, la solution est simplement de mettre une date d’expiration dans le passé.
• Le Pass the Hash est une technique classique sur le protocole NTLM. Cependant, c’est une attaque qu’on peut retrouver dans d’autres protocoles, qui ne sont pas étudiés ici. D’autres solutions doivent être étudiées pour ces cas.
• Pour plus de détails techniques sur l’installation, Google regorge de résultats, voici au hasard quelques liens : la doc et fichiers d’install MS,  le blog Veeam, le blog thesysadmins.co.uk.
• LAPS est une bonne protection. Elle permet d’augmenter grandement le niveau de sécurité. Mais ce n’est pas non plus la panacée. Cela ne bloque pas le Pass the Hash totalement, mais uniquement dans le cas des comptes d’administration locaux. Si le hash d’un compté Active Directory (au hasard l’administrateur du domaine) est connu, il pourra être utilisé via PtH.

Conclusion

Nous avons vu dans cette série d’articles une des attaques les plus courantes dans un environnement Windows en entreprise. Se protéger de cette attaque est un énorme pas en avant, puisque beaucoup d’attaquants utilisent cette technique pour obtenir des droits élevés.
Se protéger de ce type d’attaque est de plus très simple car nécessite peu de prérequis, et ceux-ci restent simples à mettre en place. D’un point de vue défensif, il n’y a donc aucune raison de ne pas mettre LAPS en place 🙂

Attention, cela ne signifie pas pour autant que tous les risques sont supprimés, de nombreuses autres techniques permettent à un pirate de devenir Domain Admin 😀

1. Le scénario n’est pas tellement exagéré.↑
2. Il est résumé et contient quelques étapes supplémentaires, décrites plus loin.↑
3. Techniquement, seul le poste client doit modifier le mot de passe, comme on le verra plus loin.↑
4. Le mot de passe sera stocké en clair. Ceci peut sembler étrange, mais ce n’est pas un problème : les seules personnes autorisées à consulter ce champs doivent avoir un accès au poste en question.↑