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.
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.
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
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.
Readit News
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...
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.
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.
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.
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
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.
http://jamesfarrugia.blogspot.com.mt/2015/10/the-volatile-se...