Skip to content
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

Open
Quiark opened this issue Jan 29, 2016 · 12 comments
Open

Security problem for remote users #258

Quiark opened this issue Jan 29, 2016 · 12 comments

Comments

@Quiark
Copy link

@Quiark Quiark commented Jan 29, 2016

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

@Quiark
Copy link
Author

@Quiark Quiark commented Feb 1, 2016

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.

Description

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:

Suggested fix

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:

  • each encrypted item must be also verified for authenticity using keyed HMAC, AES-GCM or a digital signature
  • any errors inside the server handlers should not be detailed in the response. Just return a generic 503 message
  • watch out for timing attacks that can give out the same information as error messages
  • the Verifier field is completely useless because attacker can reuse the one that she captured earlier
  • ideally the entire message should be encrypted with authentication, not only some fields
@pfn
Copy link
Owner

@pfn pfn commented Feb 1, 2016

TLS will never be implemented for the plugin.

On Mon, Feb 1, 2016 at 7:16 AM Roman Plášil notifications@github.com
wrote:

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.
Description

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:

Suggested fix

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:

  • each encrypted item must be also verified for authenticity using
    keyed HMAC, AES-GCM or a digital signature
  • any errors inside the server handlers should not be detailed in the
    response. Just return a generic 503 message
  • watch out for timing attacks that can give out the same information
    as error messages
  • the Verifier field is completely useless because attacker can reuse
    the one that she captured earlier
  • ideally the entire message should be encrypted with authentication,
    not only some fields


Reply to this email directly or view it on GitHub
#258 (comment).

@pfn
Copy link
Owner

@pfn pfn commented Feb 1, 2016

Also, at this point, I would appreciate any forks to fix this, as I do not
plan on investing any significant time to maintain the browser trio (I
absolutely hate browser development).

On Mon, Feb 1, 2016 at 9:08 AM Perry Nguyen pfnguyen@hanhuy.com wrote:

TLS will never be implemented for the plugin.

On Mon, Feb 1, 2016 at 7:16 AM Roman Plášil notifications@github.com
wrote:

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.
Description

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:

Suggested fix

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:

  • each encrypted item must be also verified for authenticity using
    keyed HMAC, AES-GCM or a digital signature
  • any errors inside the server handlers should not be detailed in the
    response. Just return a generic 503 message
  • watch out for timing attacks that can give out the same information
    as error messages
  • the Verifier field is completely useless because attacker can reuse
    the one that she captured earlier
  • ideally the entire message should be encrypted with authentication,
    not only some fields


Reply to this email directly or view it on GitHub
#258 (comment).

@Morphlin
Copy link

@Morphlin Morphlin commented Mar 24, 2016

I use KeePassHttp remotely and completely agree with @Quiark. Keyed authentication is crucial in our case. @pfn thanks for the great software, I'm sure someone that's enjoys browser Dev could help take care of this.
Nice post @Quiark!

@TheZ3ro
Copy link

@TheZ3ro TheZ3ro commented Jan 13, 2017

This is high priority! keepassxreboot/keepassxc#147

I can't believe that the password is been exchanged in plain text in the associate request!

@pfn
Copy link
Owner

@pfn pfn commented Jan 13, 2017

@TheZ3ro
Copy link

@TheZ3ro TheZ3ro commented Jan 13, 2017

You are right but lot of implementation out there are listening on 0.0.0.0
The documentation is not very specific (or I'm missing something other than the Readme.md ?) and you should specify that it's limited to localhost usage.

@TheZ3ro
Copy link

@TheZ3ro TheZ3ro commented Jan 23, 2017

@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.

@pfn
Copy link
Owner

@pfn pfn commented Jan 24, 2017

jsha added a commit to jsha/keepassxreboot.github.io that referenced this issue Jul 13, 2017
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.
@kmille
Copy link

@kmille kmille commented Sep 14, 2018

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!

@Quiark
Copy link
Author

@Quiark Quiark commented Sep 14, 2018

@kmille
Copy link

@kmille kmille commented Sep 16, 2018

That's right. But the fix for the easy and reliable way to exploit the vuln does not hurt anyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.