-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security problem for remote users #258
Comments
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. DescriptionThe 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: Suggested fixShort-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 notifications@github.com
|
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 pfnguyen@hanhuy.com wrote:
|
This is high priority! keepassxreboot/keepassxc#147 I can't believe that the password is been exchanged in plain text in the |
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>
.
|
You are right but lot of implementation out there are listening on 0.0.0.0 |
@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 <notifications@github.com> 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>
.
|
I am helping to edit a guide to using KeePassXC, and found that the author had inserted a warning: "If your machine is compromised, an attacker can intercept the communication between your browser plug-in and KeePassXC." I believe that was motivated by the warning text here. As noted in pfn/keepasshttp#258 and keepassxreboot/keepassxc#147, communicating via HTTP with localhost is safe, since an attacker who can intercept localhost communications can just read your passwords directly. Since localhost-only is now the default mode in KeePassHTTP, I think this note just creates confusion and unnecessary fear among users.
Hey, 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 <notifications@github.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>
.
|
That's right. But the fix for the easy and reliable way to exploit the vuln does not hurt anyone. |
Hi,
can't get the author's email but there's a security issue affecting users who allow remote connections to KeePassHttp.
@pfn, please contact me at me@rplasil.name for details.
For users: make sure you don't enable remote connections to the plugin. In Options - Advanced - Host, it should be
localhost
The text was updated successfully, but these errors were encountered: