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

Comments

Projects
None yet
5 participants
@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

This comment has been minimized.

Show comment
Hide comment
@Quiark

Quiark 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

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

This comment has been minimized.

Show comment
Hide comment
@pfn

pfn Feb 1, 2016

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@pfn

pfn Feb 1, 2016

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@Morphlin

Morphlin 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!

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

This comment has been minimized.

Show comment
Hide comment
@TheZ3ro

TheZ3ro 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!

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

This comment has been minimized.

Show comment
Hide comment
@pfn

pfn Jan 13, 2017

Owner
Owner

pfn commented Jan 13, 2017

@TheZ3ro

This comment has been minimized.

Show comment
Hide comment
@TheZ3ro

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

This comment has been minimized.

Show comment
Hide comment
@TheZ3ro

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

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

This comment has been minimized.

Show comment
Hide comment
@pfn

pfn Jan 24, 2017

Owner
Owner

pfn commented Jan 24, 2017

jsha added a commit to jsha/keepassxreboot.github.io that referenced this issue Jul 13, 2017

Remove note about KeePassHTTP
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.

@varjolintu varjolintu referenced this issue Jun 9, 2018

Open

Security #28

@kmille

This comment has been minimized.

Show comment
Hide comment
@kmille

kmille 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!

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

This comment has been minimized.

Show comment
Hide comment
@Quiark

Quiark Sep 14, 2018

Quiark commented Sep 14, 2018

@kmille

This comment has been minimized.

Show comment
Hide comment
@kmille

kmille Sep 16, 2018

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

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