The API Timebomb

APIs have delivered velocity and competitive advantage to companies of all sizes with IDC research calculating that 10-50% of enterprise revenue is derived from APIs, making them the interface of choice for data interchange between applications.

But this versatility is not without its price. APIs are equally attractive to attackers because they provide ready access to the backend systems holding sensitive data. As adoption grows, so too does the API attack surface, potentially creating a ticking timebomb because of the poor security afforded to these middlemen.

According to the Enterprise Strategy Group (ESG), application environments will see a significant step change in the next two years. While 35% of organizations currently run their apps over the public cloud i.e. IAAS, this will almost double to 67%, and while 39% run these apps over microservices today, this will rise to 71%. It’s a similar story to API adoption. Today, 28% of web apps and websites use APIs but that will rise to 57%. But security isn’t keeping pace.

Why protecting APIs is a struggle

APIs are stateless in nature and include the command, payload, and content, making them challenging to secure. Typically developed iteratively, they evolve over time, and this can see their footprint fluctuate or previous iterations continue to persist. Updates tend to be performed weekly or even daily, resulting in multiple earlier versions, and if these aren’t taken down or kept track of via an automated inventory. They then can become shadow or zombie APIs and possible targets for attack.

Protecting APIs is no easy feat, which is why many security teams have adapted existing solutions. Such as Intrusion Prevention Systems (IPS), next-gen firewalls, or app security tools such as a Web Application Firewall (WAF). However, these tools are unlikely to spot and flag malicious activity because while some may contain insecure code the vast majority won’t but can still be taken over. Commonly referred to as ‘Living off the Land’ (LotL) attacks, this sees the API’s own functionality used against it.

As a LotL attack doesn’t involve the use of signatures or break any rules, such activity is unlikely to be detected. If we look at the top attack method according to the OWASP Top 10 – Broken Object Level Authorisation (BOLA formerly IDOR) – the attacker simply must understand the business logic of the API to gain legitimate access to data. This means that reverse-engineering an API can provide the insight needed; there’s no need to exploit a vulnerability. So it could be argued it’s not an attack in the traditional sense.

Trust in tools misplaced

What’s concerning is that many aren’t even aware that these tools are performing badly. The same ESG survey found that 46 percent use multiple tools because they think this increases the protection offered and 38 percent chose to add in yet more tools. If these weren’t performing as expected, adding to the technology stack and the headache of monitoring, and maintaining this. More than a third thought their solutions offered complete protection even though they weren’t designed to provide API security.

At this point, it’s also worth mentioning that there’s a lot of confusion in the marketplace. An API gateway, for instance, should not be considered an API security tool. It enables the business to discover and track its APIs but does not discover or remediate coding errors nor does it stop or block API attacks. Indeed, an API gateway can exacerbate the problem by acting as a single point of failure. If compromised, then provides access to all the APIs it routes.

There are numerous examples of companies falling foul of API attacks such as Account Takeover  (ATO). For example, as APIs become more entrenched in supply chains, so the problem grows. The attack against MailChimp earlier this year should serve as a warning of how far a well-orchestrated attack can reach. It saw the compromise of API keys used to provide account access and the attackers then actively sought out finance and crypto clients. One of these was Trezor, a maker of crypto wallets. A phishing email was then sent out to Trezor customers who were urged to reset their accounts using a cloned Trezor application.

Adopting a unified approach to API protection

Such attacks indicate that modern services built on API infrastructure are not adequately protected. It is only a matter of time before we begin to see API abuse ramp up. Which is why Gartner has already warned that APIs are set to become the most frequent attack vector. To counter this, we need to rethink our approach to API protection before it is too late.

To begin with, it’s necessary to discover and create an accurate runtime inventory. APIs that document when these are spun up, updated or retired. This not only provides visibility but also the means to track APIs to ensure they comply with best practices. Armed with an inventory you can begin to focus on detection and looking for tell-tale signs of an attack or Indicators of Compromise (IoCs).

Those tools we mentioned above can help here. If the attack is based on known threats or involves a brute force attack. But the chances are it will be more subtle in approach, requiring behavioral analysis. Comparing log-in success and failure rates to accounts,.For example, benchmarking these within your industry can help determine ATO attacks. Or perhaps a single username is being used but is originating from multiple IP addresses, again an IoC.