Issue 95: Vulnerabilities at Zoom and OkCupid 💘, progress on OAuth 2.1, API Information Disclosure tutorial

Zoom has become the household name of the times, with plenty of face-to face activities moving online. While this helps to keep the bugs of the living kind at bay, the online world comes with bugs of their own, and Zoom most certainly is not an exception.

Tom Anthony from SearchPilot found that lack of rate limiting on a Zoom endpoint allowed to brute-force passwords to any private meetings in Zoom. At that time, the default Zoom passwords were just 6-digit and numeric. This meant that there were only 1 million combinations to try, and the lack of rate limiting made enumeration possible.

This is a classic example on how the issue OWASP API4:2019 — Lack of resources and rate limiting  effectively becomes API2:2019 — Broken authentication when rate limiting is not properly implemented on authentication or password reset endpoints. Such endpoints or API paths and operations require special attention. It is not enough to assume that if the overall API has some rate limits these would be sufficient across all operations: authentication-related or not.

Anthony was nice enough to include in his post the exact recommendations how to mitigate the issue that he gave to Zoom:

1. Rate limit GUIDs to a reasonable number of password attempts (e.g 10 [different] failed attempts in an hour for a given meeting)
2. Rate limit IP addresses, irrespective of GUID, for password attempts (irrespective of meeting ID)
3. Rate limit or trigger a warning should a given meeting pass a set failure rate for failed password attempts
4. Fix the CSRF on the Privacy Terms form, so it is harder to automate attacks.
5. Increase the length of the default password.

This is not the first time Zoom has had vulnerabilities that related to meeting IDs and joining meetings. We have covered previous cases, for example, in our issues 39 and 51.

Popular dating service OkCupid has fixed vulnerabilities reported by Checkpoint Research.

Some of the vulnerabilities were not directly API-related, such as deep links in their mobile app or cross-site scripting (XSS). However, these issues were seriously aggravated by the misconfigured Cross-Origin Resource Sharing (CORS) on their API server.

This allowed the researchers to retrieve sensitive personal information (PII) of users using their stolen authentication details.

Lessons learned here: fibs in your API security can make other issues so much worse.

OAuth 2.1 has now reached the milestone of an official IETF OAuth working group draft.

OAuth 2.1 is not a brand new standard per se, but rather an update for OAuth 2.0 that incorporates all the current OAuth security best practices:

• Proof Key for Code Exchange (PKCE) is now required for authorization code grant.
• Exact matching is required for redirect URIs.
• Refresh tokens are now sender-constrained or one-time use only.
• Implicit grant and Resource Owner Password Credentials grant have been removed.
• Bearer tokens in query parameters are no longer allowed.

Thus, even though there still remains some way to get OAuth 2.1 formally ratified, there is no reason not to start following these security best practices right away.

Check out one of the people behind the proposal, Aaron Parecki, talking about this milestone for OAuth 2.1 in the latest episode of the OAuth Happy Hour:

Here’s a nice quick video by Heath Adams on locating APIs leaking personal data:

• How to use Burp Suite to locate all API endpoints that a public website uses.
• How to use Google and other tools to locate the API (often OpenAPI) definition and other documentation of the API, and how to use the Wayback Machine to find earlier versions of the APIs.
• How to use a dictionary and Burp Intruder to fuzz the endpoints to find undocumented APIs that leak data.