Third-Party APIs: How to Prevent Enumeration Attacks
Jason Kent, hacker-in-residence at Cequence, walks through online-retail card fraud and what to do about it.
When organizations use APIs – the next frontier in cybercrime – to engage with third parties, it’s crucial they understand the associated security exposure they’re introducing. To do so, they must think like a hacker to evaluate whether or not they are introducing a problem or a solution for their customers and their organization. From there, they can move forward by pursuing options that both create a seamless experience for customers, while at the same time protecting critical data.
Take retailers, for example. Many retailers now use third-party credit-card processing for their online transactions. In doing so, retailers reduce their cardholder footprint and payment-card industry (PCI) standards risk exposure. However, at the same time, they’re offloading this data to a potential unsecured third party.
This introduces some key questions. Did offloading to a third party provide a solution or introduce a new problem? How can retailers provide a seamless customer experience while still protecting the critical data with which they’re trusted?
The Issue: API Abuse & Enumeration Attacks
To understand the problem here, it’s easiest to walk through a real-life scenario. Consider the credit-card processing workflow for online food ordering. An individual places his or her items to be purchased in the cart and begins the checkout process, entering payment and delivery information.
Hackers (both good and bad) at this stage can push the transaction from their web browser to an intercept proxy to conduct workflow analysis. I went through this analysis recently when looking into how retailers can better mitigate these threats.
The workflow I reviewed at this stage in the intercept proxy showed payment information that had been submitted to make the purchase, as it should. However, it also showed additional new API endpoints coming online. Researching this transaction further, I noticed an HTTP-POST of credit-card details, which had been sent to a third party via an API. The response from the third-party API included the token that this particular food retailer will need to use to match this transaction and eventually get paid.
Thinking like a potential malicious actor, I took a step back here to evaluate risk. If I had the payment information, including credit-card number and expiration date, but no credit verification value (CVV), could I use an enumeration technique to pre-fetch the tokens and try them one by one?
To find the answer to this question, I stripped all cookies, tokens, trackers, etc. from the request and found I could still get back a token. I loaded the API tokenization service request into the intercept proxy and set up a series of calls, marrying all possible CVVs with the card and expiration date, allowing me to create fake tokens that would contain the correct values. From here, I set up a rotation that creates requests from 100 to 999 in sequential order. The tokenization script worked flawlessly.
If I were truly malicious, the last step here would be to feed these generated tokens into the checkout process one by one until there was a successful match.
The Solution: Understand APIs to Block Malicious Behavior
Utilizing a retailer’s APIs and third-party APIs, malicious actors can commit this type of fraud at a high speed. And, if these actions are distributed across a number of IP addresses using bulletproof proxies, it would be hard for the retailer to notice what was happening.
So, what’s the solution? The first step is to test API functionality and behavior. If it’s possible to submit multiple tokens to find the right missing values, then there should be a transaction counter in place that allows for user errors and forces a re-authentication as part of the checkout workflow after a set number of attempts. Similarly, working with a vendor to require checkout flows to come from valid orders only is also recommended. This should be closely monitored for potential abuse.
It’s crucial to continuously monitor for this malicious behavior, automatically block multiple suspicious submissions and to create a deceptive environment to confuse a potential attacker. These types of attacks happen over an extended period of time and can involve thousands of bad requests. To protect organizations, it’s critical that security teams identify potential areas of risk, learn to spot the patterns of this type of activity and seek help from outside sources with expertise in these areas. Only then will organizations have a strong security posture that helps to mitigate these risks.
Jason Kent is Hacker in Residence at Cequence Security.
Enjoy additional insights from Threatpost’s InfoSec Insider community by visiting our microsite.