Heise recently published an article about KeePass not using HTTPS. The article turns out to be a canard, since KeePass cannot update itself. This article reminded me that I have attacked KeePass in 2009 to see how secure it is. Since it offers security features like password encryption, dual channel auto-type obfuscation, secure desktops etc., I thought this is a well-written and totally secure application.
Unfortunately I had to find out that my first two approaches of attacking KeePass worked very well (I don’t want to go into details here and provide full source for script kiddies; if you’re a developer you’ll probably be able to implement the attack based on the modifications I make to KeePass). Therefore I contacted the author, Dominik Reichl. However, he explained that such issues cannot be fixed. A few days later (2009-02-27 according to archive.org), the following text was added on the KeePass website, Security section:
All security features in KeePass protect against generic threats like keyloggers, clipboard monitors, password control monitors, etc. (and against non-runtime attacks on the database, memory dump analyzers, …). However in all the questions above we’re assuming that there’s a spyware program running on the system that’s specialized on attacking KeePass.
In this situation, the best security features will fail. This is law #1 of the 10 Immutable Laws of Security : “If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore”.
For example, consider the following very simple spyware specialized for KeePass: an application that waits for KeePass to be started, then hides the started application and imitates KeePass itself. All interactions (like entering a password for decrypting the configuration, etc.) can be simulated. The only way to discover this spyware is to use a program that the spyware doesn’t know about or can’t manipulate (secure desktop); in any case it can’t be KeePass.
If KeePass is not that secure, let’s try to make it a little more secure by yourself. Are you allowed to do so? Well, KeePass is released under GPL2 so you can modify it. You even don’t need to publish the modified source code as long as you don’t distribute your version and keep it for yourself. Only with publishing you need to publish under the same license. The relevant paragraph is
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. […]
Step 1: Compiling KeePass
- Download and install Visual Studio 2015 Community Edition if you don’t have VS 2015 already
- In the Download section, scroll to the bottom and download the source code for KeePass 2
- Unblock the ZIP file in the file properties (otherwise you might get strange security questions)
- Unzip the ZIP file
- Ideally, add all the source code to a version control system (SVN) just to be able to make changes without breaking anything
- Open the solution file KeePass.sln, which is a VS 2008 project, in VS 2015
- Confirm the one-way upgrade warning
- Try to build the solution. You’ll get some errors regarding PFX files which are used for the digital signature.
- Open the properties of all projects. Choose “Signing” and remove the checkmarks for the PFX file. I’ll assume that you don’t have an own PFX. If you do have an own PFX file, you’re probably familiar on how to use it.
- Try to build the solution. For me, it still failed due to “sgen.exe” not working well. Open the KeePass properties, go to “Build Events” and remove the post build step. This also has to do with the digital signature
- Try to build. This time it should work.
- Set “KeePass” as the startup project.
- Commit your work to SVN (if you have)
Step 2: Make it a bit more secure
For a specialized attack on KeePass, the attacker needs to find out that KeePass is KeePass. The attacker might look at the executable name, so let’s change it.
- Open the KeePass project properties
- Change “Assembly Name” to something you want, e.g. “PwManager”
So the executable name is better now. An attacker may still identify it as KeePass from the title etc., so let’s change that as well.
- Open KeePassLib\PwDefs.cs
- Change all “KeePass” to something else as well, e.g. “PwManager”
- As you’re there, change all URLs to “about:blank” if you like
Our modified KeePass version still uses the KDBX file extension, so an attacker may notice that and gather interest.
- Open KeePass/App/AppDefs.cs
- Find a class called FileExtension
- Change the extension from kdbx to something else, e.g. pwmg
- Change the “ExtId” from “kdbxfile” to “pwmgfile”. This would probably affect the Registry in case you want to register the file extension. Personally I recommend running it portable and not registering the file extension.
- Below those definitions, you’ll find some more items with “KeePass” in the name. Change it as well.
- Compile it and run it
- Commit your work to SVN
Step 3: recognize a potential replacement
Whatever efforts we take, an attacker may use other techniques to identify our application as a KeePass clone and replace it with a copy to fool us. Let’s mitigate that by changing the color of the password form. A replacement may not be able to imitate this, so you’ll notice the replacement, because it has the default KeePass color and not your color.
- From the KeePass project, open Forms/KeyPromptForm in designer mode
- Change the background color, e.g. to blue
- Compile it and run it
- Create a demo database and check the password dialog. It should have your color now
- Commit your work to SVN
If you followed this tutorial, you should now have a version of KeePass that it a little bit safer and looks similar to this:
Sure, it still does not cover all attack vectors but at least the following:
- Stealing *.KDBX files: your password file will not be found since it has a new extension now
- Replacement of KeePass by a malicious clone via the Image File Execution Options Debugger Registry key (since this would require the executable to be named KeePass.exe)
- Replacement of KeePass by a malicious clone in any other way, since you’ll likely detect the replacement due to the wrong color
What else could you consider? Based on my attacks I would do the following two things next:
- Add a part of the password to the password via code. This will prevent someone from recording your complete password with a generic keylogger. So even he has your “KDBX” file and a recorded password, he’ll still need your program to get the second half of the password.
- Detect if KeePass loses the focus and regains the focus very quickly. A user will need ~100 ms or longer to switch between applications. If the time is shorter, it’s likely that an attacker opened an invisible window and returned the focus to KeePass. Using Auto-Type will type into the attacker’s invisible window. The attacker may choose to forward the input to the original destination window so you won’t notice that it got lost.
- Display the title of the window that KeePass is going to send the password to.
- Display a list of DLLs loaded into the process. That way you might detect keyboard hooks etc. To shorten the list you could exclude DLLs signed by Microsoft, exclude known DLLs etc.
I have not yet described these modifications in detail.