Security problem for remote users

[Quiark]

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]

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:

• http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/
• http://robertheaton.com/2013/07/29/padding-oracle-attack/
• http://cryptopals.com/sets/3/challenges/17/

Cryptographic best practices:

• https://gist.github.com/tqbf/be58d2d39690c3b366ad

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]

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:

• http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/
• http://robertheaton.com/2013/07/29/padding-oracle-attack/
• http://cryptopals.com/sets/3/challenges/17/

Cryptographic best practices:

• https://gist.github.com/tqbf/be58d2d39690c3b366ad

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]

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:

• http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/
• http://robertheaton.com/2013/07/29/padding-oracle-attack/
• http://cryptopals.com/sets/3/challenges/17/

Cryptographic best practices:

• https://gist.github.com/tqbf/be58d2d39690c3b366ad

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]

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]

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]

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

[TheZ3ro]

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]

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

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

[kmille]

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!