On Valentine’s Day of this year, one of the largest cases of business logic abuse was detected. It saw a botnet distributed over 11million unique IP addresses use API calls to the login systems of a Fortune 500 hospitality provider based in the UK with the express purpose of carrying out fraud by using credential stuffing in an attempt to identify valid user accounts and access payment details.
Timed to coincide with one of its busiest days of the year for the business, the attackers sought to hide among the general influx of bookings but it wasn’t just the timing of the attack that allowed it to fly under the radar.
Business logic abuse
The attack used a technique known as business logic abuse which technically isn’t an attack at all, at least not in the traditional sense. This is because business logic abuse uses the functionality of the API or application against it in order to manipulate workflow processes and/or gain unauthorised access. In these attacks, the calls to the API look legitimate and syntactically correct. In reality, however, the attacker will have studied how it works and whether it can be tricked into oversharing data or if a sequence of events can be reordered to allow them to avoid paying, for instance.
Such attacks are bot-driven and see stolen user credentials, infrastructure such as proxies, compromised servers and devices, and management toolkits from the Dark Web such as SNIPR, BlackBullet or SentryMBA used to repeatedly attempt to complete sign up forms, account logins, partially complete purchases or make bookings. And because these actions appear bona fide, it’s incredibly difficult for defensive measures to detect them. Firewalls, Intrusion Prevention Systems, Web Application Firewalls (WAFs), and security gateways can’t stop them.
Hiding in plain sight
In the case of the Valentine’s Day attack, IP-based detection was ineffective because the attackers used residential proxy networks to mimic legitimate traffic. As a result, even though the attack generated over 28 million security events, these were only equivalent to three events per unique IP address and so failed to raise the alarm.
Preventing these attacks is also problematic. Often the subversion of business logic is not a top priority which means that perfectly coded APIs that are compliant with API protocols can still fall foul of these attacks.
This is because while the API functions correctly, the developer will have failed to anticipate if those functions can be accessed and altered or combined to achieve malicious ends. These forms of abuse are covered in several of the attack types documented in the OWASP API Security Top 10 which provides a useful starting point and should form the basis for building test cases for API testing.
A massive attack surface
But what about those APIs that have already gone live? There’s now a massive installed base of APIs. In fact, API calls now account for 71% of web traffic. This represents an enormous attack surface which business logic attacks are increasingly targeting. In fact, business logic abuse is thought to account for more than a quarter of attacks against APIs.
Addressing business logic issues post-production in applications has principally been done using bot mitigation tools. These use application instrumentation to collect signals from the client by injecting Javascript code into the web application but as both APIs and mobile applications do not use Javascript, typically interacting using XMl/JSON, the attacker can simply bypass the web application and go straight to these. Mobile applications can be compiled with SDK to receive the missing signal but there is no workaround for APIs. What’s more, application instrumentation inevitably adds to development and QA cycles and can even risk breaking the application.
Fingerprinting an attack
What organisations need is a solution that can see all the traffic to a given application or API and detect anomalies based on multiple behavioural-based criteria.
Using a central threat intelligence database of behavioural patterns, known malicious infrastructure and third party intelligence and machine learning to analyse API headers and payloads while local models determine behaviour and intent, it’s possible to create a behavioural fingerprint of the attack.
The unique fingerprint is traceable so that even if the attacker pivots and changes their strategy to avoid detection, they remain under observation. And crucially, as the approach is agentless, it does not require anyone to inject code into the API or application.
It was using this form of behavioural based analysis that allowed the hospitality provider to identify what was happening to its application APIs. It was able to determine that the botnet was predominantly made up of compromised routers and IoT devices and to track the high volume, low and slow and attack, determining that the source traffic was widely distributed over more than nine million IP addresses.
A machine learning-based policy was then devised to block the malicious traffic based on a single unique fingerprint without the need to upload an IP address list. IP lists have limited use because, as anticipated, the attacker quickly attempted to change the infrastructure they were using to continue the attack.
Because the fingerprint was tracked, this too could be successfully blocked.
De-risking the database
As a case example, the attack highlights the importance of not relying on IP-based solutions. In a world where organisations are going API-first, these interfaces now represent key ingress points and if compromised can have significant impacts on the business. These include the potential for increased infrastructure costs incurred from handling the higher traffic volumes resulting from bot attacks.
The loss of revenue from stolen goods and services and risk to the company’s reputation, with customers losing confidence in the ability of the business to deliver. And the cost of investing additional personnel into monitoring and responding to the security incident. But by using behavioural-based analysis, the business can mitigate these risks and using a light tough approach detect and block business logic abuse.
- Cybersecurity