Akamai research shows that 83 percent of all traffic on the web today are API calls (JSON / XML). In many cases this fast growth can be attributed to the adoption and popularity of mobile devices and the mobile app ecosystem, as well as the abuse by threat actors using bots to automate their manual attack processes. It’s been established that attackers are targeting public facing API’s that can be easily discovered, but there’s a whole other attack surface that’s getting little attention.
This attack surface centers on with how organizations manage the automation and orchestration of their own cloud environments using the same vulnerable API services. These API’s are often protected by basic defenses, such as cloud environment ACLs (Access Control Lists), simple API Keys, or performance dragging private tunnels. Moreover, challenges arise when trying to place an intermediary device between the corporate environment and those cloud hosted API’s, the sheer volume of transactions overwhelms these security devices leaving attack or abuse detection to be done after the fact by measuring negative performance impact or outages as a form of detection.
In this article, I’ll discuss API attack trends, the current (and failing) architectural designs for addressing security of these API transactions, attacker techniques, as well as common tools that can be used to identify your own attack surface and deploy the appropriate defenses.
Akamai has observed a steady increase in API related traffic for the past 10 years. A majority of that traffic are mobile API’s, and we’ve observed a spike in attack traffic targeting mobile API’s. But this could be explained as a focus by attackers, because these API’s are highly visible and handle authentication, as well as other important transactions.
But how do attackers perform recon against these non-publicized API environments? Well, for those API’s that are not running over a private tunnel, it’s usually quite simple.
Fierce.pl is a scanner that automates the discovery process within a domain. It can be pointed at a domain and using DNS queries, hostname ‘guessing’ and reverse lookups of any IP’s found during the scanning process – it can identify these environments.
You’ll see in the example below that a query against xyzcorp.com returns an interesting hostname called api.xyzcorp.com. This is an example of how these hostnames could be uncovered. But there’s another way to identify attack surface, and that’s by making use of Certificate Transparency Logs. 
Certificate Transparency Logs have become very useful in making the issuance and existence of SSL certificates open to scrutiny by creating an audit log which can be monitored and queried by anyone.
If the non-publicized API endpoints we were talking about earlier make use of TLS certificates, then not only would I be able to query the Certificate Logs, but they would be able to identify the corresponding hostname for that TLS cert, enabling a method of identifying and postulating the function of that API service.
“We have security,” you might say, protecting these APIs. Most commonly used is the basic function of API Keys for these environments. Which is a shared secret key that makes several assertions about contextual information agreed upon and shared between hosts which allows for this connectivity to be established. Attackers (and researchers) have made strides to find ways to find out these shared secrets or hardcoded values, and it’s sometimes by accidental exposure on the part of developers.
In this example we see a code snippet that was posted to GitHub that shows hardcoded OAuth token information that, if compromised, presents a risk to the authentication calls trusted between hosts in this process.
In comes an older tool that uses this exposure to find interesting data.
GitRob is a command line tool that can help identify sensitive information by spidering relationships within GitHub. Once pointed to a target, it can collect data on members, public repositories, search targeted file names, and generate valuable reports with mass amounts of rich context.
A response to GitRob comes in the form of a tool called Git-Secrets (owned by AWS) which can be used to scan your commits, merges, and commit messages for things considered secret, and reject prohibited regular expressions (based on patterns in its database) from being posted and exposed. As useful as this is, it still doesn’t work if developers are not using the tool or going through the thought process / procedural process of limiting accidental code exposure.
As attackers properly identify this attack surface they can then start to work through the business logic and function of how the API service works and what it does. And from that point they can start to perform many of the same attacks we have seen against client-side API services, like SQL Injection, and Command Injection. To protect against these types of attacks, you’d generally need some sort of inspection process that sits between the internet and vulnerable API services. But most of the time, the sheer volume of requests that are represented in a large corporate environment are too much for WAFs running API inspection to withstand.
A simple search for “api type:”webapps” on Shodan shows a couple hundred vulnerable services running at the time of this writing.
To get ahead of the API key exposure issues, we need to see organizations adopt more stringent processes and tools to help maintain sanitization of any code shared publicly containing sensitive data. And to protect these exposed API services, as we can see from the examples above, security through obscurity is not enough.
The need to have some sort of WAF inspection of these API calls as they leave the corporate environment can help in several ways. First it can prevent exposure to some of the previously mentioned access methods to API services and making fraudulent calls into the environment, but it can also provide more protection for your precious API services from accidental denial of service when someone makes a mistake.
(Tony Lauro manages the Enterprise Security Architecture team at Akamai Technologies. With over 20 years of information security industry experience, Tony has worked and consulted in many verticals including finance, automotive, medical/healthcare, enterprise, and mobile applications. He is currently responsible for Akamai‘s North America clients as well as the training of an Akamai internal group whose focus is on Web Application Security and adversarial resiliency disciplines. Tony‘s previous responsibilities include consulting with public sector/government clients at Akamai, managing security operations for a mobile payments company, and overseeing security and compliance responsibilities for a global financial software services organization.)
