CVE-2016-5119: MitM Attack against KeePass 2’s Update Check

1 2 > >> (Page 1 of 2)
  • Olem

    Olem - 2016-06-01

    Dominik - is everything in this article true?

    This isn't a great response for a security oriented product trusted with people's passwords!

    That said, why can't you move the update to an HTTPS site, and leave the main site on HTTP?

    • StygianAgenda

      StygianAgenda - 2016-06-06

      In the articles I've read since this hit the press, Dominik cites "expense" as the reason for not moving to HTTPS. If that's true, then that leads me to think that either Dominik doesn't know about and their free Certificate services made with the open source community in mind. I've used them in the past, and granted... it's a pain to renew and replace certs every 6 months, but it works.

      Another option is simply generating his own certs that are trusted internally by the app and nothing else, which would really only require a working build of OpenSSL on any Linux or Unix server... for pretty much anything that'll run Apache, for that matter. There are tons of HowTo articles out on the net that can be used as a guide for building out the architecture to support HTTPS and to distribute (or at least provide a resolution-point for) the certificate chain to validate any keys he personally publishes.

      With all due respect to Dominik's work, I believe that saying that HTTPS today is too much of an expense or too much of a hassle is a really poor excuse. There are free cert providers, and he can always adjust KeePass to internally validate a self created certificate that is only published as an embedded part of the binaries packaged in the KeePass installation. If he isn't savvy on how to achieve this, just ask around on FreeNode IRC Network. I'm sure there are people there that can help, either directly or indirectly, to assist Dominik to eliminating this security problem.

      There's also other alternatives... find someone else to either get involved or take over the project that will take measures to secure the update-path, or simply kill the project if there is no will to secure the distribution system correctly.

      The quotes I've read this morning that state that Dominik will not fix KeePass against MitM attacks tells me that either he is spread too thin on this project and other life-matters to give this project the attention it needs, or that he may not be prepared to do everything that a project of this nature demands. I get least I think I do... I've been there... starting with an idea that builds into something that suddenly a lot of people are using, and something happens that seems overwhelming to fix, much less knowing how to even start approaching a fix... that can be infuriatingly frustrating, whether you're new to developing or a seasoned veteran developer.

      Regardless, there are other alternative options that Dominik could consider, if he's aware of them, and willing to change the way he's been doing things. If he's the sole developer behind KeePass, it would be a really good idea to expand the project to take on more capable and willing volunteers to help iron out the issues that he's having trouble with. It's not to dog him... not at all.... I just realize that any project of any reasonable level of sophistication is often going to need more than one cortex applied to making it a complete success in all areas. If there are more people than Dominik working on KeePass' source-code though, and none of them have come up with a means to host an HTTPS site... well... that says a lot about the minds behind the project too. The KeePass site makes mention of KeePass being OSI approved. If that's truly the case, then that denotes at least a fairly strong understanding of Open Source Technology concepts and practices. So why can't he put together an Apache Vhost running OpenSSL to distribute his updates? For that matter... why does he even bother with HTTP/HTTPS, when SFTP/FTPS/FTPES work very well?

      Speaking of expense, I pay $20 per month for a pair of Linux Server droplets at Digital Ocean, which gives me all the external infrastructure I need to keep my external services running while keeping my overhead development and deployment costs to near nothing. Granted, I built out my infrastructure from scratch at all levels in my networks, both locally and remotely, and I can't even guess at the level of skills that Dominik (and anyone else directly involved in KeePass' production) may have, but that's the great thing about the Open Source Community... it helps us to help you. The more people that get involved on any given Open Source project, the more likely it is that same said project will attain a higher level of overall quality and distribution. Certainly, plenty of people use KeePass... but with news like this... with the message coming from Dominik that he won't attempt to fix the problems with his app distribution chain... I would expect to see a tremendous exodus of his userbase. Just the bad press alone surrounding KeePass right now will be enough to send the more paranoid of his users scrambling for an alternative. When it comes to security products, and more so, security product developers and/or vendors, any lack of action against a legitimate threat can ruin their reputation entirely, or at least for a very long time. Think about that one... Microsoft still catches hell to this day over mistakes they made back in the mid 1990s (over 20 years ago).

      Anyway, this is just my opinion regarding this mess, and in no way should this be considered a rebuttal to Olem's original post.

  • T. Bug Reporter

    T. Bug Reporter - 2016-06-01

    I'm guessing that most of the revenue that allows Dominik to devote so much of his time to developing KeePass comes from the ads shown on the download pages, and that switching to HTTPS would prevent those ads from appearing - thereby ensuring that no further improvements to KeePass would be forthcoming. Fixing this, unfortunately, may be unfeasible from an economic standpoint - at least not without policy changes from SF.

    Last edit: T. Bug Reporter 2016-06-01
  • Dominik Reichl

    Dominik Reichl - 2016-06-01

    It is true that the KeePass website isn't available over HTTPS up to now. Moving the update information file to a HTTPS website is useless, if the KeePass website still uses HTTP. It only makes sense when HTTPS is used for both. Unfortunately, for various reasons using HTTPS currently is not possible, but I'm following this and will of course switch to HTTPS when it becomes possible.

    Much more important is verifying your download (which I'd recommend independent of where you download KeePass from). The binaries are digitally signed (Authenticode); you can check them using Windows Explorer by going 'Properties' -> tab 'Digital Signatures'.

    Best regards,

    • C_G

      C_G - 2016-06-01

      How is it useless to protect the update file and downloads with HTTPS? It would stop the issue, would it not?

  • Olem

    Olem - 2016-06-01

    It's not useless to put the update site on HTTPS and main site on HTTP - users updating will go straight to the update site and that URL can't be tampered with.

    Regarding authenticode - is that on the installer or the main executable?

    • Horst

      Horst - 2016-06-03

      The main executable

    • Paul

      Paul - 2016-06-03

      The installer is also signed.

      cheers, Paul

  • Aaron Clay

    Aaron Clay - 2016-06-01

    Hi Dominik,

    Can you serve the insecure portions of the website over insecure HTTP iframes, and let the main site be HTTP? Modern browsers have done away with intrusive mixed content warnings.

  • Glenn

    Glenn - 2016-06-03

    Even if the site is encrypted which hopefully it will, your DNS requests are not and is sent plaintext which makes it ripe for MiTM attacks. DNSCrypt can mitigate this and encrypt ALL of your DNS requests. I highly recommend it. If your DNS is spoofed you could be redirected to a forged site and not even know it.

  • Thomas Luzat

    Thomas Luzat - 2016-06-03

    I would consider a notice to check the signature of the downloaded update manually helpful, if not already implemented.

    Possibly more useful than HTTPS for verifying the contents of would be signing them, but this does seem to only prevent a small class of attacks (suggesting to the user that an update is available). Simplifying updates of KeePass and its plugins would be way more helpful; in this case signatures should of course be verified automatically.

  • Herbert

    Herbert - 2016-06-05

    Here you have the real reason why the developer doesn't want to switch to HTTPS: "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."

    Some extra money for the developer is worth more than the security of thousands of users. This is such a sad thing. From now on, I will never recommend KeePass to anyone, and I will urge existing users to switch.

    And BTW: Why is there even a donate button? And what's with all the people who have donated? They are fooled, along with thousands of users who was given a false impression of security.

  • Dominik Reichl

    Dominik Reichl - 2016-06-05

    As there are some articles with incorrect information about the situation, here's a clarification of the update process and the notification problem:

    The version information file is now digitally signed (using RSA-2048 and SHA-512). KeePass 2.34 and higher will only accept such a digitally signed version information file.

    Here's the latest development snapshot for testing:
    When you intercept the downloaded version information file and modify it (e.g. by increasing the KeePass version), you'll notice that KeePass rejects it.

    Best regards,

    • mikefor

      mikefor - 2016-06-05

      Wonderful, thank you for the quick response and turnaround on a fix! Your hard work on this project is greatly appreciated.

    • Thomas Rechenmacher

      I wrote you an e-mail about the update-system we use for JDownloader and other tools. We'd be happy to help you implementing the client-side for keepass.

  • Sven Strickroth (MrTux)

    Just signing the version.txt file doesn't help. Because if ever a vulernability is inside KeePass, an attacker could just save the old version and deliver the old version, so that your KeePass instance would think that it is still the most recent one even it is isn't - there needs to be a timestamp included which can expire (or the file needs to be delivered over https)...

    PS: It's amazing that this gets a CVE... :(

    Last edit: Sven Strickroth (MrTux) 2016-06-05
    • fritzophrenic

      fritzophrenic - 2016-06-06

      Could you explain how being able to prevent KeePass updating could be fixed by a timestamp or anything else? Unless KeePass warns you when it can't download the file at all, wouldn't a timestamp or TLS still be vulnerable to a DOS preventing the update check from proceeding at all, thereby preventing the user from learning about the update just as effectively? I assume if an attacker is in a position to do a MiTM, she's also in a position to do a DOS.

  • Dominik Reichl

    Dominik Reichl - 2016-06-05

    That's a great idea, thanks! I'll add the timestamp.

    Best regards,

  • Sven Strickroth (MrTux)

    I'm not sure if just adding a timestamp will do the trick, as you basically need to upload a new version file once a day or week and report an error in case this timestamp is older than one day or one week - otherwise the issue I reported in my last post is still possible.

  • Olem

    Olem - 2016-06-05

    Can I point out that you're inventing a lot of complexity to work around using the generally accepted solution - TLS.

    Generally one should try and avoid inventing your own protocols, as evidenced by Sven's post. Now obviously Dominik managed this to some extent in Keepass, but that is still no excuse in my mind.

    PS, You're on slashdot and engadget.

  • T. Bug Reporter

    T. Bug Reporter - 2016-06-06

    For completeness, I feel I should note here that some commentary pertinent to this matter spilled over into this topic.

  • fritzophrenic

    fritzophrenic - 2016-06-06

    What about for the update check for plugins? Will that support checking a signature? How?

    Last edit: fritzophrenic 2016-06-06
  • Dominik Reichl

    Dominik Reichl - 2016-06-06

    Right, a man in the middle could simply block connections to the KeePass website; KeePass then wouldn't display an update notification.

    Anyway, I've found out that my website hoster provides a way to access the KeePass website via a different domain over HTTPS. I've changed the version information file URL accordingly.

    So, KeePass 2.34 will download the version information file over HTTPS and additionally checks its digital signature (as described before).

    Plugins already can specify HTTPS URLs for version information files. Furthermore, plugins can implement their own digital signature checking, if they'd want that (similar to how KPEnhancedEntryView customizes the update checking).

    Best regards,

    • fritzophrenic

      fritzophrenic - 2016-06-06

      Furthermore, plugins can implement their own digital signature checking, if they'd want that (similar to how KPEnhancedEntryView customizes the update checking).

      How? The official documentation for plugin update-check integration just says to return a URL to KeePass, and KeePass itself will check the file for a greater version number than the installed version. Would the plugin need to re-invent the wheel, downloading the file itself and checking the signature before providing the URL to KeePass? That seems wasteful. What about adding another method to override, that would specify whether or not to check the signature? And documentation on how to include the signature in the update file.

      By the way, maybe you should update that plugin update check documentation, to recommend HTTPS over other protocols. Currently it calls out plain HTTP and FTP only.

1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks