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
- The user creates an account — system verifies if userId is unique and creates an account.
- User logs in the account using the account credentials — active session on the portal is established
- User view page displaying an item of interest along with all active bidders associated with the item
- User participates in an existing auction by placing a bid — system calculates the number of active bidders and add a new bid to the scheduled time
- User wins or loses a bid — receives a confirmation to enter credit card information
- User is asked to enter credit card information — system validates credit card, debits amount and item is shipped
- User logs out — the active session is deleted
One of the several ways to abuse this workflow is depicted below
- Hacker creates an account and logs in
- Hacker views page displaying item of interest
- Hacker enters into an auction by bidding for the lowest price
- Hacker collects usernames of bidders displayed on the page
- Hacker launches brute force attack on all usernames via the login screen
- Hacker wins the bid at the lowest price
What are these conditions that led to this flaw to be exploited?
- Bidder usernames were displayed in cleartext on the item page — sensitive information disclosure
- A brute force led to account lockout — even legitimate users are not allowed to log in for a period of time
- Account lockout terminated any active session
- Session termination deletes current user data
Suggested fixes and checks to mitigate this flaw
- Apply CAPTCHA instead of rate-limited account lockout
- Disable active session termination
- Do not display active bidders on the 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. ShiftLeft’s Ocular is a platform built over the foundational Code Property Graph that is uniquely positioned to deliver a specification model to query for vulnerable conditions, business logic flaws and insider attacks that might exist in your application’s codebase.
To request a free trial and demo, please signup at https://www.shiftleft.io/ocular/