KeePass Devs Downplay Password Theft Vulnerability, What You Need To Know
The password manager KeePass is currently the subject of a debate concerning whether or not a particular design decision should be considered a security vulnerability. At the center of this debate is KeePass’ support of triggers, one of which exports users’ password databases. Threat actors could potentially leverage this trigger to export and access users’ passwords. However, the KeePass developers argue that the possibility for such an attack should not be considered a vulnerability because a threat actor with write access to a computer could steal the user’s passwords in other ways.
The recent set of attacks on LastPass that ultimately resulted in the theft of users’ encrypted password vaults has sparked increased scrutiny of password managers in general. KeePass, which stores encrypted passwords locally on users’ machines, doesn’t have the same potential downfalls as cloud-based password managers. Large databases of encrypted passwords stored on remote servers can make for attractive targets. While these databases may be encrypted, encryption is crackable given enough time and computing power. As the LastPass data breach has shown, threat actors will put in the work necessary to steal these databases, even if it takes multiple attacks to do so and the stolen data is encrypted.
Given this threat, storing your own password database locally may be an attractive option. However, simply storing your passwords in a plaintext file or spreadsheet isn’t a great idea. Threat actors also target individual users’ computers with malware that can steal important files. Many threat actors distribute stealer malware specifically designed to exfiltrate login credentials, authentication tokens, and other sensitive information. Therefore, it’s good practice for users storing their passwords locally to do so in an encrypted format with tight security controls in order to protect against certain forms of attacks.
KeePass is one solution for implementing local password database protections combined with standard password management tools. That said, a recently published proof-of-concept (PoC) exploit demonstrates that malware can inject KeePass’ export trigger into the program’s XML configuration file, forcing the application to silently export a user’s encrypted passwords into an unencrypted file the next time the user unlocks the password database. The malware could then exfiltrate this plaintext file to a command-and-control (C2) server, delivering the user’s passwords to a threat actor.
The recent set of attacks on LastPass that ultimately resulted in the theft of users’ encrypted password vaults has sparked increased scrutiny of password managers in general. KeePass, which stores encrypted passwords locally on users’ machines, doesn’t have the same potential downfalls as cloud-based password managers. Large databases of encrypted passwords stored on remote servers can make for attractive targets. While these databases may be encrypted, encryption is crackable given enough time and computing power. As the LastPass data breach has shown, threat actors will put in the work necessary to steal these databases, even if it takes multiple attacks to do so and the stolen data is encrypted.
Given this threat, storing your own password database locally may be an attractive option. However, simply storing your passwords in a plaintext file or spreadsheet isn’t a great idea. Threat actors also target individual users’ computers with malware that can steal important files. Many threat actors distribute stealer malware specifically designed to exfiltrate login credentials, authentication tokens, and other sensitive information. Therefore, it’s good practice for users storing their passwords locally to do so in an encrypted format with tight security controls in order to protect against certain forms of attacks.
KeePass is one solution for implementing local password database protections combined with standard password management tools. That said, a recently published proof-of-concept (PoC) exploit demonstrates that malware can inject KeePass’ export trigger into the program’s XML configuration file, forcing the application to silently export a user’s encrypted passwords into an unencrypted file the next time the user unlocks the password database. The malware could then exfiltrate this plaintext file to a command-and-control (C2) server, delivering the user’s passwords to a threat actor.
By default, KeePass doesn’t display a confirmation prompt requiring re-entry of a user’s master password when exporting the user’s password database. That said, as shown in the screenshot above, it is possible to enable such confirmation prompts by disabling the “Export - No Key Repeat” setting. Users can also create enforced configuration files, which could potentially thwart an attack attempting to inject the export trigger into the default configuration file. However, an attack capable of modifying the default configuration file could most likely disable the enforced configuration file and re-enable the setting, allowing exports without confirmation.
The MITRE Corporation has labeled the possibility for an unauthorized password dump a vulnerability, with the vulnerability appearing in the National Vulnerability Database (NVD) as CVE-2023-24055. Yesterday, the National Institute of Standards and Technology (NIST) updated the vulnerability’s NVD page, giving it a medium severity score of 5.5 out of 10. The specific weakness attributed to KeePass on this page is CWE-312: cleartext storage of sensitive information.
However, the vulnerability’s NVD page is marked “DISPUTED,” acknowledging that the KeePass developers disagree with the assessment that the vulnerability in question is a legitimate one. In discussions with concerned users, the developers point to sections of their website explicitly acknowledging the possibility that an attacker could inject malicious triggers into the configuration file.
In a section titled “Write Access to Configuration File,” the website reads, “having write access to the KeePass configuration file typically implies that an attacker can actually perform much more powerful attacks than modifying the configuration file (and these attacks in the end can also affect KeePass, independent of a configuration file protection). These attacks can only be prevented by keeping the environment secure (by using an anti-virus software, a firewall, not opening unknown e-mail attachments, etc.). KeePass cannot magically run securely in an insecure environment.
In another section titled, “Specialized Spyware,” the developers address suggested changes to the application, such as encrypting the configuration file or storing security settings in the database. The developers’ definitive answer to whether such changes would increase security or prevent changes by malware is “no.” This section goes on to say that KeePass is designed to protect against generic threats, not threats designed to target the program in particular. The developers then quote the first law of the Ten Immutable Laws of Security: “If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.”
While it’s true that an attacker with write access to KeePass’ configuration file might be able to perform other kinds of attacks, such as displaying a fake version of the program over the real to steal the master password, its arguable whether this possibility is a sufficient reason not to prevent the injection of malicious triggers. When asked about this vulnerability, a maintainer of a KeePassXC, a popular fork of KeePass, answered that “KeePassXC is not affected, because it doesn't support triggers.”
The MITRE Corporation has labeled the possibility for an unauthorized password dump a vulnerability, with the vulnerability appearing in the National Vulnerability Database (NVD) as CVE-2023-24055. Yesterday, the National Institute of Standards and Technology (NIST) updated the vulnerability’s NVD page, giving it a medium severity score of 5.5 out of 10. The specific weakness attributed to KeePass on this page is CWE-312: cleartext storage of sensitive information.
However, the vulnerability’s NVD page is marked “DISPUTED,” acknowledging that the KeePass developers disagree with the assessment that the vulnerability in question is a legitimate one. In discussions with concerned users, the developers point to sections of their website explicitly acknowledging the possibility that an attacker could inject malicious triggers into the configuration file.
In a section titled “Write Access to Configuration File,” the website reads, “having write access to the KeePass configuration file typically implies that an attacker can actually perform much more powerful attacks than modifying the configuration file (and these attacks in the end can also affect KeePass, independent of a configuration file protection). These attacks can only be prevented by keeping the environment secure (by using an anti-virus software, a firewall, not opening unknown e-mail attachments, etc.). KeePass cannot magically run securely in an insecure environment.
In another section titled, “Specialized Spyware,” the developers address suggested changes to the application, such as encrypting the configuration file or storing security settings in the database. The developers’ definitive answer to whether such changes would increase security or prevent changes by malware is “no.” This section goes on to say that KeePass is designed to protect against generic threats, not threats designed to target the program in particular. The developers then quote the first law of the Ten Immutable Laws of Security: “If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.”
While it’s true that an attacker with write access to KeePass’ configuration file might be able to perform other kinds of attacks, such as displaying a fake version of the program over the real to steal the master password, its arguable whether this possibility is a sufficient reason not to prevent the injection of malicious triggers. When asked about this vulnerability, a maintainer of a KeePassXC, a popular fork of KeePass, answered that “KeePassXC is not affected, because it doesn't support triggers.”
