MitM Attack against KeePass 2’s Update Check | Hacker News Reader

MitM Attack against KeePass 2’s Update Check

bogner.sh

125 pointstdkl75 comments

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

Well the indirect costs of not fixing it just got a lot bigger. Now a lot of people will realize that their passwords are not as safe as KeePass claims they are and will switch to a different product. So this way they loose both their money and their users' trust. Not a very good business decision.

Right. This is a security product. Any security product that makes things worse (and there are all too many of them) has no right to exist.

That response is crazy. If he's so set at keeping the homepage http, then make a download.keypass.com site and keep the downloads on there, with https required.

Eh. Still vulnerable to HSTS attack. To me HTTPS without HSTS is only protection to programmers. To the public, HTTPS without HSTS protection is essentially useless against MITM attacks.

Maybe, maybe not. People might not notice or care. (Of course I agree that this is a poor decision security-wise.)

Sure, but it seems as though the type of person who would use KeePass in the first place is the sort who would care.

Why would switching to HTTPS cost him any advertising revenue?

See https://news.ycombinator.com/item?id=11803716 from yesterday

That's if they switch the entire site to https. They could just switch the update check to https and have no problems with ads (although it would be admittedly less secure).

> Now a lot of people will realize that their passwords are not as safe as KeePass claims they are and will switch to a different product.

Not really.

Just check the package you download is signed by the developer and you're safe. Authenticode signatures are present on all KeePass releases on Windows and most Linux users probably get it from a distro package manager anyways.

That's wild, I didn't expect any security-centric website in 2016 to be HTTP-only! The reasoning for not doing it is weird too, they could at the very least move the update logic over to a separate SSL endpoint.

Anyway, I'm not quite sure on the differences between them but I've been using KeePassX for years and recommend it thoroughly (as long as you're not looking for a easily synced or multi-user product): https://www.keepassx.org/

> That's wild, I didn't expect any security-centric website in 2016 to be HTTP-only!

Both of the websites for PuTTY (www.putty.org and www.chiark.greenend.org.uk) are also non-encrypted. At least the downloads are hosted on a third server (the.earth.li) which does use HTTPS and 2048-bit GPG signatures are provided.

putty.org is not owned by the PuTTY developers; after some arguments the two parties came to an agreement about the use of the domain name, but you should not trust putty.org.

Thanks for the recommendation. I just switched.

/second keepassx, been using it for years too. Portable encrypted database file and cross-platform = excellent.

I was always skeptical of KeePass which is why I've been using KeePassX. It is just a simple Qt app.

Unfortunately there is no KeePassHttp support yet, so you can't hook it up to your browser, but there is a fork available with full support.

https://github.com/droidmonkey/keepassx_http/

I'd probably switch to KeePassX instead of running KeePass in wine if the password generator were as flexible.

Why are you running KeePass in wine?

That could make sense OP dual-booted and the KeePass app and database were installed on the NTFS partition.

How exactly is that supposed to make sense?

The advantage is that you get to keep your passwords on a single database rather than having a separate copy of the database for each operating system. Synchronizing two separate copies of the database would be painful.

An alternate solution is to keep a single password database on a FAT32 formatted partition or thumbdrive which is readable from both Operating systems.

Currently, no - but I have actually used a setup like that before.

I have very complex password generation requirements for some of the services I need to access and KeePassX does not:

    1) have nearly the same level of support for defining complex password generation rules
    2) have support for saving said custom password generation as a profile

So, KeePass + wine it is until I have a better alternative. :)

But why Wine?

http://packages.ubuntu.com/xenial/keepass2

Inertia. I've been using KeePass for years and I'm still on v1 because at the time the v1 database format was more well supported across all the "keepass" compatible apps on iOS, OS X, Android, etc.

What I have works for me very well although I will admit that the v2 database format is supported well enough these days that I could migrate.

Oh right, I didn't realize that people were still hanging on the legacy version. Then I suppose Wine does actually make sense

Unfortunately, the package is just a mono-wrapped version of keepass2, and in my experience runs equally as bad, if not worse, than keepass2 under WINE.

Having used both for several months, I found the only workable option for myself was converting the database to KDB 1.x and using KeePassX.

Do you have to change those passwords so frequently? You could just use an external service for creating these when needed.

