KeePass Password Manager Vulnerability: Is Your Data at Risk?
KeePass Password Safe is an open source local password manager for Windows. It is a well designed application that supports plugins and there are numerous forks available for other platforms.
The Federal Cyber Emergency Team of Belgium, cert.be, released a warning regarding KeePass. According to the warning, attackers with write access to the KeePass configuration file may modify it with triggers to export the entire password database in cleartext without user confirmation.
Update: KeePass 2.53.1 introduced a change that addresses the issue. The password manager prompts for the master password whenever data is exported after installation of the update.
Triggers automate workflows in KeePass 2.x. They are run automatically when all trigger conditions are fulfilled. Triggers may be used for a variety of tasks, including exporting the active database to a file or URL. The official help file has a section on Triggers in KeePass.
The vulnerability described requires write access to the KeePass configuration file. An attacker has to add a trigger to the file that executes when a password database file is open to export the data silently in the background. Passwords are saved in clear text to a file and the attacker would need to obtain that file later on to gain access to all stored passwords.
Vulnerability is disputed
KeePass disputes the vulnerability. It is described on the official security issues page of the KeePass website.
The main argument leveled against the vulnerability is that if an attacker has write access to the system, that system is compromised and not secure anymore. With write access, an attacker may "perform much more powerful attacks than modifying the configuration file".
The attacker could simply replace the KeePass executable with a malicious one, add malicious programs to the system's autostart, modify configuration files for other apps or change Registry information.
KeePass argues that the only way to prevent password theft is to keep the computing environment secure. Systems need to be protected with anti-virus software, a firewall, and users should not run actions on the systems, such as opening unknown e-mail attachments, to keep it secure.
KeePass won't get confirmation options implemented when certain triggers are executed. A user of the software suggested the feature, but it has been closed.
Dominik Reichl, the developer of the password manager, argues that users can already block triggers through the use of an enforced configuration file. The special configuration file has priority over the regular configuration file of the KeePass password manager.
The use of the enforced configuration file does not address the underlying issue. Even if write access is disabled to KeePass files and folders to make sure that an attacker could not modify the enforced configuration file without elevated rights, an attacker might still be able to launch a different instance of KeePass to load the database. Enforced configuration files apply only to Keepass executable files in the same directory.
KeePass users find an option in the settings to require a master key when exporting. The setting is found under Tools > Options > Policy > Do not require entering current master key before exporting. Users need to uncheck the box to disable exporting without requiring a master key.
Attackers may turn this off, however, if they have write access to the system. KeePass users have some options at their disposal.
Option 1: Switching to KeePass 1.x
KeePass 1.x is a limited version of the password manager that does not support triggers. KeePass 1.x is still in development.
It needs to be noted that KeePass 1.x lacks support for several features other than triggers. The password manager version does not support one-time passwords, smart cards, certificates, entering the master password on secure desktop, FIPS mode, custom string fields, the entry history, or recycle bin.
A full list of differences is available here.
Option 2: Switching to KeePassXC or another fork
KeePassXC does not support triggers. It loads KeePass database files and may be used instead of KeePass. Other KeePass forks may also be used.
Keeping a computer system secure is of paramount importance. Attackers who gain access to a system have lots of options at their disposal regarding data theft and other malicious activities. Still, triggers make the exporting of entire password databases simple.
Now You: which password manager do you use? (via Günter Born)
While ideally nobody should suffer problems, it is good that holier-than-though KeePass users get a wake up reminder. Complacency is an issue for anybody.
I second that!
It takes a weird state of mind to be offended by users of a program, just because they like it and you don’t.
Also, rejoicing because of those users’ supposed misfortune is evil.
Finally, feeling the urge to tell all of the above… couldn’t you at least keep it to yourself ?
well said (Clairvau)!
What complacency? It’s not news to me that if someone has write access to my PC then it’s contents aren’t secure. This is simultaneously an unnecessarily complex and surprisingly benign attack. As pointed out by the developer an attacker in a position to modify the configuration file could just substitute a modified executable, or just install a keylogger. This is only a vulnerability in the technical sense.
It’s reasonable really. It’s not a massive vulnerability for what I imagine to be the overwhelming majority of users but for people relying on other controls such as application whitelisting – it a real vulnerability.
It’s a major vulnerability in some specific, narrow edge cases.
“This is only a vulnerability in the technical sense.”
The technical sense, is the only sense.
Done. All very easy. After the change, every extension has you log in again.
using KeepassXC and thanks for the information that KeepassXC does not have this vulnerability
I find it misleading to use as a thumbnail KeepassXC since specifically it doesn’t have the vulnerability.
Otherwise, thank you for the heads-up.
I can’t understand.
Everyone switch to KeepassXC without thinking,
First, KeepassXC doesn’t have RAM encryption when the database is open ;)
Second, as the developer and designer of KeePass already said, it is obvious that if a program be malicious in desktop, then that program can do anything in system.
It doesn’t need anything.
It can just replace the keepass executable and then instead of using trigger, it just set that malicious keepass executable to upload all database data when user opened the database.
And it has nothing to do with triggers.
I can’t understand why people don’t care to read the security info page of keepass.info and just do anything they want without thinking.
Every software in desktop environments has exactly same permissions as the user so if you installed something that you don’t trust if fully, then say hi to data theft and many other things.
“Everyone switch to KeepassXC without thinking,”
I’ve thought about it for days. I am switching.
“KeepassXC doesn’t have RAM encryption when the database is open”
Yes it does.
“it is obvious that if a program be malicious in desktop, then that program can do anything in system.”
This is the dumbest thing said in security. User level privilege does not equal System level. We have administrators, UAC, secure desktop, etc… for a reason. File write access for user profile files should never be “game over” for the whole system.
“It can just replace the keepass executable”
Unless an attacker has stolen the developer’s private code signing keys, no. The problem is the malicious executable was signed by the dev himself. If we had an executable without the backdoor export feature, and signed with a different key, we could blacklist/whitelist and always run only the right program.
“people don’t care to read the security info page of keepass.info”
It was written years ago, and not intuitive to understand. People didn’t fully realize the implications of this particular design feature and its implications until recently. Happens a lot actually.
“Every software in desktop environments has exactly same permissions as the user so if you installed something that you don’t trust if fully, then say hi to data theft and many other things.”
Yes, and the original Keepass program is the problem itself. Nobody needs to install anything else in order to be compromised here.
KeePass’s disputes against vulnerability is only partly correct.
If an attacker has local access, they can copy the password database and everything, but if it is encrypted with password, you still have a layer of security.
As per the article:
“…Even if write access is disabled to KeePass files and folders to make sure that an attacker could not modify the enforced configuration file without elevated rights, an attacker might still be able to launch a different instance of KeePass to load the database. Enforced configuration files apply only to Keepass executable files in the same directory.”
It doesn’t matter whether the Keepass database is encrypted:
1) Copy Keepass Portable somewhere to userland – with a config file set to silently export the password database to plain text.
2) Point the user’s Keepass shortcut to the portable version.
3) Wait for the user to log in to Keepass normally.
4) All the users passwords belong to us.
It does not matter how strong their master password is, or whether they’re entering it on a Secure Desktop, or whether they also use a key file for a second factor. The user would not know anything was wrong. Neither would any antivirus pick up anything unusual, as it’s using a legitimate Keepass executable and config file.
Reminds me of the first three Immutable Laws of Security:
Law #1: If a bad actor can persuade you to run their program on your computer, it’s not solely your computer anymore.
Law #2: If a bad actor can alter the operating system on your computer, it’s not your computer anymore.
Law #3: If a bad actor has unrestricted physical access to your computer, it’s not your computer anymore.
This one as well:
Law #6: A computer is only as secure as the administrator is trustworthy.
Sure, 20 years ago. iOS and Xbox for example show that this is an outdated way of thinking.
This is still completely correct on desktops.
All permissions of installable packages in Windows, Linux based systems and Mac and other desktop OSes are based on user and are not sandboxed like android or iOS.
Just few apps that specifically are for their app market have a permission system that be specific to parts of systems.
All other softwares has exactly same amount of privileges as the user.
Please learn your lessons first and then make a fuss.
Yes, even keepass.info refers to this rules from long time ago but people like to do every wrong thing they want and then if any issues happens, big brother must protect them.
It’s hilarious and terrifying at the same time.
Law #1: It’s not the attacker’s program. This backdoor was built by the original developer.
Law #2: The attacker doesn’t need any rights on the OS. User level is much easier to get.
Law #3: No physical access is needed.
This one as well:
Law #6: The attacker doesn’t need admin rights.
But Law #1 is absolutely correct. We should no longer trust the program. The developer, Dominik, let everyone down by writing malicious code into the program we were supposed to trust.
This is exactly what a backdoor looks like. And the fact the developer is hiding behind plausible deniability, shows that it is very much intentional. There’s little point in hyping about how it will take thousands of years to brute force the master password, if all it takes is someone armed with Windows Notepad to bypass it.
Someone being able to silently export the user’s entire password database to a plain text file when a user unlocks their password database is not a useful feature. I guarantee this is not something that is used (or wanted) by any ordinary users. So why has the developer decided that this is such an important feature, that it needs to be left in and allowed by default. If for some reason there are a small number of users who have a genuine use for such a feature, then it should only be possible to enable it from inside the encrypted database once it has been unlocked. Being able to do this without knowing the master password is ridiculous.
The excuse “if an attacker has write access to the system, that system is compromised and not secure anymore” is a cop out. If this is what the developer believes, then why did they introduce features like “Enter Master Key on Secure Desktop (Protection against Keyloggers)” and the ability to use Key Files as a second factor? Is the developer admitting that these features they introduced are complete nonsense and they’re just security theatre?
The excuse of “the attacker could simply replace the KeePass executable with a malicious one” is also a cop out. Windows Defender will block a malicious executable. In addition, if it’s a new unseen malicious executable, it will be submitted for analysis and it won’t run at all if Windows Defender is set to “Block executable files from running unless they meet a prevalence, age, or trusted list criterion”. Replacing the KeePass executable with a malicious one is going to be extremely noisy and will set off alarm bells all over the place. But then again, this a developer who has been training his users for years to ignore security warnings like SmartScreen, instead of just signing his executables with an EV cert.
The developer also seems to ignore the concept of security being layered and the concept of “Don’t let perfect be the enemy of good”. Just because an advanced attacker could theoretically do certain things, it doesn’t mean that there shouldn’t be layers. If someone was to enable “Enter Master Key on Secure Desktop” and also use a key file second factor to unlock their database, that will likely prevent a co-worker or abusive partner from getting access to their Keepass database. However, with this KeePass configuration file attack, they would need zero skills whatsoever, all they need is Windows Notepad. That’s it. No antivirus or event logs are going to flag anything abnormal; there will be no user warnings; nothing. The attacker can just silently dump the entire password database to a plain text file and the strength of the master password will be completely meaningless.
It should not be this easy and to just ignore it is insane. What’s so special about the feature that the developer insists it is a feature that absolutely must stay as it is? Of course, there is no rational reason and just comes across as extremely shady.
The sooner public/private keypair credentials such as Multi-Device FIDO Credentials (Passkeys) becomes mainstream, the better. Then we can dump passwords and password managers for good.
Spelling mistake, third paragraph underneath the second screenshot which reads: “an attacker might still be able to launch a different instance of KeePast to load the database”.
And yes, I do use Keepass, but agree with the developer that provided the system is secure, the trigger vulnerability doesn’t arise.
Thank you! Corrected.
Which password manager one uses is personal information you should not be encouraging people to share.
Bad habits start with tiny actions, such as sharing such information online.
so much for having a Local password manager, lol that’s why I don’t trust any of them. Best option is to have them in a USB encrypted and have it with you 24/7. Anything online can be compromised.
First, I have to say that I find Martin’s assessment a bit hysterical, or maybe a better characterization is, overly dramatic, though I guess it makes for a great panic headline. I agree with the developer 100%, and have confidence in KeePass as my password security solution of choice.
Second, I too keep my database file on an always available, encrypted USB thumbdrive. That just made sense to me from the get go.
Why not put a hash of the config file in the database. Display the config change detected date and time somewhere in the headers or status bar. If the hash has changed update the date and display it. The user can then determine if they have updated the config file and can expect a date change.
This is not a KeePass vulnerability whasoever, and would never be approved on CVE.
To exploit this vulnerability the system would need to be compromised, exactly as Dominik describes.
If your system is compromised, KeePass is the last of your worries, and is outside the KeePass responsibility to keep your system secure.
Making this article ridiculous, and showing clear lack of knowledge on the subject.
@Emanon there is a CVE for this
As stated, it hasn’t been approved, https://nvd.nist.gov/vuln/detail/CVE-2023-24055
Will never be approved either, due to the reasons I already stated.
Solution to the problem:
1) by default, when installing KeePass, the installer should drop an enforced config into KeePass directory that prohibits export without the master key
2) if the user needs to export passwords without the master key, the user deletes this config
Thus, if the user has secured the installation directory (installed in Program Files or somehow manually assigned rights so that additional privileges are needed to write there), then the user is safe by default. If not, nothing will save him, because if an attacker can write into KeePass directory, he simply can overwrite KeePass.exe by backdoored one. Even KeePass XC will not save you. An attacker can change the source code of KeePass XC by adding a silent export of passwords and then replace executable.
Enforced Config also does not work if the attacker just overwrites your desktop shortcut to point to an unprotected location of Keepass with a config file that allows silent export. It doesn’t have to be a specially compiled backdoored version. It can be the same version just copied from Program Files to the User Profile directory.
For KeepassXC… the developer did not intentionally backdoor his program like Dominik did. So an attacker would need to compile a special backdoored version. But that is what digital signatures are for. Microsoft would flag the executable.
There are different levels of compromise.
Read, write, and execute.
The whole point of an encrypted database of passwords, as opposed to a plaintext file on the desktop… is that an attacker with Read access still cannot access your passwords.
Most of the excuses for this particular security concern, revolve around this basic axiom:
“If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore”.
“… we are assuming that there is a spyware program running on the system that is specialized on attacking KeePass. In this situation, the best security features will fail”
This covers the Execute level of access. Users of KeePass are aware of this and accept this risk.
But this is NOT the level of access that is assumed by this particular attack.
The file Write permission is somewhere in the middle. Although he mentions the risk in cfgw, I think most users were really unaware of the implications. Particularly how trivially easy it is to pull off.
It is very common for an attacker to be able to get file read and file write access, but is blocked from code execution because of Windows and/or other security controls. Antivirus is already watching autorun locations and other common vectors to go from file write access to execution.
This specific attack scenario tricks the user in executing code that an attacker may have written to disk. But again, Windows has security controls to protect against this with AV/EDR, application whitelisting and digital signatures. The issue is that your own software includes the malicious code to be executed and is already trusted by the OS.
If the “Export – no repeat key” feature was not included, it would not be so trivially easy for an attacker with write permissions but without execution.
Please stop assuming everyone has a flat, all or nothing, security posture. It insults the intelligence of your users to think they don’t have additional security controls in place and that write access is always game over. The security landscape is more complex than that, and your users deserve more credit.
KeePassXC still runs in the BACKGROUND even when CLOSED.
I too have experienced this.
(note: I have not enabled “Hide window to system tray when minimised”)
Not in the macOS version which I use.
Also KeePassXC supports Hardware Keys, which I use :)
Ridiculously overblown. This is like someone stealing your car keys while you fret about whether your mobile phone in the glovebox has a screen lock enabled.
Well, more like if you’ve got a lockbox with cash in the car. But the lockbox backup key is taped underneath. Having a silent export feature is a backdoor.
I don’t consider this a real vulnerability, but at the same time it would be shockingly easy for my teenager to get access to my entire database.
For the same reason, you also might want to uncheck the similar option “Print – No Key Repeat” in Tools – Options – Policy to prevent entries being printed without requiring the Master Key
Although “Print – No Key Repeat” won’t prompt for the master password. It still will prompt the user to select a printer. This means the user will know something triggered and can cancel. The Export – No Key Repeat is extremely dangerous because there is no way for the user to know it happened. The destination file path is inside the trigger, so the attacker can put it anywhere.
Hidden from user = backdoor.
It comes down to a very flawed philosophy of security.
Read how KeePassXC does security:
Plugins are a good example. But overall, Keepass2 doesn’t understand how defense in depth or layered security models work. In Dominik’s mind, there is no nuance, all systems have a flat architecture where even a simple thing like file write in userspace, equates to full system compromise. This kind of thinking should have died with Windows XP.