Series — Discovering Business Logic Flaws
Act 3 — The dynamic duo Andrew and Allen exploit Nordstorm with their FatWallet
Fast forward 2012, from my last post that enacted Citibank’s exploit from 1999.
The actors in this story are Andrew and Allen Chiu and their plot to defraud Nordstorm via a channel partner FatWallet.com.
FatWallet Inc., used to be a membership-based shopping community website that used to promote various online retailers by providing coupons and cash back incentives for purchases. Nordstorm happened to be one of their retailer partners and the Chiu brothers happened to be members of FatWallet.com.
In 2010, the criminal duo discovered a business logic flaw in Nordstorm’s e-commerce ordering system. They exploited this flaw by placing several orders that were never fulfilled (Neither were the associated merchandize shipped nor their credit card charged).
However Nordstorm’s fulfillment system continued to compensate FatWallet for each of these orders and the criminal duo received cashback credit from FatWallet.
Between January 2010 and October 2011, this dynamic duo place $23 million worth of orders on Nordstorm leading to Nordstorm paying $1.4 million worth of rebates and commissions, with more than $650,000 in fraudulent cashback payments going directly to both of them.
What are these conditions that led for this flaw to be exploited?
- An order should never be considered closed until fulfilled (shipped and delivered).
- A validation criteria should establish correlation between orderId and transactionId (received from payments processor) and dollar amount of transactionId should match the item price.
- Cashback should only be remitted after the item return period elapses.
- Cashback workflow should not be triggered as a part of the realtime transactional workflow.
Ironically, this is one of those types of flaws that’s all but impossible for an automated web application vulnerability scanner to find.
How can such flaws be identified and thereafter avoided?
Is there a human assisted expert system available to check your specific application belonging to a specific business domain for design flaws that can be exploited?
Yes, such a system does exist. At the series finale I will reveal how this expert system can be utilized to identify such flaws.
Until then, onto my next installment in this series.
This post is one of a seven part series on finding business logic vulnerabilities in your code. To learn more, please read the full series here:
Act 1 — What is a business logic flaw?
Act 2 — Attack like its 1999
Act 3 — The dynamic duo Andrew and Allen exploit Nordstorm with their FatWallet
Act 4 — Outbidding
Act 5 — Pusher in Coinbase cookie
Act 6 — Your data has been breached, now what?
Act 7 — One (Bug)Mac please!