KeePass est-il troué ?

Bon, ça commence à bien faire : après Boxcryptor qui se fait racheter et, de facto, abandonner sous sa forme actuelle, voici qu’un autre de nos outils de sécurité préférés est sous le feu des critiques : KeePass, le gestionnaire de mots de passe (nous parlons de la version originale sous Windows) !

Une vulnérabilité a été déclarée sous la référence CVE-2023-24055, et déjà les actualités fleurissent en nous suggérant qu’une faille critique affecte notre bel outil de sécurité.

Critique, vraiment ?

Déjà, à l’heure de la publication de cet article, aucun score de criticité n’a été officiellement calculé pour cette vulnérabilité. Pour en savoir un peu plus, vous pourrez jeter un œil dans le Mag #4 où on vous explique tout ça, mais sachez que ce score (CVSS) est une note sur 10, 10 étant la plus grave.

Donc tout ce qui a pu être publié avant ce week-end indiquant que KeePass était frappé d’une faille critique est prématuré, aucune évaluation n’ayant été faite à cette date (on suivra évidemment l’évolution de la situation).

Or, et le fait est plutôt rare lors de publication de CVE, une mention « disputed » apparaît, indiquant que cette vulnérabilité n’est pas clairement établie. Un tel cas de figure peut se produire quand un problème de sécurité apparaît à l’usage d’un produit, mais qu’il n’est pas certain que le produit soit directement en cause. En l’occurrence, KeePass a déjà eu son lot de « failles » dont la cause provenait de son environnement.  Comme l’indique l’auteur de KeePass : « KeePass cannot magically run securely in an insecure environment » (KeePass ne peut pas comme par magie fonctionner en toute sécurité dans un environnement non sécurisé).

Par exemple, en 2019, plusieurs gestionnaires de mots de passe avaient été épinglés pour ne pas effacer de la mémoire vive des mots de passe utilisés. Cela ne concernait pas le mot de passe maître, mais uniquement les mots de passe gérés. Sauf que, sous Windows, un programme n’avait pas de moyen de réaliser cette opération (en tout cas à l’époque).

Le problème ne venait pas tant des gestionnaires de mots de passe que du système d’exploitation sous-jacent. Sous Windows, si la mémoire virtuelle est utilisée, sachez qu’elle ne s’efface pas automatiquement à l’extinction de la machine : il faut parfois le préciser dans les paramètres de Windows, ce qui est hors de portée d’un programme « normal » (et heureusement). Vous pouvez avoir un aperçu du mode opératoire ici.

D’autres critiques avaient été émises sur la gestion du presse-papier, mais KeePass fait partie des bons élèves de ce côté. Il va même jusqu’à effacer un mot de passe du presse-papier après un délai de 10 secondes (tant que CTRL+C est réalisé avec un mot de passe non affiché dans KeePass : s’il est affiché en clair et copié via le mécanisme de copie gérée par Windows, KeePass perd le contrôle de la donnée).

KeePass prend en compte la problématique du presse-papier

Le coupable présumé

Premier point : KeePass permet l’utilisation de plugins, comme de nombreux outils modernes : si vous utilisez un CMS tel que WordPress, vous en connaissez bien le principe. Vous savez également que généralement, lorsqu’on crie à la vulnérabilité critique dans WordPress, il s’agit la plupart du temps d’une faille dans un plugin, qui n’est donc pas dans le cœur de l’outil WordPress : il est géré par un tiers, et n’est pas inclus par défaut dans une distribution native.

KeePass est donc aussi sensible à cette problématique, et il incombe à l’utilisateur de savoir si le plugin qu’il souhaite utiliser est sûr ou non. À défaut, savoir s’il est capable de gérer le risque induit par l’utilisation d’un bout de code écrit par un tiers, par exemple en se protégeant via des solutions de sécurité adaptées (pare-feu applicatif, anti-virus, solution spécifique comme WordFence en ce qui concerne WordPress).

Maintenant, KeePass propose aussi un mécanisme de triggers, justement cités comme un des éléments clés dans le CVE :

« KeePass jusqu’à la version 2.53 [la dernière en date, ndlr] (avec une installation par défaut) permet à un attaquant, disposant d'un accès en écriture au fichier de configuration XML, d'obtenir les mots de passe en clair en ajoutant un trigger d'exportation. REMARQUE : la position du fournisseur est que la base de données de mots de passe n'est pas destinée à être sécurisée contre un attaquant disposant de ce niveau d'accès en local sur le PC ». 

Voyons leur fonctionnement. Allons dans l’interface : on commence tout naturellement par lui donner un petit nom.

On choisit ensuite un événement déclencheur, parmi la liste proposée (qui est donc limitative) :

