July 1, 2023 2:00 PM (GMT+2) - JULIEN BEDEL
Souvent utilisé pour stocker les secrets critiques du système d’information, KeePass est une cible de choix pour les attaquants.
Parmi ses nombreuses fonctionnalités, le logiciel propose un système d’événement-action-condition permettant l’automatisation de tâches complexes. Ce dernier fut rapidement détourné afin d’extraire les mots de passe par simple modification d’un fichier de configuration. Particulièrement discrète, cette technique avait également l’avantage de contourner la double-authentification.
Un patch correctif publié en janvier 2023 empêche désormais ce type d’exploitation, mais nous détaillerons au cours de cette conférence comment une combinaison de fonctionnalités intégrées à KeePass permettent de contourner le patch et extraire à nouveau tous les mots de passe du gestionnaire.
7 years ago, Will Schroeder (a.k.a @harmj0y) showed how attackers could abuse KeePass trigger system in order to extract cleartext passwords. As it only required the addition of some parameters in a configuration file, this technique was at the same time straightforward and quiet. I ended up abusing triggers whenever I encountered KeePass in penetration testing engagements, gathering every secret of the IT staff almost every time.
Because write access to such file typically requires administrator rights on the target machine, the technique was considered by KeePass developers (and probably the vast majority of the infosec community too) outside of the software threat model. However, a thread released on KeePass forum in early 2023 pointed at the issue and started to make big noise. CVE-2023-24055 was eventually filled at the same time, quickly drawing the public’s attention with numerous voices claiming that the password manager was not safe.
Following this controversy, KeePass developers eventually decided to introduce an additional check in version 2.53.1, which now systematically asks for the masterkey before exporting databases. While other post-exploitation techniques such as DLL injection still (and will always, as no patch is possible neither for KeePass nor any other password manager) allow attackers to extract secrets, I wanted to have a deeper look into the trigger system, see if I could find another way to get passwords from there.
This article demonstrates how a combination of KeePass triggers, placeholders and field references can be used to export databases by simply editing the configuration file.
Will Schroeder’s article already explains very well how KeePass triggers could be abused prior to version 2.53.1. Because his technique introduces various features that we are going to abuse later in this article, we will briefly explain it here.
As described in the documentation: “KeePass features a powerful event-condition-action trigger system. With this system, workflows can be automated. For example, you could define a trigger that automatically uploads your database to a backup server after saving the file locally”.
A typical trigger would for example be:
For attackers, what is really important about triggers it that they are configured outside of the encrypted database, in the KeePass.config.xml configuration file. Depending on how KeePass is tuned, it requires more or less rights for an attacker to access the file. Note that password managers are often targeted in a post-exploitation context, meaning that we will frequently have administrator rights on the target machine. More details on KeePass configuration file locations are listed in the Configuration doc page.
The list of available events, conditions and actions are listed in the Trigger doc page. Several examples are shown in the Trigger Examples page too.
Every action available at the moment, shown from the the graphical user interface.
As its name suggests, the Export active database action will make KeePass export the current database to any reachable location. Several formats are available for the export, among which KeePass CSV (1.x) and KeePass XML (2.x) are not encrypted.
As an attacker, we can easily create a malicious trigger from the graphical interface, then grab the resulting XML in our own configuration file. Here is an example which exports every entry’s fields in a cleartext CSV, right after the database is unlocked: