Wednesday, February 9, 2022

CVE-2022-22779 :: Keybase App Vulnerability: Retained Exploded Messages in Keybase Clients for macOS and Windows

In desktop versions of Keybase older than 5.9.0, users can easily retain "exploded" messages with a few clever clicks, meaning your sensitive chats may still be read after you want them gone.


How does this work? When the Keybase desktop client is operating, a user can switch out of Keybase’s Chat tab and put their computer to sleep; if a second user explodes a message in a shared chat during that time, the message will still be visible to the original user when they return to the chat.

Using this method, an unscrupulous individual with access to a conversation could recover sensitive data.

This vulnerability affects desktop versions < 5.9.0.

This researcher used macOS platforms to identify and test the vulnerability, but was able to reproduce by following the same process on a Windows 10 VM (VirtualBox), simulating sleep with VirtualBox's "Save the machine state" option. Zoom staff handled further Windows testing.
This process was not known to be tested on any Linux distributions.

Credits 

Olivia O’Hara - twitter.com/oliviaohara

Identification [macOS]

When activated, Keybase’s chat explode feature allows users to send a message, and then have it automatically “explode”—or self-destruct from all users’ devices—after a predetermined period of time. Users can also manually explode messages if they decide the message is too sensitive for others to retain for the duration of that predetermined length of time. This feature is available on all Keybase clients, and when functioning as intended, exploded messages should instantly self-destruct across all devices that have access to a chat.

After identifying CVE-2021-34421, a mobile-only Keybase vulnerability in which exploding messages could be retained by moving the Keybase app out of the foreground, Olivia O'Hara aimed to discover whether there was a way to achieve the same result on Keybase desktop clients.

After examination, O’Hara identified multiple ways to retain exploded messages on desktop:

  1. If a message originates from Account A using a desktop client, and is then exploded -- by any member of the chat, even Account A on mobile -- while Keybase is still running on desktop, but Account A is logged out and Account B is logged in on that same desktop client, then, when Account A logs back into the same desktop client, the exploded message will still be visible.

    • This does not work if Account A is truly logged out of the desktop client; it only works if the desktop user has selected another account with the Keybase account switcher (by clicking on the “Hi [user]!” dropdown in the top left).

    • A time-delay factor comes into play here: if the desktop client is switched back to account A and the user then immediately clicks on the chat in question, the desktop client is prevented from detonating the explosion. If the user waits to click on the chat in question after switching back to account A, then the message will explode.

  2. If a mobile Keybase client and a desktop Keybase client are both awake and logged into Account A and have Keybase running in foreground, and desktop Account A sends a message in a chat, and then goes to sleep, and mobile account A deletes it, the message will still be visible on desktop account A when desktop account A comes back from sleep.

  3. If mobile account A is asleep with Keybase actively running, and desktop account A sends a message in a chat, and then goes to sleep, and mobile account A wakes up, and sees the message for the first time, and deletes it, the message will still be visible on desktop account A when desktop account A wakes up from sleep.

  4. If mobile account A is awake and has Keybase running in the background, and desktop Account A sends a message in a chat, and then goes to sleep, and mobile account A brings Keybase to the foreground, and sees the message for the first time, and deletes it, the message will still be visible on desktop account A when desktop account A comes back from sleep.

  5. If mobile account A is awake and has Keybase running in the background, and desktop Account A sends a message in a chat, and then switches to Account B, and mobile account A brings Keybase to the foreground, and sees the message for the first time, and deletes it, the message will still be visible on desktop account A when the desktop client switches back to Account A from Account B.

All of the above methods were patched in the v5.8.0 release in September 2021.

However, O’Hara also identified a method where several cycles of exploded messages could be retained at a time:

If a user sends a message in a shared chat from the desktop client, then switches to a feature in Keybase other than Chat (Files tab, People tab, etc.) and then puts the computer to sleep, messages deleted or exploded from another account/device while the desktop computer is asleep will still be visible when that machine wakes up and returns to the Chat tab.

Additionally, this cycle can be repeated n times, and all previous exploded messages from each of the n cycles will continue to be visible on the Keybase desktop client.

Using this switch-tabs-and-sleep method, a user could retain all messages in a chat indefinitely, as long as the messages were not deleted or exploded while the user was watching that chat in the foreground.


Steps To Reproduce

These steps are for macOS, but the same process was used on a Windows 10 VM (VirtualBox) with success; instead of putting the computer to sleep, sleep was simulated with VirtualBox's "Save the machine state" option.