Et pour terminer, on choisit l’action voulue à déclencher, également dans une liste prédéfinie :

Parmi ces actions, vous pouvez exporter la base des mots de passe dans différents formats, dont certains en clair. 

Une fois votre trigger créé, vous pouvez le retrouver sous forme de paramètre dans un fichier de configuration situé dans C:\Users\User Name\AppData\Roaming\KeePass\KeePass.config.xml. Ici un exemple où on se contente d’afficher une fenêtre d’information (à l’ouverture de l’outil) :

Ainsi, on se retrouve avec un fichier texte de configuration, situé dans le domaine des données de l’utilisateur actif (sous Windows). Un petit coup de WordPad pour le modifier :

Le résultat est impitoyable, à l’ouverture de KeePass :

Nous avons donc bel et bien modifié la configuration avec un simple edit du fichier, à partir des droits de l’utilisateur courant. On peut s’aider du support en ligne (Configuration - KeePass) pour chercher tout ce qu’il est possible de faire par cette méthode. Cela peut également se scripter : une fois les droits utilisateurs acquis, on peut faire modifier le fichier de configuration de KeePass avec les actions que l’on veut.

Est-ce inquiétant ?

Faisons nous-même une évaluation du score de gravité CVSS, en prenant les hypothèses les plus graves en termes d’impact (en partant du principe qu’une fois l’ensemble des mots de passe acquis, on peut faire ce qu’on veut dans l’univers de l’utilisateur).

Il faut garder à l’esprit deux éléments importants : d’abord, il faut un compte local pour pouvoir éditer le fichier de configuration, et ensuite, il faut une interaction utilisateur pour que cela fonctionne.

Les triggers de KeePass fonctionnent une fois l’outil lancé. Tout dépend ensuite de l’usage qu’on fait de KeePass, par exemple si on le laisse ouvert en tâche de fond, etc. Mais on imagine qu’un attaquant voudra exporter le fichier dès l’ouverture de KeePass et qu’il aura pu modifier le fichier de configuration avant ouverture. Avec ces hypothèses, on arriverait à un score de gravité de 7,3 sur 10, ce qui est élevé. Pour rappel, log4j atteignait 10.  

Le nœud de l’affaire consiste à savoir à quel point il est compliqué d’obtenir le droit utilisateur permettant la modification du fichier de configuration. Il faut donc une autre attaque pour pouvoir exploiter la faille de KeePass. C’est en partie ce qui explique la note de gravité que nous calculons : il est nécessaire d’avoir un accès local (les privilèges de l’utilisateur de KeePass) mais, une fois obtenu, l’exploitation de la vulnérabilité est extrêmement simple.

Que peut-on faire ?

En tant qu’utilisateur de KeePass : pas grand-chose. Pour les plus paranoïaques, un contrôle d’intégrité de fichiers qui hurle si une modification est apportée au fichier de configuration est une possibilité, mais pas des plus simple pour l’utilisateur lambda. C’est très gênant, car on dépend alors de la réaction de l’éditeur du produit.

Autre voie possible, via l’éditeur, donc : ajouter un avertissement dans KeePass lorsque des triggers déclenchent des actions sensibles comme un export de la base.

Dans le contenu de la CVE, il est indiqué que l’auteur (Dominik Reichl) pense que si un attaquant possède les privilèges de modification du fichier de configuration, il aura de toute façon une multitude d’autres moyens d’arriver à ses fins. Il a également déjà répondu au risque de modification de ce fichier de configuration ici : Enforced Configuration - KeePass.

Il existe en effet des possibilités d’améliorer les choses, mais la vulnérabilité CVE-2023-24055 repose essentiellement sur le fait que l’utilisateur n’a pas conscience de l’export, réalisé automatiquement, sans avertissement. Or un message d’avertissement semble une bonne solution, à la fois simple à mettre en œuvre, et permettant d’éviter le principal danger, à savoir l’exécution transparente de l’export.

Il y a des discussions en ce moment sur le forum de KeePass, mais même si la « faute » est du côté de Windows, s’il existe un moyen simple et efficace de contrer la menace, alors pourquoi ne pas le mettre en œuvre, surtout que la marge de manœuvre du côté des utilisateurs est quasi-nulle ?

Comme beaucoup de spécialistes dans ce domaine, Dominik Reichl ne semble pas vouloir endosser la responsabilité des autres. S’il a raison sur le principe, un logiciel proposant de sécuriser les mots de passe de ses utilisateurs ne peut pas faire comme si la problématique n’existait pas. C’est une des bases de la défense en profondeur, concept qu’il faut désormais intégrer tant la surface d’attaque sur un PC moderne est vaste.