Latest information about the KeePassRPC security vulnerabilities discovered last week

Project news
1

As you would expect, it’s been busy a week here. Lots of work is still ongoing to ensure our response to the KeePassRPC security vulnerabilities is as thorough as possible. I wanted to take some time to outline the most interesting developments since the vulnerability announcement last week…

  1. Around 16,000 downloads of the fixed version of KeePassRPC have been initiated. Considering the number of Kee browser extension and Kee Vault service users, it is likely that this is less than half of potentially vulnerable users - if you or anyone you know has yet to install the updated version, please do so immediately.

  2. I’ve released a new version of KeePassRPC - 1.13.0. This includes an additional defence against the risk from the most critical of the vulnerabilities fixed in version 1.12.0 and a way for you to detect if some historical compromise of your database has actually occurred - the details of how this works, its limitations and some related guidance are included in point 5 below. We recommend that you install this latest version soon, as with any software update, but there is not the urgency associated with version 1.12.x last week.

  3. The security researchers have recently published an article discussing some of the background to the vulnerabilities and their take on the situation: https://danzinger.wien/exploiting-keepassrpc/

  4. Both our and the independent researchers’ evaluation of the risk still points to a very low chance that the vulnerability has previously been exploited but we can not completely rule out that possibility.

  5. I can now provide further information to guide your unique risk assessment procedure.

    To ensure you gain most benefit from this information, you must first update to KeePassRPC version 1.13.0. We also recommend that you take a backup of your KeePass.config.xml file before taking any actions described in this section.

    Unless you enabled the “High security” connection mode, KeePassRPC stores information about authorised clients until you manually delete the information.

    For most users this situation therefore offers an audit trail for you to further determine whether your database was compromised before you upgraded to v1.12.0 or higher.

    Method 1

    An exploit of the far easier, faster and more stealthy first vulnerability (missing client parameter check) leads to a predictable encryption key being associated with the connection.

    If KeePassRPC 1.13.0 or higher receives a connection request from a client that uses this key, we will prevent the connection from succeeding and warn you that your databases were probably compromised. We also check all known authorised clients when you open the “KeePassRPC (Kee) Options” dialog and highlight any suspicious clients in red.

    We therefore recommend that you open this dialog in KeePassRPC 1.13.0 to confirm that no warning message is displayed.

    We have created additional documentation to explain this feature and outline what you should do if a warning is displayed to you: CVE-2020-16271 Warning message

    Method 2

    The above test for a previous exploit can not detect if the 2nd exploit was successful. This vulnerability would be harder for an attacker to exploit without your knowledge but some further manual investigation can add additional confidence that it was not exploited before you upgraded KeePassRPC.

    You can review the list of authorised connections in your “KeePassRPC (Kee) Options” > “Authorised clients” dialog. There are several critical facts to know about this dialog if you wish to use it to assess the likelihood of a successful historical exploit:

    • These authorised connections remain in this history view even after a KeePassRPC upgrade so there is no need to delay upgrading if you have not already done so.
    • They will be lost if you delete your KeePass.config.xml settings file.
    • When you “revoke” an authorisation, the information is permanently removed (unless you also maintain backup versions of KeePass.config.xml).
    • The Expiry date is calculated from the most recent time that you authorised the client; you may or may not have authorised a client with that same Unique ID at an earlier point in history but only the most recent authorisation time can be inferred from the current Expiry time.
    • The Connected column indicates whether the connection is currently active.
    • The Name and Unique ID offer a way to differentiate well-behaved clients - they can not be trusted to help you to determine if any client is malicious.
    • You can drag the width of the Expires column to view the time of expiry as well as the date.

    Thus, if you trust your date arithmetic and your memory of each time you authorised each client that you have intentionally authorised to access KeePassRPC, you can establish a pretty accurate idea of whether any clients should be treated with suspicion.

    If you find any such clients and their expiry date has not passed, you should revoke them and consider if your level of confidence in the origin of that authorisation merits further action such as changing the passwords held within your database.

  6. As implied in point 5, once authorised, a client can use the established secret key to reconnect to KeePassRPC until the successful authorisation expires. This means that a malicious client would only need to exploit a vulnerability once and could then reconnect until your chosen expiry date (1 year by default). Given that KeePassRPC 1.12.x and higher introduces additional protection against websocket connections from websites, this is unlikely to be exploitable in any meaningful way.

  7. Since the initial announcement, our community has also explored some mitigating factors such as remote script execution blocking browser extensions and certain KeePass database configuration features such as the KeePassRPC home group and hiding individual entries from the Kee browser extension. We expect that a minority of users may therefore have been immunised against the vulnerability. Searching the community forum for these discussions could prove interesting but we caution against expecting to find that your particular configuration was definitively immune.

  8. Two CVE IDs have been assigned to the related vulnerabilities by NIST:
    https://nvd.nist.gov/vuln/detail/CVE-2020-16271
    https://nvd.nist.gov/vuln/detail/CVE-2020-16272

    Thanks again to Philipp Danzinger and the team at TU Wien University for organising this formal step in the vulnerability management process.

  9. I’ve traced the introduction of the faulty code to this commit that formed a lot of the development work for KeeFox 1.3 around 7 years ago. Versions of KeePassRPC earlier than 1.3 did not rely on SRP for authentication (instead a client certificate was installed - see this old wiki page for reasoning why we started using SRP if you’re interested in archaeology).

  10. I have recently pinned this post and the security release announcement to the top of this forum to ensure that it remains highly visible for some time yet.