1. Create a group chat with other testers.
2. Access the group chat on a macOS Keybase client.
3. Optional: Change the conversation retention policy to auto-delete messages after 7 days.
4. Have other users send test messages. Ensure the macOS machine can see the messages.
5. On the macOS Keybase client, switch out of the Chat tab and put the machine to sleep.
6. If you've set a 7-day retention policy, ask another tester to explode any one of the previous messages.
7. If you do not have a 7-day retention policy, ask another tester to delete one of their own previous messages.
8. Wake the macOS machine.
9. Return to the Chat tab. The removed message will still be visible.
10. Repeat steps 4-9 as desired. Previous iterations of removed messages will also still be visible.

Proof of concept: https://drive.google.com/file/d/1Q9YDliGOqk7dH3d5j16CDGWmVw29M7Zo/view?usp=sharing

Impact 

Using this vulnerability, threat actors lurking in a group could accrue exploded messages for an indeterminate length of time. Sensitive chats sent by mistake could still be visible to group members even if exploded.

As seen in research for CVE-2021-34421, the exploitability is low from the perspective of a threat actor. However, as Keybase’s product is a communication application focused on privacy, the failure of messages to explode opens up a pathway to exploitation that gives reasonable pause to any privacy-minded user.

A unique cause for concern comes up with these exploded-message flaws: since the workaround exists on the recipient's end, updating Keybase yourself won't protect your own messages. If other parties in your group are using older Keybase versions, you can't guarantee that they're not retaining chats you've exploded or deleted. It's an interesting case where updating your own software only protects others, and you must rely on others’ integrity to protect you.

Or, maybe, if you have a message that should stay out of sight…don't write it down in the first place.

Timeline

09/29/2021: Olivia O’Hara submits a vulnerability report to Keybase detailing multiple methods of preserving exploded chats on desktop clients, including the switch-and-sleep method
09/29/2021: Keybase staff validates the report
09/30/2021: Keybase releases v5.8.0, which addresses the mobile vulnerability identified in CVE-2021-34421 and all instances of the desktop vulnerability except for the switch-and-sleep exploit method, which continues to work in v5.8.0
11/04/2021: Bounty awarded by HackerOne
11/04/2021: Keybase assigns a CVSS score of 3.8 to the vulnerability
12/17/2021: Keybase releases v5.9.0, addressing the switch-and-sleep method
01/07/2022: Keybase assigns CVE ID CVE-2022-22779 to the vulnerability
02/08/2022: Vulnerability announced via Zoom Security Bulletin

Further Reading

ZSB-22001: https://explore.zoom.us/en/trust/security/security-bulletin/
CVE.org: https://www.cve.org/CVERecord?id=CVE-2022-22779
MITRE (legacy): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22779
NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-22779



 

Wednesday, November 17, 2021

CVE-2021-34421 :: Keybase App Vulnerability: Incomplete Cleanup of Messages In Keybase for Android/iOS

In Keybase versions 5.7.0 and older, messages aren’t exploding like they’re supposed to — leaving them indefinitely viewable to lurkers.


How does this work? When the Keybase client for Android and iOS is operating, a user - let's call them User A - can background their Keybase session, and if in the meantime another user explodes a message in a shared chat with User A, the message will still be visible unless the chat is backgrounded again, or unless User A switches to another chat and returns to the original chat.

Using this method, an attacker with access to a conversation can potentially recover sensitive data. 

This vulnerability affects all Android/iOS versions ≤ 5.7.0.

Credits 

Olivia O’Hara - twitter.com/oliviaohara
John Jackson - twitter.com/johnjhacking
Jackson Henry - twitter.com/JacksonHHax
Robert Willis - twitter.com/rej_ex

Identification 

When activated, Keybase’s chat explode feature allows users to send a message, and then have it automatically “explode”—or self-destruct from all users’ devices—after a predetermined period of time. Users can also manually explode messages within the chat window, if they decide the message is too sensitive for others to retain for the duration of that predetermined length of time. This feature is available on all Keybase clients, and when functioning as intended, exploded messages should instantly self-destruct across all devices that have access to a chat.

While interacting in a group chat on Keybase’s iOS app, Olivia O’Hara was switching back and forth between apps and noticed that User A in the Keybase group chat had recommended that User B’s message be exploded. User B confirmed it was a good idea to explode the message, giving the impression that they had indeed exploded it themselves, but the message was still visible on O’Hara’s screen.

