By Prasad Kunchakarra & Eric Hein | July 31, 2019
The news of the data loss at Capital One, a major financial services firm, is very unfortunate. A hacker exfiltrated roughly 100 million credit card applications, 140,000 Social Security numbers, and 80,000 bank account numbers. The bank expects the cost of this breach to exceed $100 million in the near term. The news of this attack comes days after Equifax reached a $700 million settlement with federal regulators over the 2017 cyberattack, which exposed the personal information of 147 million people.
In previous blogs, we’ve discussed how security configuration management is essential security hygiene, and how important it is not only to design and implement effective security controls, but also to continuously scan for and detect misconfigurations. In this blog, we will examine the root cause of this latest major data breach and explain how security configuration management is once again the core issue.
Here is our analysis on what happened based on the information from the official FBI complaint. The adversary exploited a misconfiguration in a Capital One firewall. The report states:
“A firewall misconfiguration permitted commands be reached and be executed by the server, which enabled access to folders or buckets of data in Capital One’s storage space at the Cloud Computing Company.”
In this statement, “the server” refers to a Capital One server. The statement does not specify the type of misconfiguration that was exploited – we only know from the complaint that the firewall was expected to – but was not configured to – block traffic from the adversary. Misconfiguration is a loose term used in the industry to refer to any one of the following scenarios:
- Scenario 1: The configuration value is set to an incorrect value, as compared to its baseline value, sometimes also referred to as an allowable value
- Scenario 2: The baseline value (allowable value) was never established and never configured at all
- Scenario 3: The baseline value is established incorrectly, for example because it is too permissive, and implemented accordingly
- Scenario 4: The baseline value and the implemented value initially were correct, but at some point in time it was changed to an overly permissive value
- Scenario 5: Combination of the above
It should be noted that a firewall can prevent the intrusion only when the configurations are baselined and implemented correctly. NIST 800-53 – an authoritative standard in the industry – explicitly lays out several configuration management controls referred to as the NIST CONFIGURATION MANAGEMENT Control Family CM1 thru CM9. The most probable cause for this particular misconfiguration is that one or more of the CM1 thru CM9 controls were not implemented correctly.
The adversary used an account that had permissions to both list buckets/folders and copy files from buckets/folders. Here is the content from the complaint:
“Capital One determined that the first command, when executed, obtained security credentials for an account known as *****WAF-Role that, in turn, enabled access to certain of Capital One’s folders at the Cloud Computing Company
Capital One determined that the second command (the “List Buckets Command”), when executed, used the *****.WAF-Role account to list the names of folders or buckets of data in Capital One’s storage space at the Cloud Computing Company.
Capital One determined that the third command (the “Sync Command”), when executed, used the *****-WAF-Role to extract or copy data from those folders or buckets in Capital One’s storage space for which *****-WAF-Role account had the requisite permissions”
The allocation of permissions to the *****-WAF-Role account appears to be a second misconfiguration within the Capital One environment. The adversary was able to run commands using this account to view the list of folders, and then copy the data from those folders to their own S3 data storage buckets. This was only possible because the *****-WAF-Role account had been granted permission to exercise those commands – but, the complaint tells us that “the *****-WAF-Role account does not, in the ordinary course of business, invoke the List Buckets command.” Assuming common usage, the acronym “WAF” would refer to “Web Application Firewall”: it is not clear why a Web Application Firewall would have permissions to access sensitive PII and financial data. The NIST 800-53 Access Control Least Privilege principle indicates that you should only grant the minimum permissions required to perform a task. Once the adversary obtained access to the Capital One server, a misconfiguration and/or improper control implementation of Access Control permissions allowed the commands to exfiltrate the data.
In addition to the above issues, we see two other issues related to the implementation of “DETECT” controls that are meant to identify any unusual or abnormal activities. The relevant content from the report, as cited above, stated:
“…the *****-WAF-Role account does not, command in the ordinary course of business, invoke the List Buckets command”
And also:
“One of the files copied from Capital One’s folders or buckets on March 22, 2019, was a file with the name *****C000.snappy.parquet (the “Snappy Parquet File”), and this was the only time *****.WAF-Role account accessed the Snappy Parquet File between January 1, 2019 and July 20, 2019.”
Controls with a DETECT focus – if properly implemented – would have raised alarms about the *****.WAF-Role account performing the two unusual activities specified above: S3 List Bucket commands and copying of the Snappy Parquet File. There are several tools in the market that can detect unusual activity by learning what normal activities are over time. It is not clear what type of detect controls Capital One has implemented and how a misconfiguration prevented the detection of unprecedented activity.
Based on the FBI Complaint, it appears that several security misconfigurations led to this breach:
- The firewall should have been configured to block traffic, both from the adversary going in and from the data going out
- The *****WAF-Role account should not have had permission to execute the commands used to access the data, and
- The detection tools should have been configured to identify the adversary’s behavior.
It should also be noted that, although not stated, it is implied that the S3 storage was not configured to encrypt the data at rest.
Why are current methods and tools failing to catch these vulnerabilities?
The financial companies invest tens of millions of dollars to prevent data loss. A common approach is to perform periodic penetration tests to catch any vulnerabilities, including misconfigurations, and yet major data losses continue to occur. Based on years of experience architecting and securing large-scale enterprise systems, Capitis advocates the following practices to achieve effective security compliance and verification:
- Take a holistic view of the system. Most security tools are either perimeter or component focused, but adversaries will typically exploit a system of resources to achieve their goals. Start by classifying all data by sensitivity. Then look at every data flow that touches that data, from both the request direction as well as response, and determine the controls and baseline configurations needed in context for each resource participating in each data flow.
- Treat baselines as first-class citizens. Ask any IT enterprise where their baseline configurations are located and you are likely to hear they are spread across multiple databases, spreadsheets, properties and text files, etc. The baselines need to be machine readable, managed, and version controlled.
- Test security configurations continuously. It is inadequate to only conduct quarterly pen tests. Automated tests verifying each security configuration against the baselines need to be executed on every single change to the system, and ideally with every build.
- Map findings to the NIST-800-53 standard to produce readable and actionable reports It is insufficient to produce a periodic written report that will be prioritized and addressed over the next several quarters. Online dashboards are needed to present current findings with clear explanations of the failure, where to locate it, and how to remediate it. Dashboards should present dynamic NIST-800-53 reports that can be easily customized and understood by all stakeholders.
For more information about our approach see our other blog entries.
This latest data breach was the result of several security misconfigurations, but in fact it would seem that had anyone of them been addressed the attack could have been prevented. Following the steps outlined above is the only proven way to identify these vulnerabilities and thoroughly secure the system.
About Capitis
Capitis has developed a security configuration management solution driven by our experience in identifying and remediating misconfigurations in modern cloud-based architectures for large enterprises. Our custom engagements use a Defense-in-Depth strategy – we start with the system requirements, develop a system security architecture, and establish baselines for each of the components at all layers.
We not only automate the implementation of controls but also also perform independent validation and verification using C2VS – our proprietary solution that identifies misconfigurations of networks, platform components, data stores, applications, and SaaS solutions. We can compare two environments or the same environment at two different times, and identify and remediate misconfigurations. C2VS makes security configuration management an automated, achievable process. Learn more about C2VS here.
About the Authors
Prasad Kunchakarra is the CEO and Founder of Capitis Solutions Inc. He has over 15 years of experience in architecting and implementing secure platforms both for Government and commercial clients.
Eric Hein is the Chief Engineer at Capitis Solutions Inc. He has over 15 years of experience architecting enterprise applications and managing agile teams.