Lessons learned: The Capital One breach

The Capital One breach was accomplished by a former AWS employee who took advantage of a misconfigured firewall used by Capital One to protect their AWS deployment. This firewall was granted excessive permissions on the AWS instance (ability to read every stored file) and was vulnerable to a server-side request forgery attack. The attacker leveraged these issues to steal the data of 100 million American and 6 million Canadian customers of Capital One, including:

• Names
• Addresses (with postal codes)
• Phone numbers
• Email addresses
• Birth dates
• 140,000 Social Security Numbers
• 1 million Canadian Social Insurance numbers
• 80,000 linked bank accounts’ information
• Status data (credit scores and limits, balances, payment history and contact information)
• Transaction fragments from 23 days between 2016 and 2018

The attack was discovered due to the fact that the hacker bragged about her exploits against Capital One and other organizations on GitHub. An ethical hacker discovered and reported the posts, leading to rapid remediation efforts by Capital One.

Should you pay the ransom?

Download The Ransomware Paper for real-world ransomware examples, mistakes and lessons learned.

Download Now

Lessons learned

The Capital One hack provides multiple takeaways for other organizations. In general, while Capital One made a few important mistakes that made the attack possible, how they handled the remediation process can be taken as an example to other breached organizations.

Proper configuration of security appliances

One of the greatest ironies of the Capital One breach is that it was enabled by a security appliance deployed by the company. The breach was made possible because a Web Application Firewall (WAF) was deployed to protect the organization’s cloud deployment but was not properly configured. This breach should serve as a warning of the security implications of failing to ensure that all devices within an organization’s network are both deployed and configured properly.

Principle of least privilege

One of the main configuration issues of the WAF used by Capital One to protect their AWS deployment is the failure to properly implement least privilege. Least privilege states that an application or user should be limited to the level of permissions necessary to perform their job role.

In the case of the Capital One breach, the WAF used to protect the AWS deployment had the ability to enumerate and read all files stored in the cloud buckets. These permissions were in excess of what the device needed in order to do its job and enabled the attacker to use the WAF to exfiltrate sensitive data from AWS.

Server-side request forgery and the public cloud

The Capital One hacker exploited a server-side request forgery (SSRF) vulnerability in a web application firewall used by Capital One. An SSRF vulnerability makes a device take undesirable actions by forcing it to visit certain URLs. In this case, the attacker used the SSRF vulnerability and the privileges of the WAF on Capital One’s AWS instance to exfiltrate sensitive data.

Server-side request forgery is a known attack vector, and, according to Evan Johnson of Cloudflare, is the biggest security issue facing users of public clouds. The Capital One breach demonstrates the importance of understanding this particular attack vector, how it can be exploited and how to detect and/or remediate it.

The importance of cloud-specific security

Most security teams are familiar with best practices for securing on-premises systems. However, the cloud is a completely different animal. Most cloud breaches are caused by a failure to properly adapt security to a cloud deployment.

One concept that cloud users commonly have trouble with is the cloud shared security model. While Amazon (and other CSPs) take responsibility for certain parts of the infrastructure stack offered “as a service,” the customer is also responsible for part of their own security. Failing to understand how this relationship works and how to properly secure systems that are the customer’s responsibility can cause issues like the Capital One breach.

Another common problem with the use of the cloud is the customer’s failing to use available cloud-specific security services. In a statement to Brian Krebs regarding the Capital One breach, Amazon pointed to several services that it offers to customers that could have mitigated different factors that contributed to the breach. While these services often cost extra, deploying security solutions specific to the cloud environment in use can help organizations ensure the security of their data.

The importance of log monitoring

While Capital One is a technology-literate organization, as demonstrated by their fervent support of cloud computing and other initiatives, they were not making the most of their security investment.

While the misconfiguration of the WAF that enabled the attack is an understandable mistake, the Capital One data breach should not have been able to occur without detection. The actions taken by the hacker while performing the attack should have raised numerous red flags and would be present in log files.

The success of the attack in remaining undetected demonstrates that Capital One was not adequately monitoring alerts and logs generated by their deployed security devices. Effective cyberdefense is more than just deploying the right tools; it also includes listening to and acting upon what those tools have to say.

The value of responsible disclosure process

There are numerous horror stories of organizations that took punitive action against someone ethically disclosing a vulnerability in their cybersecurity posture. However, the Capital One breach demonstrates how handling responsible disclosures well can be a huge asset to an organization.

The Capital One hacker posted information about her exploits on GitHub, and these posts were discovered and reported to Capital One through their responsible disclosure program. As a result, the incident was remediated within a couple of days of discovery, much more quickly than the average data breach. While the data breach will be expensive for Capital One, their quick and professional handling of it gained them some brownie points and may prompt a decrease in regulatory penalties.

Conclusion: The value of social media for threat hunting

The Capital One breach was a bit unusual due to the fact that it was discovered by an ethical hacker who noticed it on GitHub. Since the attacker was publicly bragging about her exploits, the breach was easily remediated after discovery.

While professional hackers rarely publicize their exploits, this isn’t always true of amateur hackers. If Capital One had been monitoring their exposure on social media, even by searching for their organization’s name and doing keyword searches around it, they might have discovered the breach themselves and remediated it more quickly.

See Infosec IQ in action

From gamified security awareness to award-winning training, phishing simulations, culture assessments and more, we want to show you what makes Infosec IQ an industry leader.

Demo Now

Sources

• Lessons from the Capital One data breach, BAI
• What We Can Learn from the Capital One Hack, Krebs on Security
• Preventing The Capital One Breach, ejj.io
• Capital One: What We Should Learn This Time, Dark Reading
• Cloud Security: Lessons Learned from the Capital One Data Breach, BitSight