KeePass2 v 2.34 to fix update security problem | Hacker News Reader

KeePass2 v 2.34 to fix update security problem

73 pointsSNvD7vEJ41 comments

From the KeePass site: http://keepass.info/help/kb/sec_issues.html#updsig

In order to prevent a man in the middle from making KeePass display incorrect version information (even though this does not imply a successful attack, see above), the version information file is now digitally signed (using RSA-2048 and SHA-512).

KeePass 2.34 and higher only accept such a digitally signed version information file. This solution is more secure than just using HTTPS, because it guarantees version information safety even when the webserver is compromised (the private key for signing the version information is not stored on the webserver).

Downloads page: http://keepass.info/download.html

Edit: The update has NOT yet been released, as of (CET 11:30 2016-06-06)

View on HN

This is a partial fix, but it's not enough. An attacker performing man-in-the-middle attack can respond with the previous version of "version information file", preventing the update.

Imagine if there's a vulnerability in one version of KeePass2, and the fix is available for it. MiTM attacker sends the previous version so that the app doesn't know that there's an update, and the attacker has more time to use the vulnerability.

HTTPS prevents this. They should do both.

Update checks are usually implemented as soft-fail, i.e. failing to connect to the update server won't result in a notification, unless it's an active update check performed by the user. HTTPS alone wouldn't fix this scenario, you'd have to either do hard-fail (which could become annoying and cause users to turn off the update check) or have some sort of grace period and only nag after a couple of failed attempts or a certain amount of time, which still leaves users vulnerable for a time.

TUF[1] would also prevent this (and a whole host more potential attacks against updating). It's what TBB uses and everyone should use.

[1]: https://theupdateframework.github.io/

> Furthermore, the version information file is now downloaded over HTTPS.

It looks like they are

So, a MITM would be able to prevent automatic update notifications?

It seems not any more?:

"Resolution. In order to prevent a man in the middle from making KeePass display incorrect version information (even though this does not imply a successful attack, see above), the version information file is now digitally signed (using RSA-2048 and SHA-512). KeePass 2.34 and higher only accept such a digitally signed version information file. Furthermore, the version information file is now downloaded over HTTPS."

The question was if MITM would be able to prevent automatic update notifications. Their solution doesn't solve this: it prevents attackers from changing version information, but doesn't prevent them from replaying previous version information.

How would that work? ("replaying")

Yes.

> Downloads page: http://keepass.info/download.html

I still see a glaring MitM vulnerability…

Until the author actually switches to HTTPS, network operators can simply hijack the original downloads page in the first place. This update is barely a mitigation.

If he wants more ad revenue, his only option is to find another ad network. Eventually someone else is going to start hosting a popular fork on a different HTTPS site if he keeps stubbornly ignoring this issue.

If it's cryptographically signed and you found the public key from a more reputable place, you are ok. This is how apt repositories work - they use HTTP, but since everything is signed, mitm attacks can't do much other than see which packages you install.

Almost nobody is going to search for external sources to verify the content on keepass.info

> mitm attacks can't do much other than see which packages you install

On the contrary, if you MitM the entire downloads page you can simply offer up a hacked/backdoored version of the software. There is no signature check if you remove the signature check in the version that you distribute.

That's the fundamental trust-bootstrapping problem. You need an independent way to establish trust in the first interaction. In SSL, it's the (very flawed) CA model (never mind that nothing about SSL protects you if the website content is compromised). In this case, you can verify the download file signatures on keybase.io which is probably significantly safer than the CA model is.

Sure, in this day and age, it's slightly disconcerting to see a security-related website that isn't SSL, but on the other hand, the tendency to blindly trust the green padlock is probably even more dangerous.

http://keepass.info/integrity_sig.html https://keybase.io/reichl

Uh, sure.

But TBH, if I am going to go through the trouble of MITM'ing the site, then I am going to rewrite the site to:

* include my awesome fingerprint

* link to my awesome key

* link to my l33t entry on keybase

Side note - the CA model has issues, but in what world is pointing users to a VC funded startup that has only been around for two years "safer" than the flawed, but well understood security model of the CA system?

