Apple Pay is under attack

Digital wallets and payment mechanisms such as Apple Pay, Google Pay and PayPal have enjoyed phenomenal success due to their frictionless purchasing experience. According to Juniper Research, 3.4 billion of us chose to use the technology this year and that’s set to rise to 5.2 billion by 2026 as we embrace the cashless society.

When it comes to Apple Pay there are two APIs available that businesses can choose to implement on their websites: Apple Pay JS API and/or the W3C Payment Request API. It works via a process known as tokenisation so that when the consumer makes a purchase, a number is generated for their device and a unique transaction code. The user’s card is only used when Apple Pay is set-up and so it’s not stored.

The general perception is that digital wallets are completely secure but in reality they are still vulnerable to attack. This is because they’re based on APIs which bots can readily abuse. There’s already evidence of this in the world of online retail where scalpers have sought to subvert Apple Pay.

Sophisticated scalpers

During a recent promotion for an item that was in high demand, a large footwear and apparel retailer detected and mitigated a bot attack that saw traffic escalate to fifty times higher than normal, with 200 million API requests coming from roughly 6 million unique IP addresses. The assault did not end there with the following phase incorporating a next level attack. But this initial attack was in fact subterfuge.

Certain bot tools and 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.

In this instance, a cook group had discovered the existence of a shadow API which had access to the Apple Pay functionality on the retailers’ platform. A shadow API is one that has been spun up onto the network but has then been neglected and forgotten about, rendering it to all intents and purposes invisible to the business. Because it’s not on the API inventory, it won’t be monitored on a continuous basis and any suspicious activity will be missed.

The attackers would have detected the shadow Apple API while probing the network and after some reconnaissance would have recognised its value. They bided their time to wait for the product launch and were then able to seize the initiative. 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. 

A growing threat

The above incident is a real example of how a well-protected business can find itself subjected to a massive highly organised, multi-faceted bot attack. While the assault was successfully mitigated using shadow API specific machine learning (ML) models and policies, it highlights how these third-party payment APIs, which are typically managed by isolated groups within the business, can fall outside of the security team’s view.

One should stress that there’s no question here over the integrity of Apple Pay’s APIs. These are coded correctly but because in this case the API had been allowed to exist on the retailer’s network unmanaged, in the shadows, it had not been afforded the necessary level of protection. Unwatched APIs can be discovered and analysed by attackers allowing them to determine how the API works, how it interacts with other APIs, and the expected outcome.

Attacks on shadow APIs are growing. The API Protection Report found 31 percent equivalent to five billion out of 16.7 billion malicious transactions targeted unknown, unmanaged or unprotected APIs, making it the dominant attack method in 2022.

Shadow APIs are typically discovered through their interaction with production data. By analysing a production API which may be well protected, the attacker can simply fuzz or modify the values, enumerating through other API endpoints on different versions, under different hostnames, or simply accepting random characters at the end of the identifier. For attackers who are employing automation to monetise their attacks (by using shopping bots or credential stuffing) this strategy is akin to reading the manual on how an API works.

Upping API security

So how can businesses protect these payment channels? To start with, it’s vital to eliminate the problem of shadow APIs by using a runtime inventory solution to discover and catalogue all APIs and their connections. Organisations typically underestimate just how many APIs they have and it’s not unusual for a substantial number to be unaccounted for.

However, even if all APIs are discovered and known, attackers can still leverage seemingly legitimate transactions to steal data or commit fraud. Traditionally, WAFs (Web Application Firewalls) or API gateways have been used to protect APIs but these aren’t able to detect the subtle abuse that precedes these attacks. Being able to detect this suspicious activity is key which is why the API inventory needs to continuously scan for threats, business logic abuse and malicious activity using behaviour-based analysis.

We also need to stop looking at API security and bot security as two separate things. The two are inextricably connected, with bots frequently used to attack perfectly coded APIs. Dealing with both issues together means that the business can monitor attack traffic, analyse it, respond, and adjust its defence based on the results. The attack can then be countered using real-time blocking and even deception techniques to frustrate the attacker. Even the most resolute bad actors experience fatigue and will abort an attack that proves too difficult.

It’s only by adopting a comprehensive API strategy that covers all three of these areas – discovery, detection and defence – that the problem of shadow APIs and attacks against well-coded APIs can be thwarted. Without such measures, our move towards a cashless society may well leave businesses more exposed to attack.