3 Takeaways from the First American Financial Breach

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.