Info: When registering on Twitter, buy a virtual number to receive SMS to activate your account.

Akamai research shows that today 83% of all Internet traffic is made up of API calls (JSON / XML). In many cases, this rapid growth can be explained by the acceptance and popularity of mobile devices and the ecosystem of mobile applications, as well as abuses by actors using bots to automate their manual attack processes. It has been found that attackers target publicly available APIs that are easy to detect, but there is another attack surface that receives little attention.

This attack is based on how organizations manage the automation and orchestration of their own cloud environments using the same vulnerable API services. These APIs are often protected by basic security features such as cloud ACLs (access control lists), simple API keys, or private drag-and-drop tunnels. In addition, problems arise when trying to place an intermediate device between the corporate environment and these APIs located in the cloud, due to the huge volume of transactions, these security devices lose their power, leaving detection of attacks or abuses after the fact, measuring the negative impact on performance or interruptions in work.

In this article, I will talk about the trends of API attacks, current (and unsuccessful) architectural solutions to ensure the security of these API transactions, attacker methods, as well as general tools that can be used to determine your own attack surface and deploy appropriate defense.

Over the past 10 years, Akamai has seen steady growth in API traffic. Most of this traffic is mobile APIs, and we have seen a surge in traffic from attacks targeting mobile APIs. But this can be explained by attackers as a trick, since these APIs are clearly visible and handle authentication, as well as other important transactions.

But how do intruders conduct intelligence against these non-public API environments? Well, for those APIs that do not work through a private tunnel, this is usually pretty simple.

In the above example (example 1), you see that a request to xyzcorp.com returns an interesting hostname named api.xyzcorp.com. This is an example of how these host names can be expanded. But there is another way to determine the attack surface - using certificate transparency logs.

Certificate transparency logs have become very useful so that the issuance and existence of SSL certificates is open to review by creating an audit log that can be monitored and requested by anyone.

If the unpublished API endpoints that we talked about earlier use TLS certificates, then I could not only request certificate logs, but they could also identify the appropriate host name for this TLS certificate by enabling the method to determine and postulate the function of this API service.

“We have security,” you say, protecting these APIs. Most commonly used is the core function of the API keys for these environments. Which is a shared secret key that makes several statements about the contextual information that is agreed and shared between hosts, which allows you to establish this connection. Attackers (and researchers) have taken steps to find ways to learn these common secrets or hard-coded values, and sometimes this is due to accidental exposure by developers.

In this example (example 2), we see a piece of code that was posted on GitHub that shows hard-coded information about the OAuth token, which, if compromised, poses a risk for authentication calls that the hosts trust in this process.

When attackers correctly identify the attack surface, they can begin to work with the business logic and the function of how the API service works and what it does. And from that moment, they can start to perform many of the same attacks that we saw with regard to client APIs, such as SQL injection and Command injection. To defend against these types of attacks, you usually need some kind of verification process that lies between the Internet and vulnerable API services. But in most cases, the volume of requests submitted in a large corporate environment is too large for WAFs that perform API checks to withstand.

A simple search for “api type:” webapps on shodan.io shows a couple of hundreds of vulnerable services that were running at the time of this writing (Example 3).