someone can read the passwords using export trigger

[tempik]

Not all corporate admins lock users running the approved apps only. You don't need admin access to the computer, you can use portable KeePass locally or from USB stick and it is widely used scenario. The main issue is the user is kept unaware that there is such a risk, easy path how to get unencrypted DB, without any hacking skills and this is the main problem. It seems to me general use case is KeePass usage on unprotected, foreign PC,etc...
Nobody is talking about the option to replace .exe with modified version which is much harder task for general user. It can't be compared by trivial modification of text file.
Understand, it will not be easy to make a bullet-proof solution but better to go half-way than give up any attempt at resolution.

[Squeller]

The findings are laughable. "Someone has more control over the computer than you". That's already bad. Modern audiences have no clue about Cryptography, they just want to use stuff in ecosystems of, to them, unknown security.
I recommend Dreichl to just add some encryption scheme to config files so they do not hurt our ears any more by their screaming.

[Jan Kratochvil]

So it would be enough if at least these, if not all settings were inside the database and not in an external xml file.

[BK834]

I don't think that it is possible to put settings inside the database. The client binary could just ignore it once the database is decrypted. The only possibility would be to add an additional key required to decrypted the database, that is contingent on the integrity of the client app and configuration. But that would break all portability.

[Dominik Reichl]

On configuration encryption:

1. You could put the portable version of KeePass into an encrypted file container (e.g. VeraCrypt), such that everything (KeePass application files and the configuration file) is encrypted.
2. You could turn on EFS encryption for the configuration file (by right-clicking onto the 'KeePass.config.xml' file in Windows Explorer → 'Properties' → button 'Advanced' → option 'Encrypt contents to secure data'). KeePass respects this (i.e. the file stays encrypted when KeePass updates it).

However, neither of these two approaches increases the security against an attacker who has write access in your user profile directory (and storing the configuration in the database file also would not, as mentioned already).

Best regards,
Dominik

[Jan Kratochvil]

Yes, that's true, it won't increase the security (maybe it will make it a bit more complicated).

We can try to talk about it, maybe it will move the discussion a bit, because I still think this is a problem to be solved, not that it isn't.

Let's stay with the example I mentioned, where there is another admin account on the PC, i.e. a PC on the company network. The administrator of such a PC can quietly export data from the Keepass database without any effort, without knowing the master key and without the user's knowledge. Encryption of the disk by the user or creation of a TC (TrueCrypt) container does not increase security, because at the moment when the filesystem / TC container is connected, the administrator can again read everything he wants. Now, let's stick to "read everything" - I'm talking here about a trivial access to the filesystem and the possibility to read a plain text file. Here it is simply a glaring fact that other advanced protections are implemented, but not this basic one. I think that this is the point that needs to be addressed, because if I exaggerate a bit and stick to the above scenario, the use of Keepass as presented here is basically equivalent to the user entering his data into the plaintext directly. Everything else is just a blur around, I believe that the user thinks that his data is safe, he has a PC in perfect condition, under the management of IT experts, no virus/malware.

You don't really see this as a problem ?

Why do you resist implementing protection against this kind of abuse ?

Or should all users in the example I gave migrate their DB to Keepass 1.x, where there is no trigger/export ?

Of course, there is still the possibility to try to read the data on such a PC in a much more advanced way when Keepass is running and the DB is unlocked, or to implement malware / keylogger etc., but let's leave that aside.

As I wrote, in that scenario, which I think is very widespread, the use of Keepass is basically useless. Besides, the potential abuse is very easy to do.

[Guillaume H]

Imagine you're an admin in such a corporate network, wouln't it be as easy to replace keepass exe by a modified one than modify the config file ? After all it's open source, everyone can rebuild a modified exe so you can builtin the trigger (find the trigger test and replace it by a "true" condition).
I you can't trust admins, you should not use corporate computer for anything not related to your job.
There are mobile apps which can use kdbx files, and you can use keepass on your personnal computer. Maybe you can better trust you own devices.

[BK834]

Trusting admins is a different threat level than trusting code run as a user.
It is far more common for an attacker to first gain low level privileges. If they can run a simple script as the user, as I describe above, they can get the entire plaintext database.

The scenario is that admins can be trusted, but regular users should not be trusted.
In that case, if a new keepass version comes out (without the unnecessary feature of "export without re-key"), and is signed with a new cert. Admins can revoke trust of the old version's cert as a PUP. This will actually eliminate this particular risk. And best of all, shifts the responsibility away from @dreichl and onto Windows and its admins.

[Jan Kratochvil]

Yes, I can imagine that quite easily and no, it's not really the same.

To get the data from all the Keepass DBs on the network he manages (he has admin access to all the PCs), all he needs now is a notepad. No one will know anything, everything will be done in the background, it is enough if he waits a while...

