The Perils of Overestimating the Security of Your APIs

Marianne Williamson once said that “Empires always have the hubris to think they are indestructible, when in fact they are always unsustainable.”  Similar to empires that have fallen throughout the annals of history as a cost to their hubris, so too will companies that overestimate the wrong tools they use to secure their APIs.

In 2019, I hacked 30 bank mobile apps and APIs in coordination with domestic and international financial services and FinTech companies. In 2020-2021, I hacked 30 mobile health (mHealth) apps and FHIR APIs in coordination with healthcare providers, giving me access to thousands of patient records via their APIs due to broken authentication and authorization vulnerabilities. This year, in coordination with federal and state law enforcement agencies, I was able to take remote control of law enforcement vehicles through the automaker’s APIs.

When performing a penetration test of an API, I follow a simple four (4) step process:

Step 1 - Reverse Engineering: In this step, I download the mobile app or access the web client that talks to the API endpoint(s) and extract the APK file to use the Mobile Security Framework (MobSF) to hunt for hardcoded credentials and API secrets in the source code of the app.

Step 2 - Network Traffic Analysis: I then perform traffic analysis by inserting myself between the API client and API endpoint(s)  to better understand how the API works, what it expects for stimulus and the response. This allows me to also identify any filtering of sensitive data that the API endpoint(s) rely on the client to obscure and not render in the client to the user.

Step 3 - Map API Behaviors: I then record the API requests I extract from the stream by talking to the API endpoint(s) directly.

Step 4 - Fuzzing: I then target the APIs to try to uncover unlinked content accessible on the API endpoint(s) as well as uncover other vulnerabilities that may have been missed in manual testing.

My research has led me to discover that more often than not, organizations are using wrong tools to secure their APIs. In many of the APIs I breached, the organization was using a web application firewall (WAF) or API gateway to secure their APIs.  Despite the application of these security controls that were interdicting the traffic flowing to their APIs, they failed to see my exploitation of the logic-based vulnerabilities in the APIs, such as Broken Object Level Authorization or BOLA (also referred to as Insecure Direct Object Reference or IDOR) because of the rules-based nature of how these security controls work.

WAFs work on rules-based detection engines that check HTTP traffic against a library of rules for detecting indicators of compromise, such as SQL injection or cross-site scripting. However, because of their lack of application context, they often fail in detecting exploitation of logic-based issues, such as authorization. An example of this is being legitimately authenticated, proof of which is provided in the bearer token transmitted with the API request, but not authorized to view the data I’m requesting. BOLA vulnerabilities have been the most prevalent vulnerability inherent in the APIs I’ve breached over the span of my research into hacking APIs.  
To obtain an unbiased API hacker’s perspective of the wrong and right way to secure your APIs, I would encourage you and your team to download my new eBook “The Perils of Overestimating the Security of Your APIs,” which summarizes my research about API breaches and recommendations on how to get ahead of these vulnerabilities.