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
 

Recommended Reading:

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
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Take me to your BISO 
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-28588
PUBLISHED: 2021-05-10
An information disclosure vulnerability exists in the /proc/pid/syscall functionality of Linux Kernel 5.1 Stable and 5.4.66. More specifically, this issue has been introduced in v5.1-rc4 (commit 631b7abacd02b88f4b0795c08b54ad4fc3e7c7c0) and is still present in v5.10-rc4, so it’s l...
CVE-2021-21428
PUBLISHED: 2021-05-10
Openapi generator is a java tool which allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec. openapi-generator-online creates insecure temporary folders with File.createTempFile during the code generation proces...
CVE-2021-29022
PUBLISHED: 2021-05-10
In InvoicePlane 1.5.11, the upload feature discloses the full path of the file upload directory.
CVE-2020-27226
PUBLISHED: 2021-05-10
An exploitable SQL injection vulnerability exists in ‘quickFile.jsp’ page of OpenClinic GA 5.173.3. A specially crafted HTTP request can lead to SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerability.
CVE-2020-27229
PUBLISHED: 2021-05-10
A number of exploitable SQL injection vulnerabilities exists in ‘patientslist.do’ page of OpenClinic GA 5.173.3 application. The findPersonID parameter in ‘‘patientslist.do’ page is vulnerable to authentic...