DonPAPI – Pour l’attaque et la défense
TLDR
L’outil DonPAPI a été complètement réécrit de 0 pour le faire évoluer en lui ajoutant beaucoup de fonctionnalités, dont l’utilisation d’une GUI pour parcourir les résultats. Cela permet d’améliorer grandement l’expérience d’utilisation, le maintien et la capacité évolutive de l’outil. Des recommandations pour se protéger de l’outil existent en fin d’article.
Introduction
Il y a presque un an, nous avions publié une release de DonPAPI spéciale pour notre conférence à leHack (pas de replay malheureusement…). Cette publication a amené son lot de nouveauté et de bug, et nous avons souhaité continuer à faire évoluer l’outil.
Oui mais voilà, lorsque nous avons souhaité continuer à travailler sur l’évolution de l’outil, nous nous sommes heurtés à plusieurs problèmes :
- Il repose sur certaines dépendances problématiques
- Il n’est pas simple à faire évoluer
- Il est difficile de réparer un bug trouvé
- Le logger n’est pas créé de manière générique
- Le helper est difficile à aborder
En bref, il méritait « un petit coup de polish ». J’ai donc travaillé sur une réécriture complète de l’outil.
Rénovation
Pour refaire l’outil de sorte qu’il soit plus stable, j’ai identifié les points sur lesquels il fallait une évolution, à savoir :
- Le logger : Le logger dans le code n’est pas générique, ce qui fait que l’output n’est pas toujours pareil. Il nous fallait un nouveau logger propre et générique au sein du tool
- La gestion de la DPAPI : Je développe une librairie à côté qui gère la DPAPI, cela s’appelle dploot. La mise en place de cette librairie dans DonPAPI permet une gestion plus simple et stable de l’outil.
- La librairie d’affichage : Tous les cool kids utilisent rich pour l’affichage textuel de leur tool en python, c’est bien connu
- Code plus facile à évoluer : La mise en place d’un code générique, sans répétition, et optimisé permettra de plus facilement corriger des problèmes ou faire évoluer l’outil
- Dépendances problématiques : DonPAPI repose initialement beaucoup sur Lazagne, un outil de récupération des mots de passe sur un système. Oui mais voilà : LaZagne n’est pas une librairie python. Il est donc important de se passer du code de LaZagne, car l’évolution de celui-ci sera difficile à intégrer au fur et à mesure dans DonPAPI.
- Helper : Il faut revoir le helper afin de proposer une utilisation de l’outil plus intuitive
Évolution
Puisqu’il était question de refaire l’outil de zéro, autant bosser sur certaines fonctionnalités liées aux problématiques du terrain, à la facilitation d’utilisation
Toujours plus de secrets
S’il y a un sujet qui me passionne dans l’OffSec, c’est bien la collecte de secrets sur les postes. J’ai donc étendu un peu le contenu des secrets que l’on peut trouver avec la collecte SCCM et MobaXterm.
Ne pas se faire bloquer
Qu’on se le dise, DonPAPI n’est pas un outil OPSEC. Une partie de la collecte DPAPI qu’il fait, notamment pour récupérer les secrets SYSTEM, passe par la récupération de la hive LSA via Impacket. Oui mais voilà, en pentest, on se fiche un peu de se faire détecter, on ne veut juste pas se faire bloquer. J’ai donc ajouté un fichier de configuration DonPAPI qui permet de pimper un peu le comportement du Secretsdump de Impacket.
$ cat ~/.donpapi/donpapi.conf
───────┬──────────────────────────────────────
│ File: /home/tse/.donpapi/donpapi.conf
───────┼──────────────────────────────────────
1 │ [secretsdump]
2 │ share = C$
3 │ remote_filepath = \Users\Default\AppData\Local\Temp
4 │ filename_regex = \d{4}-\d{4}-\d{4}-[0-9]{4}
5 │ file_extension = .log
───────┴─────────────────────────
Collecte automatique de la Domain Backup Key
Si vous connaissez un peu le sujet de la DPAPI, vous savez qu’en récupérant la Domain Backup Key, cette clé unique dans le domaine, vous pouvez déchiffrer les secrets de tous les utilisateurs du domaine. J’ai rajouté une option –fetch-pvk qui va permettre d’aller chercher toute seule la Domain Backup Key.
Ciblage automatique
Pour être sûr de cibler la collecte sur toutes les machines du domaine, DonPAPI supporte maintenant un -t ALL, qui va aller chercher dans l’annuaire LDAP la liste de toutes les machines dans le domaine Active Directory, pour s’en servir comme cible. Comme ça on est sûr de n’oublier personne.
Collecte en continu
Dans certaines situations, on veut collecter en continu certaines machines, surtout lorsqu’on surveille les cookies dans les navigateurs. J’ai créé un mode –keep-collecting qui va relancer la collecte automatiquement après X secondes, X étant la valeur du paramètre.
Barre de chargement
Vu que DonPAPI est passé sur rich, il est possible de rajouter facilement une barre de progrès, qui permettra de suivre plus facilement l’avancement du scan.
Fichier de Recover
On a tous déjà vécu cette situation, où on se retrouve à devoir Ctrl+C un scan DonPAPI (ou autre d’ailleurs) alors que ça fait déjà 20 minutes que ça tourne. Pour pallier ce problème, DonPAPI supporte maintenant l’utilisation d’un fichier recover, qui permet de reprendre un scan là où il en était. Globalement, à chaque lancement de l’outil, un fichier recover est créé. Il suffira de spécifier le fichier recover (sans besoin de respécifier tous les paramètres) pour reprendre le scan associé.
Gestion des résultats
DonPAPI permettait anciennement de générer un rapport html tout beau pour permettre de naviguer dans les résultats. On a poussé le vice un peu plus loin.
Certains connaitront sans doute l’outil Roadrecon, qui dispose d’une GUI sous forme d’un serveur Flask avec une SPA Angular. Cette manipulation permet plusieurs avantages :
- Pas de crash du navigateur en cas de trop de données
- Possibilité d’avoir une visualisation en temps réel des données collectées
- Plus intuitif
- Permets d’avoir un rendu dynamique
- Plus simple à maintenir et à faire évoluer
On s’est donc inspiré de cette superbe idée pour faire la GUI DonPAPI. Cette fonctionnalité consiste donc en un serveur Flask avec une SPA VueJS. Mais on ne s’est pas arrêté là, on a ajouté quelques fonctionnalités bien sympathiques dans la GUI :
- Recherches : La recherche a été intégrée dans la GUI. Cela permet de chercher spécifiquement certains secrets, ou ce qui vient d’une certaine machine, ou un certain utilisateur au sein de l’AD.
- Export CSV : Il est maintenant possible de faire un export CSV des données de DonPAPI, afin de les partager
- Exposition de la GUI : Par défaut, la GUI est accessible en localhost. Mais avec certains paramètres, il est possible d’exposer la GUI sur le réseau local. C’est très pratique pour le partage des résultats avec un collègue en test d’intrusion. Bon vu qu’on veut montrer l’exemple, il est évidemment possible de paramétrer la GUI pour l’exposer sur HTTPS et avec une Basic Auth
- Cacher les mots de passe : Une fonctionnalité permet de cacher les mots de passe, ce qui facilite la vie quand on veut faire des captures d’écran pour un rapport
- Copy Paste : Cliquer sur une valeur dans un tableau de secrets permet de la mettre directement dans son clipboard. Warning, c’est très addictif.
Il est bien sûr toujours possible de copier plusieurs cookies pour les injecter dans un navigateur, ou de copier la commande Certipy pour utiliser un certificat collecté
Voilà, c’est à peu près tout pour cette grosse mise à jour de DonPAPI.
Comment on l’utilise maintenant ?
Bon c’est vrai, comme on l’a dit, le helper a changé. Voici donc un nouveau petit tutoriel d’utilisation :
Phase 1 : La Collecte
Pour commencer, on va utiliser un compte qui peut se connecter sur une ou plusieurs machines afin de récupérer des mots de passe. Il faut donc utiliser l’action « collect » et renseigner les paramètres
donpapi collect -u user -p password -d domain -t 192.168.0.1
Imaginons qu’on ait un compte Administrateur du domaine, qu’on veuille cibler toutes les machines du domaine et aller chercher automatiquement la Domain Backup Key, alors on fera :
donpapi collect -u user -p password -d domaine -t ALL --fetch-pvk --dc-ip 192.168.0.1
Phase 2 : L’exploitation des résultats
Bon là, rien de bien compliqué, on utilise l’action « gui » pour lancer le serveur Flask
donpapi gui
Et la magie :
Remédiations
Le but de l’amélioration de ce genre d’outil, c’est avant tout de mieux accompagner nos clients dans l’amélioration de leur niveau de sécurité. L’outil abuse certains mauvais comportements d’administration, et a donc pour but de les mettre en avant pour mieux les éliminer. Voici ce qu’on recommande pour se protéger de DonPAPI.
Réutilisation de mot de passe administrateur local
Lorsque le même mot de passe administrateur local est utilisé sur plusieurs machines, la compromission de l’une d’entre elles permet celle de l’ensemble de ces machines. En effet, l’attaquant est en mesure de tenter de réutiliser le mot de passe ou son condensat (hash) sur toutes les machines accessibles via le réseau.
La manière la plus simple pour remédier à cette vulnérabilité est de déployer LAPS (Local Administrator Password Solution) sur les serveurs et postes de travail. Il s’agit d’une fonctionnalité implémentée par Microsoft pour ses systèmes d’exploitions, permettant de laisser Active Directory gérer le mot de passe du compte Administrateur local des machines.
Lorsque LAPS est déployé, le mot de passe administrateur local des machines est
- Unique pour chaque machine
- Généré de façon aléatoire
- Renouvelé périodiquement de manière totalement automatique
- Inscrit dans un champ LDAP avec accès restreint
Les droits d’accès aux champs contenant ces mots de passe sont ensuite ajoutés aux administrateurs nécessitant ces permissions.
Une fois en place, la compromission d’une machine ne permet plus un déplacement latéral de l’attaquant par le vecteur de la réutilisation du mot de passe.
Utilisation de mots de passe dans les navigateurs
De manière générale, la bonne pratique veut qu’aucun mot de passe ne soit enregistré dans aucune application. En effet, si c’est le cas, le mot de passe est stocké sur la machine. La compromission de celle-ci permet la récupération de ces secrets (mots de passe, condensat, …).
Il est possible d’interdire l’enregistrement des mots de passe dans les navigateurs par GPO mais il est compliqué de couvrir toutes les versions.
Pour ce faire, une règle de GPO doit être créée par navigateur, certaines ne seront disponibles que si de nouveaux ADMX ont été ajoutés aux contrôleurs de domaine.
Il est impossible d’empêcher complètement les utilisateurs d’enregistrer des mots de passe dans des applications ou navigateurs (l’utilisateur peut par exemple utiliser une version portable de Firefox ou d’un navigateur moins connu qui ne sera pas prise en charge par les GPO).
Il est nécessaire de sensibiliser les utilisateurs à ces bonnes pratiques. Login Sécurité organise par exemple des sessions de sensibilisation, permettant de montrer concrètement aux utilisateurs avec quelle simplicité un attaquant est capable de récupérer leur mot de passe. Cela provoque souvent un effet d’électrochoc chez les collaborateurs, les impliquant un peu plus dans les bonnes pratiques de sécurité accessible à leur niveau.
Utilisation de comptes d’utilisateurs du domaine pour lancer des services et tâches planifiées
Toujours dans l’optique de limiter la propagation d’un attaquant, il est plus que fortement conseillé de ne pas utiliser de compte d’utilisateur du domaine (entendre : de comptes utilisés par des collaborateurs) ni de compte administrateur de domaine pour exécuter des services et tâches planifiées.
En effet, il est également possible pour un attaquant ayant compromis une machine de retrouver les mots de passe de ces comptes puisqu’ils sont également stockés sur ladite machine.
Des comptes gMSA peuvent être utilisés pour les remplacer. Comme pour LAPS, il s’agit de comptes gérés par Active Directory, possédant des mots de passe générés aléatoirement et renouvelés automatiquement de façon régulière.
Les permissions qui leur sont appliquées doivent respecter le principe de moindre privilège : ils ne doivent posséder que les droits qui leur sont strictement nécessaires pour effectuer la tâche pour laquelle ils sont créés.
Si l’utilisation de gMSA n’est pas possible, des comptes spécialement créés pour chaque service/tâche peuvent être utilisés. Ils devraient respecter des exigences de complexité de mot de passe, et également le principe de moindres privilèges.
Enfin, dans la grande majorité des cas, des comptes locaux peuvent être utilisés. En effet, si aucune ressource réseau n’est nécessaire au fonctionnement du service ou de la tâche, il est souvent possible d’utiliser un simple compte local. Si des privilèges sont nécessaires sur le serveur, le compte Système local est un bon compromis à la création d’un nouvel utilisateur sur la machine. Ceci empêchera également la propagation d’un attaquant en cas de compromission de la machine.
Segmentation des droits – principe de moindre privilège
De façon plus générale, il convient de mettre en place une véritable segmentation des comptes utilisateurs selon le principe de moindre privilège.
En effet, un collaborateur administrateur de domaine devrait posséder un compte différent par niveau de privilège : un compte pour l’administration du domaine, un autre sans privilège pour la connexion à son poste de travail, pour effectuer les tâches ne nécessitant pas de privilèges (mails, navigation internet, accès aux partages réseaux, …).
Dans l’idéal, le découpage devrait même être le suivant :
- Un compte administrateur de domaine
- Un compte administrateur des serveurs
- Un compte administrateurs des postes de travail
- Un compte sans privilèges pour se connecter à sa machine (non-administrateur de son poste)
Tous ces comptes devraient être nominatifs et facilement repérables. Ce découpage permettra, par la suite d’évoluer vers un modèle en tiers plus facilement si c’est l’objectif de l’entreprise.
La segmentation à deux comptes (administrateur et compte sans privilège pour la connexion au poste de travail) est relativement simple à mettre en place et ajoute déjà un premier niveau de sécurité. En effet, elle permet de diminuer les risques de propagation d’un attaquant si une hygiène de sécurité de base est respectée par les administrateurs (pas de réutilisation de mot de passe, utilisation d’un gestionnaire de mot de passe, pas de mots de passe en clair sur la machine, utilisation d’une bonne politique de mots de passe, pas de mots de passe enregistrés dans les navigateurs et applications …).
Plus largement, le principe de moindre privilège est une règle qui devrait être appliquée dans tous les aspects du système d’information : des permissions totales ne devraient par exemple jamais être appliquées pour un utilisateur à un partage réseau, il devrait uniquement obtenir les accès strictement nécessaires à son utilisation.
Le pôle remédiation Login Sécurité
Pour toutes ces tâches, Login Sécurité est en mesure d’aider les entreprises. En effet, une équipe dédiée à la mise en place de remédiations et à la montée en sécurité du système d’informations est présente au sein des effectifs de Login Sécurité.
Nos collaborateurs se déplacent dans les entreprises pour travailler avec les acteurs du maintien du système d’information (admins, DSI, …) à la correction et à l’amélioration de la sécurité de l’infrastructure.
Le but étant d’effectuer les actions en étroite collaboration avec les administrateurs pour transmettre nos connaissances et assurer le suivi et le maintien de la sécurité même après la prestation. L’implication des équipes d’administration est nécessaire puisque c’est eux qui assureront ce suivi.
Chaque système d’information étant différent, nous adaptons notre vision de la sécurité aux méthodes d’administrations de nos clients. Un vrai dialogue est donc mis en place dès le début de la prestation.
