Mar 022016
 

This post is about a Man in the Middle (MitM) vulnerability in KeePass 2’s automatic update check. KeePass – the free and open source password manager – uses, in all versions up to the current 2.33, unencrypted HTTP requests to check for new software versions. An attacker can abuse this automatic update check – if enabled – to “release” a new version and redirect the user to a malicious download page. Update: At the first start the users is asked if he wishes to enable the recommended update checks.

During a recent traffic analysis I stumbled upon an interesting request to http://keepass.info/update/version2x.txt.gz. As I had a few hours spare over the last weekend I took a closer look.

Screen Shot 2016-02-08 at 10.40.20

It turned out that KeePass 2’s automatic update check uses HTTP to request the current version information. For that purpose it downloads the following text file from http://keepass.info/update/version2x.txt.gz

:
KeePass:2.31
ArcFour Cipher Plugin:2.0.9
CodeWallet3ImportPlugin:1
DataBaseBackup:2.0.8.6
DataBaseReorder:2.0.8
EnableGridLines:1.1
eWallet Liberated Data Importer:0.12
IOProtocolExt:1.11
ITanMaster:2.28.0.2
KdbxLite:1.1
KeeAutoExec:1.8
KeeOldFormatExport:1
KeeResize:1.7
KPScript - Scripting KeePass:2.31
OnScreenKeyboard2:1.2
OtpKeyProv:2.4
PwGen8U:1
PwGenBaliktad:1.2
QR Code Generator:2.0.12
QualityColumn:1.2
Sample Plugin for Developers:2.0.9
SpmImport:1.2
WinKee:2.28.0.1
:

If a new version is available the following dialog is shown to the user. An attacker can modify – thought for example ARP spoofing or by providing a malicious Wifi Hotspot – the server response to introduce a new version and thereby force the following dialog to be shown. (Already heard about the new KeePass 9 release?)

Screen Shot 2016-02-08 at 10.52.20

If the user now clicks within the update dialog to download the new version, the URL http://keepass.info/ is opened to manually download the new release. Guess what, we can also intercept that traffic as it again uses HTTP. Thereby an attacker can even indirectly control the downloaded “update”.

The following video shows the attack in all it’s glory:

Suggested solution

For any security centric tool – like a password manager – it is essential to not expose its users to any additional risks.

Hence, I strongly recommend that all requests should be switch to encrypted HTTPS communication – especially version checks and updates! This should be fairly easy to implement and should not introduce any compatibility issues. Furthermore a valid certificate should be used for https://keepass.info and all unencrypted HTTP requests should be redirected to the encrypted version of the site. To provide even more security it is recommended to add the HTTP Strict Transport Security (HSTS) headers. As an alternative the update check feature could be removed.

Workaround

Until the version check has been switched to HTTPS update notifications should be taken with a grain of salt. To be on the safe side, new releases should be downloaded only directly from Keepass’s secured Sourceforge page: https://sourceforge.net/projects/keepass/

