First American Financial 885M Account Records

Note: This series aims to analyze and simplify breach and vulnerability reports that are usually cryptic and mostly written by legal. The simplified version hopes to educate and help security and engineering leadership avoid the same mistakes.

Company: First American Financial
Report Date: May 24, 2019
Vulnerable Data: 885M customer records
The complexity of hack: Medium
Vulnerability Type: Zero-Day Exploit. A common vulnerability that can existacross multiple endpoints.

Vulnerable Data

Sample vulnerable endpoint/URLs


Exploit Rule #1: Hackers are looking for monetizable data like customer names, emails, addresses, company names, credit cards, transactions, orders, financial records, etc unless if the intention is to disrupt your business.

The flaw in the URL:

The above URL suggests that it’s a document endpoint. It may contain sensitive and financial information since the First American Financial is a financial company. This endpoint is more important to hackers than let’s say “/locations”, or “/products” endpoints which are mostly public information and exploiting or accessing this data will have very little financial gains.

Once the hackers identify endpoints with critical data, the next steps are to look for the exploits.

Exploit Techniques

  1. Insecure Direct Object Reference (IDOR)
  2. Parameter Tampering

The IDOR is a common design practice across the industry to solve some common problems, for example, Google Docs, Dropbox they all use this design to allow users to share private documents by just sharing the auto-generated non-guessable document URLs. The only time this design becomes an easy pray is if the URLs are guessable or predictable and in First American Financial’s case, it seems the product had sequential or number-based document ids. That means it was easy to guess document Ids for the entire 885 million records.

If the above URL were public or non-protected, which means it doesn’t require any authentication, then this would have allowed hackers to download all the data without leaving any digital fingerprints. Also, it requires much less work on their part, as they don’t have to sign-up for the service or steal a customer or employee credentials to perpetuate the breach.

Sequential Identifiers


Never ever use sequential numbers and weak random string generators. These are easy to predict or reverse generate.

Example of good ID design: Google’s private doc’s public URL (The highlighted ID is tough to guess or predict). Anybody with the URL can access the document.

The next step would have been to use parameter tampering technique along with a script to download all the documents. Example shell script

for i in {1..1000000000}
 wget "https://../documents?id="$i

Solution: Tactically secure and validate the most critical data endpoints first.

Attackers are consistently going after three critical pieces of information if monetary benefits drive them. e.g., customer information, customer financial data, credit cards, bank accounts, transfers, transactions, orders, etc.

Financial Repercussions:

What won’t work in thwarting these kinds of attacks

Web scanners may not detect these exploits, as they focus more on injection and on fuzzing attacks than on tailored scenarios like these.

How to protect your Apps and APIs against these attacks?