I don't mean to impugn Keybase, from watching them I like what they are doing, but bootstrapping trust based on content they control is hardly ideal, and I would be shocked to hear someone say that Keybase is more reliable or more trustworthy than the CA/Browser Forum (10 years old) and the browser vendors (>20 years old depending on vendor/code base).

I don't really see how this is relevant.

It may be flawed, but clowning the CA model is beyond the abilities of the vast majority of attackers.

Setting up a MITM attack is not exactly trivial, either.

That fork is KeePassX [1]. And it's cross-platform too!

[1] https://www.keepassx.org/

Oh, I see that KeePassX now supports the KeePass2 format now! I'll definitely give it a try now that it supports that.

Support for the KeePass2 format was the only thing preventing me from using it in the past.

Ah finally! The Mono version is wonky.

Sadly, there is no sync and syncing offline changes is non-trivial in KeePass.

(At the very least, a .kdbx on Syncthing/Droxbox-like storage WILL eventually lead to data loss.)

I concur with the other commenters... I've been syncing with dropbox for years now and never had a conflict. I guess it helps I tend not to leave it open/running on multiple machines. Open it, use it, close it.

> At the very least, a .kdbx on Syncthing/Droxbox-like storage WILL eventually lead to data loss.

It's been working for me without issue since 2009-ish. I've used 1.x and 2.x databases in Dropbox.

AFAK if a conflict occure, it will create a "conflicted copy" of the kdbx file. You still have to merge files manually but no data will be lost in the process.

This is correct--I've had conflicts and a second kdbx file is created with conflicted copy and the date of the conflict in the filename.

It's a small pain to go through and figure out which item is out of sync, but doable.

At some point new passwords will be added quite rarely. Clash can happen, but in practice I've been happily using this method now for years and years.

Keepass will let you merge the databases if a conflict happens.

Why not just switch to using The Update Framework (TUF)[1]. It solves many, many, many attacks against updating systems and we really should be using it everywhere.

[1]: https://theupdateframework.github.io/

Probably because TUF is 100% Python, and KeePass is a .NET-based Windows app.

TUF is a specification (with a sample implementation in Python). There are Go implementations as well, for example.

Because they'll have to implement it in .Net which is not a small task.

Even if there is an implementation in .Net it will have to be audited and even then you are at the mercy of who ever maintains it.

Sucking in OSS libraries might sound easy and smart but it's a huge gamble unless it's a defacto standard in the industry or is being maintained by a giant corporation you might be stuck up the creek without a paddle as soon as the person maintaining it decides to drop it.

Why don't they put the update file on a subdomain with HTTPS enabled? No ad revenue lost that way.

There's a good argument to be made for signing the update information using offline keys - it reduces the damage that could be caused by a compromised SSL key. That being said, they should've still used HTTPS to secure the transport layer, as it would prevent replay attacks (as @dchest mentioned) and make it harder to exploit vulnerabilities that could be caused by e.g. corrupted update information.

My question is: Would they have released this update if the person who came forward about the fact that KeePass said that they wouldn't fix it didn't?

Of course not. Isn't laziness one of the traits of talented programmers?

No, not that ignore-security-until-too-late type of laziness. More of a automate-manual-tasks laziness.

Evidently, money is more important that security.

Ummm. Dominick Reichl makes Keepass available free of charge. It's not easy to stay ahead of smart, motivated and unscrupulous cybercriminals. The best thing to do if you want quicker response to threats is to send him a donation.

He doesn't make it free, he makes ad money. You are the product in his mindset, and that should lead to an impasse to ever using his software for security purposes. Any user seeking security and Dominick Reichi have competing interests.

That philosophy works fine for something like Google, where your information is what they make money off of. In this case, your page views are the product, as KeePass does not ask for nor use for marketing any personal information from you. Huge difference.

Since the post about this problem a few days ago I've stopped using KeePass and began using Password Safe. Good program.

Allowing these type of programs to autonotify of updates and self-update should be considered bad practice and a high security risk.

Why risk a malicious MITM-ed update? The keepass site should just provide portable zips and off-site hashes and sigs for verification.

Reply on news.ycombinator.com