Changelog

  • 8.2.2016 @ 11:30: Issue privately reported to Dominik Reichl (http://keepass.info/contact.html)
  • 8.2.2016 @ 12:00: CVE number requested
  • 8.2.2016 @ 15:45: Received response from Dominik Reichl: The vulnerability will not be fixed. The indirect costs of switching to HTTPS (like lost advertisement revenue) make it a inviable solution.
  • 30.5.2016 @ 18:00: MITRE assigned CVE-2016-5119; I reconfirmed that version 2.33 is still vulnerable
  • 2.6.2016 @ 10:00: Here is an official statement from Dominik Reichl regarding this issue.
  • 2.6.2016 @ 15:30: Even the Internet Storm Center at SANS mentioned my post about KeePass’s auto-update check over HTTP in their Daily Network Security and Information Security Podcast.
  • 6.6.2016 @ 7:00: Dominik Reichl released another post on this issue: from version 2.34 on the update information will be digitally signed. This mitigates man-in-the-middle attacks successfully.
Print Friendly

  34 Responses to “CVE-2016-5119: MitM Attack against KeePass 2’s Update Check”

  1. Keepass is released in two different versions, the 1.x series and the 2.x series. You only discuss the 2.x series. Is the 1.x series vulnerable to this, and if so, why isn’t the author changing the 1.x update file to be digitally signed?

    • Very good input! I verified this and you are right: KeePass 1 can also be tricked into thinking that there is a new version…. It still uses HTTP without any kind of digital signature for checking the current version.

  2. Any “security” software that does not arrive via a package manager that checks signatures automatically, has to be checked by the end user.

    HTTPS is not a package manager; for instance it allows delivery of bogus installers placed on the download site by a hostile party to run full speed ahead. The same hazard applies with downloads via web browser, and worse: An SSL connection validated by a web browser can be signed by any of thousands of legitimate certificates that may fall into hostile hands, potentially enabling impersonation or MITM attacks by anyone positioned to spoof DNS requests or control a router affecting potential victims’ network connections.

    The TOR Browser Bundle does self-updates right: A signing key unique to the TOR project is included in the installer, and when the installed version checks for updates, it checks the signature on the update against that key. Think of it as a chain of custody: If the distributor’s digital signature indicates that the first version installed was genuine, the signatures on all updates will prove that /they/ are genuine without user intervention.

    The first and most vitally important link in that chain is for the user to manually check the GPG signature of the first version downloaded and installed. That puts even the self-updating Browser Bundle in the same boat as KeePass2: If the end user fails to validate the first installer as authentic by checking its GPG signature, the end user can can only guess whether the program and all updates to it are legitimate or forgeries.

    Long story short: Anything that does not arrive via a the user’s operating system package manager, needs to be manually inspected to verify its authenticity. By itself HTTPS only adds a speed bump to the forgery and impersonation process.

    • Hi thanks for your comment. I agree with you on a technical level for most of your points. However, I also think that generic endusers don’t care about things like digital signatures. From my perspective that means that either the application does check its updates in a secure manner or simply does not include any update checks at all. And you are right, a custom digital signature covers every attack vector I can think of – however sometimes any solution is better than no solution! Furthermore breaking SSL is not even close as easy as you suggest in your post – simply controlling DNS or the router is not sufficient.

  3. Dominik Reichl has posted a response to these concerns, “Automatic Update Vulnerability,” at Keepass.info. He explains that the surest safety in this matter is for users to right click on any update notice and any update file they download, right click on the file and in Properties check the digital signature. The key for that is not kept on his server or other servers Keepass can be downloaded from, so that even if his or another server were to be compromised, the notification of update file and/or update itself could not be properly signed. Reichl says always checking the digital signature provides the best possible security for users, while using https is a lesser means of security.

    I am not an expert in this area, but Reichl’s clear explanation makes good sense to me. He’s including his digital signature in both update notifications and update files from version 2.34 on. I am going to turn automatic checking for updates on again and make it a point to check for digital signatures from now on.

    • Thanks for the update. I added the new information to the changelog at the bottom of the article.

  4. […] An anonymous reader quotes this report from Engadget: Think it’s bad when companies take their time fixing security vulnerabilities? Imagine what happens when they avoid fixing those holes in the name of a little cash. KeePass 2 developer Dominik Reichl has declined to patch a flaw in the password manager’s update check as the ‘indirect costs’ of the upgrade (which would encrypt web traffic) are too high — namely, it’d lose ad revenue… […]

  5. […] Details könnt ihr im Blog von Florian Bogner finden, welcher die Verwundbarkeit entdeckt hatte. Außerdem stellt er ein Video zur Verfügung, in […]

  6. […] they avoid fixing those holes in the name of a little cash. KeePass 2 developer Dominik Reichl has declined to patch a flaw in the password manager’s update check as the “indirect costs” of […]

  7. […] they avoid fixing those holes in the name of a little cash. KeePass 2 developer Dominik Reichl has declined to patch a flaw in the password manager’s update check as the “indirect costs” of […]

  8. I’m a noob in this area, but wouldn’t the idea that it’s open-source software means that someone who is savvy enough can convert the update code into https without having the original author do it?

    • Hi, yes this COULD be done. However, as the – let’s call it – reference implementation, the original KeePass will still be the one most people will download and use. So while technically true, I think forking is no viable solution in this case.

  9. […] they avoid fixing those holes in the name of a little cash. KeePass 2 developer Dominik Reichl has declined to patch a flaw in the password manager’s update check as the “indirect costs” […]

  10. Thanks for the alert. However, I don’t recall seeing any ads in Keepass.

    • Hi, you are absolutely right: There are no ads… This makes the whole story even more difficult to understand…

      • HTTPS would have to be used by the KeePass client AND the main website, keepass.info, which has ads. I assume HTTPS would interfere with his current ad provider for the site.

        • Yes I also think that Dominik meant the lost revenue of keepass.info. However even switching only the app to HTTPS would temporary increase the security level, as then MitM attacks could only be carried out if there is a real new update available.

          • Including the installer signature in the update information file would stop that attack, too.

  11. […] they avoid fixing those holes in the name of a little cash. KeePass 2 developer Dominik Reichl has declined to patch a flaw in the password manager’s update check as the “indirect costs” of […]

  12. […] lubang mereka dalam nama sedikit uang tunai. KeePass 2 pengembang Dominik Reichl memiliki ditolak untuk menambal cacat di cek pembaruan password manajer sebagai “biaya tidak langsung” […]

  13. […] recently discovered security flaw in the popular KeePass password manager adds yet another reason to that […]

  14. For ANY application that sells itself for the purpose of security to use unencrypted communications for anything is unforgivable.

  15. all keepass download are anyway hosted at sourceforge , its a better workaround to check the cryptographic hash and pgp sign key here http://keepass.info/integrity.html and here: http://keepass.info/integrity_sig.html

    • Hi detki,
      Thanks for your post. You are right, as a workaround it’s a good idea to directly download from sourceforge. However, I still think that if you do automatic update (checks) in your application you should do it right (or remove the feature).

  16. […] 5 Security links KeePass Password Safe update check vulnerable to MITM, wont fix Google pays $65k to shutter 23 Chrome bugs 427 million MySpace passwords leaked 65 million Tumblr […]

  17. […] developer of KeePass won't fix the issue according to the […]

  18. […] versions: all tested version up to the current 2.33 Tested on: Windows 7 CVE : CVE-2016-5119 URL: https://bogner.sh/2016/03/mitm-attack-against-keepass-2s-update-check/ Video: https://youtu.be/gOxcQSbpA-Q Vulnerability […]

  19. […] versions: all tested version up to the current 2.33 Tested on: Windows 7 CVE : CVE-2016-5119 URL: https://bogner.sh/2016/03/mitm-attack-against-keepass-2s-update-check/ Video: https://youtu.be/gOxcQSbpA-Q Vulnerability […]

  20. […] versions: all tested version up to the current 2.33 Tested on: Windows 7 CVE : CVE-2016-5119 URL: https://bogner.sh/2016/03/mitm-attack-against-keepass-2s-update-check/ Video: https://youtu.be/gOxcQSbpA-Q Vulnerability Status: Won't fix Abstract […]

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)