Tour d’horizon des attaques et vulnérabilités sur le gestionnaire de mots de passe KeePass 

De nos jours, l’utilisation de gestionnaires de mots de passe est fortement recommandée, tant pour une utilisation personnelle que professionnelle. En effet, la plupart des utilisateurs ont tendance à disposer d’un mot de passe unique auquel ils appliquent de légères variations (comme un chiffre qui s’incrémente ou un caractère spécial à la fin) pour se connecter à leurs différents comptes. Il arrive même encore de trouver des mots de passe écrits sur des post-its lors d’audits Red Team. La perspective offerte par ces logiciels est attrayante : moindre exposition aux incessantes fuites de données, plus besoin de retenir de nombreux mots de passe complexes et certaines solutions permettent même un stockage sécurisé dans le Cloud. C’est pourquoi nous proposons dans cet article, de s’intéresser à la sécurité du gestionnaire de mots de passe KeePass, une solution locale, gratuite et open source recommandée par l’ANSSI, que des millions d’individus utilisent au quotidien. 

La suite de cet article est scindée en trois sections : une présentation globale du logiciel Keepass, les attaques et enfin les vulnérabilités pouvant l’affecter. La deuxième partie regroupe les méthodes d’exploitation qui ne sont pas basées sur des vulnérabilités connues inhérentes à KeePass, à l’inverse de la partie finale, qui rassemble les failles identifiées au sein du logiciel et publiquement divulguées sous la forme d’une CVE. Ne seront pas mentionnées les attaques reposant sur l’utilisation d’un keylogger, car elles n’ont pas directement de lien avec le logiciel en lui-même (en plus de pouvoir être facilement contrées grâce à l’utilisation de secure desktop [1]). Sans plus attendre, commençons par la présentation du logiciel et du concept de gestionnaire de mot de passe. 

KeePass et la gestion des mots de passe 

Pourquoi autant de particuliers et d’entreprises utilisent KeePass ? Au-delà de sa gratuité, le logiciel présente un avantage considérable : il est open source. La première version du projet, KeePass 1.x (exclusive à Windows), est publiée en 2003 par Dominik Reichl et programmée en C++. Une variante développée en C#, KeePass 2.x, est également maintenue en parallèle et propose davantage de fonctionnalités (en plus de pouvoir fonctionner sous Linux et MacOS). 

De par sa nature open source, des forks du projet ont été entrepris et constituent des alternatives viables comme KeePassX (Linux et MacOS) ou son descendant KeePassXC. Ce dernier est maintenu par la communauté et compatible avec de nombreux systèmes. 

Le principe fondamental d’un gestionnaire de mots de passe est simple : proposer une base de données contenant les mots de passe de l’utilisateur stockés de manière sécurisée et ne pouvant être débloquée qu’en utilisant un mot de passe maître (master password). KeePass, contrairement à d’autres alternatives, propose uniquement un stockage en local, dans un fichier repérable à l’extension .kdb ou .kdbx en fonction de la version. Les algorithmes de chiffrement utilisés pour assurer sa confidentialité sont AES-256, Twofish ou ChaCha20. L’intégrité quant à elle est assurée par l’algorithme SHA-256 et l’authenticité par HMAC-SHA-256. Ces algorithmes sont aujourd’hui considérés comme sûrs et font partie des recommandations officielles d’instances gouvernementales comme l’ANSSI [2] ou le NIST. 

L’utilisation d’un gestionnaire de mots de passe est très intéressante pour l’utilisateur. Outre les problèmes comme l’implémentation des algorithmes cryptographiques utilisés, on aurait même tendance à les considérer comme infaillibles, surtout dans le cas d’un logiciel uniquement utilisable localement comme KeePass. La réalité est un petit peu plus complexe. Intéressons-nous maintenant aux attaques et vulnérabilités ayant affecté ce logiciel tout au long de ses 19 années d’existence. 

Quelques attaques connues 

Maintenant que KeePass et le concept de gestionnaire de mots de passe ont été introduits, intéressons-nous aux attaques permettant de récupérer le contenu d’une base de données sécurisée .kdbx sans avoir une connaissance préalable du master password. 

