Disclosed - Minor Bugs in Keybase.io

(These bugs were responsibly disclosed on 7th December 2014, and were reported fixed on 9th December 2014. I sought & received permission to make these findings public.)

I love the idea of Keybase.io. It's a site which takes a lot of the hard work out of encryption.

I've discovered (and responsibly disclosed) a minor vulnerability with their web service. It doesn't lead to anyone's details being exposed, or point to an underlying flaw with their services - it's just a slight lack of professionalism which could have some unintended consequences.

Default Errors

It's a really good idea to make sure that your default error pages don't leak any information about your infrastructure. An adversary who knows that you're one or two patches behind may find it easier to target an exploit towards you.

Keybase expects a certain format of URL. If you want to see my page, visit keybase.io/edent. Presumably, the server looks up the string "edent" in a database. If it doesn't find a match, it displays an error page. Suppose, however, that we send it some non-text content? What happens then?

By sending the string "%." we've caused the server to go and have a little bit of a lie down. In the meantime, it "helpfully" tells the world that it's running nginx 1.6.1.

Apparently, that version of the software has a SSL session reuse vulnerability. Ooops!

If we pass it a similar string "%" we get this returned to us.

This is problematic for a number of reasons.

• We now know the username of the running app. It was probably guessable anyway, but it's nice to be sure!
• The layout of directory tree is now obvious.
• A fairly comprehensive list of the software used is available.
• By looking at those line numbers, we can probably determine the software version and see if any have known bugs or exploits.

The Keybase.io team raised this problem with their software stack provider.

These are not exactly show-stopping bugs; an adversary would already need to have compromised the server to make the most use out of them. And, in all honestly, a sufficiently determined attacker could probably ascertain your software stack. But there's no need to make it easy for them!

On a product level - these error pages just look horrible. You don't want your users accidentally getting a page full of tech gibberish. Log the error somewhere and present a nice, clean, brand-aware "Whoops!" page.