API Security Lacking for Ecosystem and Third-Party APIs?

Research by the CQ Prime Threat Research Team documents how attackers bypass API security to target third-party and partner eco-system APIs to achieve their end-goals. In the latest research report, attackers hit APIs supporting a financial services partner eco-system, ApplePay and a third-party inventory lookup.

Third-party and Eco-system APIs are not New

Long before APIs exploded into mainstream use, organizations used them to support and grow their partner ecosystem. Third-party APIs enable app-to-app connectivity for functions such as log aggregation and analysis, and integrations between consumer banking applications to enable cross-account visibility. They tie customer relationship management (CRM) and marketing automation together and provide a wide range of services across many industries. Recent research from the Postman State API Report noted that 27% of the respondents use APIs to enable partner relationships.

These trends are not surprising, given the move towards the cloud, adoption of SaaS solutions, the ubiquity of mobile devices and the flexibility that APIs provide. The growth in usage is not without its risks – APIs can be used as a malware delivery vector as seen in supply chain attacks, like SolarWinds. A more recent example can be seen in the LoNg4J variant of Log4j, where susceptible servers were found through API-connected (and trusted) third-party applications such as logging and SIEM solutions.

Third-party APIs are often brought into the organization without security teams being aware of them. One theory is that the partner team or business group managing the third party relationship is dealing with a secure API. In other cases, their implementation may have subtle flaws or a vulnerability that can be exploited. Even perfectly coded and implemented third-party APIs can be a target by threat actors hiding in plain sight. Furthermore, as certain third-party ecosystems grow, by their nature they become a valuable single point in the digital supply chain where an attacker could use a trusted API to target many victims. In an analysis of by 24 known supply chain attacks done by European Union Agency for Cybersecurity (ENISA), 62% of the attacks leveraged the implicit customer trust established by the digital connection.

Partner Ecosystem APIs Targeted by Bots

In an example from the Cequence API Protection Report, ecosystem APIs hosted by a financial services organization were targeted to simultaneously attack multiple partners using the APIs. The (mitigated) attack was a coordinated credential stuffing campaign where attackers cycled their malicious traffic through the partner API. The targeted API enabled consumer-friendly money management features including cross-account visibility, retirement planning, and net-worth tracking.

Attackers were aware of this one-to-many connection in the institutions’ supply chain and they knew that these API calls likely came from allowing trusted applications, originating from the attackers’ ultimate target – the banks themselves. Therefore, instead of attacking the bank directly, the attackers targeted the trusted API ecosystem and by proxy, the partner banks. The attack was identified and blocked based on the following behaviors:

• Known malicious infrastructure: Traffic originated from 250,000 geo-distributed residential proxy IP’s belonging to Bulletproof proxy providers in the Middle East, North Africa, Korea, Russia, the Philippines, and Indonesia.
• High session rotation: Each IP address showed high session rotation.
• No business dealings: Traffic was originating from countries where genuine user interaction is limited or non-existent.
• High login failure count: The attack showed a high rate of login failures per IP address.

The combination of known malicious infrastructure and identifiable behaviors was picked up immediately with over 50 million requests blocked within a single week.

Perfectly Coded (Apple Pay) and Secure API Under Attack

Margins in the sneaker resale markets have tightened along with a general decrease in asset prices across stocks, crypto currencies, and trading cards. While the tighter margins have weeded out some of the attackers, it has also made those remaining in the game much more dedicated to finding a competitive edge against others. To that end APIs such as Apple Pay are a perfect target for attackers, as they are designed for a frictionless purchasing experience for humans, which bots will readily abuse in attempt to steal data and disrupt a business.

Certain bot tools and communities that try to obtain the latest models of sneakers from Nike and Adidas and others, known as cook groups, aim to limit their membership to a small group of users. This ensures that they do not tip their hand on second-rate products and gives defenders an insight into their strategy. They effectively save their bullets for the most important launches. During a 3-hour launch for a highly anticipated sneaker, a large footwear and apparel retailer detected and mitigated a bot attack that was 50X normal, coming from more than 200 million unique IPs.

The attack did not end there with the next phase incorporating one of the aforementioned attack secrets. One cook group had discovered the existence of a shadow API which invoked the Apple Pay functionality on the retailers’ platform. To avoid detection for as long as possible, the attackers held onto this trick until the last minute, and as soon as the launch began, the (shadow) Apple Pay API was hit with more than 100 million malicious API requests, all from high-quality residential proxies. While the attack was successfully mitigated using shadow API specific ML models and policies, it highlights how third-party payment APIs (e.g., Apple Pay, Google Pay, PayPal, etc.), typically managed by the business groups can fall outside of the security team’s view. These APIs are coded correctly, but their shadow classification, and lack of protection makes them more susceptible to an attack.

Third-party API Hammered by High Volume Enumeration Attack

In another example of abusing the trust established by the API-host-to-user relationship, a local inventory search function used to enable Ulta Beauty customers to find and buy products nearby was hit by an attack that was 700X larger than average load.

The attack originated from high-quality residential proxy IP addresses rotating through more than 153,000 unique product and SKU combinations while scraping 61,000 ZIP codes and 33,000 products. These proxies rendered traditional web application firewall (WAF) and CDN mitigation efforts ineffective. With the attack volume increasing, the inventory search API supplier notified the Ulta Beauty security team of the sudden traffic surge, requesting help to stop the attack or to renegotiate their financial terms. The investigation mapped the attack to OWASP API4 (Lack of Resources and Rate Limiting) and API5 (Broken Function Level Authorization).

The Cequence CQ Prime Threat Research team worked closely with the Ulta Beauty security team to put policies in place to block 85.9 million total requests resulting in $80,000 saved in infrastructure and loss prevention. At the height of the attack, policies were blocking upwards of 17 million requests based on the following behaviors:

• Aggressive enumeration: The attack cycled through ZIP codes to find areas with a greater concentration of products with higher retail values impacting resources and infrastructure.
• Web-to-mobile shift: Initially, attackers targeted the web API, but quickly pivoted to the analogous mobile API which provides similar information.
• Direct-to-API: The attack was designed to target the inventory API directly, without hitting any other app or web function. Typical behavior would show the user traversing multiple APIs.
• Volumetric threshold: The attacker used enumeration to rotate through the inventory at such a volumetric rate that it represented 90% of ALL the customer traffic at the time.
• Outdated browser used: The attack was built to use very outdated or anomalous versions of Chrome.
• Single cookie generation: Each attack generated a single cookie whereas typical users would generate upwards of 40-50 cookies as they browsed the inventory.

API Security and Bot Protection are Inextricably Connected

The rapid growth in API attacks and the corresponding, dedicated API security solutions market has led to a confusion that stopping bots and API security do not belong together. The truth is APIs and bots are inextricably connected. The same characteristics that developers love about APIs – flexibility, speed, ease of use – are also loved by attackers who, as shown in above, either find coding errors to exploit, or use bots to attack trusted, perfectly coded third-party APIs, or a combination of both.

Complete API protection will be illusive unless security and development have a complete understanding of how APIs – both correctly coded or those with errors – can be attacked. This includes how a risk is discovered, the tactics, tools, and procedures attackers use to exploit it, and how attackers will react to resistance. This means not only making sure that your APIs are not susceptible to the OWASP API Security Top Ten as a starting point, but also to look at what can be defined as API10+, a category that encompasses the many ways that a perfectly coded API might be abused.

Schedule your third-party API protection demo today.