Force brute 

Description 

La première attaque qui sera présentée dans cette section est effectuée par force brute. Le principe est simple : récupérer l’empreinte du mot de passe maître (permettant de déverrouiller la base de données) et tenter de la casser. Le succès d’une telle attaque repose sur l’utilisation d’un mot de passe faible ou compris dans une liste connue. Dans la démonstration suivante, nous utiliserons l’outil JohnTheRipper. 

Exploitation 

Dans la capture suivante, le mot de passe maître utilisé pour déchiffrer le fichier .kdbx peut être retrouvé à partir de son empreinte grâce à une attaque par force brute. Il devient alors possible d’accéder à la base de données et de récupérer son contenu. 

KeeFarce 

Description 

La deuxième attaque est nommée KeeFarce et a été mise au point par un chercheur nommé Denis Andzakovic en 2015 [3]. Le principe est le suivant : exporter les mots de passe d’une base de données KeePass ouverte via la récupération d’objets directement depuis la mémoire du processus. Le fonctionnement détaillé de l’attaque est le suivant [4] : 

1. Une DLL malveillante est chargée dans le processus de KeePass puis un appel à LoadLibraryA() est forcé pour charger la DLL d’amorçage grâce au fichier KeePass.exe. 
2. La DLL d’amorçage (fichier BootstrapDLL.dll) va ensuite charger le runtime .NET CLR (Common Language Runtime) qui va lui-même exécuter l’assemblage KeeFarceDLL.dll, contenant la charge utile principale de l’attaque. 
3. KeeFarceDLL.dll va instancier CLR MD (Microsoft.Diagnostic.Runtime.dll), puis l’attacher au processus KeePass, ce qui permet de parcourir la mémoire allouée sur le tas, de localiser des pointeurs d’objets ou d’appeler des fonctions par réflectivité. Dans le cas de KeeFarce, CLR va énumérer le tas à la recherche d’un objet KeePass.UI.DocumentManagerEx et le sauvegarder. Cet objet contient des informations sur la base de données active et le groupe racine de l’instance KeePass ciblée. 
4. KeeFarceDLL.dll va ensuite charger réflectivement l’assemblage légitime du processus KeePass et instancier un objet KeePass.DataExchange.PwExportInfo avec les paramètres récupérés à l’étape précédente. Le rôle de cet objet est de contenir les informations liées à l’export d’une base de données. À noter que cette action est possible car l’exploit fonctionne dans le même contexte .NET que l’exécutable Keepass grâce à a technique d’injection DLL utilisée précédemment. 
5. Dernière étape de l’attaque, un objet KeePass.DataExchange.Formats.KeePassCsv1x est instancié et la méthode Export est récupérée. Cette fonction est ensuite invoquée (exécutée réflectivement). Sont passés en paramètre l’objet PwExportInfo ainsi qu’un chemin de destination pour le fichier .csv créé. 

Si l’attaque s’est correctement déroulée, un fichier contenant tous les mots de passe stockés dans la base de données est créé dans les dossiers de l’utilisateur ciblé. Les captures suivantes montrent la réalisation de l’attaque. 

Exploitation 

Dans ce scénario d’exploitation, un utilisateur légitime a déverrouillé sa base de données et un attaquant est capable d’exécuter des commandes sur la machine. L’utilisation des mécanismes de sécurité proposés par KeePass comme une clé composite (composition de différents secrets) ou le secure desktop n’ont pas de conséquences sur la faisabilité de l’attaque. 

L’attaquant ayant au préalable déposé les 4 fichiers nécessaires à la réalisation de l’attaque sur la machine de la victime va déclencher l’exploitation en exécutant le programme KeeFarce.exe. 

L’attaque est un succès, tous les mots de passe de la victime ont été exportés dans le fichier keepass_export.csv. 

KeeThief 

Description 

