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.
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.
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.
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
