Consider this stat from a recent report by Noname Security. More than 87% of their respondents are concerned with the security risks of outdated or unnecessary APIs. In the API hacking world, we call those zombie APIs.
You know the type of API endpoint I’m talking about. It’s those forgotten APIs that are no longer being maintained but still exist for “backward compatibility”. These APIs can become outdated, unreliable, and vulnerable to hacking. A potential security risk for any application that uses them.
It’s such an important class of vulnerability. It lands as #9 on the 2023 OWASP API Security Top 10 list as API9:2023 Improper Inventory Management.
Let’s talk about that before bad code bytes you and you join the undead. (groan…. ya, that’s a pretty bad zombie joke 🧟 )
Why finding Zombie APIs is important
Finding zombie APIs is crucial for us as these neglected APIs can be a goldmine of vulnerabilities and security loopholes. We can exploit these vulnerabilities to gain unauthorized access to data, bypass security controls added to later versions, and even compromise entire systems when ongoing patching isn’t being maintained.
APIs tend to get more brittle over time. This is why API security best practices always talk about sunsetting and disabling older versions.
But security teams who manage risk aren’t always aware of exposed APIs thanks to API sprawl. And when more than one-third (35%) of organizations release updates to their APIs daily, and a further 40% do it weekly, from a security standpoint it becomes much more difficult to keep track of all the API traffic.
How digital transformation and app modernization create the illusive “zombie API”
Here is another top finding in Noname Security’s research. With the cloud migration of existing apps and the adoption of SaaS-based services that deliver new business value, within the next two years, it’s expected that over 50% of the organizations surveyed will have active APIs deployed in all their apps.
Combined with API-first app architectures that are becoming more prevalent for developers these days, rapid API production will no doubt lead to more API sprawl and the risk of more vulnerable APIs.
While a strict API governance strategy can help mitigate this risk, the reality is it’s hard to manage API sprawl when the app team is consuming third-party APIs while at the same time also connecting data to internal and external systems that security teams may not have visibility to.
How to Identify Zombie APIs
If you want to identify zombie APIs within an organization, there are several steps you can take.
The first step involves creating an inventory of all the APIs being used in the target organization. This includes both internal and external APIs. This will help you understand the scope of API usage and identify any potential zombies that may exist. API discovery tools can help here during recon.
Analyze API usage
Once you have an inventory of the APIs, you can start analyzing their usage. This involves looking at the number of requests being made to each API, who is making the requests, and how those APIs are being used. This can help you identify APIs that are no longer being used or are only being used by legacy systems. This is much harder to do if you are limited to black-box testing. However, if you can gain access to API gateway traffic data, you can usually parse this out.
Check for versioning
It’s important to check if target APIs have versioning. Versioning allows support for backward compatibility with older versions of the API endpoint. It also means that older versions may not be maintained anymore and could be vulnerable. Check metadata like URL pathing, cookies, claims in access tokens, custom HTTP headers, and HTTP request parameters for obvious versioning artifacts. If you find any outdated versions of an API, you should consider attack threats there first.
Look for signs of neglect
APIs are often neglected and not maintained. Signs of neglect include outdated documentation, lack of updates, and no support or contact information. If you come across any APIs that have these signs, they could be zombies. Pay special attention to metadata that may expose older frameworks and services. It’s not uncommon to stumble upon an old API version running in really old container images that may be vulnerable.
Perform security scans
Finally, you should perform security scans on your APIs to identify any platform or framework vulnerabilities. This can help you identify any potential risks associated with the infrastructure of your APIs, including zombie APIs that may be vulnerable to attacks. FOSS tools like nikto are designed to do this quite quickly.
What to do when you find a potential zombie
Once you have identified an API endpoint that might be a zombie, use BurpSuite to capture a request to it. Then capture the same request to a newer version, and use Burp Comparer to see what is different. Within seconds you might be able to identify changes in the payload that you can tamper with. I’ve talked about tampering with API data in weird places before. You should be able to follow that guidance (especially the section on tainting payloads) to start trying to explore how to kill the zombie API.
Look at the data closely
Pay special attention to JSON properties that are added or removed between versions in the payload body. Developers may have changed the data schema for an object which may allow you to tamper with a request to expose an excessive data exposure vulnerability. You never know if a developer was exposing sensitive data improperly in an older version that has since been fixed.
You may even see that the older version allows modification of the data to trigger a mass assignment vulnerability. I’ve actually found a couple of critical high-severity security issues that allowed privilege escalation within a tenant using this tactic. While the developer was preventing the changing of sensitive properties in the new endpoint version, the older one did not, which allowed me to taint the API data and give me more access than the application expected.
Look for possible platform or framework changes
You should also check the headers in the HTTP response for any differences that might indicate a change in the platform or framework. The API gateway may be redirecting older versions to an internal API server that may not have the proper controls that the new API versions possess. The use of multiple technology platforms is not uncommon and the functional or security capacity may be different between versions that may give you a foothold.
Some say finding shadow APIs or rogue APIs is a bigger risk to a company than those posed by zombie APIs.
I don’t agree.
A shadow API may be found through API discovery. But old APIs may sit dormant and forgotten for some time as new APIs (or at least new versions) are deployed. And that dormant code increases the brittleness and attack surface of an otherwise trusted API.
As API attacks become more prevalent and sophisticated, organizations must prioritize API security and implement strict governance strategies and best practices to mitigate the risks of zombie APIs. By doing so, they can avoid the potentially catastrophic consequences of apocalyptic zombie APIs that may cause data breaches, unauthorized access, and system compromise.
And you as the API hacker can help them find and eradicate these zombies before they get bitten.
Did you find this useful? Then you might like my Ultimate Guide of API Hacking Resources. Enjoy!