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.
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:188.8.131.52 DataBaseReorder:2.0.8 EnableGridLines:1.1 eWallet Liberated Data Importer:0.12 IOProtocolExt:1.11 ITanMaster:184.108.40.206 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:220.127.116.11 :
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?)
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:
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.
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/
- 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.