Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

7/26/2019
10:00 AM
Chetan Conikee
Chetan Conikee
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

3 Takeaways from the First American Financial Breach

Data leaks from business logic flaws are not well understood and difficult to identify before they reach production environments. Here's how to find and prevent them.

On the eve of Memorial Day weekend earlier this summer, Brian Krebs of the Krebs on Security website dropped a bombshell tweet that held the security community in suspense for several hours.

Krebs doesn't use hyperbole often. The data exposure he later reported on was at First American Financial Corp., whose website was exposing highly sensitive mortgage transaction documents (including wire transfers, Social Security numbers, bank account numbers, and more) to anyone who knew the URL, without authentication. Moreover, each document's URL was serialized and therefore easy to guess.

The data leak was the result of a business logic flaw, which is a category of vulnerabilities specific to an application and business domain. A business logic flaw allows an attacker to misuse the application by circumventing the business rules of the application. These attacks are disguised as syntactically valid web requests that carry malicious intentions to violate the intended application logic.

Business logic security issues are not well understood by the industry and difficult to identify before they reach production environments. The First American Financial exposure provides several valuable lessons on how to manage business logic risk in DevOps pipelines that seem to accelerate every day. Here are three:

Takeaway No. 1: Ensure Business Logic Flow Control
Broadly speaking, the First American Financial example falls into a type of business logic vulnerability called insufficient process validation, which occurs when an application fails to enforce business process rules, enabling an attacker to circumvent the intended flow or business logic of the application.

To correct this type of vulnerability, a security team needs to ensure flow control, multistep processes that require each step to be performed in a specific order by the user. Examples of multistep processes include order/transactions lookups, wire transfers, password recovery, purchase checkout, and account sign-up. Without validating the flow control, an attacker can perform a step incorrectly or out of order to bypass access controls.

Flow control is a part of business logic, which refers to the context in which a process will execute as governed by the business requirements. Exploiting a business logic flaw generally requires knowledge of the business but not technical skill. The person who discovered the First American Financial website flaw was a real estate developer, and, in fact, many business logic flaws are exploited by non-technical customers who find them during normal use. But this is what makes flow control issues so dangerous. Because the flow is being manipulated in unintended ways, validation and security checks baked into other processes may not be taking place.

Takeaway No. 2: Understand Authentication and Authorization Flaws
Traditional code analysis tools can't uncover business logic flaws because they have no context of how the application is supposed to work. The tools don't understand what data is critical, how it should be handled, when to authenticate access requests, and what appropriate authentication measures are.

Modern omnichannel applications must account for many different authentication points, such as the browser, iOS/Android devices, APIs, and deep embedded links. Are all these paths authenticated and authorized? Although we cannot definitely determine the cause of First American Financial's breach, it likely stems from lack of authentication for embedded email links.