Often enough that I don't want to have to rely on a separate script or service to generate the passwords for me and save the profiles and then copy the result into KeePass entries.

And KeepassX also supports version 2 and is MUCH lighter. :)

Why have you always been skeptical of KeePass? What is it about KeePassX that reassured you?

I looked at KeePassX several years ago but it didn't have as many security features as KeePass. For example, KeePass supports entering the password via secure desktop where KeePassX didn't.

KeePassX doesn't do auto-updating, for one. I am kind of a purist when it comes to software, and anything that feels clunky and bloated I'm just going to assume is made by people with insufficient competence. And truly, nobody is competent enough on their own, it requires a community. And it is much easier to collaborate through github than through... however it is that KeePass does it.

KeePass doesn't do auto-updating either, fwiw.

Many years ago I reported two bugs in KeePass, one related to the tray icon, and the other related to some bad rendering in the GUI.

Both were closed, with reasons like "this is a bug in .NET", "this is a bug in Windows". Maybe they were, but somehow other applications didn't expose them. The bugs were annoying, and if it were my software I would have fixed them somehow, even if they were not my fault.

Long story short, the author gave me a bad impression, the kind of "know it all, know it best" attitude. So his refusal to fix this MITM problem doesn't surprise me one bit.

Why is there advertisement on the automated update server? Why can't he just split them apart? What with things like Let's Encrypt nowadays, there really shouldn't be any excuse not to use https. Especially for a security related product!

There isn't an automated update server. KeePass can't auto-update. The web server has a text file on it that contains the version number of the latest release. KeePass (optionally) checks that file to see if a new version is available and displays a notification to the user. Downloads and installation of new versions has to be done manually by the user. The binaries are hosted on SourceForge and other mirror sites, and in my cursory checking those are serving the file over HTTPS. The binaries are digitally signed.

So any possible attack against KeePass would as most cause the notification dialog to appear saying there's a new version.

anyway, the author found a solution by signing the text file that the update checker looks at. IMO, that's a superior solution to HTTPS. He's posted a statement on the KeePass website. http://keepass.info/help/kb/sec_issues.html#updsig

I've already been slowly migrating from KeePass to https://www.passwordstore.org/ and this is just one more reason why.

  The indirect costs of switching to HTTPS (like lost
  advertisement revenue) make it a inviable solution.

How does HTTPS result in lost ad revenue?

Hackernews thread from yesterday: https://news.ycombinator.com/item?id=11803716

https://news.ycombinator.com/item?id=11803716

The answers here are off the mark. You can obviously have the update channel use HTTPS and keep your website at HTTP (not recommended, but certainly possible).

Or just sign the updates and version information.

The way the update system works (according to the article) is that it shows a pop-up with the new version, and that pop-up opens their site (via HTTP). It is conceivable that they'd rely on the impressions coming from update dialogs for their ad revenue, so the argument they used (which - just to clarify - is not my argument) would apply here as well. Switching to HTTPS (or some other signing mechanism) for the update check would solve one of the problems described in the article (tricking the user into thinking there's a new version available), but it would not eliminate the MitM opportunity on the site itself.

The MitM on the automated update check is by far more dangerous.

He has fixed it and is signing the version info file.

So wait, so this project that I use to store my passwords and that always seemed to take security and encryption seriously is leaving a public vulnerability unfixed because of "lost ad revenue"??

I'm baffled.

I completely understand the need to support the project financially, but this answer leaves me feeling very uncomfortable.

1. Many ad networks do not support serving over HTTPS. 2. Serving HTTP ads only your HTTPS-only site will show scary mixed-content warnings in many browsers, driving away users.

Roboform has been my go to, but honestly I don't know how well the security is on it but by the track record it looks as though they have not had any issues by what short searching I have done.

I've seen several open source systems that share on GitHub such as PadLock but have yet to be able to test these to compare to Roboform. Considering how cheap I was able to pick up Roboform to (as a college student I got 4 years for 1) I really haven't seen the urge to switch considering on how universal Siber System's Roboform does on multiple systems.

Even though this can also be a downfall if the developer's slack on one system, I have been satisfied with these guys since I started using them so many years ago and really haven't found many complaints.

