Tales from the Front Lines: How Third-Party APIs Simplify Enumeration Attacks

As a mechanism to offload PCI risks, many retailers are now using third-party credit card processing for their online transactions. The retailer’s benefit is they are no longer handling the credit card data, thereby reducing the cardholder footprint (and PCI exposure). The potential drawback to this approach is that now a third-party controls that data.

While researching this topic for a customer recently, I looked at the credit card processing workflow for online food ordering. After placing my desired items in a “cart,” I began the checkout process, pushing the transaction from my web browser to an intercept proxy. There I was able to do some workflow analysis.

The workflow displayed in the intercept proxy capture showed the credit card details had been submitted to the order as they should, but it also showed some new API endpoints coming online. Digging into the transactions, I saw an HTTP-POST of my credit card details (highlighted in grey below) had been sent to a third-party via an API.

Image 1:third-party API transaction POST

The response back from the third-party API included the token that my food retailer will use to match up this transaction and eventually get paid.

Image 2: API token response

Putting on my security hat, I wondered, If I were an attacker and I had the card number and the expiration date but didn’t have the “CVV” or Card Verification Value (the three-digit number 100 in image 1 above), as many credit card dumps contain, could I use an enumeration technique to pre-fetch the tokens and try them one at a time?

Surely there is some sort of access or authorization that is needed to engage the tokenization API. Surely there is something gating requests to the tokenizer script. Alas, no.

I stripped all cookies, tokens, trackers, etc. from the request and could still get back a token. See OWASP API Top Ten API1 Broken Object Level Authorization and API2 Broken Authentication. This is a wide-open service that also suffers from OWASP API4 “Lack of Resources and Rate Limiting.”

To look at what is happening, I like to use an “intercept proxy” called BURP Suite Pro. It has many testing tools and often makes automation of simple tests extremely easy. To test my idea, I loaded the API tokenization service request into BURP Suites Intruder and set up a series of calls and married all possible CVVs with the card and expiry, resulting in the creation of (fictitious) tokens that would contain the correct values, shown in the right side of image 3. I set up a rotation in Intruder and fired off 900 requests from 100 to 999 in sequential order. The tokenization script worked flawlessly, as seen in my attacker output.

Image 3: Token generation using enumeration techniques

If I were an attacker, the last step is to feed these newly generated tokens into the checkout process one at a time. Utilizing the retailer APIs and third-party APIs it is possible to commit this type of fraud at high speed, and if the load is distributed across many IP addresses using Bulletproof Proxies, it would be pretty unnoticeable to the retailer.

When enterprises use APIs to engage with third-party services to create a seamless experience for customers, it’s critical to fully understand the security exposure, answering the question of whether or not we are introducing a problem or a solution. In this case, it is possible to pre-enumerate the checkout process off-site and attempt fraud against the retailer’s customers.

So how would someone prevent this? The first thing I would suggest is to test the API functionality and behavior. Is it possible to submit token after token in order to find the right CVV value? If so, there should be some kind of transaction counter that allows for user mistakes but then forces a re-authentication as part of the checkout workflow after a certain number of attempts. Similarly, working with the vendor to require checkout flows to come from valid orders only is also reccomended. This should be tightly monitored for abuse.

Cequence can monitor for this behavior and automatically block submissions over specific thresholds or create a deceptive environment that will confuse a would-be attacker. These kinds of attacks happen over a very long period of time and can involve thousands of bad requests making it difficult to see the patterns without Machine Learning models to match up fraud attempts.