Discovering Business Logic Flaws: Act 2

Mar 19, 2019 9:50:01 AM By Chetan Conikee
Act 2 - Attack like it's 1000

Editor's note: This is the 2nd article in a six-part series by Chetan Conikee. We will publish the series in it's entirety within the next few days. To be notified when a new article in the series is published, "Join" the community in the bottom right hand corner of this page. By joining our community, you'll receive a free download of the book "Epic Failures in DevSecOps", including Chetan's chapter, "Strategic Asymmetry – Leveling the Playing Field between Defenders and Adversaries".

Act 2: Attack like it's 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 :

Signet/Jared jewelers exploit :

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

  1. 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?

  2. Even if authorized, are referential integrity checks performed to ensure that the account number belongs to the user.

  3. 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.

  4. 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.