someone can read the passwords using export trigger

[Ivano Guerra]

A terrible problem !!!!!
the problem is not the file, but the application. Someone can save the password file into USB or into the cloud.. because keepass is very secure even if the file is unfortunately lost , but someone can get it and run hack into his PC in a very simple way

Absolutely it is needed a new file format incompatible with previous versions (and obviously a new version of keepass for this file that can import old file and save into the new format), that avoid this problem, as making impossible to export data in clear text with that bug. All password has to stay in a enclosed container and should not exit from here withoud explicit confirmation of the user with at least typing again the master password

[Guillaume H]

How would you access the database without an app ? Obviously an app is needed, and obviously again somone can temper this application or replace it by a corrupted one. The database is safe until you open it. If anybody steal your database, it can't be opened without your passphrase even using a corrupted version of keepass. The database is unsafe (i.e. the security drop down to the security level of the machine you are using) at the moment you open it. New database format would not solve the problem by itself as long as someone can get access to the program file directory.

[Ivano Guerra]

You are right !
I missed that export to clear text is possible only after opening the file !

[Jan Kratochvil]

I think for a lot of Keepass users this vulnerability is really critical. For example - imagine using Keepass in a corporate environment. That is, a situation where Keepass portable is installed and used by a user without admin rights on a company-managed PC. Then it is enough for the administrator of such a PC to modify the .xml config file and just wait for the user to use his Keepass. I hope that the authors will get over their egos, and release a quick fix without further defending and analyzing the situation. There are certainly many scenarios where Keepass is used on a PC where there is an admin account outside the control of the current user. Nowadays it is perhaps better to use a passworded Excel spreadsheet than Keepass.

[Guillaume H]

You should not use keepass on a computer you do not trust.
If you don't trust your corporate computer (and admins), don't use your personnal keepass on this computer.
On the other side, when you can trust the admin team they can install an enforced configuration of keepass and protect access to the files so any non admin user can't modify them. Plus they can install a policy in the EDR to track access attempts to keepass files so they can send alerts if someone try to break in.

[tempik]

The main issue is that KeePass tries to evoke in users it is very secure but it is not.
Why implementing memory protection etc. when protected DB can be easily exported in cleartext without user intervention?
I am not talking about hacked PC, imagine shared computer, where all users are admins. By trivial modification another user can, without noticing, export passwords from protected DB of different user!
For general user, they can't imagine such easy method of attack vector on their protected DB! They imagine, ok, another user can copy my DB file but without master password it is useless but it is not true! Why memory protection is implemented from memory dumps etc. when we can edit triggers easily, silently? Not attacker, it applies to any normal user, with privileged permissions.
Another attack vector is e.g. USB stick with KeePass portable and DB inside. Very easy to "steal" it for a while, edit XML as a normal non-privileged user, return back, wait some time, connect again, get cleartext passwords, without the DB owner knowledge!
There are millions of other vectors paths of DB export, how to steal passwords, no hacking required, no deep knowledge required.
DB is compromised with the default KeePass configuration and that is WRONG!
As others mentioned, using protected XLSX (AES256), data inside will be more safe as it is impossible to open the file without the password, with no option to mark it somehow to extract the content upon next opening... :-)

[Guillaume H]

Using keepass private DB on an admin shared computer isn't a good practice. You shouldn't use keepass to protect against other admins. You can use keepass on that computer to share passwords between admins of equal privileges
If you are in need of protection bewin admins maybe think of having an admin computer for each member of your admin team or think about throwable VDI (as soon you close the session the virtual machine is deleted and if you connect again you get a new one)

[tempik]

You don't understand what I tried to say.
If you will declare such behavior clearly on homepage so every user will know that it can't be used e.g. on shared computer as the encrypted DB is not protected in any way from some access (attack) vectors, than no one will complain.
Read it as: why implementing advanced protections against memory dumps etc. when anyone can edit unprotected xml to dump the protected DB silently?
I am sure there are majority of users they don't know it can't be used on shared PC or that DB with APP on USB stick is dangerous as anyone with the physical access to this stick can export DB easily (with the unwanted help of the DB owner).
From HOMEPAGE:

...manage your passwords in a secure way. You can store all your passwords in one database, which is locked with a master key. So you only have to remember one single master key to unlock the whole database. Database files are encrypted using the best and most secure encryption algorithms currently known (AES-256, ChaCha20 and Twofish)...

It evokes me that DB can't be brute-forced, dumped without knowing the master password but it is not totally true as it uses flawed design (bad default config) when DB can be decrypted via configuration file.
It is definitely bad implementation, without any doubt.

[Eddy D]

I am happy that this discussion has become more focused on what attacks we can and cannot expect KeePass to prevent.

