Keybase: “Our browser extension subverts our encryption, but why should we care?”

Two days ago I decided to take a look at Keybase. Keybase does crypto, is open source and offers security bug bounties for relevant findings — just the perfect investigation subject for me. It didn’t take long for me to realize that their browser extension is deeply flawed, so I reported the issue to them via their bug bounty program. The response was rather… remarkable. It can be summed up as: “Yes, we know. But why should we care?” Turns out, this is a common response, see update at the bottom.

What is Keybase?

The self-description of Keybase emphasizes its secure end-to-end encryption (emphasis in original):

Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can’t leak your files or be hacked.

So the app allows you to exchange messages or files with other people, with the encryption happening on sender’s computer in such a way that decryption is only possible by the designated recipient. This app is available for both desktop and mobile platforms. And for desktop you get a bonus: you can install the Keybase browser extension. It will add a “Keybase Chat” button to people’s profiles on Facebook, Twitter, GitHub, Reddit or Hacker News. This button allows you to connect to people easily.

Clicking the button will open a chat window and allow you to enter a message directly in the browser. Only after that initial message is sent the conversation will be transferred to the Keybase app.

So what’s the issue?

The issue here is a very common one, merely a week ago I listed it as #6 in this article. The extension injects its user interface (the button and the chat window) into third-party websites, yet it fails to isolate it from these websites. So the first consequence is: the Keybase message you enter on Facebook is by no means private. Facebook’s JavaScript code can read it out as you type it in, so much for end-to-end encryption. This is quite contrary to the promise Keybase still makes on their Mozilla Add-ons and Chrome Web Store installation pages.

Don’t believe that Facebook would intentionally spy on you? Maybe not, but by now it is pretty common to protocol all of user’s actions, for “site optimization” purposes — this includes anything entered into text fields of course. But in my opinion, that’s not even the worst issue.

A website could do more than passively spying on you. It could just as well instrument the Keybase user interface in order to send messages in your name, while also making this user interface invisible so that you don’t notice anything. Why would Facebook want to do something like that? Not necessary them, rather anybody who discovered a Cross-Site Scripting (XSS) vulnerability in one of the websites that Keybase integrates with. So if hundreds of people complain about you sending them spam messages via Keybase, it might be somebody exploiting the Keybase extension on your computer via an XSS vulnerability in Reddit. Have fun explaining how you didn’t do it, even though the messages were safely encrypted on your computer.

What does Keybase think about this?

According to Keybase, “this is all clearly described on the install page and is known.” In fact, close to the bottom of that page you find the following:

What if my browser is compromised?

The Keybase extension uses a compose box inside your browser. If you fear your browser or the social network site’s JavaScript has been compromised — say by another extension or even the social network acting fishy — then just compose the message inside the Keybase app directly. Or send a quick hello note through the extension and save the jucier private details for inside the app.

To me, this is thoroughly confusing. First of all, “browser is compromised” to me sounds more like malware. Trouble is, malware affecting the browser will affect the Keybase app just as well, so the advise makes no sense. But let’s say that it really is “the social network acting fishy,” how are you supposed to know? And is Facebook spying on you “fishy” or just its usual self?

It’s not that this issue is unavoidable. Avoiding it is fairly easy, by isolating all of the extension’s user interface in an <iframe> element. This would prevent both the website and other extensions from accessing it. Disaster averted, nothing to see here. But according to Keybase:

there were technical reasons why iframes didn’t work, though I forget the details

I translate this as: “Using iframes required a slightly more complicated approach, so we couldn’t figure it out.” Also:

It’s such a minor feature for us, it’s not worth a fix.

I translate this as: “We will keep pushing this extension because it gets users to promote our app for free. But we don’t care enough to make it secure.”

And now?

The only advise I can give you: uninstall the Keybase browser extension ASAP. As to the app itself, it might be secure. But as experience shows, the claim “end-to-end encryption” doesn’t automatically translate into a secure implementation. Initially, I planned to take a closer look at the crypto in Keybase, to see whether I can find weaknesses in their implementation. But that’s off the table now.

Update (2018-09-10): After I wrote this, EdOverflow pointed out that he made a similar experience with Keybase in the past. He could demonstrate that the domain ownership validation approach used by Keybase is flawed, yet Keybase wasn’t really interested in fixing this issue. Why they don’t require their keybase.txt file to be always located within the .well-known/ directory is beyond me, it solves the security issue here without any obvious downsides.

And then I also found this older vulnerability report on HackerOne about the Keybase extension opening up XSS issues on websites. The reporter recommended staying clear of innerHTML and using safe DOM methods instead, something that I have also been preaching for years. The response he received sounded very familiar:

There was some reason our extension developer decided against that approach, though he agrees it’s better in theory.

In other words: “We don’t know how to do it, but we’ll claim that we have a good reason instead of asking for help.”

Update (2018-11-07): I now requested explicitly that Keybase makes my report on HackerOne public, and they promptly rejected. I’m not sure which part of my report they consider a secret, given that they consider it a known and documented issue. Maybe it’s merely our conversation that they don’t want to be public?