Series — Discovering Business Logic Flaws
Act 2— Attack like its 1999
In the prior installment I discussed and described the definition of a business logic flaw.
Let us now turn back time to 1999 and recount events leading to Citibank attack on approximately 360,000 of its customers’ financial data
The company said that hackers who breached Citi Account Online on May 10 had acquired the personal information of about 1 percent of its 21 million North America customers, or approximately 210,000 credit card holders
~ Wired
They simply logged on to the part of the group’s site reserved for credit card customers — and substituted their account numbers which appeared in the browser’s address bar with other numbers.
This sounds like a good old parameter tampering attack (aka forceful browsing). Even worse than that, the parameter in question sounds like it was a directly referenced account number (with predictable sequence) and that it was included in the URL of the request rather than securely placed within the body in a POST request.
This attack might sound complicated to the masses who may not be familiar with application security. It’s one of those “attacks” that anyone with basic knowledge of a browser is capable of successfully pulling off.
I guess I’m not surprised since I still run across applications in 2018 that are still vulnerable in a 1999 sort of way.
Molina Healthcare exploit : https://krebsonsecurity.com/2017/05/molinahealthcare-com-exposed-patient-records/
Signet/Jared jewelers exploit :
https://blog.shiftleft.io/deconstructing-data-leak-incident-of-signet-jewelers-parent-company-of-kay-and-jared-jewelers-44a8d6b881fb
What are these conditions that led for this flaw to be exploited?
- Lack of authorization checks for every user request. Web portals have several channels of communication like the browser, mobile apps, embedded links in email that track back to the portal. Are all these paths authenticated and authorized?
- Even if authorized, are referential integrity checks performed to ensure that the account number belongs to the user.
- Using direct object references: Account numbers are retrieved from databases and they obviously have a primary key id that uniquely identifies each of them. Rather than directly passing the account number into the user session object, one can create a transient and random account-id and cache map to the real account-id in scope of active session.
- Don’t send sensitive information in the URL of a request: When in doubt, send parameters within the body of a POST request. This won’t protect you from this type of attack but it makes the flaw slightly less obvious.
Ironically, this is one of those types of flaws that’s all but impossible for an automated web application vulnerability scanner to find but incredibly easy for even a savvy 10-year-old to discover.
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!
