This report was fully disclosed on 11 March 2020

Summary

Due to the lack of rate limiting or captcha on a specific end-point it is possible for an unauthenticated attacker to send a large number of SMS text messages to a phone number of their choosing.

This allows a remote unauthenticated attacker to abuse the service and perform “SMS Flooding”, resulting in the target receiving hundreds or thousands of SMS text messages per minute.

About Zoom: “Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, collaboration, chat, and webinars across mobile devices, desktops, telephones, and room systems.”

Proof of Concept

First we must craft a request to the vulnerable end-point. The request body is as follows.

POST /mobile/sendtextlink?num=6475551337&req=0 HTTP/1.1
Host: zoom.us
Connection: close
Content-Length: 22
User-Agent: Hacker 7.23
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Encoding: gzip, deflate

phoneNumber=6475551337

In this case we used a free phone number provided by our friends at TextNow as our target for testing.

Once we have crafted this request, we can use Burp intruder to repeat the request a desired number of times. For our proof of concept we choose numerical sequence of 100.

We can note that the first response was received at 12:50:09 and the last response was received at 12:50:19. Since 100 requests were sent we can determine that messages can be sent at a minimum rate of 10 messages per second, or 600 per minute from a single attack.

image tooltip here

image tooltip here

As shown in the following screenshots 100+ sms messages were received by the target.

image tooltip here image tooltip here image tooltip here

Active Exploitation

At 2:57 AM on 25 Feburary, Twitter user @scottbix posted a video of his phone being flooded with messages from various platforms, including but not limited to Zoom. Based on this example we can determine with a high degree of certainty that this vulnerability is actively being exploited for malicious purposes.

  • Implement captcha and other rate limiting controls to prevent abuse.
  • Discontinue unused end-points
  • Implement a security and bug reporting information such as a security.txt file so security researchers can more easily report findings in the future.
  • Perform a full penetration test of the web platform and API to identify further issues.

Remediation Status

On 02 March 2020 Glitchwitch re-tested this issue and has noted that it has been fixed. Requests to the vulnerable end-point now respond with HTTP error code 404, indicating the end-point has been removed.

Response From [email protected]

On Friday, February 28, 2020 19:06, Zoom (Security) [email protected] wrote:

Hi,

Thank you for your report! We’ve opened a ticket internally to do further investigation and make the necessary fixes. I’ll keep you appraised of any new information as it develops.

Zoom Video Communications

Response From [email protected]

On Monday, March 2, 2020 20:54, Zoom (Security) [email protected] wrote:

We’ve opted currently to remove the functionality entirely as we no longer view it as a necessary component for onboarding. We’d ask that we can coordinate with you on publication of your findings here. If that’s amenable to you I’d like to put you in touch with someone on our Comms team. Regardless, thank you again for finding and bringing this to our attention!

Zoom Video Communications

Timeline

  • 25 February 2020: Affected Party Notified
  • 28 February 2020: Affected Party Responded (+3 days)
  • 2 March 2020: Affected Party Released Patch (+6 days)
  • 2 March 2020: Affected Party Responded (+6 days)
  • 11 March 2020: Report Published (+15 days)