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
KeePassRPC provides a remote access interface for KeePass Password Safe 2. There is currently no official release but you can view the source code in the KeeFox repository. The most interesting files are:
I’ll publish an more in depth introduction to those files soon.
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 libraries already exist for most programming languages.
Communication with the RPC server is currently via direct unencrypted TCP socket connections only. In future, I intend to add support for TLS encrypted sockets. It would also be possible to add a HTTPS server or even an alternative RPC protocol with the same API (e.g. XML web services). Although I think that a single plugin with a standardised API would be beneficial for KeePass plugin developers and users, we would need to avoid adding too many alternative access methods - a couple of protocols and a couple of transport mechanisms are probably OK though?
The API will experience minimal 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 may be able to produce this branch fairly soon.
In any event, I’d like to discuss what you might change about the API. What would you like to see? Is there any part that could be made simpler? What about user-interaction? Many parts of the API can trigger interaction with the user, is that a sustainable approach for a remotely accessible API or must we aim for a non-interactive service?
KeePassRPC is written in C# and utilises the JayRock libraries. It should run with the .NET Framework version 2.0 and higher as well as Mono, although thorough testing currently occurs only with .NET Framework 3.5 SP1.
Who doesn’t prefer the simple option? Software developers are no different and security software is generally better the simpler it is so a sensible rule-of-thumb is to always KISS whenever possible, that’s Keep It Simple, Stupid! Therefore, I am pleased that in the past few weeks I’ve been able to simplify the most crucial aspect of the way KeeFox communicates with KeePass.
The key change is that KeeFox now requires a new KeePass plugin called KeePassRPC instead of the (now retired) KeeICE plugin. This new plugin allows KeeFox and KeePass to communicate using a simpler language than was previously possible and makes some features much easier to implement. Most people won’t notice any difference but there are a number of benefits:
- Simplicity (ICE is complicated, making connection problems difficult to fix)
- Modifications to enable KeeFox to work in different environments should be easier (e.g. JetPack add-ons, other Mozilla applications, non-Windows operating systems)
- A secure communications channel between KeeFox and KeePass should now be possible (this communication never leaves your computer so the practical risks of using unsecured communication are not as high as might be feared but extra layers of security can only help)
- KeeFox can continue to work with .NET version 2.0 (the new version of ICE requires .NET 3.5 SP1 which is currently installed on about 25% fewer machines than version 2.0)
- The Mozilla add-ons review team will be able to scrutinise KeeFox faster and/or in more depth.
Of course, choosing to abandon the KeeICE plugin was a painful decision because it will delay the release of KeeFox version 0.8 and a large proportion of the time I have spent getting KeeFox 0.7 working reliably has been at least indirectly related to work on the KeeICE plugin. However, I think that the benefits far outweigh the drawbacks so ultimately the decision was the only sensible one I could take.
There will still be a bit of a wait before the new KeeFox development snapshot is ready, while I finish the migration to KeePassRPC and run some basic functionality tests to reduce the chances of new bugs creeping in.
I think that in future, other applications will easily be able to take advantage of the features that KeePassRPC offers. Look out for more technical details on this website if you are interested in adding further functionality to KeePass.
PS: Just in case anyone was developing with the KeeICE server plugin, let me know and I’ll help you either take on ownership of the KeeICE source code or migrate your project to KeePassRPC