Extracts passwords from a KeePass 2.x database, directly from memory | Hacker News Reader

Extracts passwords from a KeePass 2.x database, directly from memory

github.com

32 pointsdsr1220 comments

Is this not an instance of "it rather involved being on the other side of this airtight hatchway" [1]?

edited to clarify: I don't mean the specific attack described there, but the general issue that it represents: "X did something insecure because you granted a malicious program permission to alter its operation" doesn't really imply anything about X except that it isn't literally magic.

[1]: http://blogs.msdn.com/b/oldnewthing/archive/2013/08/02/10438...

I would assume that this only works on an unlocked (unencrypted) database in-memory.

This is a cool tool for an attacker, but I would guess that almost all virtual password managers are vulnerable to it and that this 'vulnerability' is not specific to Keepass, this is just an implementation.

The only way to mitigate this attack vector 'somewhat' is having the database lock after a timeout and don't leave it unlocked all the time. I would guess this is true for all password managers.

But I'm happy to be told differently.

In general, I think a Keepass tool is nice for private use, but because of the nature of these tools, I would use a kind of centralised password server with RBAC to limit the scope of a breach.

So if you're capable of injecting code into an arbitrary process (which requires admin privileges if I understand correctly), couldn't you just inject it into a browser and steal them that way

If you have the access to the memory, you also have the access to clipboard, and keypress events. In other words, you already have the user's passwords in plaintext.

Though KeepPass clears the clipboard (mainly to prevent the user accidentally pasting their passwords somewhere else, like a public forum).

I would think if you had something running locally on a machine with an unlocked password database the KeepPass client would also be vulnerable to all kinds of gui scripting (Applescript, WSH, etc.), it's designed to let users copy and paste passwords, after all.

I would recommend unticking application's Options -> Policy -> Export checkbox, or at least Export - No Key Repeat to require entering the Database Password once again to confirm the export.

This extractor relies on KeePass' code itself, so setting that option should(?) render this trick futile.

I will check the source code to confirm this workaround.

The injected dll could presumably just uncheck the checkbox/modify the check logic since its running in the same process space anyway

aaand nope, it only checks for that AppPolicy on UI level. The implementation class does what's required without checking application settings.

This isn't an attack on the KeePass database but on a particular KeePass implementation.

If this attack is a worry, use KeePassX[1], the KeePass implementation formerly only for Linux and now available for WIndows, OS X, Linux and BSD. I am no expert, but it seems this attack is very narrowly targeted and constructed.

KeePassX is currently in Beta 2[2] for those of you who are good at evaluating source code. The world would be a better place if more people took a deeper look at the code: https://github.com/keepassx/keepassx

1) https://www.keepassx.org/ 2) https://www.keepassx.org/news/2015/09/514

What does this mean: "extraction of KeePass 2.x password database information from memory"?

When is KeePass data held in memory? When the program is simply running or only when you copy a password to the clipboard?

KeePass shows accounts in a ListView type of control and in a dialog, both of which probably store the data in memory. I'm just wondering if this tool can snatch accounts just from simply having KeePass running, in which case this could be bad for malware/spyware. Picture a malware program running, waits for KeePass to show up in the process list, grabs all your accounts and sends them to a remote site. Yikes.

Here's a similar case of how one can extract data from RAM. Of course it's more of a proof of concept than anything else, but it does show some inherent vulnerabilities in our systems.

http://jamesfarrugia.blogspot.com.mt/2015/10/the-volatile-se...

The readme doesn't seem to mention or I have missed it: I assume this works on a locked instance of KeePass (the database opened, but the application interface locked)?

I always had a feeling that KeePass was likely not much better than a flat text file, or piece of paper with all my passwords on it. Thank you for confirming this.

It's much harder to inject code to a running process and steal information, assuming the user entered the encryption key and didn't close the app in time, than to just look for all text files on the computer and read them.

True, thank you for this clarification. I myself use KeePass but it's more for convenience of password generation and storage than anything else.

Not sure how your comparison relates to this article. It's a completely different attack vector.

I, for one, will keep using KeePass and sync my database between devices via cloud services.

As a countermeasure to this, you can 'pepper' your passes or secrets with reserved letters / symbols that only you know about. For example if a pass is

    _SOSECRETOMG!_

You simply omit the exclamation symbol, and reveal the real pass which is:

    _SOSECRETOMG_

That's a very basic example, and can be made as complicated as your brain will allow. The older you are, the harder this gets to do small byte flips like this.

One of the features of KeePass is that you never see or type an actual password. You simply hit CTRL-C to copy the pw to memory and paste into the form. This is a guard against key loggers and visual snooping.

Better: Auto-Type. That way it's never even in the clipboard.

What is up with all this satanic symbolism ?

Reply on news.ycombinator.com