I get what you're saying Dominik, and I agree with you. There are countless other ways a compromised environment can target a password manager. Expecting KeePass (or any password manager) to be immune in such situations is unrealistic.
I merely provided an alternative for OP. Even if that alternative is not vulnerable for this specific attack, a compromised PC can and will find other ways to steal his passwords. But similar to how KeePass protects against keyloggers, this would be one thing less to worry about for OP.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spyware or PUPs can be caught by AV or EDR. That's a fight that Windows admins have to fight.
But when you make the attack surface so wide and easy, that non-privileged code need only change a single config file, or also maybe a shortcut file too... that is not acceptable.
Having this "Export - No repeat Key" feature can be considered a spyware backdoor. It does the attackers job for them. What people are asking is for a new version of KeePass without spyware built in. Nobody legitimately needs that feature. With a new version, Windows admins can just label your old vulnerable versions as a PUP, so downgrading would be harder.
👍
4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are different levels of access. 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 you mention 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.
👍
2
🎉
1
Last edit: BK834 2023-02-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is the most sensible post in this entire discussion, and I agree wholeheartedly. Thank you for your accurate description of the situation.
It's outrageous that the KeePass team doesn't see the nuances (as far as I've read this thread), but choose to live in a black and white world. If a simple change in a human-readable and -writable config file can lead to my entire encrypted database to be dumped in plain text, this is a huge deal.
This "feature" should either be removed, or at least be protected by the master password. There should not be a setting to turn off the master password protection if the "feature" is kept around.
On another note, happy birthday to your post, it's exactly 1 year old!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took a look at KeePassXC. They have an option called KeeShare, and the settings for it, including the private key of the machine, are stored in a config file(...)
Edit:
It seems like the KeeShare settings I mentioned are deprecated and will be deleted soon. KeePassXC seems like a solid option if you're worried about this CVE.
👍
2
Last edit: Sergiof 2023-01-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But KeeShare is disabled by default and the real user must first set it up explicitly after unlocking with the key.
I was also worried about keepassxc-cli, which has an export feature that can run in the background. But it still requires the key to be typed into the command line. So not as bad as piggybacking on the main UI unlocking process.
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah. Not sure if most people know this. Very different philosophy on security.
Does KeePassXC support (KeePass2) plugins?
No, KeePassXC does not support plugins at the moment and probably never will. KeePassXC already provides many of the features that need third-party plugins in KeePass2 out of the box, so for most things you don't even need plugins, nor should you ever want them. Plugins are inherently dangerous. Many KeePass2 plugins are barely maintained (if at all), some have known vulnerabilities that have never been (and probably never will be) fixed, and none of them are as thoroughly tested and reviewed as we test and review code that goes into our main application. We find that encouraging users to install untested (and often quickly-abandoned) third-party plugins is inherently incompatible with the security demands of a password manager.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From all my current reading if the attacker has access to your system already it's already to late for any security actions. All they need to do is copy your keepass database which has no Master password login and that is all they need to break your security logins saved in the keepass database. And once they got that it's all ready to late they don't need to do any sophisticated xml once they have your UNsecured database for them to freely gain your login site access.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if the attacker has access to your system already it's already to late for any security actions.
There should be a statement like this in inch-high type on every page on keepass.info. There are too many ill-informed KeePass users posting here, trying to implement procedures that amount to locking the barn door after the horse has already got out.
👍
1
👎
3
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adding an additional layer to the security isn't "locking the barn door after the horse has got out". Is there no point in forcing the attacker to perform more intrusive actions, like injecting modifications into the executable or having to download a malicious version of keepass?
The more noise the attacker has to make, the easier it is to detect the attack, both for the sake of a forensic investigation in case it is already too late, and for the sake of setting off the alarms before it's too late.
❤️
2
👍
3
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In this case, if I have a great antivirus, a great windows configuration and a great encrypted disk : then I can protect a plain text file. So why do I need keeypass ?
You will also tell me that hashcoding passwords on a server is useless because the system is supposed to be secure, or why I don't have to enter a code on my credit card because I'm supposed to keep it protected in my wallet
Allowing silent export to plain text without asking for confirmation : I think keepass can avoid that. Unless it is intentional to keep this feature :-o
👍
3
❤️
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried for years to convince Dominik to implement a solution for this, even opened a feature request for an 'essential' version where plugins\configs are not available: https://sourceforge.net/p/keepass/feature-requests/2704/
You're wasting your time, Dominik has stated that he would not do that.
We have to respect that as KeePass users even if we disagree.
😕
6
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What about Dominiks statement about an essential version ?
He said:
"With an essential version, it would basically be the same: if the user ignores the essential version, gets and runs the full version instead, the limitations of the essential version are irrelevent"
So everyone which has a copy of your database
will be able to use a full version without any restrictions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With 'essential' version, users\organization can choose to use this safer but more limited version, are you suggesting malicious swap of that version with the regular one?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What? you're making no sense.
The database itself isn't the issue. I can send you my database right now with zero worries.
The worry is that when a benign user opens his database, he is more exposed to attacks with the current version, it has nothing to do with getting the database itself.
I linked some tools there, you can look and see how they work:
you get access to a system
you set up a 'trap' like a trigger or malicious plugin
you get the data without ever knowing the master-password
👍
1
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's the threat scenario. If an attacker has write permissions on your user profile, they can swap the executable for one with the ability to export invisibly.
I can see how Dominik doesn't want to bother with a half solution that won't work.
The only way to really do what that feature request was asking, is to completely revoke the digital signatures of the existing versions with that "Export - No Key Repeat" function. That way Windows itself will warn the user if an attacker replaced the binary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But many people do not know (or talk about) the silent export feature and continue to post :
this question : "Can Keepass database be hacked using brute force ? If someone (sys admin/colleague/hacker) obtained (...) Keepass database, can the database be hacked using brute force? " (www.reddit.com)
or partial solutions, I mentioned it here : https://sourceforge.net/p/keepass/discussion/329220/thread/a146e5cf6b/#49c2
There should be clearer information on the first page of the keepass web site instead of "first page > security > last item : security issues > then Write Access to Configuration File".
And you can read "(..) 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 (..)"
which must be interpreted as : "an attacker can read all your passwords in clear text"
The documentation only talks about programs : "add malware", "replace the "KeePass.exe" file by some malware"
But the stantard 'silent export' feature does not require a malware that an anti virus could detect, you just need notepad.
There is also a lack of information.
👍
4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think those using Keepass should know why they are using it already and if they aren't using Master Password to lock the database then one is asking for trouble. It's not up to Keepass to police users behaviour if they don't protect their own database.
👎
3
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you set up a 'trap' like a trigger or malicious plugin
you get the data without ever knowing the master-password
The place to stop this sequence of events is at #1. Protecting against #2 & #3 is pointless, because once #1 occurs, there are a zillion ways for the Bad Guys™ to pwn you from there, with or without KeePass's unwitting help.
👎
4
Last edit: T. Bug Reporter 2022-12-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be nice if the official KeePass executable wasn't an accomplice to the data exfiltration, wouldn't it?
I fail to see how there is no point in preventing KeePass itself from exporting all passwords without notifying the user of the actions that are about to take place and asking for the master password as confirmation.
If the attacker had to deploy malware to perform these actions, which is the only other way I can think of to perform this attack, most computers have software capable of detecting and stopping the attack (an antivirus).
👍
4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Neither KeePassXC nor any other password manager is secure if you are running spyware or allow an attacker to write to files on your PC.
https://keepass.info/help/kb/sec_issues.html#cfgw
https://keepass.info/help/base/security.html#secspecattacks
Best regards,
Dominik
I get what you're saying Dominik, and I agree with you. There are countless other ways a compromised environment can target a password manager. Expecting KeePass (or any password manager) to be immune in such situations is unrealistic.
I merely provided an alternative for OP. Even if that alternative is not vulnerable for this specific attack, a compromised PC can and will find other ways to steal his passwords. But similar to how KeePass protects against keyloggers, this would be one thing less to worry about for OP.
Spyware or PUPs can be caught by AV or EDR. That's a fight that Windows admins have to fight.
But when you make the attack surface so wide and easy, that non-privileged code need only change a single config file, or also maybe a shortcut file too... that is not acceptable.
Having this "Export - No repeat Key" feature can be considered a spyware backdoor. It does the attackers job for them. What people are asking is for a new version of KeePass without spyware built in. Nobody legitimately needs that feature. With a new version, Windows admins can just label your old vulnerable versions as a PUP, so downgrading would be harder.
There are different levels of access.
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 you mention 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.
Last edit: BK834 2023-02-07
This is the most sensible post in this entire discussion, and I agree wholeheartedly. Thank you for your accurate description of the situation.
It's outrageous that the KeePass team doesn't see the nuances (as far as I've read this thread), but choose to live in a black and white world. If a simple change in a human-readable and -writable config file can lead to my entire encrypted database to be dumped in plain text, this is a huge deal.
This "feature" should either be removed, or at least be protected by the master password. There should not be a setting to turn off the master password protection if the "feature" is kept around.
On another note, happy birthday to your post, it's exactly 1 year old!
The change you describe has been made, 7 months ago.
cheers, Paul
I took a look at KeePassXC. They have an option called KeeShare, and the settings for it, including the private key of the machine, are stored in a config file(...)
Edit:
It seems like the KeeShare settings I mentioned are deprecated and will be deleted soon. KeePassXC seems like a solid option if you're worried about this CVE.
Last edit: Sergiof 2023-01-31
But KeeShare is disabled by default and the real user must first set it up explicitly after unlocking with the key.
I was also worried about keepassxc-cli, which has an export feature that can run in the background. But it still requires the key to be typed into the command line. So not as bad as piggybacking on the main UI unlocking process.
Yeah. Not sure if most people know this. Very different philosophy on security.
From all my current reading if the attacker has access to your system already it's already to late for any security actions. All they need to do is copy your keepass database which has no Master password login and that is all they need to break your security logins saved in the keepass database. And once they got that it's all ready to late they don't need to do any sophisticated xml once they have your UNsecured database for them to freely gain your login site access.
There should be a statement like this in inch-high type on every page on keepass.info. There are too many ill-informed KeePass users posting here, trying to implement procedures that amount to locking the barn door after the horse has already got out.
Adding an additional layer to the security isn't "locking the barn door after the horse has got out". Is there no point in forcing the attacker to perform more intrusive actions, like injecting modifications into the executable or having to download a malicious version of keepass?
The more noise the attacker has to make, the easier it is to detect the attack, both for the sake of a forensic investigation in case it is already too late, and for the sake of setting off the alarms before it's too late.
In this case, if I have a great antivirus, a great windows configuration and a great encrypted disk : then I can protect a plain text file. So why do I need keeypass ?
You will also tell me that hashcoding passwords on a server is useless because the system is supposed to be secure, or why I don't have to enter a code on my credit card because I'm supposed to keep it protected in my wallet
Allowing silent export to plain text without asking for confirmation : I think keepass can avoid that. Unless it is intentional to keep this feature :-o
I've tried for years to convince Dominik to implement a solution for this, even opened a feature request for an 'essential' version where plugins\configs are not available:
https://sourceforge.net/p/keepass/feature-requests/2704/
You're wasting your time, Dominik has stated that he would not do that.
We have to respect that as KeePass users even if we disagree.
What about Dominiks statement about an essential version ?
He said:
"With an essential version, it would basically be the same: if the user ignores the essential version, gets and runs the full version instead, the limitations of the essential version are irrelevent"
So everyone which has a copy of your database
will be able to use a full version without any restrictions.
With 'essential' version, users\organization can choose to use this safer but more limited version, are you suggesting malicious swap of that version with the regular one?
Yes, thats the way an intruder may work on his own system
with the copy of the database.
What? you're making no sense.
The database itself isn't the issue. I can send you my database right now with zero worries.
The worry is that when a benign user opens his database, he is more exposed to attacks with the current version, it has nothing to do with getting the database itself.
I linked some tools there, you can look and see how they work:
you get access to a system
you set up a 'trap' like a trigger or malicious plugin
you get the data without ever knowing the master-password
That's the threat scenario. If an attacker has write permissions on your user profile, they can swap the executable for one with the ability to export invisibly.
I can see how Dominik doesn't want to bother with a half solution that won't work.
The only way to really do what that feature request was asking, is to completely revoke the digital signatures of the existing versions with that "Export - No Key Repeat" function. That way Windows itself will warn the user if an attacker replaced the binary.
Yes, my request has also been closed : https://sourceforge.net/p/keepass/feature-requests/2773/
But many people do not know (or talk about) the silent export feature and continue to post :
this question : "Can Keepass database be hacked using brute force ? If someone (sys admin/colleague/hacker) obtained (...) Keepass database, can the database be hacked using brute force? " (www.reddit.com)
or partial solutions, I mentioned it here : https://sourceforge.net/p/keepass/discussion/329220/thread/a146e5cf6b/#49c2
There should be clearer information on the first page of the keepass web site instead of "first page > security > last item : security issues > then Write Access to Configuration File".
And you can read "(..) 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 (..)"
which must be interpreted as : "an attacker can read all your passwords in clear text"
The documentation only talks about programs : "add malware", "replace the "KeePass.exe" file by some malware"
But the stantard 'silent export' feature does not require a malware that an anti virus could detect, you just need notepad.
There is also a lack of information.
I think those using Keepass should know why they are using it already and if they aren't using Master Password to lock the database then one is asking for trouble. It's not up to Keepass to police users behaviour if they don't protect their own database.
When did we ever say that you don't have a master-password?
These can bypass your master-password, that's the whole point...
The place to stop this sequence of events is at #1. Protecting against #2 & #3 is pointless, because once #1 occurs, there are a zillion ways for the Bad Guys™ to pwn you from there, with or without KeePass's unwitting help.
Last edit: T. Bug Reporter 2022-12-24
Is that so? what's the point of KeePass if it doesn't do its due-diligence in protecting the user? how is it different from an excel sheet?
This is a moot point because KeePass already implements so much to protect a compromised host. let's look at a few:
Secure Deskop - https://keepass.info/help/base/security.html#secdesktop
Memory Encryption - https://keepass.info/help/base/security.html#secmemprot
Autotype Obfuscation - https://keepass.info/help/v2/autotype_obfuscation.html
All these features are only viable when you have access to host, hypocrisy at its best
It would be nice if the official KeePass executable wasn't an accomplice to the data exfiltration, wouldn't it?
I fail to see how there is no point in preventing KeePass itself from exporting all passwords without notifying the user of the actions that are about to take place and asking for the master password as confirmation.
If the attacker had to deploy malware to perform these actions, which is the only other way I can think of to perform this attack, most computers have software capable of detecting and stopping the attack (an antivirus).