This week, we focus on incidents of data exposure through vulnerable APIs. We examine a new report of data leaks in YouTube and Google APIs, vulnerabilities in open-source projects, and API hacks at healthcare and automotive companies. On a positive note, we share an update from the OpenAPI Initiative on the latest specifications for Overlays and Arazzo.
Industry News: OpenAPIs Overlays & Arazzo Standards
The OpenAPI folks have been busy! Lorna Mitchell, member of the OpenAPI Technical Steering Committee, shares her insights and some potential use cases for two new standards from the OpenAPI Initiative: Overlays and Arazzo.
Both specifications open a range of new opportunities and potential solutions for API quality, security, testing and governance. Lorna describes a number of possible use cases for Overlays to automate quality checks and process updates on OpenAPI documents. The concept reminds me of working with XSLT stylesheets, eons ago, to transform SOAP messages; though thankfully using Overlays looks far more simple in contrast.
Likewise, Arazzo offers, among other things, many new ways to improve API security testing by constructing and validating real-world business scenarios in sequences of linked API calls. Also, my colleague Philippe Leothaud shared his observation on LinkedIn about how Arazzo has the potential to be an essential tool for building API infrastructure designed for AI consumption.
So, lots of exciting new capabilities and solutions in store for OpenAPI users!
Vulnerability: Leaky YouTube API nets Hacker $10,000
A researcher discovered vulnerabilities in YouTube and Google APIs that exposed the private email address of anonymous YouTube accounts. Just for good measure, exploiting an additional API vulnerability also ensured targeted users were not notified about the attack.
First, the vulnerable YouTube API accepted a public channel ID in the request and returned an internal Google account ID (Gaia) in the response. This was the key vulnerability since it effectively verified a Google account ID for an anonymous YouTuber.
Next, the researcher found a vulnerable Google API to accept a Google account ID and return that user’s email address. This API was used by an older Google product called Pixel Recorder for sharing videos with other users.
So in just two quick API requests, the private email address of an anonymous YouTuber was retrieved. Not so anonymous!
One of the side effects of using the Pixel Recorder API was that it triggers an email notification to the targeted user whenever a video was shared, possibly alerting the user to the attack. The researchers found another API bug to prevent that email notification from being sent: setting an extremely long name for the title of the video.
The API failed to enforce practical limits on the length of the title, which allowed the request to be processed and the email address retrieved, but also prevented the email notification from being sent due to the excessive length of the title.
This case underscores how hackers probe and test an API’s input and output properties for vulnerabilities. It also highlights the importance of setting practical constraints on API parameters to mitigate the risk from such attacks.
Vulnerability: Excessive Data Exposure in Vulnerability Scanner
API security often emphasizes validating user input. However, the API response data should also be inspected and validated to prevent unauthorized leaks of private data.
A recent example of an API data exposure vulnerability was reported in ReNgine, an open-source reconnaissance and vulnerability scanner. The disclosure document provides a detailed breakdown of the bug, making it a valuable resource to learn about common API vulnerabilities.
In this case, the API unintentionally returned excessive user information, including a password. This is similar to a previous case of API data exposure by the social media platform Spoutible.
One way to help avoid this is by consistently enforcing strict schema validation on API response messages. The task of defining a schema forces a developer to carefully consider what data should be allowed in the API response. This practice can help to uncover flaws and data leak vulnerabilities before APIs are pushed into production.
Credit to the ReNgine team for setting clear guidelines for responsible disclosure and for quickly addressing the vulnerability. Credit also goes to the ethical hacker for documenting the issue in detail, providing the broader community with a valuable learning opportunity!
Vulnerability: API leaks Medical Records and PII
A recent report highlights a case of medical records and patient PII (personally identifiable information) leaked through unprotected APIs. The API endpoints, along with security keys, were exposed in public Javascript files. If these are uncovered, since the APIs did not enforce authorization, a malicious user could leverage the APIs for unauthorized access.
In addition to lacking proper authorization checks, the vulnerable API was also designed to use sequential numbers to access patient records. This makes it extremely easy for a hacker to guess the IDs of patient records and use the API to perform mass data scraping.
Why were the APIs to sensitive medical records left unprotected? It may be that the API developers assumed the APIs would only ever be used by a trusted client, with examples of the API requests “hidden” deep inside Javascript files that no one was likely to find. But as shown in the report, tools are available to scan public web assets and uncover a hidden attack surface, including API calls.
This incident underscores a critical point for developers and security teams: even APIs intended for use solely by trusted clients must operate under the assumption that unauthorized actors will find those API endpoints and attempt to exploit them. API security should be baked into the API’s design with authorization and input validation, following principles of least privilege and zero trust.
Vulnerability: Unsecured Spring Boot API impacts Volkswagen
The European ethical hacking group Chaos Computer Club reported how an unsecured Java framework API allowed them to access private keys that exposed location data of more than 800,000 Volkswagen vehicles, including vehicles used by law enforcement and prominent political figures. The vulnerability traces to the Spring Boot framework and an exposed actuator API endpoint. Actuator endpoints are provided for application developers to monitor and debug an application. These endpoints are unrestricted by default, which shifts the burden of ensuring proper configuration and security onto developers using the framework.
Here is a short summary of key points in the exploitation path.
- Researchers discovered an exposed Spring Boot actuator endpoint that required no authentication to access.
- This vulnerable endpoint allowed an unauthenticated user to access and download a snapshot of a Java application’s runtime memory, known as a heap dump.
- Within the heap dump, researchers found AWS credentials for an S3 storage bucket, containing 9.5TB of telemetric data, including detailed geo data (about 800,000 cars dumped their telemetry data every 24 hours).
-
Additionally, the heap dump exposed client IDs and secrets, which could be used to generate JWT tokens and access other APIs to retrieve private user data.
Secure-by-default is an approach to technology development that advocates security being enabled by default, without users having to turn it on. This approach would ensure that security controls are enabled and properly configured out of the box. Unfortunately, this is not the case for many 3rd party dependencies, including frameworks, libraries and Cloud platforms, so users must review and ensure appropriate security controls are enabled.
Tip of the hat to 42Crunch’s Axel Grosse for contributing to the review of this case.
Webinar: API Security for the Connected Vehicle Ecosystem
I’m thrilled to connect with automotive cybersecurity expert Darren Shelcusky to explore his deep expertise and valuable insights on successfully driving API security and DevSecOps programs in the automotive industry. Register for next week’s webinar
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
