KeePass 2.53.1 password manager resolves vulnerability controversy
KeePass 2.53.1 is a new update for the password manager that addresses a potential vulnerability in the application.
Last week, word about a vulnerability in the password manager spread online. Reported by the Federal Cyber Emergency Team of Belgium, it revolved around the application's trigger mechanism.
Using a specific trigger, an attacker could export the entire password database to another file. The main issue that Belgium's Federal Cyber Emergency Team saw was that KeePass did not prompt the user for the master password before allowing the export of passwords to commence.
KeePass itself disputed the vulnerability, stating that malicious actors needed write access on the system and that the access would give them even more malicious options, including replacing the KeePass executable file, running malicious programs on the system, or modifying autostart and configurations on the system.
The lead developer of KeePass, Dominik Reichl, suggested that users could create an enforced configuration file to lock the trigger functionality. An attacker with write access could, however, modify that configuration file either, so that it did not resolve the underlying issue.
A properly protected system, with state-of-the-art antivirus, a firewall, and users who avoid common attack scenarios should prevent this type of attack entirely.
KeePass users had a few options to deal with the issue. They could switch to KeePass 1.x, a legacy version of the password manager that is still actively maintained. It lacks several features, including triggers. Other options included migrating to a KeePass port. The benefit of that approach is that the password database format is supported.
KeePass 2.53.1: vulnerability resolved
The point release addresses the issue. The official changelog highlights the fact: "Removed the 'Export - No Key Repeat' application policy flag; KeePass now always asks for the current master key when trying to export data.".
In other words: KeePass will prompt the user for confirmation before export data operations. Confirmation is given with the user's primary password, which needs to be entered before data exports begin.
The controversially discussed vulnerability shows how important it is to address concerns, especially regarding security. Reichl may not have changed his initial opinion that the vulnerability is not one, but he reacted to public concern and made a change to the application to address these concerns.
Information about the use of triggers is not available, but it seems likely that only a minority of KeePass users use these. Even fewer may use the password export trigger.
Closing Words
KeePass users may want to upgrade to version 2.53.1 immediately to protect their passwords against automated exports.
Users may also want to check a KeePass security setting to make sure that the database is properly protected against brute force attacks.
Now You: vulnerability or not, what is your take on this case?
A lot of noise about a non-issue. In the end Dominik realized he couldn’t persuade the people (or maybe bots?) who don’t want to listen to rational arguments, so he chose the pragmatic path of removing the feature.
Of course this does nothing to actually resolve the problem, because there wasn’t a real problem in the first place. But hopefully it will at least quieten down the noise.
Pretty uninformative article. But I know NOW, that if I give someone access to my computer and have my Keepass program open that anyone could export the password database. Of course, they would have access to all the information except Keepass if the program wasn’t open at the time.
I suggest reading the entire discussion thread at https://sourceforge.net/p/keepass/discussion/329220/thread/a146e5cf6b/ (be warned, it’s lengthy, but worth reading). It’s pretty informative to learn what are the attack scenarios, possible mitigations etc.
Good. KeePass has too many niche features for tasks that are irrelevant for 99.99% of users (like this trigger). It’s a password manager, security comes first!
With that said, the issue was a bit overblown and there was already a setting to disable triggers.
How dose this solve anything? If I was a hacker, with your Database file, what’s stopping me from just using 2.53 or earlier for the export vulnerability, this only restricts/requires a password now moving forward.
Yeah, that doesn’t solve anything. This is what the author said from the beginning: if the system with the program is already compromised and the intruder has write access to the system, there is no way to solve the problem at the program level.
It would be helpful if you could make a CLEAR linkout to the program website! Maybe put it in your Summary box.
There isn’t one that I can see in the entire article.