This is so easy, incomparably easy with what you mentioned. Why replace Keepass with your own code to get the data, to deal with signing, antispam, etc., when the existing Keepass application has everything already in place, ready and carefully documented ?

I understand the author doesn't want to program another lightweight version of the application that won't have trigger/export functions because it doesn't solve the problem (such a version exists - Keepass 1. x), I also understand that he stands for the fact that if someone has admin access to another PC he can implement any other means to gain access to the data stored in Keepass, but I don't understand why not go the other way and simply remove such an easily removable vulnerability from my point of view.

Why ?
What's the point ?

Surely no one will continue to use Keepass on a PC that has another admin account whether the user knows it or not ?

I think that's exactly what a lot of people would appreciate and it's exactly why they want to use an application like Keepass.

[steelej]

The issue being discussed in this long thread may not be an issue for many users of KeePass. Do we know how many users actually use the Export trigger. I didn't even realise that this existed and I have been a daily user of KeePass for very many years.

Assuming it is a relatively rare need would it be possible/sensible to add an enforced configuration option (outside of the Trigger configuration settings) to explicitly actively permit this trigger to be enabled and perhaps also have a parameter that gives (or suppresses) a warning message to a user that the database is being exported together with the destination file name and folder to confirm the export?

This could stop all all exports other than that explicitly configured by an admin with update access to the enforced configuration.

[Jan Kratochvil]

Then I hope that in all the years you have been using Keepass you have never used it on a PC where there is another admin account than yours, because you would probably never notice that your data is no longer just yours...

And yes, what you say would be the way I think the situation should go.
Perhaps the author of the application himself will change his mind.
I hope so.

[BK834]

Not sure how many people understand that this keepass app is one of many. And is the only one with this vulnerability. Other apps have a different philosophy to 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.

[Alan78673]

I use KeePass on my corporate work computer and only keep work related passwords in the database. But any admin could edit the config file (or the enforced config file), have KeePass export all of my passwords the next time I open it, and then edit the config file back. I would never know my passwords were compromised. This makes KeePass useless for any work/corporate environment.

[Jan Kratochvil]

Exactly.
There will be hundreds of scenarios like this.

[BK834]

Switch to KeePassXC and have your admins add @dreichl's digital signature to the revocation list.

[BK834]

KeePassXC doesn't have this feature (Trigger on Open, Export silently without repeating the Key).

However, they do have a CLI program that can basically do the exact same quiet export. It's a bit more difficult than someone just editing your config.xml to add a trigger automation.
It would require writing a wrapper script in powershell that will launch the GUI KeePassXC but stealing focus to the terminal running the script. So when the user sees the GUI window, they don't know they are really typing the password into the script.

It's still phishing and living-off-the-land. Same attack, but with extra steps.
Although it'll be really hard to do this kind of user input redirection without an attentive user typing a long passphrase, to know something is wrong. A full keylogger would be needed to be really stealthy. And those should be picked up by AV/EDR.

[Thomas J Howard]

The actual security landscape is much more complex than just the range of technically possible attacks.

There are quite many scenarios mentioned in this thread and it is very hard to discuss them all in fine detail, but I wanted to point out couple things.

First, the obvious. There is a huge difference between an attacker having to modify one XML config file in users profile, and modifying any OS files, injecting DLLs, reading process memory, etc. The fact that he might be able to does not mean that it is a good strategy, or that he would want to.

First of all, having access to user profile does not automatically mean having access to the passwords in a database, or, rather, it shouldn't. Profile can be edited and read offline, while the database is locked, by an attacker (regardless if it is inside or outside threat) that has access only to user files on a network share. This might not be flashy and require some patience (e.g. modify XML, wait for passwords to appear), but is effective nonetheless. This is an example of an attack vector that does not require executing any code by an attacker. And executing code is almost always noisy (which is why I will be mentioning that quite a lot)
Unless I am missing some big flaw in how OS and KeePass works, then obtaining the passwords requires actions to be taken by an attacker. A lot of those action will actually look suspicious to any half-decent security software and many will cause audit entries, which might be red flagged.

The insider threat from OS Admin is real and no security-aware company ignores that. It is being dealt with in many ways, but most prominently, with auditing. Properly deployed security relies on layers and layers of measures, hard technical ones as well as monitoring. Properly configured corporate (but also home if you know what you are doing) system will allow executing code only from approved sources (Windows AppLocker/SRP). This means, that the only usable KeePass will be the one provided by the administrator, in a directory that cannot be written to by regular users. What it also means, is that the modifications of critical security software, which KeePass qualifies as, will be (or should be, but for sure CAN be) monitored by Security team. If Windows Admin modifies the local KeePass files, outside of the normal software management procedure, this should be regarded as a security incident and an alert should be raised in SOC. This is one huge security layer that I think many in this thread are forgetting. Does it make it impossible to do so? No, but it leaves traces, raises red flags and gives the organization the ability to respond. Accounts can be locked, passwords reset, users can be notified.
Administrator can install keylogger, memory dumping, dll injecting software on the PC we are using, sure, but doing so in a way that will not be detected by security agents, that will not leave audit trails and will not raise alerts is another story.

