How does KeepassRPC open a remote website exploit path (even if implemented incorrectly?)

#1

My perhaps naive assumption was that KeepassRPC potentially opened a network port on my machine which would:

1.) Normally be blocked by my Windows firewall.
2.) Only be exposed to my local network, due to the firewall in my router.

Based on the description accompanying the 1.12.1 release, it sounds like simply by running KeepassRPC, a malicious website can bypass both of those and so the KeepassRPC interface is in effect tunneled through both of these firewalls by my web browser? If this is right, running KeepassRPC is a LOT more risky than I thought it was.

Can you provide some explanation of how this works, or a link to an explanation of the underlying technology that allows this?

Thank you!

#2

KeePassRPC technical detail discusses things from the KeePassRPC perspective. The key section relevant to your question is the transport protocol. In our case, we use websockets and it turns out that there is no protection against any remote website from connecting to a websocket running on localhost.

There has always been the possibility of another system being able to remotely connect to the network port, firewalls permitting, so we designed the protocol such that any access attempts would be authenticated and transparent to the user. It is in two implementation details of this design that the vulnerabilities have been found and fixed.

At the time of development, this was the only possible way to connect KeePass to a browser extension. An alternative technology has been developed in the past few years (as mentioned in the security release announcement); we’re considering switching to that one day if times permits or someone contributes the code for the new approach, as per the GitHub issue https://github.com/kee-org/browser-addon/issues/23

#3

As a fix for the security problem (but not necessarily any of the workflow problems listed in issue 23) would you accept a commit for a helper application that basically just sends the websocket text over something like a bidirectional named pipe, and then modifies the plugin to have an option to turn off the network socket interface and open a named pipe instead?

#4

On the security topic, I had NO IDEA that using Kee meant opening a server that was reachable from every malicious ad that comes up in my web browser. That’s a much larger attack surface than I realized, and pretty scary when considering that there are no automatic updates to the KeepassRPC plugin.

Hopefully someone (possibly me) can find a way to limit this to a local (or at least local network) attack surface, where the vulnerabilities would then primarily be in the Kee plugin, which IS automatically updated.

Barring that, please do what you did with Kee 3.5 and release a new version of Kee any time a vulnerability is found in KeepassRPC that explicitly disallows connection to a vulnerable KeepassRPC plugin. That will at least force Kee users to upgrade their vulnerable KeepassRPC plugins immediately.

#5

I’ve replied to your question about issue #23 on that GitHub issue to keep discussion about that feature in one place.

Barring that, please do what you did with Kee 3.5 and release a new version of Kee any time a vulnerability is found in KeepassRPC that explicitly disallows connection to a vulnerable KeepassRPC plugin. That will at least force Kee users to upgrade their vulnerable KeepassRPC plugins immediately.

If there are ever any similarly critical vulnerabilities found in KeePassRPC then I would definitely take this same approach. For less critical ones I’ll make a risk assessment and decide accordingly.