Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Security problem for remote users #258
For users: make sure you don't enable remote connections to the plugin. In Options - Advanced - Host, it should be
I was looking into starting to use KeePass as the password manager and first thing I searched for was browser integration. I think KeePassHttp is a very useful tool but when I looked deeper I found some issues.
The communication between KeePass and the browser plugin is encrypted using AES 256. The implementation in KeepassHttp is not secure though. Attackers who are able to capture this encrypted traffic and send requests to the server can manage to decrypt captured passwords. Users who don't enable any remote connection and only stay on localhost for both client and server should be fine, others could be in trouble.
The fundamental problem is that the integrity of the encrypted entries is not protected using an authenticated MAC, authenticated encryption mode or a signature. This allows for the CBC padding oracle attack to be executed remotely to decrypt any encrypted entry that was captured earlier.
Leaking entire passwords to remote attackers is of course a serious problem but its impact is limited by the default setting to not allow remote connections. Furthermore, the padding oracle attack requires a few thousands requests to be executed, each of which pops an error tooltip on the targeted user's desktop. This doesn't mean that the user is protected though, a coworker could execute this attack when the target is away from the computer for example.
Leaving this particular vulnerability aside, the project's GitHub description says that KeepassHttp exposes password entries securely. I think most users, especially as the project reaches a wider user base, will just take that for granted and not pay attention to the caveat that the first key exchange is totally unprotected.
CBC padding oracle attack:
Cryptographic best practices:
Short-term mitigation: An update for KeepassHttp that disables remote access completely or at least strongly warns users about this danger. Direct users in how to securely perform the association (with a disconnected computer).
Proper fix: Use cryptography best practices or, even better, use a TLS connection with self-generated certificates that the user confirms on both ends. Cryptography best practices in this case would be:
TLS will never be implemented for the plugin.
On Mon, Feb 1, 2016 at 7:16 AM Roman Plášil firstname.lastname@example.org
Also, at this point, I would appreciate any forks to fix this, as I do not
On Mon, Feb 1, 2016 at 9:08 AM Perry Nguyen email@example.com wrote:
First of all, this is over localhost. If you can be sniffed over localhost, your security has already be broken, game over. Secondly, this is documented. If you are wanting to use keepasshttp over the Internet, you should add keys manually. Keepasshttp does not work over non localhost by default…
On Fri, Jan 13, 2017, 11:29 AM TheZ3ro ***@***.***> wrote: This is *high priority*! keepassxreboot/keepassxc#147 <keepassxreboot/keepassxc#147> I can't believe that the password is been exchanged in plain text in the associate request! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#258 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfQxYVsIjDR2gKIDlwB6iza6EhRAyhoks5rR9CngaJpZM4HO5MN> .
@pfn do you think you can address this?
Anyway what you said here is a "bad" simplification of reality.
No, this is false, once an attacker has compromised your system sufficiently to sniff localhost traffic, they will have access to everything. Being able to sniff localhost implies root access and full capability to dump memory. Only thing I would support would allowing for an easier method to exchange keys out of band. (ie showing a dialog for manual key entry, and having the browser extensions show their keys) Any "secured" method of key exchange would require extensive and invasive user interaction to enable. The only fixes I'm interested in are for any padding Oracle issues as implied by the referenced thread. This should be solvable by catching exceptions and not returning an error response. On Mon, Jan 23, 2017, 3:24 PM TheZ3ro <firstname.lastname@example.org> wrote: @pfn <https://github.com/pfn> do you think you can address this? I'm willing to help implementing an alternative key exchange protocol (I said alternative so both can be supported and maybe let user chose to use the secure one with an option in passIFox/chromeIPass) First of all, this is over localhost. If you can be sniffed over localhost, your security has already be broken, game over. Anyway what you said here is a "bad" simplification of reality. If an attacker can sniff on localhost, and the key is exchanged properly, this won't leak my password! (if he does have a keylogger/clipboard-stealer but the user use KeePassHTTP and leave his database closed this the attacker can't do anything) Even if my PC is compromised I hope my password will still be safe and private. This is the scope of a password manager. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#258 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfQxXOEEEYUMuaCZrwKV5_MafWbt_Cjks5rVTalgaJpZM4HO5MN> .
added a commit
Jul 13, 2017
referenced this issue
Dec 14, 2017
This is implemented right for the decryption of the encrpyted IV (Nonce) in Protocol.cs (line 25: TestRequestVerifier). As you can see there is a try catch surrounding the decryption of the nonce. If there is an exception the client will get a 200 and no 500 response.
If you need further explanations or help please ask!
With a fix like this you still run the risk of having a timing or other side channel. The only correct fix is having authentication on the ciphertext using either HMAC or GCM or other authenticated mode. pá 14. 9. 2018 v 17:11 odesílatel busbauen <email@example.com> napsal:…
Hey, i wanted to report the same issue. I wrote a CTF challenge and exploit for this vulnerability. The fix for the padding oracle attack is pretty easy (you don't have to move away from CBC even if GCM would be a better AES mode): Just don't tell the client if there was an Padding Exception during decryption. This is implemented right for the decryption of the encrpyted IV (Nonce) in Protocol.cs (line 25: TestRequestVerifier). As you can see there is a try catch surrounding the decryption of the nonce. If there is an exception the client will get a 200 and no 500 response. Decrypting the encrpyted url does indeed return the exception to the client (KeePassHttp.cs line 86). To fix this vuln add a try catch to the KeePassHttp.cs like in Protocol.cs If you need further explanations or help please ask! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#258 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADmw8ZTfVdrBU8DcAb2rwmzO5Fkrv4nks5ua2pAgaJpZM4HO5MN> .