Keybase is notifying Android users of a bug in its mobile app that might have unintentionally included the users' private key —used to encrypt conversations and other private data— into the automatic backups created by the Android OS and uploaded on Google's servers.
Keybase, which is a company that provides a wide range of identity proofing and encrypted communication tools, says it fixed the bug and has sent notification emails to users it believes are affected by this issue.
The emails contain instructions on how users could force their device to generate a new private encryption key.
Keybase uses this private key as part of a private-public key pair system to verify a user's identity and encrypt conversations sent through the Keybase chat system from that device.
Issue affects only "early adopters" of the Keybase Android app
According to an email seen by Bleeping Computer, the issue appears to affect only "early adopters" of the Keybase Android app.
Keybase estimates that around 10% of Keybase Android app users are affected by this bug. On its website, the company boasts to service over 205,000 users; albeit is unclear how many of these also use its Android app.
Keybase said that users who back up their Android device through Google Play and users who reused passwords from other accounts or used a weak passphrase are affected.
How Keybase creates and uses private keys
How the bug occurs
As Keybase points out, this isn't a serious issue unless users are really bad at choosing passwords. An attacker would first need access to a user's Google account (to extract the Android backup files), and then the Keybase passphrase (to decrypt the private key). Nonetheless, we've seen many cases of bad password practices in the past to rule out possible attacks on Keybase accounts.
Keybase works by allowing users to register a Keybase account and use it as a central hub to verify profiles on other online sites and verify devices the user owns.
An attacker may obtain a user's Keybase account password (passphrase), but he won't be able to impersonate that user in Keybase-encrypted chats and private PGP-protected messages unless he sends those messages from verified devices.
The bug Keybase just fixed allows an attacker to obtain the private key and impersonate the user's Android smartphone. This is why it is important that users secure devices, even if there's a little possibility they were affected.
Keybase has included the following instructions in the email to possibly affected users. Users who received the email should update their Keybase app and go through the following steps to create new private keys. The old backups can be left alone, as the private key contained within won't work anymore.
We recommend you revoke and reprovision your Android phone.
If you've got Keybase installed on another computer or have a paper key, the simplest way is to:
1. uninstall the Keybase Android app
2. reinstall and provision as a new device (you'll pick a new name, even though it's the same hardware)
3. remove your old device under the "devices" tab
If Android is your *only* device, then jeez, you have another problem, which is you're risking data loss. We recommend first:
1. make a new paper key under the devices tab in the app.
2. leave your android app open on Keybase for ~15 mins, on a good connection, just to make sure it has time to rekey your conversations for your paper key.
3. Then follow the above instructions.
This doesn't affect PGP keys or anything outside of Android.
Despite this issue, users shouldn't be deterred from using Keybase, which is currently the only service that provides support for end-to-end encrypting Git operations, Reddit and Twitter private messages.
Test every layer before attackers do
Security teams log 54% of successful attacks and alert on just 14%. The rest move through your environment unseen.
The Picus whitepaper shows how breach and attack simulation tests your SIEM and EDR rules so threats stop slipping by detection.
Get the whitepaper
Comments
Occasional - 8 years ago
Ok, as you said: "...users shouldn't be deterred from using Keybase, which is currently the only service that provides...". Being stuck with less than great options is something we all face.
Still, with an identity security centric company, should they have released an app with a security hole?
Wish they gave some detail on how that type of bug got through their design and development regimen. What was it that they had not anticipated or falsely assumed? It's not that knowing could help others avoid the exact same mistake - but that it could help others see the flaws in the process that lead to such a mistake getting in to production.
Cringed when I saw: "Some users considered this a feature..." can anyone pin a date on the first use of "undocumented feature" as a euphemism?
GwynethLlewelyn - 2 years ago
Piping in late... as in six years late...
Actually, I rather use Keybase the other way! Instead of storing Keybase's private key on Google, I store Google's private key on Keybase :-) (well, the _many_ keys I have for Google... and Microsoft... and everybody else)
So, if Keybase ever gets hacked _and_ they manage to guess my password, then they can unlock access to my Gmail account and potentially read all my (unencrypted) emails there.
Hmm.
Anyway, just a thought. The argument that "it's encrypted but you can guess weak passwords" is valid — to a point — but it would be the same argument as assuming that if you lose your YubiKey and someone manages to guess your logins and (allegedly weak) passwords, they can then proceed to use the YubiKey on all my accounts, or at least try, one by one, to see which of those can be unlocked with the YubiKey. Unless it's one of those who require a fingerprint to unlock, of course. The others, then, are "insecure" because they're easily lost. Right?
The whole point of using a password-locked key — physical, digital, both, others — is to have at least two barriers to safeguard your privacy: say, a password (or a PIN), _and_ a key. To hack your acconts, you need both. It's arguable that anyone can _easily_ guess a password to a Keybase private key. And note that the hacker would have to hack _first_ into that person's Google account, so that they could grab the Keybase key stored there. Someone who uses Keybase is very likely concerned with their security (if not, what would be the point of using Keybase? WhatsApp or Telegram are also encrypted end-to-end, and used by far more people on a daily basis), so it's unlikely that they use an easy-to-guess password — it's far more likely that they use multi-factor authentication for Google as well, and _those_ are not _that_ easy to circumvent.
So here's the scenario: you have (potentially), say, 200 or 400 thousand Google accounts, among the 1.4 billion or so that Google has, which have (potentially) their Keybase private keys stored on them. Where do you start?
Granted, people have public profiles on Keybase, so that would be a good starting point: see if they publish their Gmail account anywhere, and proceed to hack Google. One by one. Can you automate that process? Well, maybe, but it's also not that easy or obvious, unless the hacker is aware of a very simple way to defeat Google's protections — merely using the brute-force, old-school method of "guessing" passwords, is _not_ as easy as the article somehow implies. After all, Google needs to fight professional hackers every day, many of which come from military special ops from foreign countries; nevertheless, Google _does_ keep them at bay, counter-fighting while at the same time strengthening its defenses as well. They can easily spot the signature of a brute-force attacker, and block them reasonably quickly, before they even have a chance to do anything malicious.
Granted, Google's system is never 100% fail-proof (beware of those who claim otherwise for _their_ own services!), but it's pretty close to that, for most operations. It remains to be seen if any hacker wannabe is, indeed able to penetrate Google's systems _that _easily. ..