Cette troisième attaque nommée KeeThief a été révélée par deux chercheurs du nom Will Schroeder et Lee Christensen en 2016 et est détaillée dans l’article “KeeThief – A Case Study in Attacking KeePass Part 2” [4]. Celle-ci repose sur le même principe que la précédente, c’est à dire l’énumération d’objets depuis la mémoire du processus Keepass. En revanche, le moyen d’accéder aux mots de passe est différent : il est ici question de récupérer les secrets de clé depuis la mémoire et non de provoquer un export. 

KeePass met à disposition, pour renforcer la sécurité de ses bases de données, le mécanisme de clé composite. En plus du mot de passe maître déjà évoqué précédemment, il est possible de requérir d’autres composants pour déverrouiller le fichier. 

Les options proposées sont les suivantes et peuvent être utilisées conjointement : 

• Un fichier de clé keyfile, stocké sur la machine ou sur une clé USB par exemple. 

• Un Windows User Account WUA, qui consiste en l’ajout à la clé maître d’une composante spécifique à un compte Windows. Si cette option est activée, il ne sera pas possible de déverrouiller la base de données depuis un autre compte Windows que celui sur lequel elle a été créée. 

Cette attaque permet de récupérer tous les secrets simultanément puis d’en tirer parti avec une version modifiée du logiciel. Le fonctionnement détaillé est le suivant : 

1. Une fois encore, CLR MD est utilisé pour énumérer le tas à la recherche d’objets. Dans le cas de KeeThief, le type KeePassLib.PwDatabase est convoité car il représente l’instance actuellement ouverte. 
2. Ensuite, la méthode GetReferencedObjects() est appelée pour lister tous les objets référencés par l’instance récupérée. La variable m_strUrl est récupérée depuis l’objet KeePassLib.Serialization.IOConnectionInfo car elle contient le chemin de la base de données actuellement ouverte. 
3. En énumérant une nouvelle fois les objets référencés, il est possible de récupérer KeePassLib.Keys.KcpPassword, KeePassLib.Keys.KcpKeyFile, ou KeePassLib.Keys.KcpUserAccount qui sont les trois éléments potentiels d’une clé composite KeePassLib.Keys.CompositeKey. Il n’est pas possible d’accéder directement à leur valeur, car les blocs de données contenus dans ces objets sont protégés (classe ProtectedBinary). Leur chiffrement est mis en place grâce à la classe .NET System.Security.Cryptography.ProtectedMemory qui utilise les fonctions mises à disposition par DPAPI RtlEncryptMemory() et RtlDecryptMemory(). 
4. Pour chacun des objets constituant la clé composite récupérés, les instances de ProtectedBinary associées sont énumérées à la recherche des blocs de données chiffrées m_pbData. 
5. Étant donné que ces blocs sont chiffrés avec le flag SameProcess, il n’est pas possible de les déchiffrer directement dans KeeThief.exe. Il est donc nécessaire d’effectuer l’appel à RtlDecryptMemory() depuis le processus KeePass.exe. La solution retenue est la suivante : injecter du shellcode permettant d’appeler la fonction directement dans le processus et récupérer les résultats. Cette solution est d’autant plus avantageuse que les clés secrètes utilisées pour protéger les données en mémoire sont éphémères et spécifiques à cette instance du programme, donc différentes à chaque exécution. 
6. Il devient donc possible de déchiffrer les blocs de données protégées directement depuis le processus KeePass.exe et de récupérer la clé composite constituée du mot de passe maître et éventuellement d’un keyfile et d’un WUA. 

Il n’est pas possible d’utiliser directement les secrets de clé récupérés pour déverrouiller la base de données pour la simple raison qu’aucun champ n’existe pour saisir le keyfile et le WUA. Heureusement, KeePass est un logiciel open source, on peut donc modifier le code du formulaire présenté à l’utilisateur et y intégrer les deux valeurs manquantes. En exfiltrant le fichier .kdbx ciblé et en faisant usage de la version modifiée de KeePass localement, il devient possible d’avoir accès au contenu de la base de données. 

Exploitation 

