Anatomy of a BOLA Attack – Part 2
In the first post of our blog series on API threat hunting, we explored the technology shifts that are making API threat hunting an essential priority for security leaders. We then followed this up with a real-world example from Uber of how multiple undiscovered API vulnerabilities can be combined with potentially devastating impact.
It can be tempting to view high-profile incidents like the one at Uber as a “perfect storm”. But as APIs assume a more central role in your business, finding and mitigating these types of API vulnerabilities must be a core element of your security program.
To illustrate the point, we’ll explore a lesser known example of how a similar technique of stacking multiple API vulnerabilities opened the door to sensitive data exfiltration at the German education application firm Scoolio.
Incident Snapshot
| Attack Summary | Vulnerabilities Exploited: OWASP API Top 10 |
|---|---|
Outcome of Attack: Massive Data Exposure Industry: Education Vulnerabilities Exploited: |
|
The Scoolio app collects extensive information from its student users. For example, it conducts personality tests, provides social networking and chat features, and manages activities like study planning and tutoring. These features amass a trove of personally identifiable information (PII).
Security researcher Lilith Wittmann discovered a BOLA vulnerability in Scoolio’s APIs in 2021 that made it possible to utilize two API calls to access PII and other data for any other user of the Scoolio app.
For a brief overview of how the exploit worked, check out this excerpt from our recent webinar, “API Threat Hunting: Anatomy of an API Attack.”
Click here to watch the complete webinar replay.
In the example, you see some of the same techniques from our last post on Uber repeated, such as excessive data exposure giving an external party the ingredients needed to execute a BOLA attack. But in this case, there was also a third example of how an OWASP API Top 10 item can appear in a real-world environment.
Improper asset management
One particularly notable element of Scoolio API vulnerability exploit is that it took advantage of improper asset management, which is number 9 (API9:2019) on the OWASP API Top 10 list. If you paid close attention to the attack sequence described in the video excerpt above, you may have noticed that the first step is applied to version 3 of the API, while the second step was taken against version 2. Improvements were made in version 3 that more tightly governed access to PII. However, these improvements were undermined by the fact that the more vulnerable version 2 remained accessible to all. Ultimately, both version 2 and version 3 were affected by the BOLA vulnerability. But the unnecessary presence of version 2 made the impact of the vulnerability more severe.
A note about UUID usage
You may have noticed that in both the Scoolio incident and the Uber incident described in our last post, the attack technique used centered on discovering and using universally unique identifiers (UUIDs). But it’s important to note that this has more to do with these specific API implementations than any case to be made against the use of UUIDs. The use of UUIDs is in fact a very good practice. Using randomly generated numbers instead of a predictable sequence of user identifiers makes it more difficult for a threat actors to access information for users en masse. The problem arises when the UUID information is exposed too permissively and combined with BOLA vulnerabilities.
Key takeaway for Security Teams
Our intention in recounting the Uber and Scoolio API security incidents is not to disparage the companies affected. API vulnerabilities are a fact of life that affect all organizations that use APIs widely. Rather, our goal is to bring an important point to life: understanding API vulnerabilities conceptually isn’t enough.
Your applications will only be protected if you have ways to map broad categories of API threats to specific aspects of your unique API implementation. Only this will give you the foundation you need to conduct proactive API threat hunting activities that reduce your ongoing risk.
In our next and final post of this series, we’ll share some practical tips and examples of how to do this in your environment and get your API threat hunting initiative off the ground.
In the meantime, we also encourage you to check out the full replay of the API threat hunting webinar excerpted above.
Additional Reading in our API Threat Hunting Series:
*** This is a Security Bloggers Network syndicated blog from Blog authored by Tal Leibovich. Read the original post at: https://www.neosec.com/blog/anatomy-of-a-bola-attack-part-2
