
Extracts passwords from a KeePass 2.x database, directly from memory - dsr12
https://github.com/denandz/KeeFarce
======
0xcde4c3db
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...](http://blogs.msdn.com/b/oldnewthing/archive/2013/08/02/10438842.aspx)

------
louwrentius
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.

------
Macha
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

------
Grue3
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.

~~~
blacksmith_tb
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.

------
synchrone
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.

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

------
snassar
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](https://github.com/keepassx/keepassx)

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

------
sadkingbilly
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.

------
iljun
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...](http://jamesfarrugia.blogspot.com.mt/2015/10/the-volatile-security-of-
volatile-memory.html)

------
throwaway125
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)?

------
splitdisk
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.

~~~
ronreiter
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.

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

------
signaler
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.

~~~
sadkingbilly
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.

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

------
_TEST_
What is up with all this satanic symbolism ?