Dans ce scénario, un utilisateur légitime a déverrouillé sa base de données KeePass en utilisant un mot de passe, un keyfile ainsi que son WUA (Window User Account). Pour assurer le plus haut niveau de sécurité possible, le mot de passe a été saisi au travers du secure desktop. 

Un attaquant ayant identifié que la base de données était ouverte est en mesure d’utiliser l’attaque pour extraire les trois composants de la clé composite KcpPassword, KcpUserAccount et KcpKeyFile depuis la mémoire du processus KeePass.exe. 

L’attaquant maintenant en possession des différents secrets peut utiliser la version modifiée du logiciel en local pour déchiffrer la base de données exfiltrée. 

L’exploitation est un succès, l’attaquant a maintenant accès au contenu du KeePass attaqué. 

Note : Les deux attaques précédentes ont été reprises et améliorées par d’autres professionnels de la cybersécurité depuis leur première publication. En effet les progrès des techniques de détection modernes les ont rendues très difficiles à utiliser discrètement. Pour répondre à ces nouvelles contraintes, des variantes comme KeeFarce Reborn [5] créée par Julien Bedel ou encore KeePassHax [6] créée par holly-cracker sont apparues et se présentent sous la forme d’une seule DLL. Celles-ci peuvent être utilisées indépendamment d’un injecteur en particulier, à la différence des concepts originaux. D’un autre côté, snovvcrash a pris une direction différente en utilisant D/Invoke (invocation dynamique de code non managé sans passer par P/Invoke) pour contourner les moyens de protection. La méthode employée est décrite dans l’article suivant [7]. 

Plugins 

Description 

KeePass met à disposition des utilisateurs un mécanisme d’extension des fonctionnalités (plugins [8]). Deux formats sont acceptés, PLGX et DLL, qui nous intéresse en particulier. Il est donc possible de charger directement une DLL dans le processus KeePass, sans recourir à un injecteur. Il n’est également plus nécessaire de parcourir la mémoire à la recherche d’objets. Le projet KeeFarce Reborn [5] déjà évoqué propose une version de l’attaque sous forme de plugin. Il est possible d’en tirer partir à la condition de disposer de droits suffisants sur le répertoire C:\Program Files\KeePass Password Safe 2\Plugins pour y placer la DLL malveillante. De la même manière que les attaques précédentes, tous les mots de passe seront exportés dans un fichier à la prochaine ouverture de la base de données (moment où sont chargés les plugins). 

Exploitation 

Dans le scénario suivant, nous partons du principe que la victime s’est fait compromettre son compte par un attaquant. Celui-ci va tenter de récupérer les mots de passe stockés dans une base de données KeePass en abusant du système de plugins. La première étape est le dépôt du fichier de l’attaque KeeFarceRebornPlugin.dll dans le répertoire Plugins des fichiers du logiciel. Il sera ensuite trouvable dans la liste des plugins installés. 

À présent, la prochaine fois que la victime ouvrira sa base de données, le plugin malveillant sera chargé par le logiciel et provoquera l’export des mots de passe dans un fichier export.xml. L’attaquant aura donc accès au contenu du KeePass de sa victime, l’attaque est un succès. 

Triggers 

Description 

Introduite dans le même post que KeeThief, la méthode d’exploitation suivante n’est plus basée sur la récupération d’informations depuis la mémoire du processus, mais sur l’exploitation de la fonctionnalité trigger (déclencheur) [9] de KeePass 2.x pour exfiltrer tous les mots de passe d’une base de données. 

En effet, il est possible d’effectuer diverses actions en fonction de déclencheurs comme Opened database file (ouverture de fichier de base de données). Certaines telles que Execute command line / URL (exécuter commande) ou Export active database (exporter la base de données active) sont particulièrement intéressantes du point de vue d’un attaquant. En disposant de droits d’écriture sur le fichier de configuration, il devient possible de mettre en place un déclencheur pour exporter la base de données lors de son ouverture par le propriétaire légitime. Le script PowerShell suivant est inclus dans le répertoire Github de KeeThief [10] et permet de trouver les fichiers de configuration KeePass 2.x ainsi qu’ajouter ou supprimer des déclencheurs malveillants comme il est possible de voir dans le code suivant (tiré de la fonction Add-KeePassConfigTrigger). 

