Hacker News Reader

Comment by jonathanstrange | Hacker News Reader

That feature is extremely insecure and makes no sense for a password manager. It ought not be possible to trigger anything in an unencrypted document or install/run anything over plaintext data without first providing the master passphrase for that password document. That should be obvious.

View on HN

Am I reading that right, that if you point Keepass.exe at any .kdbx and simply add an export option to the XML config it'll export it without the master password?

Granted you need local access to modify the config, but generally the .kdbx is stored (securely) on some shared environment. Grabbing that would mean you could export passwords at your leisure in this setup?

So this makes no sense. Someone that works at Dropbox has access to millions of kdbx files, and doesn't need any master passwords, just their own copy of keepass.exe?

To perform an export of a KeePass database, the database needs to be opened using (at least) a master password. A database file without its master password is still worthless on its own.

But you don't know that you are entering the password to release all your passwords into cleartext, all you wanted to do is check wether your farmville cows still exist.

That's my biggest quirk. There shouldn't be any way to export plaintext data without explicit user feedback and confirmation in the first place. That this is triggered by an unprotected global configuration file is just the icing on the cake.

As I understand it, if you modify the xml, Keepass will silently export entries in the database once you load it (by providing the password).

Keepass will (by default) not ask for the password a second time before exporting - but you have to decrypt the database once before it can be exported.

So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".

The point is that the password manager application ought to allow a configuration change which affects document X's plaintext only after the master passphrase has been entered by the user for document X. It's not hard to implement that for configuration files and plugins in a multi-document setting, you just need to store suitable authorization secrets in the documents. In a single-document application it's more trivial, of course, you'd encrypt the configuration file and plugins with keys derived from the master passphrase or check their signatures.

It's actually less of a risk than I thought, because the configuration is on your local install of KeePass, not in the database file.

If an attacker can modify your local install, you've lost anyway....

You have to think about security as being layered. There is a huge difference between creating a mock copy of an application or injecting code into an existing binary, and toggling a setting in a human-readable XML configuration file. Most operating systems also monitor executables more carefully than document files.

My understanding is that the attacker doesn't need to inject code, they can simply take screenshots or recordings programmatically and when that shows the password manager all passwords are exposed.

> So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".

No, the threat model is "the attacker can modify config file", which for default installation also means "the attacker can modify the executable".

The export would only be triggered when a database is opened, so the master password is required.

I'm just guessing here, but I'd assume this vulnerability does happen once the master password is input.

So, the attacker modifies the config file, then the user eventually uses the password manager as usual, and then a file in disk with all plain text passwords is generated and subsequently read by the attacker.

I guess the point here is you don't need a memory read vulnerability.

Can someone more knowledgeable confirm?

The point is that the file itself should be encrypted or at least signed with the master password.

For a general configuration file, there is not "the" master password, since it is independent of password database files.

I guess it's an issue of UI.

Given that dumping a cleartext password list is a legitimate thing you might want to do, and being a plugin (or setting) a somewhat acceptable way of achieving this, the issue here is that, as it is, the user is not being unequivocally made aware of what happened.

So yeah, I agree, in any case the feature, as it is implemented, is completely unacceptable.

I would hope that the password manager application does not itself have access to the unencrypted passwords, without the user providing the master password.

This is correct.

But users are constantly providing the master password to use the application normally. The only complaint is that after first providing the master password to cause the application to decrypt the document, the application decrypts the document, and if someone has modified the application to do other stuff after decrypting the document, it does that stuff.

They're proposing that the author change the application so that it pops up a dialog whenever the KeePass application is directed to export the decrypted document.

I'm not a KeePass dev, but with a bit of search and pattern recognition, it looks like this export feature is implemented in KeePass-2.53-Source\KeePass\DataExchange\ExportUtil.cs:

   public static bool Export(PwExportInfo pwExportInfo, FileFormatProvider fileFormat,
       IOConnectionInfo iocOutput, IStatusLogger slLogger)
   {
       PwDatabase pd = pwExportInfo.ContextDatabase;
       ...
       // [IF CONFIG FILE DOESN'T ALLOW EXPORTING WITHOUT KEY]
       if(!AppPolicy.Current.ExportNoKey && (pd != null))
       {
           // [THEN ASK FOR IT AGAIN]
           if(!KeyUtil.ReAskKey(pd, true)) return false;
       }
       ...
       Stream s = (bFileReq ? IOConnection.OpenWrite(iocOutput) : null);
       try { bResult = fileFormat.Export(pwExportInfo, s, slLogger); }
       finally { if(s != null) s.Close(); }
    }

They're complaining that an evil maid attack can turn off `AppPolicy.Current.ExportNoKey` and set it up to export the document silently. They want it to read:

   public static bool Export(PwExportInfo pwExportInfo, FileFormatProvider fileFormat,
       IOConnectionInfo iocOutput, IStatusLogger slLogger)
   {
       PwDatabase pd = pwExportInfo.ContextDatabase;
       ...
       // [ALWAYS ASK FOR MASTER PASSWORD AGAIN BEFORE EXPORTING]
       if(!KeyUtil.ReAskKey(pd, true)) return false;
       ...
       Stream s = (bFileReq ? IOConnection.OpenWrite(iocOutput) : null);
       try { bResult = fileFormat.Export(pwExportInfo, s, slLogger); }
       finally { if(s != null) s.Close(); }
    }

They've even gone so far as to ask the author to create a "KeePass Essentials" version, which removes the export feature, plugins, and configuration files entirely:

https://sourceforge.net/p/keepass/feature-requests/2704/#b3c...

But they ignore that with write access to the application directory, an attacker can just change the application to not show that dialog at all.

Application directory and Application Settings directory are not the same thing, usually. (Indeed usually on Windows and Linux, the former isn't writeable to the user account without elevating privileges, the latter is)

I checked where the relevant files are when installing KeePass 2 for windows.

There is a global configuration file at "C:\Program Files\KeePass Password Safe 2\KeePass.config.xml" but by default, this one just contains a directive to use the user's configuration. This one also needs elevated privileges to edit.

The user's configuration file is at "C:\Users\<username>\AppData\Roaming\KeePass\KeePass.config.xml"

So if you want to avoid an attacker being able to change the user's configuration without elevation, then you can just change the security settings of that last file, e.g. by taking away the user write permission.

However, the user is probably launching the KeePass executable via some sort of shortcut. For example, a pinned shortcut on the taskbar. This would also be a user file, at "C:\Users\<username>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\KeePass 2.lnk"

So if the attacker can modify the user's files, then they can probably also modify that shortcut, e.g. to point at a modified copy of keepass. This shows that the behavior of the "real" KeePass application is probably not very relevant here. It is difficult to defend against an attacker with that level of access.

> They're complaining that an evil maid attack can turn off `AppPolicy.Current.ExportNoKey` and set it up to export the document silently.

If an evil maid has access to make such a change, wouldn't it be easier to just replace keepass.exe with custom version? The source is already available. Just call this function after successful login - ignoring XML configuration, "KeePass Essentials" version, etc.

business logic

you extremely have no idea what you're talking about. the password exists because that's how encryption works, and no other reason. if your hard drive is stolen, they need the password. there is not one single other reason that the password exists

Reply on news.ycombinator.com