First of all thanks a lot for the extraordinary good handling of this vulnerability. All steps taken and all information provided I have seen so far seem exemplary!
Now I’m still wondering if there is a public demo exploit. From what I’ve read so far I assume there is none (and personally I’d feel better when that stays for a while like that ;-)). But do you plan to release one at some point and if so could you announce it then?
After looking at the git change set I figured that one would still need Kee/PassRPC specific knowledge, just like you wrote, of the auth process to wirte an exploit. And I didn’t dive into the code so far to do that. However if there is a public exploit or will be at some point I’d be interested in how fast and maybe unnoticed it would go on my specific systems (and if it is really near the minute mark or far off - which I would assume right now…). Therefore I kept the old plugin on all systems which were using it and would do a check once there is a demo. And if it really is a matter of seconds maybe re-evaluate the specific system risk.
I wouldn’t recommend keeping the old plugin files around on your system for later testing unless you anticipate significant difficulties connecting the system to the internet in future. All old KeePassRPC releases for the past few years are available at https://github.com/kee-org/keepassrpc/releases so you can download a vulnerable version as and when you are ready to perform some careful testing.
I haven’t analysed the full set of factors that would affect the speed of the 2nd vulnerability (weak random numbers) but I understand that the security researchers who identified the vulnerability are planning to write a bit more about it in the future so perhaps some more details about these factors will become known at that point.
However, for the 1st vulnerability (missing client parameter check) there is no significant time required for the vulnerability to be exploited so I think that makes the timing for the 2nd one moot. It sounds like this detail may have been unclear in my original announcement so I will re-vist it soon to see if there is some way to clarify that there is not always going to be a noticeable delay when an exploit executes.
No public demo exploit has been published, and nor do I intend to do so. If / when a malicious exploit (most likely for the 1st vulnerability) begins circulating in the wild, there may be some benefit in me or the security researchers releasing some example code to help others to learn from my mistakes but it is too early to say if this will definitely happen.
I have another question which is related to the proof of concept exploits:
Is it possible that any browser protection (another browser add-on or a system wide protection) would have blocked the code performed by malicious websites?
Under which circumstances did you test the exploits?
For instance: Does the NoScript Firefox add-on block these requests? Does the wide-spread uBlock Origin offer any protection regarding this vulnerability?
The vulnerability can be exploited by literally anything which can connect to your local host via a HTTP/WebSocket connection and here connect to KeePass with the vulnerable plugin active on the KeePassRPC port (default 12546).
To do so from any website which you open in your browser a few lines of JavaScript are enough.
Now that means:
If you prevent JavaScript on sites which you don’t trust (or all sites) for example with an extension like NoScript, those sites can not exploit the vulnerability.
System wide security software (or other security extensions) which scans for malicious code on websites does not offer protection (yet) since the malicious code required is specific and not yet known. Therefore there is no signature of it and the security software simply “does not know” yet that this code is malicious. However, if the malicious website would host other malware code as well which the security software already knows, it could still block the site.
With that in mind and @luckyrat answer it is really unlikely that the vulnerability was already exploited. However, once more information about the specifics of the exploit code from the security researchers (or even a demo exploit) gets published, exploiting it will be relatively easy.
Thanks for you answer. I also came to this conclusion after some research.
The one thing which really shocked me and I wasn’t aware of is that any website can access localhost and/or LAN through a stock-config web browser.
I blocked this via uMatrix. Anyone interested in blocking access to localhost/LAN can view the instructions here: https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.2.3-uMatrix
With such a block in place, the exploit shouldn’t have been possible. Am I right?
I did not thoroughly evaluate all potential mitigating factors. The fact that the exploit is possible in any circumstance is all that I needed to know before releasing the fix and announcing the vulnerability.
This is correct; also bear in mind that if a site that you have previously whitelisted is then subsequently hacked and this hypothetical KeePassRPC exploit code is installed onto the site, you would be as vulnerable as if you were not using the NoScript extension.
This is most likely also correct, although not all system security software relies only on signatures. The efficacy of such behavioural analysis solutions is questionable so there is certainly no guarantee of protection but one might expect that a connection from a web browser’s content process to a localhost websocket would be considered at least a little bit suspicious. Overall though, I don’t think it is very likely that any system-based protection would have been effective.
Anything that blocks all remote hostnames from accessing localhost would prevent the vulnerability from being exploited. Whether this is practical without also preventing the Kee extension from connecting from the browser to KeePassRPC would depend upon the specific tools being used to implement that block.
Thanks for sharing the link to information about uMatrix - I’d be interested to hear how successful this approach is.