Fictional reenactment of chat, viewed on iOS app (black name = current device):

 

As the group continued chatting, more messages came through, but the supposedly exploded message was still visible. To complicate matters, when the chat was viewed simultaneously on a desktop client, the message showed as being successfully exploded.

Fictional reenactment of chat, viewed on a macOS desktop client (black name = current device):

At this point, O’Hara hypothesized that while any mobile user had their Keybase app running in the background, all explosions performed by any other user would not successfully execute on the mobile user’s device. However, O’Hara also witnessed two other things:

  1. Any messages exploded while the mobile user was running Keybase in the foreground would disappear as intended; 

  2. Messages always exploded as intended when viewed on a macOS desktop client.

Further examples, viewed on the Keybase iOS app:

Screen Shot 2021-06-27 at 00.37.58.png
 

The same test, viewed on the Keybase macOS client:

Screen Shot 2021-06-26 at 19.54.21.png

To attempt to reproduce the issue on other mobile devices, O’Hara mentioned this discovery to John Jackson. Together, they created a chat and obtained a proof of concept.

Video proofs of concept [iOS]:
https://drive.google.com/file/d/1J8NEIbWhY4-xKfbw9pcne-iGFGYeEV_d/view?usp=sharing
https://drive.google.com/file/d/1q2YL0LvQz-M8UM26BysJNc_syyvr7lmI/view?usp=sharing

After O’Hara and Jackson successfully reproduced the explosion failure, Jackson tapped in Robert Willis & Jackson Henry to further investigate and test the issue across more platforms.

While investigating further, O’Hara and Jackson were able to reproduce the issue on an Android mobile Keybase client as well as on iOS. Extended testing from the group revealed that the issue could be reproduced on any mobile Keybase client, but could not be reproduced on any desktop clients.

Impact

Users who quickly explode messages after sending them do so with the intention of maintaining anonymity and preventing sensitive information from being screenshotted and linked to themselves. Screenshots via external tools can work against the privacy model that Keybase has defined, and in this case, the user’s expectation of functionality doesn’t align with the way the application is built. While the attack is local, there’s a potential window for a user to have their exploded chats inadvertently retrieved by a third party and used against them; for instance, law enforcement agencies could abuse this window of functionality during a raid, or journalists, detained and inspected while traveling for high-priority cases, may unintentionally put confidential sources at risk.

The exploitability is low from the perspective of a threat actor. However, as Keybase’s product is a communication application focused on privacy, the failure of messages to explode opens up a pathway to exploitation that proves a reasonable concern for any privacy-minded user.

Timeline

06/01/2021: Olivia O’Hara discovers the flaw in the Keybase application
06/13/2021: Sakura Samurai members identify the same vulnerability in the Android client and test remaining clients
06/14/2021: John Jackson reports the vulnerability via Keybase’s HackerOne Program
06/25/2021: Keybase staff validates the vulnerability report
06/25/2021: Bounty awarded by HackerOne
06/26/2021: John Jackson follows up with program manager
08/10/2021: John Jackson follows up with program manager
08/13/2021: Program manager notes that the vulnerability has been submitted and is being addressed
09/30/2021: Keybase releases update 5.8.0, which patches all instances of the vulnerability
10/25/2021: Keybase assigns CVE-2021-34421 with a CVSS score of 3.7 to the vulnerability, reversing course on an earlier Zoom-wide decision to forgo assigning CVEs to low- and medium-severity vulnerabilities¹
11/09/2021: Zoom releases security bulletin ZSB-21017 for the vulnerability

Further Reading

The Security Ledger - Researchers Find KeyBase Exploding Messages Are A Dud: https://mailchi.mp/securityledger/weekly-ledger-week-of-nov-8-2215112

ZSB-21017: https://explore.zoom.us/en/trust/security/security-bulletin/
CVE.org: https://www.cve.org/CVERecord?id=CVE-2021-34421
MITRE (legacy): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34421
NVD: https://nvd.nist.gov/vuln/detail/CVE-2021-34421

Sakura Samurai: sakurasamurai.org
John Jackson: johnjhacking.com

___________________
1. Zoom, which acquired Keybase in 2020, became a CVE Numbering Authority (CNA) in April 2021, and initially stated it would no longer issue CVEs for vulnerabilities with a CVSS severity rating of low or medium. In November 2021, this author learned via email that due to requests from researchers, an internal [Zoom] decision had been made to publish/assign these low and medium CVEs “for the time being”, according to HackerOne staff.