Fun fact: If you noticed a while ago Zoom’s web client going AWOL for a week, it’s because someone found a passcode-cracking hole

Zoom has confirmed it fixed a vulnerability that could have been exploited by miscreants to crack the passcodes needed to access strangers’ private chin-wagging.

The video-conferencing biz said it addressed the weakness in its systems after the issue was discovered and privately reported by UK-based bug-hunter Tom Anthony. To hear him tell it, Zoom did not put sufficient protections in place to prevent criminals from discovering a given meeting’s passcode through brute-force.

By default, Zoom would prompt people to create a six-digit passcode to protect their conference calls, and so it was possible for eavesdroppers to rapidly run through all possible combinations, from 000000 to 999999, until hitting the correct one for a particular meeting.

“I poked about in the Zoom app and noticed the default passwords being six digits and numeric, meaning one million maximum passwords,” Anthony explained in a write-up this week.

Normally, this in itself wouldn’t be a major issue, as most applications and services limit the number of passcode-entry attempts a user can make before being locked out, or at the very least limit the rate at which guesses can be made. There’s no way someone should be able to run through all one-million combinations before being blocked or curbed.

In Zoom’s case, however, Anthony found that there was no rate limit. However, there was a snag: each passcode check required sending two HTTP requests to Zoom’s servers, which made automated cracking an impractically long process. By the time a miscreant had gone through all the codes until hitting the right one, the meeting would have long since ended, due to this overhead.

But then…

Here is where things get interesting. Of those two HTTP requests, the first submits a passcode, and the second checks to see if it was successful. These requests require obtaining and using a unique ID number, or a GUID, from the Zoom servers. Anthony found it was possible to request a large number of these GUIDs beforehand, and then using this pool to launch batches of passcode checks in parallel, reducing the time needed to run through all the codes.

“There was no rate limit on repeated password attempts, each comprising two HTTP requests – one to submit the password, and follow up request to check if it was accepted by the server,” said Anthony. “However, the speed is limited by how quickly you can make HTTP requests, which have a natural latency which would make cracking a password a slow process; the server side state means you have to wait for the first request to complete before you can send the second.

“However, we should note that the state was stored against the provided GUID, and you can ask the server for as many of those as you want by sending HTTP requests with no cookie. This means we could request a batch of GUIDs and then chunk the one million possible passwords up between them and run multiple requests in parallel.”

Anthony said his proof-of-concept passcode cracker was able to break a meeting’s six-digit password in about 25 minutes from a single computer, and he believes this could easily be reduced much further using more machines. “With improved threading, and distributing across four or five cloud servers, you could check the entire password space within a few minutes,” he said.

While Anthony focused on the web client for his research, he believed the issue was present in all forms of the Zoom client. And if you’re wondering why the web version of Zoom went offline for a week in April, it was to fix this very issue after he alerted Zoom to the security shortcoming.

Upon learning of this issue, we immediately took down the Zoom web client to ensure our users’ security

In a statement to The Register this week, a Zoom spokesperson said: “Upon learning of this issue on April 1, we immediately took down the Zoom web client to ensure our users’ security while we implemented mitigations. We have since improved rate limiting, addressed the CSRF token issues and relaunched the web client on April 9.

“With these fixes, the issue was fully resolved, and no user action was required. We are not aware of any instances of this exploit being used in the wild. We thank Tom Anthony for bringing this issue to our attention.”

This, of course, was all happening at the height of Zoom’s security and privacy crisis. With the pandemic lockdown driving millions upon millions of people stuck at home onto what had previously been mostly an enterprise video-conferencing service, Zoom was suddenly in the spotlight, and being scrutinized by infosec bods.

In fact, as Zoom took down its web client, its CEO was publicly pledging to do better on security.

By June, Zoom appeared to have beefed up its defenses and privacy measures, and had hired HackerOne to run its bug bounty program to reward those who privately report vulnerabilities in future.

There was a bit of communications breakdown after the security flaw was addressed. In mid-April, Anthony heard Zoom was planning to set up the aforementioned bug bounty program run by HackerOne, and asked the video-conferencing biz if he could still publicly disclose the details if he successfully applied for a reward. He was worried the bounty program rules would require him to keep schtum, and he felt the flaw deserved public attention.

Anthony didn’t hear anything back, and so spilled the above details onto his website on Wednesday this week.

However, Zoom has since been in touch with him, we understand. In an email to El Reg, Anthony told us: “I did get a very nice email from Zoom apologizing they hadn’t followed up on my contacts, and letting me know about some of the things they’re doing to improve their researcher communication going forward. They also welcomed future feedback and bugs from me.” ®

READ MORE HERE