Et si vous pouviez comparer régulièrement les mots de passe contenus dans votre annuaire Active Directory avec une liste existante de mots de passe que l’on sait être compromis ? Et si, en plus, cela ne vous coutait rien à mettre en oeuvre ? Bonne nouvelle ! Après avoir lu cet article, vous saurez comment faire !
Les sources
Github est formidable en ce sens qu’il permet de partager avec tous des outils développer pour répondre à un besoin spécifique : c’est également le cas ici, où la société improsec (https://improsec.com/) a mis à la disposition de tous un ensemble de script permettant de comparer les hash des mots de passe d’un annuaire Active Directory avec une base de mots de passe réputés compromis.
Le code source, actuellement en version 3.0, est disponible à cette adresse : https://github.com/improsec/Get-bADpasswords
L’application est livrée avec un petit catalogue de mot de passe type, mais nous sommes bien loin de ce que les bases disponibles sur le darkweb proposent… Heureusement, il existe un site web bien connu qui met à disposition une base de données de plus de 613 Millions de mots de passe différent dans sa version monolithique de mai 2022 (https://haveibeenpwned.com/Passwords). Malheureusement, il n’est pas possible de l’utiliser directement avec le script d’improsec, le fichier récupéré ne contenant pas les informations dans le bon format…
Toutefois, bonne nouvelle ! Les développeurs du script ont compilés et mis à disposition la base de données de HaveIbeenPawned à l’adresse sur leur site sharepoint. Il ne nous reste plus qu’à mettre tout cela en place…
Mise en œuvre
Si la question du positionnement de l’application dans le tier 0 ne se pose pas, il reste celle de déterminer si l’on doit la positionner sur un serveur dédié dans le tier ou s’il serait préférable de la laisser sur un contrôleur de domaine. En toute honnêteté, la réponse dépendra pour beaucoup de l’appréciation du risque global et des mesures de protection déjà en place au sein de votre SI.
Dans le cadre de cet article, la solution de laisser tourner l’application sur un contrôleur de domaine a été retenue : d’une part, parce-qu’il s’agit de l’emplacement recommandé pour un SI peu sécurisé et d’autre part parce-que le script peut extraire les hash des comptes (et donc, potentiellement, de les exfiltrer). C’est aussi une solution qui évite de disposer d’un compte de service (ou d’un gMSA) pour faire tourner l’application…
Avant de commencer, récupérer les sources depuis les liens donnés plus haut. Suivez ensuite les indications ci-dessous (des indications complémentaires sont indiquées à la fin de la liste d’action) :
- Sur le contrôleur de domaine, créer le dossier c:\Scripts\Get-BadPassword
- Déposer dans le dossier le contenu du script récupéré depuis le repository Github
- Editer le fichier get-badpasswords.ps1 et modifier les lignes suivantes :
- Ligne 14 : mettre le nom pleinement qualifié de votre domaine (ex. : blog.mssec.fr)
- Ligne 15 : mettre le DistinguidhedName du votre domaine (ex. : dc=blog,dc=mssec,dc=fr)
- Ligne 36 : indiquer l’adresse de votre serveur de messagerie
- Ligne 37 : indiquer l’adresse mail du destinataure
- Ligne 38 : indiquer l’adresse mail de l’expéditeur
- Ligne 39 : indiquer le sujet du mail
- Sur le serveur, installer la dernière version de Visual C++ (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads)
- Sur le serveur, lancer PowerShell en mode administrateur puis installer le module dsinternals :
install-module -name dsinternals -scope AllUsers
- Débloquer l’exécution des scripts précédement téléchargé :
Get-ChildItem C:\Scripts\Get-BadPasswords -recurse | unblock-file
- Copier la base de mots de passe d’improsec(fichier leaked-passwords-v8.bin) dans le dossier C:\Scripts\Get-BADpasswords\Accessible\PasswordLists
Lors de la mise en place de la solution, vous pouvez rencontrer des erreurs pour l’intégration du module dsinternals : ce dernier requiert que nuget soit installé. Si vous êtes sur un serveur version 2016, faites attention à la version TLS utilisé par le système (version 1.2 requise).
Si vous avez besoin de vous authentifier pour envoyer des mails, vous devrez modifier la ligne 392 et probablement modifier légèrement le code pour ajouter la gestion de l’objet psCredential.
Si votre annuaire est en francais, vous devrez également modifier le fichier contenant les groupes d’administration :
- Ouvrir le fichier C:\Scripts\Get-BADpasswords\Accessible\AccountGroups\1 – administrative.txt
- remplacer le contenu du fichier par les données suivantes :
- Administrateurs
- DnsAdmins
- Admins du domaine
- <SID du Domaine>-519
- <SID du Domaine>-518
Les groupes Administrateurs de l’entreprise et administrateurs du schéma poseront problème si vous n’utilisez pas les SID des groupes. Vous pouvez également ajouter d’autres fichiers pour qu’ils soient pris en compte par le script et associer les membres de ces derniers comme des comptes sensibles.
Tester le script
Pour vérifier que le script fonctionne, procédez au test suivant :
- Créer un compte utilisateur de test et assignez-lui le mot de passe Passw0rd2020!
- lancer le script :
.\Get-bADpassword.ps1
- Assurez-vous de recevoir le mail à la fin de l’exécution du script.
- Assurez-vous que le script a bien reconnu le compte de test
Si le test est concluant, vous avez terminé l’installation !
Exécution automatique par tâche planifiée
Si le lancer à la main, c’est bien, le faire s’exécuter régulièrement c’est encore mieux ! Le script est parfaitement compatible avec l’exécution par une tâche planifiée sur le système hôte :
- Créer une nouvelle tâche planifiée
- La configurer pour s’exécuter avec le compte SYSTEM
- La configurer pour s’exécuter avec des privilèges élevés
- Configurer le déclencheur pour une exécution quotidienne
- Configurer l’action suivante :
- Démarrer un programme
- Programme : powershell.exe
- Arguments : -windowstyle hidden -file .\Get-bADpasswords.ps1
- Démarrer dans : C:\Scripts\Get-BADpasswords
Et voilà, le tour est joué !
Conclusion
Bien que cette solution ne soit pas le summum en terme de protection dans le choix d’un mot de passe, elle apporte déjà un contrôle sur les mots de passe existants et permet d’alerter de la présence de mots de passe exposé dans le SI avant qu’il ne soit trop tard.
Il est possible d’aller plus loin en ajoutant des solutions tierces comme Netwrix Password Policy Enforcer et Netwrix Password Reset qui permettent d’atteindre les objectifs suivants :
- Appliquer une stratégie de mot de passe sur une unité organisationnelle
- Valider que le mot de passe n’est pas compromis au changement (liste, carrousel, mots interdits,…)
- Renforcer l’expérience client (rappel des règles en place à la saisie, explication sur le refus d’un mot de passe, …)
- Portail interne de Self Password Reset
Si vous en souhaitez une démonstration, n’hésitez pas à le demander !
