SBN

Part 2: The Dark Side of APIs

Ryan Barnett, Principal Security Researcher, Akamai

Elad Shuster, Senior Security Researcher, Akamai

During its research into Credential Abuse attack campaigns, Akamai’s 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.

 

Key Points:

  • 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 Background

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.

As a part of a continuous effort to protect its customers from cyber attacks, Akamai has been monitoring and analyzing malicious login requests across all of its Kona security customer base. Such attacks are known as Credential Abuse (also known as “Credential Stuffing“), and we already published several articles on this topic, such as the Web Application Defender’s Field Report: Account Takeover Campaigns Spotlight and SSHowDowN: Exploitation of IoT devices for Launching Mass-Scale Attack Campaigns.

Application Log In Method Statistics

During this research, we analyzed a day’s worth of data from our Cloud Security Intelligence (CSI) platform. Our data corpus included a total of 413,392,955 daily login requests originating from 27,882,776 IP addresses, and targeting 48,702 Internet hosts. Our research showed that at least 42% of the monitored applications were strictly using Web and mobile API Calls for performing logins. These applications were using JSON, XML, SOAP and other API-related message formats to transmit user credentials to the web applications. Only 55% of the applications were strictly using standard form-based authentication, while merely 3% were using both approaches.  

According to our research, 78% of all API-based login requests were done by mobile clients. These include native mobile apps, HTML rendering components within mobile apps, and mobile browsers. The other 22% were divided between standard desktop browsers, as a part of AJAX API calls and IoT devices, which were mostly gaming consoles.

When looking specifically at the desktop browser’s AJAX API calls, we observed that most of them were done as “Same Domain” AJAX calls; meaning that the login API call was executed by JavaScript code running inside the site and contacting an API endpoint hosted on the same domain.

The “Same-Domain” vs. “Cross-Domain” (AJAX) login API calls topic poses interesting defensive challenges. Some API protections, aimed at blocking automated attack tools, rely on injecting a JavaScript challenge or some client fingerprinting code. Injecting JavaScript challenges is mainly possible when controlling both client and server code. However, if the API is consumed by multiple 3rd parties, the API calls potentially become “Cross-Domain”, and the option to execute JavaScript code in the client is not always possible. Think about a company that provides mobile APIs which handle credit card payment transactions. This API can be consumed by a wide range of mobile apps, which the credit card API company does not control. This, in turn, means that it will be extremely hard to push some kind of JavaScript challenge, or mobile device fingerprinting solution to run on the various mobile client apps. This cross-domain login architecture limits protection options.

Credential Abuse Campaign Statistics

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 (millions of unique attack sources a day) Credential Abuse attack campaigns, 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,000,000 abuse attempts each, while API application logins saw four times as much, nearly 4,000,000 attempts per application!


In the Credential Abuse scenario, the limited capabilities that some “Anti-Automation” and “Anti-Bots” solutions rely on are likely to be the primary factors. Many solutions rely on device fingerprinting, CAPTCHA and JavaScript based challenges. While these detection methods can be extremely helpful in standard web ecosystems, they are not likely to be effective when used in mobile environments and with IoT devices.

Some vendors in this space (including Akamai) provide solutions that are capable of differentiating between humans and bots in mobile applications. Such detections require mobile application developers to include in their mobile app code a special SDK provided by the vendor, which collects and analyzes mobile device-based metrics and telemetry. This includes measurements such as global positioning data, touch screen gestures, screen resolution and orientation, and connectivity type, to name a few.

A key factor in API based attacks is the ability to easily distribute the attack workload among thousands of bot nodes. Since API based logins were meant to be consumed programmatically, it is extremely simple for an adversary to build a distributed botnet, which will divide the work among thousands of nodes. This approach is critical in Credential Abuse campaigns: any application blocks a user after three failed attempts, forcing campaigns to perform “low & slow” attacks, where each node sends about 3-5 login requests in the span of 24 hours.

This theory is strongly supported by our research. On average an API-based attack campaign will involve 19,000 unique IP addresses, while campaigns that target standard web forms login involved only 4,000 IP addresses. That’s 4.75 times more bot nodes per campaign in API-based logins.

Credential Abuse Tools

There is a multitude of automated tools for performing credential stuffing campaigns, some of which maintain a large and active community for selling pre-canned credential stuffing campaign configuration files. The most popular credential abuse tool is called SentryMBA.

 

SentryMBA Tool Screenshot

While going through these underground web sites and looking at the pre-canned configuration files that are on sale, we noticed that campaign configuration files for API logins seem to have a higher price than those that target web based forms, as shown in the Figure below.

SentryMBA Configuration Pricing on Credential Abuse Forum

The rationale for the higher price point is related to the increased velocity supported by authentication APIs coupled with the challenges of utilizing the traditional anti-automation mechanisms.

Conclusion

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:

  1. 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.

  1. 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).

  1. Provide a proper logging and visibility into security events in APIs. Visibility should be granular and provide insights on specific API endpoints and methods.

  1. 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.

  1. 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.

Acknowledgments

The research and data presented in this document was originally drafted by Ory Segal, with data collected and analyzed together with Or Katz and Aharon Fridman.

 

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Ryan Barnett. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/H2xqWz92-Nc/part-2-the-dark-side-of-apis.html