Having a highly automated environment, with minimal manual intervention done by admins means that any change done to single computer is an outlier and there is a real possibility of someone asking questions. It also means that any change that is company-wide will be quite visible and there are many layers of verification involved.

If we assume, that we can trust the KeePass software on the host, then having a way to block exports from database (by having a database-local switch, similar to what windows does with private keys) would be an increase in security as it would make it impossible or at least harder to execute an attack having just ability to modify user config files. And making things harder for the attacker is actually what "security" means. Nothing is impossible, to a properly motivated attacker and hence nothing is 100% secure. What we can do, is increase the costs of an attack and force attacker to generate more noise, hence increasing the chance of being detected, and leaving more information for post-incident analysis.

The question is, can we actually make this assumption? I am pretty sure that we have to at some point. If we cannot assume that basic OS mechanisms work, then if the system has any exposition to any potential attackers, then we have to consider it compromised. And, aside from perfectly air-gapped, underground, systems without any external connectivity, it is just unrealistic.

To be more generic - if we want to steal user passwords from a database, we need some code to extract the passwords or get the encryption key. Currently, this code is embedded in our trusted application, which means an attacker does not even have to risk any significantly more risky techniques.

What most likely will be regarded as completely normal operation and will not cause any red flags? User (or rather userspace program) modifying the contents of XML config file within profile and KeePass exporting all passwords to a text file. This actually only requires the attacker to overwrite a regular user file (which is nowhere near code execution), and then reread a contents of another file. There were browser-base JavaScript attacks that allowed for modification of user files and download of user files. No OS-level code execution was possible, and yet, that would potentially be enough to compromise a KeePass database.

At the same time assuming that if attacker has ANY access then he has ALL access is just plain wrong. A successful attack has several privilege escalation steps, where an attacker gains higher and higher access. Dumping a KeePass database sure sounds like an awesome place to start. Security software monitors the usage of "hacker tools" and techniques that would allow dumping windows credentials from memory. Do you think that this is completely pointless? Because arguing for keeping the current KeePass behaviour is logically directly opposite. And I have seen first hand such rules thwarting an attack.
Attacker can sometimes have technically quite extensive access and yet be very limited in what he can do to accomplish his goals. Quite often those limitations do not come from just technical capabilities.
You can have full administrative privileges on a host, but if you try messing around with a security agent you are risking getting noticed. And without killing the agent, without disabling windows event logs being forwarded to SIEM, you can't really start running around dumping memory, running mimikatz and other tools. Because you might get noticed.

Security is built in a similar fashion that an ogre is - it has layers. We make it harder for an attacker to do "stuff" and remaining unnoticed at the same time.
I believe that both in home and corporate environments having the ability to export a crucial security asset (KeePass DB) by only editing one XML file is facilitating number of attacks which would not be possible in other case. This means that it effectively lowers the maximum achievable security.

While I understand, that it is possible to disable the triggers using enforcing config file, I do not consider this to be in line with "secure by default" approach. Requiring additional steps from user/administrator to disable a feature that can be used by an attacker to compromise your database does not sound very security-oriented to me. And I would rather not have this feature at all in a software that is critical to the security of many of my accounts.

[Dominik Reichl]

If you want, you can disable the trigger system, export commands, plugins and/or other features that you consider to be dangerous using an enforced configuration file:
https://keepass.info/help/kb/config_enf.html

The enforced configuration file must be stored in the application directory (i.e. the directory in which 'KeePass.exe' is stored). If the advanced network that you're describing (with auditing, monitoring, security agents, many layers of verification, ...) does not allow a proper protection/monitoring of files in the application directory (!), then the network isn't that advanced...

When introducing an application into a highly locked down network, I consider it to be the responsibility of the administrators to research what lockdown capabilities the application has and use the ones that they want (and in my opinion, the documentation of KeePass' enforced configuration is easy to find; it's linked from multiple pages).

Best regards,
Dominik

[Nick Zh.]

I'm sorry, Dominik. but to disable password-less export by trigger user must first:
1) Know that such functionality even exists
2) Figure out how to turn it off securely
And as long-term KeePass user (11 years) and professional IT engineer (sysadmin/security) I FAILED TO BOTH. I didn't know that this functionality exists before all of the fuss. And I failed to actually implement measures against that: I tried twice, but I didn't have enough time or energy to figure it out to end.
Here you have attached the link. What do you think, can a random IT guy figure out after his working day for like 10-15 minutes how settings precedence and merge modes work in KeePass, where files are located and how to disable triggers in the xml configuration he sees for the first time? And what about non IT-one?
My configuration is vulnerable right now. So I think your argument that the random user can turn it off is simply unrealistic. This is fantasy. The vast majority will never manage to do this.

