The Hong Kong Monetary Authority (HKMA) announced the launch of Open API in July to provide convenient access by the public, preparing Hong Kong to move into a new era of smart banking and ensuring the competitiveness of the banking sector. In light of the HKMA’s initiative, let us also be aware of the potential cybersecurity threats brought by APIs as well.
APIs enable software and system developers to integrate with other systems based on a defined set of communication methods. APIs serve as software building blocks and allow for software reuse – essentially allowing fast development of new systems based on existing capabilities. Within a few years, all major sites and Internet-based companies started exposing APIs. Some of the best known companies whose APIs helped their business model flourish are Facebook, Twitter, Google and Amazon.
In order to learn about the adoption and use of APIs across the Internet, we decided to use our Cloud Security Intelligence (CSI) data analysis engine. From observations of 144.7 billion HTTP transactions (going to the origin web application) on a given day, the system identified 36.6 billion API transactions – that is one quarter of total web transactions that reached origin web applications. We speculate that the numbers may be higher than 25% – however, we used a conservative detection approach to identify APIs.
A closer look at these API transactions revealed that 38% of the API calls were performed by mobile clients. When comparing this against a previous dataset (which showed 65% of API traffic from mobile clients), this supports our assumption that mobile applications are among the biggest drivers for API development and usage.
The distribution of APIs across industry verticals shows that ‘High Technology’ companies are at the top of all API calls, ‘Other Digital Media’ is next, followed by ‘Gaming and Retail’.
APIs are simple, open and yet extremely powerful. Traditional web applications aren’t going anywhere as humans will always need them – however, APIs will continue to be developed to solve countless needs. Hence, we should take deeper dives into the threats to APIs, such as credential abuse campaigns.
During its research into credential abuse attack campaigns, our threat research team conducted an analysis of web logins to gain insights into how widespread the adoption of API-based logins is and whether or not this trend also affects attackers and attack campaigns. It will come as no surprise that API-based logins are highly targeted by credential abuse attackers for a variety of reason.
- 30% of all API authentication attempts are fraudulent
- Credential abuse campaigns launched at API authentication endpoints process four times as many user credentials vs. normal form-based authentication applications
- Credential abuse campaigns launched at API authentication endpoints may employ 4.75% more botnet clients.
Credential abuse
Logins are one of the most prominent places where applications have migrated from standard web requests to API calls. Almost all web and mobile applications maintain user state by requesting users log in to the application. Historically, login requests were standard HTTP POST requests, submitted when a user clicks the “Log In” button in a form within an HTML page. Increasing usages of AJAX, JavaScript frameworks (e.g. jQuery and Angular) and mobile application frameworks have shifted login requests towards API calls.
Out of the total logins that were analyzed, a whopping 30% were identified as fraudulent logins, submitted as a part of massive credential abuse campaigns. This data is simply mind boggling: almost one out of every three login attempts were identified as being fraudulent!
When it comes to massive credential abuse attack campaigns (millions of unique attack sources a day), our data reveals that 88% of the attackers targeted API calls at some point during their campaign. In contrast, only 22% of the attackers abused only standard web forms authentication. Naturally, some attackers target both, depending on the application they are attacking at the moment.
One of the most obvious differences between API-based credential abuse campaigns and those targeting web forms was the average number of attempted accounts tested per application in each campaign; standard web forms received 1 million abuse attempts each, while API application logins saw four times as much, nearly 4 million attempts per application!
Authentication APIs are a ripe target for credential abuse attackers. Organizations that are looking to defend against such attacks across their entire API portfolio should make sure that whatever solution they choose, it handles the following areas properly:
- Ability to parse and understand Web and mobile API call messages, and to apply proper protections and detection techniques on them, in the most granular way possible. This includes XML based messages, JSON messages, and RESTful services.
- Ability to differentiate between automatic and malicious attacks, such as those performed by bots, in an API environment, which is not necessarily consumed by web browsers (e.g. native mobile apps, gaming consoles and other IoT devices).
- Provide a proper logging and visibility into security events in APIs. Visibility should be granular and provide insights on specific API endpoints and methods.
- Provide clean and simple API security management solution, which allows the organization to assign different security policies to different API endpoints, apply granular application layer protections as well as rate limiting, and provide visibility into all of the APIs that are exposed to external users.
- Provide a feed of client reputation and intelligence, which includes visibility to malicious actors specifically performing credential abuse campaigns over API calls such as those used by mobile, web and IoT applications. Such a feed can serve as a safety net or a final line of defense in situations where previous protections provide partial coverage.
Written by Ryan Barnett (left), principal security researcher at Akamai, and Elad Shuster, senior security researcher at Akamai
Be the first to comment