Exploitation 

Dans le scénario suivant, nous partons du principe que la victime s’est fait compromettre son compte par un attaquant. Celui-ci va chercher à récupérer les mots de passe stockés dans une base de données KeePass. L’attaquant va commencer par énumérer les fichiers de sa victime à la recherche du fichier de configuration. 

L’attaquant ayant connaissance de l’emplacement de ce fichier et disposant de droits d’écriture ajoute un déclencheur malveillant qui va exporter tous les mots de passe contenus dans la base de données dès son ouverture par la victime. 

La backdoor étant implantée, il ne reste plus qu’à attendre l’ouverture de la base de données et l’export des mots de passe. Au bout de quelques temps, le fichier Raph-Database.csv contient bien les mots de passe exfiltrés, témoignant du succès de l’attaque. 

Il est également possible de supprimer le déclencheur du fichier de configuration pour effacer les traces de cette exploitation. 

Triggers v2 

Description 

La dernière méthode d’exploitation qui sera présentée dans cette section est très récente. Il y a quelques semaines, lors de la conférence leHACK, Julien Bedel a dévoilé une nouvelle technique permettant d’exploiter la fonction des déclencheurs de KeePass pour récupérer des mots de passe stockés dans une base de données. L’export n’étant plus une option viable suite à la version 2.53.1, il a donc fallu s’y prendre différemment. La technique suivante est tirée de la conférence et de l’article y faisant suite [11]. 

KeePass met à disposition un système de placeholder (espace réservé) permettant de désigner le champ d’une entrée en base de données. Par exemple, {USERNAME} permet de désigner le nom d’utilisateur, {PASSWORD} le mot de passe et {CMD} permet même d’exécuter des commandes (et donc des scripts). 

Cette attaque est basée sur un déclencheur et deux placeholders permettant d’exécuter des scripts PowerShell nécessaires à la réalisation de l’attaque. Chaque entrée en base de données est représentée par un identifiant unique caché appelé UUID (chaîne aléatoire de 128-bits ou 32 caractères hexadécimaux). Le premier placeholder sert à récupérer l’UUID du mot de passe à exfiltrer (opération complexe qui ne sera pas détaillée ici), et le second permet de récupérer les informations intéressantes comme le titre, le nom d’utilisateur, le mot de passe et l’URL associée. Un second trigger peut également être ajouté pour détecter la présence du fichier contenant les mots de passe extraits et ainsi éviter d’effectuer plusieurs fois l’extraction. 

Il est bon de noter que la réalisation d’une telle attaque requiert des droits administrateur. En effet, depuis la mise à jour 2.54 de KeePass, la modification du fichier de configuration des déclencheurs est réservée aux utilisateurs privilégiés, dans le but d’éviter les actions malveillantes que celles présentées dans les deux sections précédentes. 

Exploitation 

Dans le scénario suivant, nous partons du principe que la victime s’est fait compromettre sa machine par un attaquant et que celui-ci veut maintenant accéder au contenu de sa base de données KeePass.  

L’attaquant va pour cela chercher à créer un déclencheur malveillant s’exécutant toutes les 5 secondes et contenant la charge utile constituée des deux placeholders dont le fonctionnement a été détaillé précédemment. 

Une fois que la base de données est ouverte par son propriétaire légitime, les mots de passe sont exportés dans le fichier extract.txt. 

Bilan 

Ceci conclut cette première section à propos des attaques pouvant être réalisées pour récupérer des secrets contenus dans une base de données KeePass. D’autres méthodes existent et on peut imaginer que de nouvelles techniques seront découvertes dans le futur. L’article “A Case Study in Attacking KeePass” [12] de Will Schroeder présente notamment d’autres chemins d’exploitation tirant parti de WMI (Windows Management Instrumentation) grâce à des évènements permettant de cloner un keyfile ou encore de DPAPI dans le cas de l’utilisation de WUA (KeePass utilise DPAPI pour intégrer une composante liée au compte Windows de l’utilisateur à la clé composite). 

