Are there any plans for sandboxing or memory protection from tools such as KeeFarce? (https://github.com/denandz/KeeFarce)
Alternatively, are there good mitigation strategies for this sort of threat? I can see this sort of tool being deployed with RATs and slurping up much more than a keylogger might - it makes KeePass a bit of a threat to security in that aspect. The tool is dead simple and dangerous and I'm uncertain on how to approach the threat within my organisation.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you can persuade someone to run your malware there are much simpler ways to extract the KeePass data. The easiest is to capture the master password and the database file.
Protection from these threats is to prevent software installation, so no admin accounts for users.
cheers, Paul
Last edit: Paul 2015-11-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KeeFarce is not a threat (and the developer of it apparently knows that, as he nowhere declares it as threat or attack).
This tool extracts information of a running KeePass process (with an open database) using a rather complicated method (using DLL injection). There are much simpler ways to achieve that. For example, a tool could send simulated keypresses to the KeePass window to export the data to a file (e.g. press Alt+F, E, Tab, Space, ...). Before that, a screenshot could be created and displayed above all windows in order to hide this procedure (and a user probably would not notice a screen freeze of one second).
Like others wrote before, the actual problem is running specialized malware. If you're doing this, everything's over; software cannot protect itself in such a case. I wrote about this before: http://keepass.info/help/base/security.html#secspecattacks
Best regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KeeFarce currently only works with KeePass 2.x, but without a doubt a similar data extraction tool could be developed for KeePass 1.x. My simple method using simulated keypresses could be adapted within a few minutes.
When you run specialized malware, no application can protect itself from this [1].
Protections against generic (non-specialized) malware can sometimes be implemented. For example, TCATO [2] is a way to protect auto-typed data from keyloggers, the secure desktop [3] protects your master password from some keyloggers, secure edit controls [4] protect against password control spies, and so on. These protections only work against specific classes of generic malware. For example, while TCATO protects against keyloggers, a malware that is both a keylogger and a clipboard spy at the same time renders TCATO useless. Again, the actual problem is running malware, not any insufficient protections. There is no protection against a malware monitoring everything, except not running the malware. Protections like TCATO might save you in the case of running some non-advanced malware, but they're not a license for running any arbitrary malware.
Would turning off the export capability in Keepass policies have mitigated this attack? Is there a list of recommended settings somewhere to "harden" Keepass (obviously this would be dependent on a specific user's need of certain functionality). But I probably don't use half of the features in the software, so disabling them seems prudent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes you can disable certain things, but any software which attacks KeePass directly will take that possibility into account and work around it.
Keep unknown programs off your computer and use an up to date anti virus, the usual safe hex rules.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This makes Keepass a really hard sell for business use. I get that technically this vulnerability is difficult to protect againts universally, but from the perspective of a non-technical person it just looks like you are ignoring the problem by saying if you can't fix all issues you might as well not bother. Basically my users are going to point out that if you know of the vulnerability you should protect against it. Is there some argument for ignoring this issue that doesn't involve the idea that we cannot be perfectly secure on infected or shared machines? For example if you are using KeePass in a corporate environment, and don't have control over the machine, but would like to be assured that your data is safe, or if you are sharing a pc with your child, and would like to know that they can't get your passwords with script kiddie level ease. How would you explain to these users why Keepass is insecure?
Last edit: iondream 2015-11-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would argue that in this particular case (KeeFarce), the reason for not fixing the vulnarability in KeePass is because the vulnuralbility is not in KeePass. The problem is at the OS level. The OS allows one program to modify the memory used by another program. There is not a defect in KeePass that allows this to happen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue is one of targeted attacks. If you make a fix for Keefarce, attackers will look for another method and they may not publicise the new one, so you can never really know if you are ahead or behind. That doesn't mean Dominik won't improve KeePass, just that it's a moving target.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This makes Keepass a really hard sell for business use.
But the argument being used here is just as valid for whatever product you might choose as "better" than KeePass.
Yes, this KeeFarce program highlights a potential attack vector, but similar attack vectors exist for every program - which is, I think, the point that the KeeFarce author is (clumsily) trying to make, using KeePass as an example.
If you take the existence of KeeFarce to mean that KeePass is a terrible program, you're missing the point. If you decide to use program FooBar instead of KeePass because of this, there's nothing to stop someone from writing a FooFarce program that would use similar techniques. In fact, that may be an ulterior motive of the KeeFarce author - to scare people into choosing programs that are even easier to attack than KeePass.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for all the replies. I guess I will have to tell my users that we are using EMET to mitigate, since as David points out, its an os level issue. I also agree with T. Bug Reporter that the effect of the article is to lower confidence in keepass, and password safes in general, as on first glance its condemning it. The idea that this is the state of the art is discouraging to users, since they think "I might as well go with nothing if this is not secure." Thanks to all, youve helped me to fashion a marketable response to my users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"I might as well go with nothing if this is not secure."
Users need to understand that security isn't a yes-or-no proposition. No combination of measures can ever provide perfect security, but that's not enough of a reason to abandon the effort.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very true. There is a pretty good article on lwn.com called "Security in an error-prone world" thats unfortunately behind a paywall. Heres the outline.
[$] Security in an error-prone world [Security] Posted Nov 3, 2015 17:05 UTC (Tue) by corbet
The 1957 Chevrolet Bel Air was a beautiful car, kernel.org administrator Konstantin Ryabitsev said at the beginning of his Korea Linux Forum talk. It had roomy seats, lots of features, and a smooth ride; it was all about power and comfort. But if you got into an accident with this car, it would kill you; it was not designed around the idea that things might go wrong. Our computer systems in 2015 mirror the Bel Air of 1957; they are not designed around humans and the mistakes they make. Konstantin had a simple message for the audience: take a cue from the automotive industry and design and build systems that do not fail catastrophically when errors are made.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've thought about this attack vector and how to minimize it because all password programs are vulnerable more or less on this kind of attack.
How about removing all sort of exporting (especially unencrypted exporting, but why not remove all?) from the standard program and provide a seperate version if a user wants to export a kdb(x) ?
It's an easy countermeasure, only requires the Keepass maintainer to provide an additional version (one with and one without) export functionality.
The version without exporting could show a message dialog that this version does not support exporting and link to the one with export functionality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Exporting isn't the only way to obtain the passwords. If an attacker can obtain your master password via key logging then they only need a copy of the database. They could also save a copy after changing the master key, or change KeePass.exe, etc, etc.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course my solution will not help against keyloggers etc. . But why not make an countermeasure against Keefarce? Why keep this loophole open for the script kiddies out there who e.g. stick an USB stick in your Windows PC in an unattended moment and get all of your passwords without key logging? AFAIK it does not need even an admin account and you also do not need Keefarce at all to export generally. Exporting a Keepass file is something you normally do very seldom IMHO and it should be hard(er) to do. Another thing to do is asking for the master password on export generally again. Just make it harder on this two points and nobody can steal your entire kdbx in plaintext with two clicks.
Last edit: Marvin 2015-11-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are there any plans for sandboxing or memory protection from tools such as KeeFarce? (https://github.com/denandz/KeeFarce)
Alternatively, are there good mitigation strategies for this sort of threat? I can see this sort of tool being deployed with RATs and slurping up much more than a keylogger might - it makes KeePass a bit of a threat to security in that aspect. The tool is dead simple and dangerous and I'm uncertain on how to approach the threat within my organisation.
Thanks
If you can persuade someone to run your malware there are much simpler ways to extract the KeePass data. The easiest is to capture the master password and the database file.
Protection from these threats is to prevent software installation, so no admin accounts for users.
cheers, Paul
Last edit: Paul 2015-11-04
Take a look at the project and try it out. It collects the passwords and puts them to plaintext.
Last edit: Brian Auron 2015-10-31
I'm interested on that too. Is there a way to protect KeePass from it or software like that?
There is only one solution for such problems:
Don't install Malware or software from unknown sources.
Don't run with admin rights for normal usage.
Is KeePass 1.x or a KeePass 1.x database affected by KeeFarce because it just says "KeeFarce allows for the extraction of KeePass 2.x ..."?
P.S. Shouldn't KeeFarce be added to known Security Issues?
Last edit: James 2015-11-02
Downloading and running Malware is not a security issue of KeePass or any other program.
KeeFarce is not a threat (and the developer of it apparently knows that, as he nowhere declares it as threat or attack).
This tool extracts information of a running KeePass process (with an open database) using a rather complicated method (using DLL injection). There are much simpler ways to achieve that. For example, a tool could send simulated keypresses to the KeePass window to export the data to a file (e.g. press Alt+F, E, Tab, Space, ...). Before that, a screenshot could be created and displayed above all windows in order to hide this procedure (and a user probably would not notice a screen freeze of one second).
Like others wrote before, the actual problem is running specialized malware. If you're doing this, everything's over; software cannot protect itself in such a case. I wrote about this before:
http://keepass.info/help/base/security.html#secspecattacks
Best regards,
Dominik
Thanks for your comments.
Does this special attack affect Keepass 1.x dbs?
What differs KeeFarce to a Keylogger or similiar software mentioned? Is it harder to detect?
KeeFarce currently only works with KeePass 2.x, but without a doubt a similar data extraction tool could be developed for KeePass 1.x. My simple method using simulated keypresses could be adapted within a few minutes.
When you run specialized malware, no application can protect itself from this [1].
Protections against generic (non-specialized) malware can sometimes be implemented. For example, TCATO [2] is a way to protect auto-typed data from keyloggers, the secure desktop [3] protects your master password from some keyloggers, secure edit controls [4] protect against password control spies, and so on. These protections only work against specific classes of generic malware. For example, while TCATO protects against keyloggers, a malware that is both a keylogger and a clipboard spy at the same time renders TCATO useless. Again, the actual problem is running malware, not any insufficient protections. There is no protection against a malware monitoring everything, except not running the malware. Protections like TCATO might save you in the case of running some non-advanced malware, but they're not a license for running any arbitrary malware.
Best regards,
Dominik
[1] http://keepass.info/help/base/security.html#secspecattacks
[2] http://keepass.info/help/v2/autotype_obfuscation.html
[3] http://keepass.info/help/base/security.html#secdesktop
[4] http://keepass.info/help/base/secedits.html
Would turning off the export capability in Keepass policies have mitigated this attack? Is there a list of recommended settings somewhere to "harden" Keepass (obviously this would be dependent on a specific user's need of certain functionality). But I probably don't use half of the features in the software, so disabling them seems prudent.
Yes you can disable certain things, but any software which attacks KeePass directly will take that possibility into account and work around it.
Keep unknown programs off your computer and use an up to date anti virus, the usual safe hex rules.
cheers, Paul
This makes Keepass a really hard sell for business use. I get that technically this vulnerability is difficult to protect againts universally, but from the perspective of a non-technical person it just looks like you are ignoring the problem by saying if you can't fix all issues you might as well not bother. Basically my users are going to point out that if you know of the vulnerability you should protect against it. Is there some argument for ignoring this issue that doesn't involve the idea that we cannot be perfectly secure on infected or shared machines? For example if you are using KeePass in a corporate environment, and don't have control over the machine, but would like to be assured that your data is safe, or if you are sharing a pc with your child, and would like to know that they can't get your passwords with script kiddie level ease. How would you explain to these users why Keepass is insecure?
Last edit: iondream 2015-11-03
I would argue that in this particular case (KeeFarce), the reason for not fixing the vulnarability in KeePass is because the vulnuralbility is not in KeePass. The problem is at the OS level. The OS allows one program to modify the memory used by another program. There is not a defect in KeePass that allows this to happen.
The issue is one of targeted attacks. If you make a fix for Keefarce, attackers will look for another method and they may not publicise the new one, so you can never really know if you are ahead or behind. That doesn't mean Dominik won't improve KeePass, just that it's a moving target.
cheers, Paul
But the argument being used here is just as valid for whatever product you might choose as "better" than KeePass.
Yes, this KeeFarce program highlights a potential attack vector, but similar attack vectors exist for every program - which is, I think, the point that the KeeFarce author is (clumsily) trying to make, using KeePass as an example.
If you take the existence of KeeFarce to mean that KeePass is a terrible program, you're missing the point. If you decide to use program FooBar instead of KeePass because of this, there's nothing to stop someone from writing a FooFarce program that would use similar techniques. In fact, that may be an ulterior motive of the KeeFarce author - to scare people into choosing programs that are even easier to attack than KeePass.
Thanks for all the replies. I guess I will have to tell my users that we are using EMET to mitigate, since as David points out, its an os level issue. I also agree with T. Bug Reporter that the effect of the article is to lower confidence in keepass, and password safes in general, as on first glance its condemning it. The idea that this is the state of the art is discouraging to users, since they think "I might as well go with nothing if this is not secure." Thanks to all, youve helped me to fashion a marketable response to my users.
Last edit: iondream 2015-11-03
Users need to understand that security isn't a yes-or-no proposition. No combination of measures can ever provide perfect security, but that's not enough of a reason to abandon the effort.
Very true. There is a pretty good article on lwn.com called "Security in an error-prone world" thats unfortunately behind a paywall. Heres the outline.
[$] Security in an error-prone world
[Security] Posted Nov 3, 2015 17:05 UTC (Tue) by corbet
The 1957 Chevrolet Bel Air was a beautiful car, kernel.org administrator Konstantin Ryabitsev said at the beginning of his Korea Linux Forum talk. It had roomy seats, lots of features, and a smooth ride; it was all about power and comfort. But if you got into an accident with this car, it would kill you; it was not designed around the idea that things might go wrong. Our computer systems in 2015 mirror the Bel Air of 1957; they are not designed around humans and the mistakes they make. Konstantin had a simple message for the audience: take a cue from the automotive industry and design and build systems that do not fail catastrophically when errors are made.
Heres the slides from the talk
http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf
I've thought about this attack vector and how to minimize it because all password programs are vulnerable more or less on this kind of attack.
How about removing all sort of exporting (especially unencrypted exporting, but why not remove all?) from the standard program and provide a seperate version if a user wants to export a kdb(x) ?
It's an easy countermeasure, only requires the Keepass maintainer to provide an additional version (one with and one without) export functionality.
The version without exporting could show a message dialog that this version does not support exporting and link to the one with export functionality.
Exporting isn't the only way to obtain the passwords. If an attacker can obtain your master password via key logging then they only need a copy of the database. They could also save a copy after changing the master key, or change KeePass.exe, etc, etc.
cheers, Paul
Of course my solution will not help against keyloggers etc. . But why not make an countermeasure against Keefarce? Why keep this loophole open for the script kiddies out there who e.g. stick an USB stick in your Windows PC in an unattended moment and get all of your passwords without key logging? AFAIK it does not need even an admin account and you also do not need Keefarce at all to export generally. Exporting a Keepass file is something you normally do very seldom IMHO and it should be hard(er) to do. Another thing to do is asking for the master password on export generally again. Just make it harder on this two points and nobody can steal your entire kdbx in plaintext with two clicks.
Last edit: Marvin 2015-11-04
That is what auto-lock is for. My KeePass is only ever open for a maximum of 5 minutes unless I'm working on it.
cheers, Paul