Don PAPI, ou l’art d’aller plus loin que le Domain Admin

Quand on fait un TI interne, on a souvent l’habitude de dire « De toute façon, lundi midi, j’suis Domain Admin » (On a de l’humour dans la sécu hein ! ^^’).
Evidemment, c’est une blague, même si à 12:01 on sent des fois une goutte de sueur couler sur la tempe.

Mais une fois qu’on est DA, on fait quoi ? Parce que c’est bien gentil d’avoir les clés du royaume, mais c’est tout sauf suffisant ! Après tout, le but d’un TI, ce n’est pas juste de faire responder into user credz into local admin into RCE into DA, c’est de trouver les différentes surfaces d’attaque possibles, qui permettent d’accéder aux données réellement importantes¹.
Et une des surfaces d’attaques sous exploitées (jusqu’à maintenant), c’est DPAPI !

SéKwaSa

DPAPI pour les nuls

Pour ceux qui ont déjà entendu parler de DPAPI : calmons nous, on ne va pas rentrer trop dans les internals DPAPI.
Pour ceux qui n’en ont jamais entendu parler : ça va bien se passer, ne vous inquiêtez pas !

Alors, DPAPI, c’est quoi ? C’est une technologie barbare de Microsoft, qui signifie Data Protection Application Programming Interface. En gros, c’est une API qui permet de simplifier la gestion des secrets sur windows.
Pour faire très simple, admettons que je m’appelle Chrome et que je propose d’enregistrer le mot de passe d’un site dans mon coffre fort.
Plutôt que d’utiliser moi même un chiffrement custom -avec les risques que cela implique- je vais utiliser CryptProtectData(), une fonction DPAPI, donc proposée par défaut dans Windows, qui permet de chiffrer de manière forte, réversible, et « sécurisée » le mot de passe du site web, le tout de manière totalement transparente pour l’utilisateur.
A l’inverse, quand l’utilisateur voudra lire son mot de passe, je pourrais simplement utiliser la fonction CryptUnprotectdData() pour le déchiffrer et lui donner.

Quelques détails techniques

Lors de l’appel à la fonction CryptProtectData(), Windows va créer un fichier chiffré, qu’on appelle un « blob DPAPI ».
Le chiffrement induit par cette fonction nécessite une clé secrète pour être fonctionnel. Et quelle est la clé la plus secrète qu’on puisse trouver sur un ordinateur ? Le mot de passe de l’utilisateur, et pour être plus précis, un dérivé de ce mot de passe.
Ainsi, lorsque cette fonction est utilisée, Windows va lire le blob DPAPI (chiffré donc) et la clé dérivée pour effectuer le déchiffrement de cette manière.

Déchiffrement via DPAPI

Ainsi, tout est parfait dans le meilleur des mondes. La donnée est chiffrée de manière sécurisée, l’utilisateur peut la récupérer quand il en a besoin, tout va bien, fin de l’histoire.

La problématique en pratique

Evidemment, ce n’est pas réellement la fin de l’histoire, sinon, on en aurait pas fait un article 🙂
En fait, on se heurte ici à un problème basique en cryptographie : la clé de chiffrement. Pour pouvoir chiffrer et déchiffrer, il y a 2 options : soit l’utilisateur rentre son mot de passe à chaque appel à DPAPI, soit il est stocké quelque part. Et ça tombe bien, le mot de passe de l’utilisateur est par définition stocké dans l’OS, donc autant en profiter.
Le problème, c’est que cela implique qu’un attaquant pourra tout aussi bien récupérer le mot de passe pour déchiffrer les blobs lui même.

A cela, il faut ajouter un point important : un environnement Windows en entreprise doit permettre au support IT de changer le mot de passe des utilisateurs. Le problème est ici simple : la clé est un dérivé du mot de passe.
Si l’utilisateur change lui même son mot de passe, Windows est assez intelligent pour modifier automatiquement le dérivé puisque l’utilisateur connait le mot de passe d’origine et tout va bien.
Mais si c’est le support IT qui change le mot de passe, celui ci ne le connait pas, par définition. Windows ne saura donc pas retrouver retrouver ses petits et tous les secrets seront perdus.
Microsoft a donc mis au point un principe de Domain Key globale à l’entreprise qui permet également de lire des blobs DPAPI. Pour faire simple, la clé de chiffrement DPAPI peut être créée soit par le mot de passe de l’utilisateur, soit par la Domain Key.

Chiffrement DPAPI avec la Domain Key

Bref, on se retrouve donc avec des secrets déchiffrables par 2 clés différentes, ce qui fait quand même trop !

Et maintenant ?

A quoi ça nous sert tout ça?