Tour d’horizon des vulnérabilités 

KeePass a été affecté par des vulnérabilités pouvant potentiellement mettre en péril la confidentialité des informations stockées par ses utilisateurs. Dans cette section, nous revenons sur les 4 dernières vulnérabilités publiquement référencées en date. À noter que durant sa longue existence, 19 ans lors de la rédaction de cet article, les deux versions de KeePass (1.x et 2.x) n’ont connu que 8 vulnérabilités publiques (dont 2 au cours des 6 derniers mois) [13]. 

V1 : Injection de CSV (CVE-2019-20184) 

La première vulnérabilité discutée dans cette section est une injection de CSV après l’export d’une base de données et a été identifiée par Pablo Santiago [14]. Celle-ci affecte les versions de KeePass inférieures à 2.4.1. Lors de l’ouverture du fichier obtenu par un logiciel comme Excel ou LibreOffice Calc, les données de la cellule Titre peuvent être interprétées comme une formule et permettre à un attaquant d’exécuter des commandes. Une interaction de la part de la victime reste nécessaire. Il est parfaitement possible d’imaginer un scénario dans lequel un attaquant dispose de la clé maître d’un KeePass partagé et y ajoute une entrée malveillante exploitant cette vulnérabilité. N’importe quel utilisateur ouvrant un export CSV de cette base de données pourrait alors voir sa machine compromise. 

Le champ titre de l’entrée ajoutée à la base de données est une formule de tableur permettant d’ouvrir le programme calculatrice. L’export sous forme de fichier .csv se fait tel que présenté dans la capture suivante. 

À l’ouverture du fichier exporté, le champ Titre de la troisième entrée de la base de données est interprété comme une formule, résultant en l’ouverture de la calculatrice. 

V2 : Identifiants en clair dans les logs (CVE-2022-0725) 

Cette seconde vulnérabilité publiquement référencée est une divulgation d’informations. Il était possible de récupérer les mots de passe copiés depuis KeePass en clair dans les logs système de la distribution Linux Fedora. Le problème était causé par la méthode utilisée pour ajouter des données au presse-papier (donc non inhérent au logiciel) et a été corrigé dans la version 2.54 de KeePass. La capture suivante illustre la vulnérabilité [15]. 

V3 : Détournement du fichier de configuration (CVE-2023-24055) 

Cette troisième vulnérabilité créée par Alex Hernandez [16] est en réalité la qualification de la première attaque basée sur les déclencheurs présentée dans la section précédente. Celle-ci a été publiquement dévoilée en 2016 et aucune modification du logiciel n’a été proposée pour tenter de l’endiguer.  

La CVE est actuellement disputée car le développeur de KeePass, Dominik Reichl, estime que “la base de données de mots de passe n’est pas censée être protégée contre un attaquant disposant déjà d’un accès local sur un PC”. Après de nombreux débats dans la communauté, une modification a été apportée dans la version 2.53.1 de KeePass et le mot de passe maître est dorénavant requis lors de l’export d’une base de données, rendant l’attaque beaucoup plus compliquée à exploiter. 

 

V4 : Récupération de mot de passe maître via un dump mémoire (CVE-2023-32784) 

La dernière faille qui sera présentée dans cette section permettait de récupérer le mot de passe maître grâce à un dump mémoire du processus KeePass. Les informations suivantes sont tirées du répertoire créé par le chercheur à l’origine de la découverte [17], vdohney.  

KeePass utilise une boîte de texte customisée pour la saisie de mots de passe nommée SecureTextBoxEx. Pour chaque caractère entré, une chaîne de caractère résiduelle est créée en mémoire. De plus, à cause du fonctionnement de .NET, il est très difficile de s’en débarrasser. Par exemple, pour la saisie de la chaîne Password il sera possible de trouver les traces suivantes : •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d. Il est donc possible de chercher ces chaînes dans un dump mémoire du processus pour récupérer en quasi-totalité le mot de passe maître, en dehors du premier caractère. L’exploitation de cette vulnérabilité facilite grandement le cassage de l’empreinte du mot de passe maître. La capture suivante illustre l’exploitation de la vulnérabilité. Celle-ci a été corrigée dans la version 2.54 de KeePass. 