edit My entire reasoning for posting was that while I'm very familiar with Roboform my experience with KeePass was always lacking compared to others.

Couldn't this be solved by signing the update file?

But the excuse of the dev is bogus in any case. In is trivial to have that single file transferred via HTTPS. His ad revenue excuse makes me thing something fishy is going on here.

That would help, but an attacker being able to deliver an arbitrary website by MITM is still something that should be avoided.

Signing the update file and having a separate page for the SHA256 hash of the binary would win back a lot of my confidence at this point.

See a more detailed (but still very wrong in my opinion) response from Dominik here: https://sourceforge.net/p/keepass/discussion/329220/thread/e...

Disable the update via:

https://sourceforge.net/p/keepass/discussion/329220/thread/a...

Well I'm glad I switched off of keepass awhile back.

Anyone know any good password managers that have web login and support U2F? Lastpass does not :(

I just use a gpg-encrypted org-mode file (I can transparently decrypt it with emacs). It's remarkably convenient, and I don't have to worry about software going out of support.

Yea I used to do something similar, but I'm really looking for something with web support...

The indirect costs of switching to HTTPS (like lost advertisement revenue) make it a inviable solution

This doesn't entirely make sense. I'm sure it's possible to serve adverts on a HTTPS page, and let's encrypt is hardly expensive

> I'm sure it's possible to serve adverts on a HTTPS page

Yes, you can, but you lose a tremendous amount of ad revenue and a number of ad providers still don't support HTTPS.

Is this becuase all the third party assets and scripts would need to be HTTPS as well? If they weren't then you get that browser warning about mixed content?

https://news.ycombinator.com/item?id=11803716

Too many ad buyers don't have https support, so the number of bidders for the ad space is lower, meaning a lower price per ad.

It's free software; You have no right to complain or dictate priorities when you aren't paying for it. You aren't the customer, KeePass 2 advertisers are.

Use 1password and pay $5 a month if you want the right to complain.

Projects should not be exempt from criticism just because they're free. That's a terrible attitude. The article does not attempt to dictate anything, I would not even call it a complaint. It merely points out unsafe practices and recommends a solution, in a very objective tone.

That's a justifiable sentiment when people are complaining about missing features or mundane bugs, but security vulnerabilities are a whole different matter. That's causing harm, not just failing to provide value. You're still allowed to complain about a mugging you didn't pay for, after all.

How about those who donate? Aren't they kind of customers? And what would you say if Linux updates could be easily changed with MitM?

Even if you believe there is no right to complain, you have the right to warn others about issues you see. Contacting the maintainer beforehand and suggesting a fix to them is common courtesy if you do that.

Giving something away for free is not an excuse for it to provide negative value by exposing its users to MitM attacks.

Negative value is a subjective judgement.

Updates themselves are signed packages. While it's not ideal, careful users do gain value in an open, free, and mature solution.

Full disclosure: I sell a plugin for KeePass 2.

I'm not necessarily saying that Keepass2 provides a negative value overall. As you say, that's a subjective judgement. However, the unnecessary MitM exposure is certainly a negative value.

What "complaint" are you talking about? The blog is an objective explanation of a CVE along with explicit suggestions to the author and an discussion on how to protect yourself if you're a user.

> It's free software;

It is not free software, it's proprietary. Please don't use the phrase "free software" in this context, as it confuses people. It has a very specific meaning in the context of software.

Even in the context of software, it still means no cost.

In the context of software it can also mean FOSS, but just because we're talking about software doesn't mean we suddenly lose the 'no cost' meaning.

'Free' has exactly two specific meanings on the context of software. Sorry to burst your bubble. The version you are referring to is irrelevant in the minds of the vast majority of people who use software.

On the homepage it says: "KeePass is really free, and more than that: it is open source (OSI certified). You can have a look at its full source and check whether the encryption algorithms are implemented correctly.".

Why do you say it's proprietary?

Ah sorry, I was wrong. I thought that KeePass was proprietary and that KeePassX was a free software replacement. :P

KeePass is GPL2 licensed.

>You aren't the customer, KeePass 2 advertisers are.

Well certainly those advertisers will leave along with the user base. This sort of silly attitude is what keeps a lot of people from using free software to begin with.

Reply on news.ycombinator.com