But I am not so happy about the attacks that are being proposed. It seems to me they are very specific, i.e. in a particular scenario, where the attacker has exactly this permission but not that permission.

You can look up what Bruce Schneier calls "Movie Plot Threats" to learn more about this kind of thinking. The basic problem is that if we change the specifics of the attack scenario just a little bit, the proposed mitigation no longer works. In all of the proposed scenarios, the attacker has write access, and with just a little tweak to the assumptions he can easily bypass the protection mechanism that is being proposed here.

I do not believe this is at all a matter of "ego" (it's really a shame to use such words for a developer who is quite the opposite). This is a matter of sane security design. There is no good reason, and many bad ones, to add a "security feature" which does not answer a realistic and general threat model.

I would be very interested (but skeptical) to hear a realistic scenario where the attacker has write access that is truly limited to the config file and nothing else. If there is no such realistic scenario, it follows logically that preventing modification of config files, or disabling export of cleartext passwords, is just security theater.

[tempik]

Current design seems to me like super trooper encryption used to protect XLSX file,e.g. via user password but with the unprotected option in Excel app to decrypt file automatically upon loading the file and storing it in cleartext to disk, silently.
You can't decrypt DB or make a memory dump but why doing it when it is enough to say Excel to decrypt and save it automatically, silently?
As a guy working in IT security no one will convince me that this is the correct design for the application behavior. How it behaves now, with no option to block such attack vectors and such insecure behavior in default configurations is the issue which should be solved immediately in my opinion.

[Eddy D]

@tempik you are not the only KeePass user who works in IT Security. In fact I think KeePass appeals precisely to people who understand that Security is more important than flashy UIs.

I design Security systems professionally, and I respectfully disagree with your opinion. I applaud @dreichl for his excellent Security Engineering choices, and I really hope logic will prevail in this discussion.

[dad4all]

I think, it's as realistic to expect a hacker to modify the Keepass-Config-file to export all passwords...
...than any hacker would modify a "win.ini"-file allowing to export all Windows-AD-Passwords without prompting any user. I wonder, why Microsoft didn't invent that feature.

We shouldn't discuss about this backdoor in keepass, we should fix it.

[ichi123]

I don't understand how a developer can be so narrow-minded in such a matter.
Everyone is talking about malware, spyware, hackers.
You have all seen too many Sci-Fi movies.

What about the usual attackers?
The internal attackers?
What about the evil network administrator who wants access to the passwords of the hot accountant?
What about the storage administrator who wants to take a look at the financial accounting?

And what about the evil wife who, due to the media wave, now has the opportunity to access the passwords?

I can use AV software against keyloggers and spyware.
Against (legitimate) access to a config file, I as a simple user can do little.

Why does software that should contribute to security open up the possibility of spying on passwords to such a large group of people?

[BK834]

I think it should be classified as a phishing vulnerability.

There is no way to prevent someone from writing an exact lookalike client app, just to steal your password and/or export an unlocked database.

---

The limitations on enforced config, is that an attacker can just replace the shortcut file used to launch keepass, or the keepass exe itself. It becomes file integrity whack-a-mole.

Only an external file integrity monitor can really protect against this.

If keepass were to try and do this, people might somehow get a false sense of security.
I agree, it shouldn't be so easy that it requires no skill.

But the feature requests and offered solutions aren't going to solve the problem. If an attacker can replace the keepass client binary, they can bypass any check for exportability, and do anything else.

Web browsers are similar. If an attacker can access the filesystem, they can MITB, steal sessions, etc.

I think this may be overblown solely from the misunderstanding from people who think that the config file is the database file (often stored in the cloud).

---

Brainstorming a PoC:

1. Script that searches for all lnk files in the user profile directory.
2. Finds any keepass shortcut.
3. Copies location of keepass app dir to the writeable user profile temp dir.
4. Replace keepass.exe with older version.
5. Modify the config xml to allow export and triggers, and adds a trigger to export on open.
6. Replaces the shortcut destination to the new location.
7. Adds a scheduled task to upload plaintext csv file to attacker webserver.

Enforced Config won't protect against this.
And any and all updates to Keepass itself won't work either since it just uses a downgraded keepass to phish the entire database.

BTW, if I did this with Chrome or Firefox, I could also change all the bookmarks and/or MITB access to online password managers or banking sites.

The best way to mitigate is to set up enforced config and always navigate directly to the keepass app directory in Program Files and never rely on shortcuts if you don't trust your own user profile. The vulnerability will still be there, but at least will require Admin.

---

So the only Real solution I see, goes back to what I said earlier about external file integrity.

First, KeePass devs will need a new version of keepass.exe that completely removes the "export without re-key" feature. Then KeePass will have to revoke the certificates used for digital signatures of their binaries and issue new ones. So Windows will warn users when they execute an old version.

Do you think this will solve it?

[Guillaume H]

That won't solve it. That won't protect form an attacker who can fool a user to use a corrupted version correctly signed. Don't need to be signed with the same cert, only need to be signed with a valid cert.

[BK834]

Requiring an attacker to get their own valid cert is definitely a good security control.
It puts the responsibility onto Windows, the Domain Admins, and the User... and off @dreichl.
Those of us with concerns about this kind of attack, could now use Windows built in tools to alert or block suspicious applications (like an old version of keepass) as a PUP.

[dad4all]

I'd suggest to call it "backdoor" which enables fishing?

For me, there is no difference to routers listening at hidden telnet/rpc/you name it ports and hard-coded passwords.

It's not a bug, since it's documented - it's no feature either since 100% of all users don't use it - users are unaware of the functionality and it compromises security => it's a backdoor.

[dartraiden]

If an attacker can change the executable file, nothing will save you. 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.

Even if these code will be removed from KeePass attacker can add it back, compile his own KeePass.exe and replace executable.

[BK834]

This is where application whitelisting can absolutely save us.
Attackers are known to trojanize apps that users are using. A password manager app is the crown jewels and makes a tempting target.

So admins have fought this threat by only allowing applications signed by a whitelist of certs, to run. Even just a warning instead of a full block, would be enough for a user to think twice about unlocking a database of passwords.

But with Keepass, the "export silently" feature/backdoor... exists natively in the trusted code that is already signed by @dreichl .

The only way forward is to treat Keepass, and everything signed by Dominik as an untrusted PUP. Use KeepassXC, and whitelist "DroidMonkey Apps, LLC".
This way, an attacker's own compiled code will fail to run or alert the user.

[Jan Kratochvil]

I think it will either be resolved very quickly or it's over for Keepass.

I also think that the majority of users who use Keepass use it because Keepass has a very good reputation in general, they use it at work, at school, generally on PCs that will never be under their exclusive control. There is no point talking about any trust in the administrators of such PCs.
As has already been said here, if the authors believe that this is the only possible correct approach, then it would be fair to make this clear on the Keepass home page.

KeePass is a free open source password manager, which helps you to manage your passwords in a secure way. You can store all your passwords in one database, which is locked with a master key. So you only have to remember one single master key to unlock the whole database. Database files are encrypted using the best and most secure encryption algorithms currently known (AES-256, ChaCha20 and Twofish).

ATTENTION!
Keepass is designed so that it cannot be used securely on a PC that is not under your exclusive control. If there is another account on "your" PC with administrator privileges (PC at work, school, friend's PC, shared PC within the family) it is possible to export all your data from the Keepass database without your knowledge and without knowing the master key. This is the expected behaviour and the Keepass application is designed to allow such functionality.

[rpr]

Could someone explain the claim that it is possible to export all data from the Keepass database without knowing the master key?

In https://cve.cert.hr/cve/CVE-2023-24055 I read: "KeePass through 2.53 (in a default installation) allows an attacker, who has write access to the XML configuration file, to obtain the cleartext passwords by adding an export trigger."

KeePass triggers are explained in https://keepass.info/help/v2/triggers.html
I see that there is a possibility to define the following trigger:
after event "Opened database file" do action "Export active database"
It means that after user opens a database file, which requires him to provide the master password, KeePass will export the database to a file. I don't see a possibility to do such an export without knowing the master password.

BTW, the triggers are saved in the KeePass configuration file (KeePass.config.xml) and so they can be manipulated by anyone having access to the user's profile.

[steelej]

As I understand it the problem is that the configuration file containing the triggers could be modified by another user who has sufficient access privilege to modify the file containing the trigger information outside of KeePass. Modifying this configuration file does not need the KeePass fle master password.

The trigger can only run when the Keepass user opens the KeePass file with their password (plus other credentials if being used) and KeePass will then silently run the Export trigger that could save the KeePass data to a simple text file where it could later be accessed by the malicious user.

For those of us using a computer as a single user this should not be a problem unless you leave your computer unlocked. It is however a possibility when some other person has admin rights to your computer (which can happen for example in a corporate environment) or has access to your computer while it unlocked before the main computer password lockout timer kicks in. Then they could access, and edit, the configuration file without the KeePass database file being unlocked. The next time KeePass is unlocked it will extract the data.

[BK834]

Well, there is KeePass the official client software, and there is keepass the standard format.
There are other clients out there. It may be the end for this version.
If someone starts using a different app, with a different look, they avoid this issue.

[Guillaume H]

Apps are open source, easy to port exporting to them. Plus, if you're using a corporate computer you have no admin rights, you can only use what admins have installed on your computer.

[BK834]

you can only use what admins have installed on your computer.

Exactly my point. If there were a version of keepass that did not have this easy to abuse feature, the admins can just install that safer version and block any other version as a PUP.