Case Files: Attack like its 1999 (Citibank) in 2012 (Signet/Jared jewelers, Molina Health)
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 to 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 an email that trackback 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 the scope of an 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. 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/
Case Files: Attack like its 1999 (Citibank) in 2012 (Signet/Jared jewelers, Molina Health) was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/case-files-attack-like-its-1999-citibank-in-2012-signet-jared-jewelers-molina-health-d81f37be9b44?source=rss----86a4f941c7da---4