...And I remember you implemented DACL setting only in config because you were not expecting plain user can edit config file to remove it. So, you’re not expecting plain user to be able to secure himself from that trigger thing, right?

[Nick Zh.]

At the same time assuming that if attacker has ANY access then he has ALL access is just plain wrong.

I totally agree with you. I'm using non-admin account on my local machine for more than a decade and I clearly expect such the software as KeePass to use advantage of different levels of user rights, UAC, etc.

[Jan Kratochvil]

I am convinced that the author of Keepass knows and is well aware of all that we have written here.
Now it's just a matter of whether it can publicly admit it and implement a fix, or whether Keepass will fade into obscurity and eventually be flagged as a potentially exploitable application in all malware databases.

I understand that this is a hard decision.

One more note - I am of the opinion that most of the users have been using Keepass for years and not other applications with a similar label in their name. And that's simply because this Keepass was the one, maybe the first, trustworthy one, with a number of very good ratings, the author himself added them to his homepage. I also believe that the majority of users have never installed any extensions, plugins, or even disabled these options in the configuration of Keppass, and this is also true for the use of triggers. And all of this in the good belief to make their Keepass as safe as possible. Well...

Mr. Reichel, still nothing?

[Horst]

I belive the opposite, a majority of not paranoid users
will have some very useful plugins installed.
Like KeePassEnhancedEntryView or WebAutoType

[Thomas J Howard]

I fully understand that enforcing the configuration is possible and that it can have pretty much the same protections as the binary can. That is all fine and appreciated, but it not the main point here.

Security is a game of cost effectiveness and resource allocation. We can make systems extremely secure, but at the same time, no business is interested in such costs (no government either). IT Administrators are usually overburdened with tasks and responsibilities while not being paid adequately. In real world it is impossible for an IT administrator to be competent in configuring all applications, event such critical to security as keepass. Configuration can be disabled, errors can be made. At some point we will rely on default configuration, by choice or mistake, and whether it is good or bad, this is how the world works.

Before you say that this is "somebody else's problem", consider this - do you want to research all aspects of your OS security? All applications, browsers? Do you know which software on your OS verifies CRLs by default? We have enough problems to research as is, with all IT systems getting more complicated and more interconnected. It would be great if we all had spare time and energy to research everything security-related.

This is why, there has been a huge push for "secure by default" in last years. Because we know, that most things will stay on defaults.
Making the defaults in security-critical software (as which KeePass fully qualifies) in such a way it allows new attacks is in my opinion against best practice. In real world applications this will result in decreased security for a lot of users. And this alone should be strongly considered.

So, as much as we CAN protect against it, this is not how security should be designed. I understand that this is a case of security vs usability, but from my point of view it looks like the export triggers are used by a minority, while the majority will rely on unsecure defaults. It makes math easy for me, though it is based on anecdotal data that I observed myself.

Personally, I do not understand why there is such a push back against making KeePass undoubtedly more secure by default. The technical solution seems pretty simple at first glance - change the default, remove the option to configure this (export without entering the key) from the user-writable configuration file, and only allow such configuration in enforced configuration, which is considered an internal part of KeePass and is equally protected. If someone wants this risk-increasing feature it can be enabled in enforced config.

[Alan78673]

Heck, for that matter is it THAT onerous to type the main password before exporting? Let's say I have KeePass running minimized at my desk, get up to go to the bathroom, and forget to lock my workstation. With the option to "export without entering the key" my coworker could slide over to my desk and export my whole database. Why not remove that option altogether? The coworker could still scroll though the database till I got back but couldn't export the whole thing. I understand the fun of making things configurable but it is really that much of a hindrance when we're talking about exporting the whole database?

[Nick Zh.]

And for all of these guys talking "if an attacker has full access to your machine, it's no longer your machine": the privilege level needed to change config file in user's AppData folder is one of the smallest. It clearly NOT equals to "full access to machine". By saying this you just deny any security measures on which modern security is built.
For example, your browser on Windows system needs admin privileges to update itself. Why, why does it use separate process for that task? And even on top of that, why doesn’t it run JavaScript code, render interface, run extensions just in one process with user rights and instead use separate child processes with lowered privileges?
Does it mean that not all code running on your system is equal? And may it be possible you can use this fact to make user's data safer? To make it harder for bad guys to steal something?

And KeePass already have config file secured by admin privilege rights in "Program Files" folder. Why, just why shouldn't we use that fact to secure dangerous (and I'm sure seldom used) settings?