Series — Discovering Business Logic Flaws

Act 4— Outbidding

In my previous post we witnessed a vendor partnership flaw that was exploited. Let us now situate ourselves in an online auction event.

Online auctions offer buyers and sellers of a wide variety of goods an enormous platform for trade. Just like local auctions, there are sellers and bidders and winners and losers. Winners are expected to pay for what they bid on at the conclusion of the auction.

At online auctions, you will be required to register before you can buy or sell an item(s). Registration is required to track items you bid on or sell, keep up with the bids, determine the winning bids and build a database on seller and bidder feedback.

A normal workflow initiated by a consumer on such a platform would entail

1. User creates an account — system verifies if userId is unique and creates an account.
2. User logs in the account using the account credentials — active session on portal is established
3. User view page displaying a item of interest along with all active bidders associated with the item
4. User participates in an existing auction by placing bid — system calculates number of active bidders and add new bid to scheduled time
5. User wins or loses a bid — receives confirmation to enter credit card information
6. User is asked to enter credit card information — system validates credit card, debits amount and item is shipped
7. User logs out — active session is deleted

One of the several ways to abuse this workflow is depicted below

1. Hacker creates an account and logs in
2. Hacker views page displaying item of interest
3. Hacker enters into an auction by bidding for lowest price
4. Hacker collects usernames of bidders displayed on page
5. Hacker launches brute force attack on all usernames via login screen
6. Hacker wins bid at lowest price

What are these conditions that led for this flaw to be exploited?

1. Bidder usernames were displayed in cleartext on item page — sensitive information disclosure
2. Brute force led to account lockout — even legitimate users are not allowed to log in for a period of time
3. Account lockout terminated any active session
4. Session termination deletes current user data

Suggested fixes and checks to mitigate this flaw

1. Apply CAPTCHA instead of rate limited account lockout
2. Disable active session termination
3. Do not display active bidders on item page — use redaction or pseudonyms

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!