Today we published a new version of KeePassRPC (1.12.1) which resolves critical security vulnerabilities in all previous versions of the plugin.
To ensure that your passwords stored within KeePass Password Safe remain secret, you must install this new version immediately.
This does not affect Kee browser extension users that store passwords only in Kee Vault.
This is not a vulnerability in the Kee browser extension so re-installing, updating, downgrading, disabling or removing Kee will not affect your exposure to this risk.
If you are unsure whether you are affected, simply follow the instructions for updating KeePassRPC. If you find an old version of KeePassRPC.plgx on your computer, you should replace it with the newest version immediately.
Download version 1.12.1 or newer from GitHub and install it right now. If you’re unsure how to install a new version of a KeePass plugin, we have documentation to help you at Upgrading KeePassRPC.
Additional information about the update
Version 1.12.0 and 1.12.1 both contain the fixes for these vulnerabilities. If you’re one of the few people who have installed version 1.12.0, you only have to upgrade to 1.12.1 if you want to connect the KeeBird Thunderbird email client extension to KeePassRPC. Unless you already have version 1.12.0 installed, please install version 1.12.1.
If for some reason you are unable to update to the new version, some mitigating actions include:
- Lock your KeePass databases and do not unlock them until the plugin has been updated
- Close all web browsers and do not browse the internet until the plugin has been updated
- Change the websocket port that KeePassRPC listens on
The 3rd suggestion relies on security through obscurity and is thus unlikely to greatly reduce your risk for very long. Obviously all 3 of the above suggestions are very significantly worse than simply updating the plugin straight away.
About the vulnerabilities
Credit for discovering and responsibly disclosing the two related vulnerabilities goes to Philipp Danzinger, Michael Pucher and Georg Merzdovnik for helping explore the vulnerabilities as well as co-developing and hosting the proof of concept exploits.
Successfully exploiting either vulnerability results in an attacker gaining access to all passwords in any open KeePass databases. No obvious user interaction is required, only a visit to a malicious web site; in some cases there is no visible evidence that the vulnerability is being exploited.
'ALL' passwords may not strictly be true for every user. Expand this section to learn about the subtle potentially mitigating details
KeePassRPC offers an occasionally-used feature called “Kee home group”. For each open database in KeePass, KeePassRPC will only reveal passwords if they are contained within this group.
Additionally, individual password entries can be hidden from KeePassRPC.
For most people the entire database of entries was at risk of exposure but for those that utilise either of these two features, that action may have limited the set of entries that were at risk of exposure.
Even if you used these features to manage your entries, an additional factor may still have allowed all entries to be exposed. As explained in the KeePassRPC user interface and existing documentation, enabling the KeePass placeholders feature is a security risk in its own right. If you had any entries visible to KeePassRPC which had the placeholder feature enabled, it is feasible that an attacker could have used this to access all entries.
It is also worth remembering that KeePassRPC only ever sees entries which have a URL field set so if that field is empty, the contents of the entry can only have been at risk if you also utilised the placeholders feature.
Update: An initial version of this announcement stated that remote code execution would be possible via placeholders. Deeper investigation has confirmed that this was not possible. Apologies for the additional alarm but I felt it was better to err on the side of caution.
We consider this to be the most serious category of security vulnerability and implore you to take immediate action - KeePass does not have an automatic update feature so you must apply the fix yourself.
These vulnerabilities were not previously publicly known so if you take prompt action, it is extremely unlikely that your passwords have been exposed. However, it is not possible to determine with 100% certainty that you were not targeted by a malicious attacker so you may wish to change your passwords, at least somewhat sooner than you otherwise would have done. For what it’s worth, I will personally be undertaking a password change procedure on all passwords that can feasibly be used to access systems that affect the integrity or security of KeePassRPC, the Kee browser extension, Kee Vault and all related services. Otherwise, I think that the risk is low enough that I will not be accelerating my usual 5-20 year change cycle for any other passwords.
Your master password is never exposed through KeePassRPC and the security of your kdbx file remains intact. It is the individual entries within your KeePass database that were at risk.
Kee 3.5 contains many improvements relating to password saving so if you choose to change any of your website passwords, you may wish to do so using the latest beta version. We’ll be requesting that this version of Kee is released to all Kee users very soon but it can take many weeks for the web browser developers to approve a new release.
The two vulnerabilities outlined below reside in the SRP authentication implementation; successful exploitation allows an attacker to bypass the usual password-based authentication procedure.
- A piece of information supplied by a KeePassRPC client was not correctly validated before being relied upon in the SRP algorithm.
- The use of a non-cryptographically secure random number generator in a cryptographically sensitive calculation vastly increased the chance of an attacker being able to guess their way past the usual protection that SRP offers. On some systems a successful exploitation could go unnoticed and complete in less than one minute, although in many cases it would take longer and result in noticeably “strange” behaviour that could alert a user to the threat before it succeeds.
Both vulnerabilities have now been addressed and I have additionally developed a further security layer to reduce the chance that future vulnerabilities in the SRP server could be exploited by malicious websites. In case this additional security layer poses a problem for any consumers of KeePassRPC that are not modern browser extensions, the information I’ve posted in this new documentation topic will allow you to work around the new limitation.
What you can do to help
No single person or organisation can release perfectly secure code so it is great to see the wider security community probing our Open Source software for vulnerabilities like this.
Perhaps you have the experience to help too? As well as reviewing the source code and seeking out vulnerabilities, you may be able to help to reduce the attack surface of KeePassRPC by developing a modern replacement for the HTTP-based communications protocol (websockets) that allowed these vulnerabilities to be exposed to remote systems. We may not be able to make this change without breaking backwards compatibility and it may limit the usefulness of KeePassRPC outside of the context of a browser extension but these drawbacks may be a price worth paying in order to reduce the risk of a similar vulnerability being exploited in future. I’m undecided if it is something we should actively pursue and don’t currently have the resources to implement it alone. Please check out the relevant GitHub issue if you are interested in helping out.
If none of the above sounds like it’s your thing please check out other ways you could help at Contributions, bugs, help and support guidelines .
My priority for the past 24 hours has been ensuring a fast and thorough response to the discovery of this vulnerable SRP server implementation. As such, I can’t yet be very definitive regarding how or why these implementation mistakes were made. It appears as though they can be traced back to code that I wrote around a decade ago when so many factors were different to today. At a later date I will perform a more in-depth analysis of the likely causes - my initial thoughts lead me to think that some significant factors will have been the lack of available battle-tested .NET implementations of big integers and SRP6a.
Distributing critical security updates for a KeePass plugin has never been easy but I hope that this announcement, the use of the optional update notification feature within KeePass and the upcoming version 3.5 of the Kee browser extension - which will refuse to work with any earlier version of KeePassRPC - will all go some way towards accelerating the uptake of this important software update. Please point your co-workers, friends and acquaintances to this forum topic if you think they may also need to install this update.
In case it needs explicitly stating, I can confirm that I am personally very sorry that these vulnerabilities were introduced into KeePassRPC and remained present for so long. I am therefore very grateful to the security researchers (Philipp Danzinger, Michael Pucher and Georg Merzdovnik) who discovered the vulnerabilities and so professionally and clearly conveyed their findings to me.
I will prevent replies being added to this topic because posts in this category are often pushed to the community by email but please do post a new topic on this forum if you have any questions - I can’t promise a personal reply but I’ll try my best and hopefully other members of the community can help out when I’m not available.
I’m sure you’ve already done it but just in case: Upgrade KeePassRPC.plgx now!