Bilan 

Nous avons donc vu que KeePass a été affecté par plusieurs vulnérabilités ayant été publiquement référencées au cours de son existence. La majorité d’entre elles ne sont pas critiques et sont bien souvent induites par des composants extérieurs à KeePass (comme .NET ou l’ajout de données au presse-papier sur Fedora). Le logiciel n’a pour l’instant connu aucune faille sur les implémentations des algorithmes cryptographiques utilisés ou d’autres fonctions essentielles, ce qui est plutôt bon signe. 

Conclusion 

La première section de cet article nous a offert un tour d’horizon du concept de gestionnaires de mots de passe et des problématiques liées à travers la présentation du logiciel KeePass. Nous avons ensuite vu dans les détails quelles attaques pouvaient être utilisées pour récupérer les mots de passe stockés dans une base de données KeePass sans en être le propriétaire légitime. Pour terminer, nous avons pu nous familiariser avec quelques-unes des vulnérabilités ayant affecté le logiciel depuis sa première publication en 2003. 

Que pouvons-nous en tirer ? KeePass semble être une solution robuste, et ce sur de nombreux plans : logiciel local, open source, implémentant des algorithmes robustes et offrant des moyens de déverrouillage multifactoriels. Bien sûr des attaques existent, mais il semble relativement compliqué de proposer une solution 100% hermétique à toute forme d’exploitation, surtout dans le cas où un attaquant dispose de permissions administrateur sur la machine de sa victime. L’utilisation d’un gestionnaire de mots de passe n’empêche pas le maintien d’une bonne hygiène numérique (ne pas installer de logiciels douteux, mettre en place un mot de passe maître fort, utilisation de l’authentification multifactorielle). Dans tous les cas, d’un point de vue logiciel, KeePass semble s’imposer comme une solution locale de référence et constitue une alternative solide à ses concurrents payants et dans la plupart des cas basés sur le cloud. Néanmoins, une attention particulière doit être dédiée au renforcement des postes de travail et du réseau dans lequel ils sont déployés, l’attaque d’une base de données KeePass étant bien souvent réalisée dans un contexte de post-exploitation. 

Références 

[1] https://keepass.info/help/kb/sec_desk.html 

[2] https://www.ssi.gouv.fr/uploads/2021/03/anssi-guide-selection_crypto-1.0.pdf 

[3] https://github.com/denandz/KeeFarce 

[4] https://blog.harmj0y.net/redteaming/keethief-a-case-study-in-attacking-keepass-part-2/ 

[5] https://github.com/d3lb3/KeeFarceReborn 

[6] https://github.com/HoLLy-HaCKeR/KeePassHax 

[7] https://hackmag.com/coding/keethief/ 

[8] https://keepass.info/help/v2/plugins.html 

[9] https://keepass.info/help/v2/triggers.html 

[10] https://github.com/GhostPack/KeeThief/blob/9e60798ba51d03de687bbc1a5248f12032b01951/PowerShell/KeePassConfig.ps1 

[11] https://d3lb3.github.io/keepass_triggers_arent_dead/#using-keepass-as-a-programming-language 

[12] https://blog.harmj0y.net/redteaming/a-case-study-in-attacking-keepass/ 

[13] https://www.cvedetails.com/vulnerability-list/vendor_id-12214/Keepass.html 

[14] https://medium.com/@Pablo0xSantiago/cve-2019-20184-keepass-2-4-1-csv-injection-33f08de3c11a 

[15] https://bugzilla.redhat.com/show_bug.cgi?id=2052696 

[16] https://github.com/alt3kx/CVE-2023-24055_PoC 

[17] https://github.com/vdohney/keepass-password-dumper