For example, with nonsensitive data, an email to a customer might include links to documents with only contextual authentication (e.g., clicking the link in a known valid customer's email) for ease of use. However, even when properly authenticated, referential integrity checks must still be performed to ensure that any lookup or action is associated to the specific user tenant in question. In other words, once authenticated, users should not be able to access data from others' accounts.

Lacking referential integrity checks, an insecure direct object reference (IDOR) occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as was the case with First American Financial's URL or form parameter. An attacker can manipulate direct object references by merely changing the predictable sequence in order to access other objects without authorization, unless an access control check is in place. Here are three examples:

URL parameter-based: Let's say you are an online banking customer for a (very insecure) bank. Upon login, you are taken to a URL that looks like https://onlinebanking/customer/27. Looking at the URL, you can tell that you are customer number 27. What would happen if you changed the URL to https://onlinebanking/customer/28? If you are able to see customer 28's data, then you have definitely found an instance of IDOR.

Query parameter-based: Imagine that your name is John Smith and you want to access your annual review by going to https://mycompany/reviews?employee=jsmith. You are very curious about whether your coworker, Amy Jones, has received a better review than you. You change the URL to https://mycompany/reviews?employee=ajones. Voila! You now have access to Amy's review.

Resource-based: If your website has an admin page with a URL of https://mywebsite/admin, which is normally accessed by a menu item that is only visible when the user has admin privileges, see what happens if you log in as a non-admin user and then manually change the URL to point to the admin page. If you get to the admin page, you found another instance of IDOR.

This type of IDOR exposure is increasingly common, as we saw with breaches at Fiserv, LifeLock, Panera Bread, and Kay Jewelers, all within the last several months. In fact, the Kay Jewelers breach suggests that First American Financial may not be out of the woods. When Kay Jewelers first learned of its IDOR vulnerability, it corrected it for new transactions but did not initially fix it for pre-existing transactions.

Takeaway No. 3: Characterize and Measure Logic Flaws for Decisioning
For an existing web application, finding business logic flaws is costly and cumbersome for developers because these flaws are inherently linked to the application business logic. This calls for high-level characterization and measurement for decisioning.

For a web application under development, it's important for developers to seek guidance during the design of the authentication procedures. The goal is to enforce the security of the design of the authentication procedure by considering human factors and design errors. For example, to discover business logic flaws associated with authentication and authorization, we would need to correlate usability issues (lost phone, security unawareness) with human behaviors (active session, autocomplete forms).

On this basis, we can provide a set of security and usability requirements developers and architects can use during the early design of the end-user authentication procedure to prevent business logic flaws.

Related Content:

 

Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Chetan is a serial entrepreneur with over 20+ years of experience in authoring and architecting mission critical software. His expertise includes building web-scale distributed infrastructure, personalization algorithms, complex event processing, fraud detection, and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
tdsan
50%
50%
tdsan,
User Rank: Ninja
7/26/2019 | 8:33:17 PM
Similar comments in previous articles but oh so true

For a web application under development, it's important for developers to seek guidance during the design of the authentication procedures. The goal is to enforce the security of the design of the authentication procedure by considering human factors and design errors. For example, to discover business logic flaws associated with authentication and authorization, we would need to correlate usability issues (lost phone, security unawareness) with human behaviors (active session, autocomplete forms).

On this basis, we can provide a set of security and usability requirements developers and architects can use during the early design of the end-user authentication procedure to prevent business logic flaws.


I remember reading an article from DR that talked about combining "IT Security" with "DevOps" to create a "SecDev" or "DevSec" group. I think in this particular case, this is a good use case where the security teams can get involved in the security design aspects and make suggestions as to how to utilize existing tools from operations:
  • SAML
  • Password Hashing
  • SSO using same username and password (passthrough)
  • Read-only AD/LDAP replicas
  • Single or Multi-tenant forest creation
  • Key or Token exchange
  • MFA/2FA

We are seeing more of this, Louisiana is under a state of emergency (schools are being plummeted by various cyber actors), by working with various groups from different regions of the US, we can start coming up with better ways of addressing this cyber issue. A number of companies are doing a good job to help, it just depends on your budget, but if you have good people on staff, it may not have to cost the organization anything but labor cost.

Just a thought.

T
For Cybersecurity to Be Proactive, Terrains Must Be Mapped
Craig Harber, Chief Technology Officer at Fidelis Cybersecurity,  10/8/2019
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
USB Drive Security Still Lags
Dark Reading Staff 10/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17545
PUBLISHED: 2019-10-14
GDAL through 3.0.1 has a poolDestroy double free in OGRExpatRealloc in ogr/ogr_expat.cpp when the 10MB threshold is exceeded.
CVE-2019-17546
PUBLISHED: 2019-10-14
tif_getimage.c in LibTIFF through 4.0.10, as used in GDAL through 3.0.1 and other products, has an integer overflow that potentially causes a heap-based buffer overflow via a crafted RGBA image, related to a "Negative-size-param" condition.
CVE-2019-17547
PUBLISHED: 2019-10-14
In ImageMagick before 7.0.8-62, TraceBezier in MagickCore/draw.c has a use-after-free.
CVE-2019-17501
PUBLISHED: 2019-10-14
Centreon 19.04 allows attackers to execute arbitrary OS commands via the Command Line field of main.php?p=60807&type=4 (aka the Configuration > Commands > Discovery screen).
CVE-2019-17539
PUBLISHED: 2019-10-14
In FFmpeg before 4.2, avcodec_open2 in libavcodec/utils.c allows a NULL pointer dereference and possibly unspecified other impact when there is no valid close function pointer.