KeeFox 1.2.5b1 released
Version 1.2.5 is nearly ready to be released so beta testers will soon be upgraded to this new version with a few small but important bug fixes:
- A fix for Thunderbird 25
- A couple of bug fixes that caused some passwords to not save to KeePass
- Danish, French, Korean, Portuguese and Russian languages created / updated (some not complete yet)
- Fix for intermittent failed KeePass shutdown on Mono (Mac/Linux)
- Some other small changes
Big changes in KeeFox 1.3 and 1.4
Some big changes are coming to Firefox at the end of this year and we’ll be watching them as they develop over the coming month or two so that KeeFox 1.4 can continue to work beyond 2013. It could be an exciting opportunity to make some improvements to KeeFox so within a couple of months I’ll be posting a bit more detail about the changes and what we can all do to help.
Before then, I’ll be releasing KeeFox 1.3 which contains just as many large changes but they are fairly invisible by comparison to the ones expected in KeeFox 1.4.
KeeFox 1.3 contains support for keyboard shortcuts, context (right-click) menus and some big changes to the way that KeeFox communicates with KeePass.
It’s the last change that I’m most interested in at the moment because of the security and usability implications of changes to this part of KeeFox.
If you’re not technical, feel free to stop reading now but if you think you might be able to contribute a little time to review the current KeeFox 1.3 alpha release that would be very helpful.
I’ve posted a draft of the new communications protocol to the manual so please start by taking a read through that. There’re also a few non-technical pages available in draft:
Version 1.3.0a1 is currently available as an experimental build on the 1.3dev github branch. Known issues include:
- Several incomplete features make the build unsafe
- Installing this build will probably prevent future versions of KeeFox (including later builds of 1.3.0) from working unless you delete your Firefox profile or make complex manual preference changes
- Only tested on Firefox 25 on Windows 7
- No UI to manage authorised clients
- No UI to change the keyboard shortcuts
- Context menu implementation incomplete
- First-time user experience not working
- Connection establishment logic needs more work and maybe better notifications to users, especially for the edge cases when things go wrong
If you come across anything else that’s a problem with either the specification or implementation of the new KeePassRPC protocol please raise an issue on github so we can discuss it further - note that no-one should be using this alpha version for sensitive data at the moment so don’t worry about responsible disclosure, etc.
I’ll add a few of the above issues to github so if someone else wants to help out by implementing some of them, please keep an eye on the issues listed in the KeeFox 1.3 milestone.
Over the next month or two I’ll be working on the remaining issues above, improving the documentation and generally working towards getting a beta version ready for the Autumn.
Thanks to everyone that notified me of the problems with the recently released version of KeePass.
I hope to release a new version in 4-6 weeks with a beta available within a few weeks. In the mean time, the existing version of KeeFox will continue to work with KeePass 2.17. As with the previous problematic KeePass upgrade, your upgrade route will be much simplified if you continue using KeePass 2.17 until after you are running a new version of KeeFox*. There are currently no known security problems with KeePass 2.17 that necessitate an immediate upgrade.
This time there were many changes to KeePass that prevented KeeFox from working. I was notified of at least some of these changes in advance of the release of KeePass 2.18 but did not have a development environment to work and test with until after the official release last week.
I have identified a way to get KeeFox to work with 2.18 and most users shouldn’t notice any differences but in light of the following major changes to the KeeFox code I have decided to push the fix to existing users quite cautiously - there’s no point in risking breaking KeeFox for everyone just so that some people can run the very latest version of KeePass.
For anyone interested, the two major changes to the KeeFox code are:
1) I’ve upgraded (and then customised) the Jayrock JSON-RPC server bundled within KeePassRPC
2) I’ve set .NET 4 as the default runtime for KeeFox users who don’t yet have a copy of .NET installed
This work required an upgrade to Visual Studio 2010 and I took that opportunity to make a clean break from the existing SVN revision control at Sourceforge; KeeFox code is now available on github, details will be announced in the coming weeks.
* Or at least downgrade to 2.17 before installing the new version of KeeFox.
Another technical post here which explains why KeePassRPC is secure and how an application developer needs to handle authentication with the plugin to protect its users.
Security conscious people might view a KeePass remote access system with fear and loathing and it is true that installing this plugin exposes a new attack vector. I’ll explain how KeePassRPC can be exploited to access a user’s password database but you will see that the installation of the plugin is safe provided that…
A) Neither me nor any 3rd party developers of libraries used in this project have made a mistake in the plugin code
B) Both client and server machines remain secured from 3rd party threats such as viruses, trojans, keyloggers, etc.
The source code for this plugin is available for all to view - this is the best reassurance that you can get regarding point A; of course if any mistakes are discovered I would fix them as quickly as possible and announce the release of the new version straight away.
Point B is often a matter of contention among users looking for a high security password management system. An oft-repeated claim is that “product x protects against keyloggers” and while there is usually truth to this statement it is never a cast-iron guarantee of protection. There really is nothing that can be done to protect your data once any machine you use has been compromised - security software will protect you against the most common (usually generic) attacks but they are not the panacea they sometimes market themselves as.
With that in mind I will introduce the first way in which KeePassRPC protects a KeePass user’s data but first some background information is required.
After installing KeePassRPC, the KeePass executable will begin listening on a network port for requests from other applications that want to access the data inside KeePass. Currently this communication is limited to network traffic that stays within the local computer (aka localhost or 127.0.0.1 on an IPv4 network) which limits the scope for remote exploitation; as with any network server it may become necessary to permit remote access for some client applications (this change would be announced and explained to users).
This communication is encrypted by an SSL connection in a similar way to the protection offered during online payment transactions. This provides assurance to the RPC client that any data transferred across the connection is protected from eavesdroppers and is going to/from only the KeePassRPC plugin. If the local (server) machine is compromised and the private key stolen, a malicious application could pretend to be KeePassRPC. This is bad but damage is likely to be limited to collection of new password data and hence is unlikely to result in widespread data disclosure unless data collection occurs over a considerable length of time.
Being an open source application presents unique challenges to secure public/private key communication since all keys that are included in the application are by definition NOT private. KeePassRPC works around this by borrowing a bit of code from the Mono project which allows the generation of a new private/public key pair on the user’s machine. This key is then stored in the .NET key store, providing a certain amount of protection against malicious users stumbling across it.
A more concerning issue exists though: What if the attacker pretends to be an RPC client and connects to KeePassRPC to extract all password data? In this case it is irrelevant whether the client can trust KeePassRPC and the encrypted transport protocol does nothing to stop the attacker accessing data. This exploit is particularly interesting to an attacker if they can connect to KeePassRPC remotely since execution privileges on the server running KeePass would not be required.
An examination of the KeePassRPC source code will show that this eventuality has been anticipated and the user has been given tools with which to protect themselves against this threat, giving the KeePassRPC plugin reassurance that the client requesting authentication is who it claims to be. To do this, the client sends its name and a cryptographic signature of that name to KeePassRPC. Using the public key in the KeePassRPC source code the plugin is able to confirm that the client’s name is accurate.
Job done? Not quite…
What is to stop an attacker from impersonating a known client? For example, said attacker could just look in the KeeFox add-on source code to extract the official KeeFox name and signature and send those to KeePassRPC for successful authentication and full access to the user’s passwords!
Protection against this threat relies on the client application (e.g. KeeFox) storing a private identifier and sending this to KeePassRPC (again, this must be generated dynamically rather than stored in the public source code). The combination of claimed name, official confirmed signature and unique private identifier gives KeePassRPC assurance that the authentication request has come from a known client. This information is of course transferred over the already encrypted transport layer.
There is a remaining problem: How does KeePassRPC know that it can trust one client but not another? Unfortunately we have to defer to the user’s own judgement here. Any previously unknown clients must be presented to the KeePass user for confirmation before their first successful authentication. Any clients that the user authorises are recorded in the KeePass XML config file to enable automatic authorisation for all future requests from that same client. The actual data written to the config file consists of a hash of the combined client identifier signature and unique private identifier.
This STILL leaves some unanswered questions:
What if someone manipulates the KeePass config file? This is where point B (back at the top of the article) is most keenly highlighted - if an attacker can manipulate the KeePass config file they have a variety of options open to them to exploit the password data. On the off-chance that it is ONLY the config file that they can modify then I think that KeePassRPC may be exposing a new attack surface. “Never say never” but I think this situation is as close to never as you could safely get (why would this be the only writeable file?!) If any other files are writeable or new files can be created there are thousands of other easier ways to break into a KeePass database without messing around calculating suitable SHA hashes.
What if the user is tricked into authorising a malicious client? The authorisation dialog boxes are presented in a way that should reduce the likelihood of this happening but we must accept it is a possibility, perhaps especially among those users who do not fully understand the language of the questions they are asked by KeePassRPC.
So this protection results in the following required handshake between an RPC client and the KeePassRPC server:
Client -> Server: Standard SSL handshake to encrypt transport channel
Client -> Server: JSON-RPC “Authenticate” request sent, including client version number, client name, base64 encoded signature of client name and a base64 encoded private identifier
Server -> Client (assuming successful authentication): Return value of 0 (zero) to the “Authenticate” method request
As explained in the previous post, you will need to contact me in order to get the correct signature for your chosen client name.
As announced earlier this year, KeePassRPC is a remote access interface plugin for KeePass Password Safe 2. This post is aimed at application developers; it outlines how you could use the plugin to enhance your user’s KeePass experience and references the latest version of the source code (0.8.5). There is currently no official release but you can see version 0.8.4 in use with KeeFox 0.8.4 and view the source code for 0.8.5 in the KeeFox SVN repository.
The RPC system is an implementation of JSON-RPC - this is a simple protocol and probably does not support every possible desired feature but clients are easy to implement and existing implementations exist for most programming languages already, so you don’t need to be a .NET C# expert to work with this plugin.
In fact, you don’t even need to be able to compile the C# source code to get started provided you’re happy to wait until the next experimental release of KeeFox. Either way, you will need to contact me to “register” the name of your client application and users will then require the latest version of the KeePassRPC plugin in order to use your client application - more details of this process are at the end of this post.
Note that no testing has been done with concurrent connections from multiple RPC clients. For this reason, there may be several parts of the plugin that exhibit multi-thread bugs when more than one client connects. The majority of the plugin code will be perfectly thread safe but I have had to prioritise getting the plugin working with a single RPC client (KeeFox) and have therefore cut a few corners which may need to be worked on before multi-client support is 100% stable. Please do let me know if you find any bugs (or better yet, any fixes for said bugs!)
The image below (click to see a larger version) shows some of the more important areas of the plugin architecture. The most relevant to anyone interested in calling the API is the KeePassRPCService class; most of the listed methods can be called by sending JSON-RPC requests to the RPC server. Many calls to the API will require or return Entry or Group objects. I’ll leave the detail of how to authenticate and some examples until a later post but please get in touch if you’re interested.
The API will experience very few changes over the next few months because I need it to remain stable in order to ensure that version 1.0 of KeeFox can be released with well-tested components. As the release of KeeFox version 1.0 approaches, I intend to branch the development of KeePassRPC so that an improved version 2 API can be produced, hopefully with input from other developers interested in communicating with KeePass Password Safe. If requested, I would be able to produce this branch fairly soon.
Version 2 is not currently under development but I hope it would include the features below.
- Extension system (probably through the use of additional KeePass PLGX plugins?). This will allow anyone to add support for new RPC clients without my involvement and will likely involve also adding support for a less KeeFox focussed entry/group window tab(s).
- Upgrade hash generation function from SHA128 to SHA256 for “future-proofed” security.
- Some kind of audit logging (maybe best via a 3rd party KeePass plugin)
- Give end user ability to ignore authentication requests from chosen KPRPC clients
- Integrated HTTP(S) server to enable easier access from most locations and applications
- Some kind of support for KeePass entry tags
So, if you can think of any way that your application could benefit from communication with a KeePass database please follow these steps:
- Leave a comment below or email me with the name of your client application as you would like it displayed to KeePass users (e.g. “KeeFox Firefox add-on”)
- Take a look at the source code for the plugin while you wait
- I’ll provide you with a base64 encoded hash of your client application name (after encryption with a private key) and instructions on how to use this to authenticate with the KeePass plugin
- Either you or I will need to change a couple of lines in the plugin to add support for your client application
- You can develop your client application using an experimental build of KeePassRPC until I release the next official version