Anatomy of a BOLA Attack – Part 1

In the first post of our blog series on API threat hunting, we reviewed some foundational API security terminology and explored the technology shifts that are making API threat hunting a must-do priority. But often the best way to understand the impact of specific types of API threats is by analyzing and learning from real-world examples.

The high-profile 2019 API security incident at Uber is a particularly instructive example of how well-understood types of API vulnerabilities can be hard to spot in specific environments – and how catastrophic the potential exposure can be if the wrong person eventually discovers them. 

Let’s dive into the details.

Account takeover is one of the most common – and potentially devastating – attacks directed at APIs. In 2019, a researcher named Anand Prakash demonstrated how multiple API vulnerabilities could be exploited to perform an account takeover of any Uber user. The attack method stacked two very well-understood API vulnerability types that were hiding in Uber’s application stack.

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.

Fortunately, the vulnerabilities that enabled this account takeover method were reported responsibly and remediated by Uber before they could be exploited by threat actors. But they are excellent examples of how even well-known API vulnerability types are often overlooked by large and sophisticated development and security teams.

Excessive Data Exposure Vulnerabilities at Uber

The Open Web Applications Security Project (OWASP), an online community that is instrumental in developing and sharing knowledge about application security topics, maintains a list of the top 10 API vulnerability types. Item number 3 (API3:2019) on this list is excessive data exposure. In short, excess data exposure means that the API shares more information than is necessary to operate. Step 1 in the Uber attack sequence outlined in the video clip above shows how a minor vulnerability of this nature, sharing the UUID unnecessarily, can be a stepping stone to a much broader attack.

Broken Object Level Authorization at Uber

Unfortunately for Uber, the vulnerability above was combined with a second type of vulnerability called broken object level authorization (BOLA). This is item number 1 (API1:2019) on the OWASP API Top 10. BOLA vulnerabilities can be particularly devastating since they can be used to retrieve an access token that gives a threat actor broad control over an account. This BOLA vulnerability compounded the severity of the issue for Uber. The researcher or any user, even when in possession of a single UUID, should be limited to accessing information only about that specific user. Instead, the BOLA vulnerability allowed the user access to any other UUID as well.

Key takeaway for Security Teams

As this example shows, even if you understand the OWASP API Top 10 conceptually detecting specific instances of them is far from easy – even if you have a large and sophisticated security team. While Uber was fortunate that the researcher who discovered this set of vulnerabilities acted responsibly, it could have just as easily been discovered by a malicious actor.

In our next post, we’ll share another example of how similar techniques can be used to exfiltrate data. We’ll then conclude this series with some practical tips for getting your API threat hunting program 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:

• Why API Threat Hunting is Now Essential