The emergence of trinity attacks on APIs
When it comes to attacks against application programming interfaces (APIs), the building blocks that provide access to many of our applications, the OWASP API Top Ten is seen as definitive – and rightly so. Compiled in 2019 based on a risk analysis conducted by an OWASP working party as well as the in the field experience of security practitioners, the list acts as a bible to developers and security professionals alike. But it very clearly delineates between each of the attack types. What we’re seeing today is that attack tools, techniques, and procedures (TTPs) no longer follow these clear-cut definitions. Instead, they’re combining multiple variants.
During the first half of 2022, we saw the emergence of the first trinity attack that used three TTPs from the OWASP list. These combined Broken User Authentication (API2) with Excessive Data Exposure (API3) and Improper Assets Management (API9). While our tracking revealed these attacks only represented a small proportion of the attacks monitored – 100 million – the rate of trinity attacks was consistent throughout the year, indicating that it must be paying off as a technique.
Triple whammy
Trinity attacks are powerful because they allow the attacker to use each of the attacks together resulting in complementary forms of compromise. A credential stuffing where attackers target authentication mechanisms to obtain user logins is often associated with Broken User Authentication (API2) whereas Excessive Data Exposure (API3) typically sees APIs expose too much personal data. Typically, a successful credential stuffing attack will use a checker functionality to check user information APIs for sensitive customer data which can be stolen immediately after login and if that checker API returns more data than necessary the attacker effectively hits the jackpot.
When it comes to Improper Assets Management (API9), a good example of this is the Shadow API – an API that has been spun up and forgotten about or neglected to the point where it’s effectively invisible: nobody knows it’s there is managing or monitoring it. Such APIs are often vulnerable because they are not on the security team’s radar. The attacker can easily discover them using known API patterns before launching a credential stuffing attack or causing the API to leak excessive amounts of data.
Spotting trinity attacks is problematic for many businesses because they simply lack visibility of the attack surface as they fail to inventory their APIs and keep this up to date. They also don’t monitor for attacks that seem to be making legitimate requests but in large volumes. If the request via the API seems valid, it won’t trigger an alert because API security systems typically don’t monitor by using behavior-based analysis.
The right solution for the job?
Many organizations have seen their API infrastructure grow organically over time and so they started 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 we’ve already touched on, there is usually a bot element to trinity attacks. They 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. This lack of understanding of the relationship between bot security and API security 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 defense. So, where should the business start?
A unified API protection strategy
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 prioritize 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 prioritize 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 behavioral 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.
A gamechanger
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 defense 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 analyzing how each API works, interacts with others and the predicting the outcome of a given transaction. 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 organizations don’t know they’re happening until it’s too late. How we carry out API security therefore must change if we are to keep pace with evolving attacks.