How APIs are being Targeted with Trinity Attacks
By Andy Mills, VP EMEA, Cequence Security
Application Programming Interfaces (APIs) are growing twice as fast as traditional web traffic but their popularity and their exploitability also makes them a prime target. Out of just over 20 billion transactions observed during the first half of 2022, 16.6 billion were found to be malicious, according to the CQI API Protection Report 2022, equivalent to around 83 percent. But the ways in which these interfaces are being abused is evolving.
The primary ways in which APIs are attacked or abused have been documented in the OWASP API Top Ten. The report found that two types of attack led the pack: the exploitation of Improper Assets Management (API9 in the OWASP list) and Insufficient Logging and Monitoring (API10). The former was favoured by those deploying shopping bots while the latter was used to carry out content scraping. But the report also unearthed a previously unobserved pattern. Malicious attackers were now combining the tactics, techniques and procedures (TTPs) detailed in the OWASP Top Ten in order to abuse perfectly coded APIs.
Figure 1: Mapping of OWASP API Top 10 attack types and bot attacks 1H 2022
Contrary to popular belief, even if the API is coded perfectly correctly, adheres to the API specification it is designed against, is properly inventoried and has been tested to ensure it is not susceptible to any of the OWASP Top Ten API Threats, it can still be probed and compromised. This is because, while shift left efforts to test APIs pre-production are beneficial, no measures will stop a persistent automated attack. If the assets being protected by that API are attractive enough, attackers will persist and will compromise it usually by using its own functionality against it in an attack known as business logic abuse.
Perfectly coded and inventoried APIs do, of course, take much more effort to compromise. They need to be studied to see how they work, how they interact with one another and what the expected outcome of any API call should be to avoid triggering an alert. Learning and exploiting an API and using its own functionality against it is often referred to as Business Logic Abuse and it’s this that is now on the up as API development and security during production improve.
Trinity Attacks and API10+
One such form of abuse is the trinity attack. This sees the combined use of Broken User Authentication (API2), Excessive Data Exposure (API3) and Improper Assets Management (API9) from the former OWASP Top Ten to create a chimera of an attack. Trinity attacks are a form of combined or API10+ attack that are still relatively small in number, with 100 million registered by the report, but the rate at which they are occurring is ramping up, as can be seen from the graph. It’s a worrying trend, as it suggests more attackers are catching on to using this approach.
Figure 2: Growth in the number of API10+ attacks during 1H 2022
Trinity attacks can be devastating. So how might they manifest? Broken User Authentication can result in credential stuffing, whereby the attacker targets the authentication mechanisms that protect user integrity. A successful credential stuffing campaign will often utilise a checker functionality that checks user confirmation APIs for sensitive customer data which can be stolen immediately after login. Excessive Data Exposure results when the checker APIs return more data than necessary, giving the developers a false sense of security because the user confirmation happens after authentication.
The combination of APIs exposing too much (personal) data and those that are vulnerable to credential stuffing therefore makes this deployment a ripe target for API abuse. And finally, the attacker can further the attack through Improper Assets Management. This typically resulst in Shadow APIs ie APIs that fly under the radar of the security team which are to all intents and purposes invisible. These shadow APIs allow the attacker to then enumerate the victim’s infrastructure using the known API patterns to discover and establish other APIs that are unprotected and vulnerable to the credential stuffing and exposed excessive data vulnerabilities we’ve just covered.
An eCommerce Attack
Such attacks are highly organised and well executed. Take, for instance, the case of an ecommerce platform that was targeted last year in a bid to automatically purchase items with stolen credit card data.
Reconnaissance was conducted by mapping the entire site using commonly known vulnerability scanning tools from a single IP address. This included some basic behaviours like SQL injection, command injection (OWASP API8), directory traversal, and searching for exposed sensitive files. When basic recon did not yield any low-hanging fruit, the attacker moved on to mapping the API ecosystem.
The attackers then began using existing attack configurations from well-known bot automation tools like OpenBullet to perform basic credential stuffing and account creation attacks. During a 24-hour period, they initiated more than 1.5 million requests from 130,000 IP addresses, which were effectively mitigated through the use of over 1,000 behavioural fingerprints.
However, the attack continued even as it was mitigated, leading to the discovery that this was ultimately a feint by the attackers and was not the end goal. During the following attacks, the reconnaissance behaviour returned, this time focusing on account creation and checkout APIs.
The attackers discovered that upon creation of a brand-new account, and before email verification had taken place, the checkout APIs (particularly those to add a payment method) could be invoked by the user. This is an example of Broken Function Level Authorisation, because this API functionality was intended to be used only by users who were both authenticated and authorised.
The focus of the attack then shifted to account creation, and the attackers immediately began stuffing new (fake) accounts with stolen payment information, targeting retail products for purchase. They did not care that the credential stuffing campaign was failing because they were watching which of the new accounts they had created would be able to successfully access payment APIs, iterating through the stolen credit card details until they found one eligible to continue with the purchase.
Mitigating Multi-Faceted Attacks
As can be seen from this example, spotting trinity attacks is difficult without behaviour-based monitoring and analysis. If the business is not looking for attacks that seem to be making legitimate requests but in large volumes, this activity won’t be seen as a red flag.
Many organisations have seen their API infrastructure grow organically over time and so they start out with, and continue to rely upon, security solutions designed to monitor and detect web applications such as Web Application Firewalls (WAFs). These solutions use a signature-based alert mechanism and are therefore unable to detect and block let alone defend against trinity attacks. Others may rely on their bot tools but these use Javascript to determine and block an attack. RESTful APIs use JSON or XML, not Javascript, which means they cannot be monitored by bot software.
As there is usually a bot element to trinity attacks, it also makes sense to join up API and bot monitoring security. Such attacks enumerate at speed across the infrastructure so are often automated by bots. But given that WAFs are blind to high volume attacks making legitimate requests from the API and that the bot solutions cannot read API payloads, these attacks simply bypass them both undetected and unchallenged. Unfortunately, this lack of understanding of the relationship between bots and APIs continues to persist with the two often treated as separate problems by security vendors.
It’s an artificial distinction that plays right into the hands of the attackers which is why it makes more sense to look at API protection as an issue that requires bot detection and mitigation as well as management of the API’s security through discovery, detection and defence. So where should the business start?
Discover, Detect and Defend
Initially, it’s imperative that you get on top of your APIs by determining how many you have, what they do, and that you make provisions to be able to document any changes on a continuous basis using a runtime inventory. Surprisingly, those responsible for their API ecosystem often rarely know how many they have and routinely underestimate the numbers, as a result of which it can be easy to get overwhelmed when this discovery is performed. However, as the risks posed by APIs will differ, it’s relatively simply to prioritise them.
Some APIs will be purely informational while others may expose sensitive data such as personally identifiable information or credit card data. Some may not be properly authenticated, while others may be prone to business logic attacks like account takeovers or scraping. Risk assessing the APIs will therefore allow the business to prioritise the inventory but keep in mind that the risk posed by an API can change over time. Attackers can and will continue to probe APIs for weaknesses, and a problem with configuration or a connection to a less secure system could introduce new vulnerabilities.
With the inventory in place, you can consider what runtime protection to put in place. This should scan for business logic abuses, data leaks and other common attack types as covered by the OWASP Top Ten but it should also be able to cope with changes in the attack landscape by drawing upon machine learning technology to carry out threat based and behavioural analysis. This can determine the intent of the transactions (whether performed by bots or individuals) and continually track sophisticated API attacks as they retool to evade detection. Action can then be taken to block or deflect the attack, from basic block and rate limiting to HTTP header insertion and deception.
The API Lifecycle
It’s only by looking at the entire API lifecycle that the business can hope to protect its APIs from both current and emerging forms of attack. From security testing at development, through to managing the API as part of an ecosystem that is tracked and managed using a runtime inventory, to active defence that looks for attack patterns, there needs to be a cradle to grave approach.
The trinity attack indicates that attackers are getting much more adept at analysing how each API works, interacts and performs. It’s a significant upping of the ante in the API security stakes and, at the moment, many of these attacks are going undetected and unchallenged simply because organisations don’t know they’re happening until it’s too late.
To stop them, we need to take a new approach to how we secure APIs and start using the same joined up thinking that the attackers have already demonstrated. API attacks are no longer separate and distinct, they’re becoming elements of much more ambitious persistent campaigns and so any approach to security needs to adopt the same tactics, by using a wide angle lens to capture every element of the attack.
About the Author
Andy Mills is VP of EMEA for Cequence Security and assists organisations with their API protection strategies, from discovery to detection and mitigation. He’s a passionate advocate of the need to secure the entire API lifecycle using a unified approach.
Prior to joining Cequence, he held roles as CRO for a major tax technology provider and was part of the original worldwide team of pioneers that brought Palo Alto Networks, the industry’s leading Next-Generation Firewall, to market.
Andy holds a Bachelor of Science Degree in Electrical and Electronic Engineering from Leeds Beckett University. Andy can be reached online at [email protected] and at our company website https://www.cequence.ai.
