This week, we take a look at the recent data spill incident at Clubhouse, the (poor) state of API security in major healthcare mobile applications, how scope-based reconnaissance methodology works, and the latest update (v3.1.0) to the OpenAPI Specification.
Vulnerability: Clubhouse
Clubhouse is an audio-only social network app for iPhone. Last Sunday, it had a data spill incident in which one of the users started streaming multiple rooms from their own website. This breaks Clubhouse’s terms of service and customer expectations: conversations are only supposed to be accessible live and only to the users in that particular room.
Daniel Sinclair posted his analysis on the root cause of the incident in his Twitter thread. It turns out that APIs and tokens are at the heart of it.
Clubhouse itself is actually mostly handling just the user management part. A different platform, Agora, does the audio streaming. When users join a room, they are issued an Agora token. The Clubhouse app then uses these tokens to grant users access to the audio stream.
Attackers used their Clubhouse user token and had a bot join every room, collect the Agora tokens, and plug them into a browser client. This worked because Agora tokens are long-lived and independent of Clubhouse. Once you get an Agora token, you retain access to the room’s audio stream even if you leave the room in Clubhouse (so the state of your Clubhouse user token changes, but Agora token doesn’t) and join another one.
Lessons learned here:
- If your service or application is popular, attackers will do their best to figure out the APIs behind your app and use them to work around any limitations you have imposed on the user interface.
- Beware of scripted enumeration, such as room enumeration to obtain Agora tokens in this case.
- Pay attention to token lifecycle and the connection between the service provider (here Agora) and the identity provider (Clubhouse). Long-lived tokens that cannot be recalled can bite you.
Research: API security in healthcare mobile apps
Approov has published security research by Alissa Knight on 30 popular medical healthcare apps. It is estimated that together these apps have 23 million users.
The findings of the research are pretty dismal:
- 100% of the checked apps were vulnerable to Broken Object-Level Authorization (BOLA/IDOR) and exposing personal (PII) and health (PHI) information!
- 50% of the APIs tested gave access to other patients’ pathology, X-rays, and clinical results.
- 77% of applications had hard-coded API keys, tokens, or credentials.
Below are some of the recommendations from the research:
- Address both app security and API security: recognize that synthetic traffic to the API is an issue and arises from bots and automated tools, not from genuine apps and legitimate data requests.
- Shift left and shield right: secure the development process and harden apps, but ensure that runtime protection is also in place.
- Protect against X-in-the-middle attacks: certificate pinning is critical but often left undone because expired certificates can block apps and impact the user experience. However, when done correctly, certificate pinning does not impact either performance or availability.
- Improve visibility into controls: organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily โ both for compliance with HIPAA mandates and to sustain data security and privacy.
- Penetration testing, as well as static and dynamic code analysis, should be performed regularly.
See the press release for the report summary. The full report is available here.
Methodology: Reconnaissance guidelines
Reconnaissance (aka recon) is the process of discovering the attack surface of a system under penetration testing. With modern complex systems, the attack surface can be significant, and thus the discovery could include several different approaches and tools.
Harsh Bothra has done a nice job summarizing the various approaches in his Scope Based Recon Methodology:
- The small scope would only include a single URL, or a small set of URLs, in a system (for example, staging, development, and testing environments).
- The medium scope would include wildcards and subdomains.
- The large scope would include all the resources that the organization has.
Here’s the handy mindmap that he came up with:
For each area in his map, Bothra provides a quick description and links to the popular tools used for the procedure. Definitely worth checking out.
Standards: The OpenAPI Specification v3.1.0
The OpenAPI Specification (OAS) is the prevailing industry standard for HTTP (including REST) API contracts and documenting them.
The standard is maintained by the OpenAPI Initiative (OAI), an industry consortium under Linux Foundation that includes vendors such as 42Crunch, Google, IBM, Kong, Microsoft, MuleSoft, Oracle, Postman, SAP, SmartBear, and others.
This week, the OAI has officially released version 3.1.0 of the OAS. The major changes in the new version include:
- Full compatibility with the JSON Schema standard
- Support for webhooks
- Support for identifying API licenses using the standard SPDX identifier
-
pathItemsobject is now optional, making it simpler to create reusable libraries of components. - Mutual certificate for API authentication is now supported.
Note that v3.1.0 is incompatible with v3.0.x โ there are breaking changes in the standard. Thus, it will take some time for the tooling to catch up with the new version.
For more details, see:
- The official announcement by the OAI
- A post by Phil Sturgeon on the major breaking changes and migrating from 3.0.x to 3.1.0
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