Revenons à notre postulat de base : lors d’un pentest, on est rapidement Domain Admin. Et qui dit Domain Admin dit possibilité de récupérer la Domain Key pour déchiffrer TOUS les blobs DPAPI de TOUS les utilisateurs de TOUT le parc.
C’est donc là que revient notre question principale : on fait quoi une fois qu’on est DA ? On peut en fait se servir de cet accès pour se connecter aux machines et utiliser la Domain Key pour déchiffrer les blobs DPAPI et donc les secrets !
La finalité d’un TI, qui est en fait la même que celle d’un attaquant réel, c’est de récupérer des informations sensibles, et être Domain Admin n’est qu’un moyen d’y arriver. Une fois DA, il est plus simple d’accéder à toutes les informations, mais ce n’est pas toujours suffisant.

Prenons un exemple simple : l’entreprise cible possède un ERP, accessible via un navigateur, qui contient des secrets de fabrication. Pas de chance : c’est une authentification qui n’utilise pas Active Directory. Et donc même en étant Domain Admin, impossible de s’y connecter pour voler les données convoitées. Coup de chance pour nous, Jean Jacques de la compta utilise chrome, et comme il ne se souvient jamais du mot de passe de cette application, il l’a enregistré dans Chrome… via DPAPI 😉

La solution : DonPAPI

DonPapi

Et c’est donc là qu’intervient DonPAPI 🙂
Développé par Touf, le principe de DonPAPI est simple : lors d’un TI, nous avons, comme expliqué plus haut, tous les éléments pour extraire les secrets chiffrés via DPAPI. Mais il n’y avait aucun outil capable d’automatiser cette tâche.
De là, DonPAPI est né, avec le principe basique d’utiliser ce qui se fait déjà en TI, pour y rajouter une couche de DPAPI.
Alors concrètement, comment ça fonctionne ?

Basé sur le principe de CrackMapExec et d’Impacket, DonPAPI se connecte aux machines, grâce à des comptes locaux ou le DA, via SMB afin de pouvoir classiquement exécuter des commandes.
Ensuite, le tool va tout simplement chercher sur la machine certains fichiers connus pour être des blobs DPAPI : les credentials enregistrés dans chrome ou IE, les clés wifi, les mots de passe RDP, etc.
Afin d’éviter les risques de détection par des AV ou des EDR, l’outil va simplement télécharger les fichiers, puis les déchiffrer localement, sur le poste de l’attaquant et les enregistrer dans une base de données.
En somme, 3 étapes basiques :

• connexion
• téléchargement
• déchiffrement

Mais ça, c’était pour la beta. A force de réflexions et de tests, l’idée est venue de faire mieux encore : après tout, DonPAPI permet de récupérer des blobs DPAPI, mais tant qu’on y est, pourquoi ne pas faire plus ?

D’autres features ont été rajoutées au fil du temps, permettant de récupérer -en plus des blobs DPAPI- d’autres infos juicy, comme les mots de passe VNC, mremoteNG, etc, qui contiennent des credentials potentiellement importants.
Et quitte à rajouter ça, autant continuer le développement pour rajouter une fonctionnalité permettant de faire des dashboards html à présenter en rapport d’audit 🙂
Bref, l’idée, si elle n’était pas encore claire, c’est de pouvoir se servir de DonPAPI pour étendre la surface d’attaque, montrer les risques globaux lors d’un pentest, et rapporter au client le risque pour les données métiers.

Donc, après des mois de code, de tests durant des TI, de debug dans tous les sens, et de « tiens, je pourrais peut être supprimer la fonction <NOM>_old_back », Touf a décidé de rendre le projet open source sur github : https://github.com/login-securite/DonPAPI
Pour faire ça correctement, il a expliqué et annoncé son projet lors d’un événement du Defcon Group Lille, lors d’une session de conférences ouverte à tous², ainsi qu’à HackSécuReims, un forum étudiant dédié à la sécurité informatique.

Actuellement, DonPAPI permet de faire les choses suivantes :

• récupération de credentials venant de :
  • Tâches planifiées
  • Windows Vaults
  • Windows RDP
  • AdConnect
  • clés Wif
  • credentials Intenet explorer
  • credentials & cookies Chrome
  • credentials & cookies Firefox
  • VNC
  • mRemoteNG password
• compliance en vérifiant :
  • le SMB signing
  • l’OS et le domaine des machines
• création de rapports

Evidemment, il reste de nombreuses choses à faire et à optimiser pour rendre l’outil encore plus incroyable. Donc si vous avez des propositions, n’hésitez pas à ouvrir une issue, ou mieux encore, de faire une PR 😉

Coté Login Sécurité, on est plutôt fiers de dire que le projet a atteint les 200 stars en quelques semaines à peine. Plusieurs retours et améliorations ont déjà été faits pour rendre l’outil encore meilleur, et on a hâte de voir l’évolution de cet outil

Corto

[1] Parce que oui, être DA, c’est bien, mais c’est pas le but d’un TI. Dans la réalité des faits il faut montrer que le coeur de métier est impacté, pas juste l’IT.↑

[2] Le Defcon Group Lille se retrouve régulièrement pour faire des conférences, n’hésitez pas à venir y faire un tour, c’est rempli de geeks 😀 ↑