KeePass Disputes Vulnerability Allowing Stealthy Password Theft (bleepingcomputer.com) 66
The development team behind the open-source password management software KeePass is disputing what is described as a newly found vulnerability that allows attackers to stealthily export the entire database in plain text. BleepingComputer reports: KeePass is a very popular open-source password manager that allows you to manage your passwords using a locally stored database, rather than a cloud-hosted one, such as LastPass or Bitwarden. To secure these local databases, users can encrypt them using a master password so that malware or a threat actor can't just steal the database and automatically gain access to the passwords stored within it. The new vulnerability is now tracked as CVE-2023-24055, and it enables threat actors with write access to a target's system to alter the KeePass XML configuration file and inject a malicious trigger that would export the database, including all usernames and passwords in cleartext. The next time the target launches KeePass and enters the master password to open and decrypt the database, the export rule will be triggered, and the contents of the database will be saved to a file the attackers can later exfiltrate to a system under their control. However, this export process launches in the background without the user being notified or KeePass requesting the master password to be entered as confirmation before exporting, allowing the threat actor to quietly gain access to all of the stored passwords. [...]
While the CERT teams of Netherlands and Belgium have also issued security advisories regarding CVE-2023-24055, the KeePass development team is arguing that this shouldn't be classified as a vulnerability given that attackers with write access to a target's device can also obtain the information contained within the KeePass database through other means. In fact, a "Security Issues" page on the KeePass Help Center has been describing the "Write Access to Configuration File" issue since at least April 2019 as "not really a security vulnerability of KeePass." If the user has installed KeePass as a regular program and the attackers have write access, they can also "perform various kinds of attacks." Threat actors can also replace the KeePass executable with malware if the user runs the portable version.
"In both cases, 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)," the KeePass developers explain. "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." If the KeePass devs don't release a version of the app that addresses this issue, BleepingComputer notes "you could still secure your database by logging in as a system admin and creating an enforced configuration file."
"This type of config file takes precedence over settings described in global and local configuration files, including new triggers added by malicious actors, thus mitigating the CVE-2023-24055 issue."
While the CERT teams of Netherlands and Belgium have also issued security advisories regarding CVE-2023-24055, the KeePass development team is arguing that this shouldn't be classified as a vulnerability given that attackers with write access to a target's device can also obtain the information contained within the KeePass database through other means. In fact, a "Security Issues" page on the KeePass Help Center has been describing the "Write Access to Configuration File" issue since at least April 2019 as "not really a security vulnerability of KeePass." If the user has installed KeePass as a regular program and the attackers have write access, they can also "perform various kinds of attacks." Threat actors can also replace the KeePass executable with malware if the user runs the portable version.
"In both cases, 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)," the KeePass developers explain. "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." If the KeePass devs don't release a version of the app that addresses this issue, BleepingComputer notes "you could still secure your database by logging in as a system admin and creating an enforced configuration file."
"This type of config file takes precedence over settings described in global and local configuration files, including new triggers added by malicious actors, thus mitigating the CVE-2023-24055 issue."
Most vulnerability hunters are useless (Score:5, Interesting)
Re: (Score:2)
Yea, I kinda have to agree on this one. If the attacker can change your config files you're already rooted.
Re:Most vulnerability hunters are useless (Score:5, Interesting)
Yea, I kinda have to agree on this one. If the attacker can change your config files you're already rooted.
Agreed. If someone has this level of access, they can replace KeePass.exe with PhishingExecutableWhoseFrontEndLooksExactlyLikeKeePass.exe and just steal your master key. Along with the database they also already have.
If you can't trust the computer you're running on, you can't trust the computer you're running on.
Re:Most vulnerability hunters are useless (Score:5, Interesting)
Maybe. It depends on the system. On a desktop you are probably right, as most desktops give their users administrative access. Once the atacker has administrative all bets are off.
But a device that protects its user doesn't do that. But desktops are nightmare security wise because they do. So lets imagine we have a device set up to protect it user, like an Android phone.
In that scenario you have secure boot, so the attacker can't alter the base OS. The base OS implements it's own version of secure boot for the apps, so the attacker can't change them either. Lets imagine the scenario the attacker has convinced the user to install their app. The phones protect the users so well that won't buy the attacker much, so lets even things up a bit by assuming the user has told keepass to store it files and config on an unencrypted SDCard that every app has write access to. Even if that scenario, the attacker would not have much of a hope without this vulnerability. With it the user is hosed.
This isn't hard to fix. As someone noted elsewhere here, all they have to do is authenticate the config file or at least some parts of it, with the master password. Their excuse for doing doing this, to wit "there is no point because the OS is weak already" doesn't seem like a good reason not to do it. The OS may be hardened one day. If they refuse to fix their side keepass will never be hardened.
Re:Most vulnerability hunters are useless (Score:4, Insightful)
Android, or AOSP., by default is as secure as a modern OS can get. It uses SELinux to ensure that getting root doesn't mean much. It has fscrypt() for filesystem based encryption, and can be implemented with an immutable OS core, guarding against OS modifications.
What kills Android's security are device makers. The first thing is the disinterest in patching beyond a few months... maybe a year or two if one buys a flagship Android model. Then, there are the weakened implementations done by phone makers. A good number vulnerabilities are something left there deliberately, or through setting security aside to get more user metadata (or even user data.)
Another thing that kills security are unscrupulous stores. Stuff like F-Droid, Amazon and other open source repos tend to be very well curated, but often a phone from some countries is attached to a store which at best doesn't really go after people who make malware, or at worst, just lets any app maker upload what they want, malicious or no.
If Android had an open standard, (LineageOS. perhaps), all device makers allowed people to upgrade to it, as opposed to locking bootloaders and guarding SoC blobs like it was the formula of Nuka-Cola, the Android ecosystem would be a lot different.
AOSP itself is very secure, it is the ecosystem that isn't. Contrast that to iOS where the ecosystem is secure, but the OS itself, if jailbroken, effectively loses all effective security, while a rooted Android device will be just as secure as without root, assuming no PEBCAK issues, and a good su binary which requires apps to request su access in the install manifest.
Re: (Score:2)
Nothing makes windows look secure. Not even shills.
Re: (Score:2)
On a desktop you are probably right, as most desktops give their users administrative access. Once the atacker has administrative all bets are off.
Do you mean Windows or other Desktop examples? On linux the KeePass config file is /usr/lib64/keepass/KeePass.config.xml and it's set to be writeable only by root.
Re:Most vulnerability hunters are useless (Score:5, Insightful)
While this is correct, this defeats the purpose of a Password Manager with an encrypted database.
If only access to a non-secured file on my PC is needed to read all my passwords, I could have stored them in a MS Word file from the beginning.
Re: Most vulnerability hunters are useless (Score:1)
Mod parent up!
Re: (Score:2)
If your device gets stolen, your passwords are still safe as this attack requires you to maintain access to your system. The file on your computer should be secured, you shouldn't let other people log in as you or have access to your private files.
Re: (Score:3)
If the configuration file can be modified by any non-admin user then it is a vulnerability. If only the user who owns the data or an admin can modify the config file (true if you follow Microsoft's recommended best practices on where to store such files) then the user is either attacking themself (not interesting) or an admin is doing it, and as stated the admin can do any number of things such as keylog the password to get at the data.
Microsoft's Raymond Chen has a blog series called "if only I was on the
Re:Most vulnerability hunters are useless (Score:4, Interesting)
> then the user is either attacking themself (not interesting)
Except that "the user" attacking themselves is the basis of almost all malware. Virtually all viruses, trojans, worms, etc.all start their infection as a program run by the user. For all practical purposes they *are* the user.
If the user is able to screw themselves over without confirmation then so can any malware, and your platform or program offers no meaningful protection against malware.
Discussions of security boundaries and and making a distinction between user and admin is significant for multi-user server scenarios, but almost completely irrelevant to single-user desktop systems. "Oh good, the malware hosed all my files and stole my banking information, but at least it didn't infect the OS or applications!" - said no desktop user, ever.
In this case the vulnerability *does* cross a security boundary - the one protecting the contents of the password database. Not all such boundaries are implemented by the OS. And you *don't* need to be an admin to edit the config file - it's just possible for users to set it up that way. If they know about this vulnerability, which let's be honest, most will not.
The real question here is why in the seven hells does a program whose entire purpose is to secure a database even have an option to automatically export an unsecured version of that database without user confirmation?
Re: (Score:3)
I don't quite see how this is that big an issue as well, if I have write access to your system simply replace KeePass with your own that exports the password when the user enters their password. This vunerablity just makes it easier for the attacker, but not by much since KeePass is open source.
Anyway once your system is compromised, they can grab your password and do what they want, weather its stored on the cloud or not. That is one of the reasons passwords suck.
Re: (Score:2)
Because on Windows at least "write access" isn't universal. For example, a normal user will not have write access to the KeePass binary without first going through a UAC prompt, because the ProgramFiles directory where it lives requires a higher level of access than their account normally has.
The configuration file, on the other hand, is in their personal config directory and someone with only low level access can write to it. A badly configured network share, or a compromise in some app run by that user, c
Re:Most vulnerability hunters are useless (Score:4, Insightful)
That analysis falls too short. An attacker with write access can already do a ton of things, including, for example, wrapping the application and thereby stealing the master password or tricking the user into giving UAC permissions. And that does not even include the countless possibilities for a local privilege escalation that Windows is basically defenseless against in practice.
I agree with the KeePass people: They can do nothing effective about this problem. And I applaud their willingness to, unlike commercial vendors, not do anything that looks good but does not fix the problem and to document the problem instead.
Re: (Score:2)
I would agree the threat here is pretty small. However I would characterize this as a vulnerability. Why because its an integrity failure.
Reality on almost all platforms getting code execution as an ordinary user and access to write THAT (not other users files) is generally a lower bar than access to Administrative functions, system areas of the filesystem or other users files.
A e-mail phish will get code execution in a user context and if you are not trying to escalate privileges isnt likely to trigger any
Re: (Score:2)
Well, I agree there should be better security, but I just do not see it. Unfortunately that MAC idea falls flat on a number of other attacks and basically only adds a false sense of security. If you really need security for some software with an insecure user account, you need to move that software out of that user account. Anything else is just misleading.
Re: (Score:2)
"Tricking them into clicking an unexpected UAC prompt... Well, that requirement alone seems like it makes it well worth fixing this bug so they have to go through yet another layer of security.
Re: (Score:2)
It is not a bug. It is functionality you think should not be there and thet the software designers disagree with you about. And I do not think you have a case.
Re: (Score:2)
Cumulatively I've wasted probably a year of my life arguing about not fixing vulnerabilities that require the attacker to have essentially already compromise the system. I've had vulnerability "researchers" point out denial of service attacks against wireless systems when the attacker can transmit data to the devices (or they could just generate noise and drown out the system), or attacks again IoT devices that require the attacker to be in your house for 30 minutes with hundreds of dollars worth of specialize equipment and to physically take apart my devices. There are real vulnerabilities out there and I will admit that sometimes a seemingly unremarkable issue can be coupled with another unremarkable issue and create something workable but the one in the article isn't one of them.
Its still a valid vulnerability.
You are seeing it as a low risk attached to this vulnerability.
Low risk doesn't mean that a vulnerability doesn't exist.
It just lets you prioritise other vulnerabilities ahead of this one as targets for remediation and mitigation.
Re: (Score:1)
Re: (Score:2)
Only for the configuration options that create a vulnerability that breach an additional layer of security. Like exposing all the passwords you have locked "safely" away.
Seriously, why the $%#@! does a program whose entire reason for existing is to keep your passwords safe even have an option to remove all that protection without any user confirmation? I'm trying hard to think of any non-malicious reason, and I'm coming up blank.
If you want to export things, fine, no problem, it's great that they have the
Re: (Score:2, Insightful)
Security should always be approached in layers. The idea is that even if one layer is compromised (and it should be assumed that at least one layer WILL be compromised), the other layers will at least partially protect what needs to be protected. No single layer is 100% secure. The argument that someone can replace the executable, the expertise level for developing a compromised executable is vastly higher that just changing a config file with the OS supplied notepad.
Saying "oh the PC is compromised, all is
Re: (Score:3)
Saying "oh the PC is compromised, all is lost" is a very nihilistic way of handling this issue.
Nope. The correct terms for this approach are "pragmatic" and "professional". If the PC is compromised while in use, "all is lost" is a realistic analysis of things. All your broken stance will be getting is some window-dressing "measures" that do not fix the issue. You know, MS-style. Because users ask for things they do not understand.
Re: (Score:2)
I have to say, I missed the condescending tone of slashdot comments...nowadays they don't do it like they used to do.
In your comment I see an opinion that is repeated again and again however I see no real counterpoint. The MS-Style comment is just an appeal to the old-school hate of microsoft with no real essence. In practice though security is flawed act of compromise which we usually try to be "secure enough" and hope that breaking the security is hard enough that nobody has the knowledge or time to do it
Re: (Score:2)
Well, calling something an actual expert does "nihilistic" is a good start on the condescending. I would even call it "exceptionally arrogant and insulting". Also "clueless" comes to mind. So I am not sorry in any way but rather think I used restraint.
As to
An automatic trigger of a plaintext password export through a config option is the dumbest sh*t you could ever implement in a password manager.
Nope. Some actual understanding of security models required. The reason you are not getting what is going on here is simply fundamental incompetence with regards to technical risk management. Oh, sorry, should I have called you "insight challenged" inst
Re: (Score:2, Interesting)
Malware exists, and it gets around quite well.
Which means that if you're doing *anything* security related (like making a password manager), your first assumption should always be that user-space has been compromised by malware. The user visits the wrong website, or opens the wrong Word file from an infected co-worker, and *BAM* malware is now free in their user-space. There's very little you can realistically do to protect user-space from infection. All it takes is a single vulnerability in a single pro
Re: (Score:2)
Re: (Score:2)
Well, and while we are wishing for things we cannot have, what about world-peace and a pony for everybody? It does make some sense to defend against generic (!) keyloggers and generic (!) clipboard monitoring software, because these are non-targeted, unspecific and often really low-skill attacks. Modifying the config file of KeePass is none of these and there is no way KeePass can defend against it, no matter how desirable that would be. Seriously. Security is not about wishing for things. Security is conce
Re: (Score:3)
Indeed. That seems to be what is happening here. An attacker with write access can already do basically everything, including wrapping or changing the application code. And then they can just steal the password when the user enters it the next time. Defending against something like that is not an application problem, because no application can do it.
Looks to me some people are trying to profit off the recent vulnerabilities in other password managers.
Re:Most vulnerability hunters are useless (Score:4, Informative)
The application code is usually going to be behind a much more reliable wall of security - you cannot modify an executable from user-space (well, not if installed normally anyway)
The config file though *is* writable by the user. You *could* put it behind an admin-only security wall, but then you can't save any changes to the program settings - which largely invalidates the purpose of having a configuration file in the first place.
Re: (Score:3)
What prevents a malicious attacker from putting their own executable in appdata and redirecting the user's shortcut?
Re:Most vulnerability hunters are useless (Score:4, Interesting)
I worked in a large social network. We did take in money and accepted credit cards as a payment.
Then PCI came along, we secured our systems (created a totally separate Cardholder Data Environment etc), and got audited. The CDE and procedures were fine, thus the auditors looked at our other interfaces as well, clearly out of scope for PCI or credit card security.
And found that we have a horrible USER ENUMERATION VULNERABILITY.
An attacker could, by brute force, find out if a user with given username exists on the system!!!!
This finding made it into the official PCI audit report and internal "shit to fix fast" lists.
We were a f'n social network. Connectivity, enabling people to find each other, was major rage. We had a genuine "find members of opposite memeber around you" search option.
And then comes up an auditor complaining that your users can find out if another person _exists_ on your "public by design" network.
Re: (Score:2)
Similar to a 1Password tradeoff (Score:1)
Sound similar to the logic in this vulnerability in 1Password. Still surprise me.
Thread "Why does 1password still install to the user’s local application directory?": https://1password.community/di... [1password.community]
The vulnerability is from a Cure53 report: 1PW-18-003 WP2: Windows malware can trivially backdoor .html and .js (High)
https://bucket.agilebits.com/s... [agilebits.com]
They do provide some manual mitigation since this year: use the MSI.
https://support.1password.com/... [1password.com]
Also reminds me of "On the Security of Password Manage
Who the hell is Chrispass2? (Score:1)
Solution: Encrypt the config nodes in the XML? (Score:2)
Wouldn't the best solution be to encrypt, at the minimum, the sensitive nodes of the XML config file? I can't think of any good reason to allow an external unauthenticated application to edit the KeePass config file.
Re: Solution: Encrypt the config nodes in the XML? (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why not just use Excel then? (Score:1)
Re: (Score:2)
Re: Why not just use Excel then? (Score:1)
Re: (Score:3)
Password managers are not magic and they primarily serve two main purposes
1. Use of different passwords for every single site
2. Use of passwords that are random, difficult to guess and difficult to crack but difficult to remember
They also have some fringe benefits in that it's a single place to go to store all your passwords and the automated inputting and autocomplete on login but ultimately they *ALL* suffer the same "flaw".
You can think of the parallel of a bank vault and passwords being money. You make
Re: (Score:3)
A system breach always means all data is vulnerable. You use KeePass for cases where, for example, your computer or storage medium gets stolen.
Sounds bad to me (Score:1)
Maybe I didn't understand correctly but how can anyone use keepass if that is the case?
I thought that by using a strong master password I was encrypting the database so that none would have access to it.
If all it takes is system access, that means I can just copy the kdbx file and and extract everything at my leisure on a machine I control.
How is this not terrible? It practically eliminates the main use case
Re:Sounds bad to me (Score:5, Informative)
The point is an attacker having write access to your system already eliminates the protection provided. Your database is protected against people having read access, getting copies of your files, etc. But if an attacker has write access to your system, then them being able to write to and change your configuration file means they have the same level of access as required to exploit any of a thousand other means of accessing the same information once you've unlocked your database. And the point is the same is true of any method of password storage besides memorisation. If they're stored on your computer, and an attacked has write access, this is not a KeePass vulnerability - you're already rooted.
However, I'm not in complete agreement with the developers. I understand why an enterprise user might want an option to export passwords from a database, and might for security reasons even want the ability to do so from an automated script out of the view of the current user who's just logged in. However, the functionality of Triggers [keepass.info] in KeePass which is utilised here has very little value to the average home user. I feel like there should be "Home" and "Enterprise" versions, where the Home version either omits it entirely, or at least protects the ability to export databases within permissions established when the database is created. Because such functionality makes it trivial for a 'trusted user' within your abode who has write access to your system to bypass your database security. Now, as devs are trying to point out, that's not a vulnerability because such a user has plenty of other methods at their disposal of achieving the same (such as compiling their own copy of KeePass with an exploit which mails out the passwords when the database is opened, etc), but let's be honest, the degrees of technical difficulty in doing so does differentiate.
So, a workaround is to simply use an implementation of the protocol which doesn't include functionality to automatically export your database in plain text if a local user decides that's what they want to do. I've tried various implementations, but KeePassXC is by far my preferred client, paired with KeePass2Android [github.com] on the mobile.
Re: (Score:2)
On the Mac side, KeePass XC is nice, but a third party client, Strongbox, supports 2FA, and it also has a very good iOS offering. The Strongbox devs cover a lot of bases with their product, and it is worth the price of admission.
The one thing I like about KeePass that other .KDBX compatible programs don't have, is the ability to specify password templates. For example, if I want something that generates phone number-like passwords, or Windows CD key codes. This way, I have randomness, but the passphrase
Re: Sounds bad to me (Score:2)
Uh, here's an idea... (Score:2)
Dear mainteners (Score:1)
Re: (Score:2)
Stop making excuses
Indeed, there is no excuse for unnecessarily increasing the attack surface; because of a feature that is enabled by default, yet is largely ignored by most users; when it might more safely be implemented with usage policies and disabled by default.
Those maintainers who refuse to consider this, when they are responsible for software that is part of a chain of good security practices, are being inappropriately light-hearted in the circumstances.
Re: (Score:2)
> unnecessarily increasing the attack surface
QFT
If you were a KeePass maintainer I would still trust the software.
Sounds like bullshit to me (Score:3)
A threat actor with write access to the target has already won and can do whatever they like. This is not an application problem and no application can defend itself against something like this. This is an OS and system problem.
The people that submitted the CVE are probably trying to profit off the other recent PW-manager vulnerabilities.
Seems legitimate (Score:3)
Re: Seems legitimate (Score:4, Insightful)
The scariest thing about KeePass is ... (Score:2)
... is that they still use SourceForge.
Really?
Low Impact (Score:1)