This week’s big security news involved a data breach at Capital One that, by the company’s own estimate, affected approximately 100 million individuals in the United States and approximately 6 million Canadians. Among the data leaked were 140,00 Social Security Numbers (SSNs) and 80,000 bank account numbers belonging to secured credit card customers. It has been claimed that the Capital One breach may be as far reaching as the Equifax breach of 2017, which affected an estimated 147 million consumers and cost the company at least $575 million in fines and up to $700 million in compensation.
So what exactly happened at Capital One, how did it happen and what lessons can we learn from yet another massive data breach?
What Happened At Capital One?
As has been well-documented since the news broke earlier this week, an individual by the name of Paige A Thompson, aka Erratic on Twitter (her account has since been suspended), was indicted by the FBI on July 29, 2019 on a single count of Computer Fraud and Abuse. The charge pertains to an alleged network intrusion that resulted in the exfiltration and theft of Capital One confidential consumer data, including credit card applications and other digital documents.
The hack is said to have taken place on or after March 12, 2019, when Thompson allegedly used a vulnerability in a firewall application to access a privileged account. Once she had gained access, the FBI claim, she went on to use it to issue server commands to obtain personally identifying information (PII) belonging to applicants of a Capital One credit card product between 2005 to 2019. The information disclosed includes names, addresses, zip codes/postal codes, phone numbers, email addresses, dates of birth, and income.
The investigation was triggered by an email sent to Capital One’s Responsible Disclosure email address – a channel the company uses to receive intel on bugs, vulnerabilities and other security issues – by an unidentified security researcher. Despite the FBI not naming the Cloud Service provider used by Capital One to host the breached server, the security researcher’s email refers to “leaked s3 data”. The reference to “s3” clearly indicates Amazon’s Simple Storage Service (S3). Capital One have, also, been vocal about being clients of Amazon S3 in the past.
Although the technical details of how Thompson allegedly hacked into the server are sparse at this time, we do know that, according to Capital One, the leak occurred through a firewall vulnerability issue. Amazon’s S3 and other cloud services come strongly touted with a Web Application Firewall known as AWS-WAF, which can be hosted on the Amazon CloudFront. Ms Thompson’s CV, a partial screenshot of which appears below, indicates that she was formerly employed by Amazon, and had extensive experience of networking, S3 and CloudFront technologies.
Under the Twitter handle of “Erratic”, Thompson had earlier posted some generalized descriptions suggesting how she might undertake similar attacks.
What Are Web Application Firewalls (WAFs)?
According to Capital One’s statement, the firewall configuration vulnerability has now been fixed. Although it has not been confirmed, given what we do know, it’s a reasonable assumption that the issue concerned Capital One’s configuration of Amazon’s Web Application Firewall, the AWS-WAF.
Web Application Firewalls are intended to protect particular web applications by analyzing packets of incoming traffic according to a set of rules or policies, and filterering out potentially harmful traffic. The kinds of attack that WAFs are designed to defend against include cross-site scripting (XSS), cross-site request forgery (CSRF) and SQL injection.
Amazon’s AWS-WAF allows customers like Capital One to either set up their own rules or buy pre-configured Managed Rules from AWS Marketplace sellers. The fact that there is a market for managed rules testifies to the fact that configuring and maintaining WAFs is no simple matter. It is not just a matter of configuring a WAF once and letting it run; rather, WAFs need to be actively maintained as the application behind a WAF is itself likely to evolve with development and user demand and require different rules for its traffic over time. Because of this, WAFs can be subject to both a high degree of false positives (blocking harmless traffic) and false negatives (allowing malicious traffic). They can also impact performance if not configured correctly. These and other considerations create the need for specialist third-party vendors to provide and maintain Managed Rules.
It is not known whether Capital One was using a Managed Rules provider or had configured their own firewall settings, but there is an interesting piece of data revealed in a screenshot of Erratic’s postings in an open Slack channel.
The names of the first two highlighted items coincide with information in the FBI indictment that indicate they could be the stolen material from Capital One. The first item is the name of a directory containing hundreds of items with the same name as the breached account, while the second is a compressed file of 28GB of data. However, the name of the third item,
Rotate_Access_key.tar.xz is a file of 35GB of compressed data and may also hold a potential clue to the hack.
Access keys are required for Amazon IAM users in order to login to an AWS instance. AWS customers are advised to rotate these access keys on a regular basis. However, rotating keys, while not complicated, involves several distinct steps important for security. These include separate measures to ensure both that the previously used key is deleted and that the Secret Access Key required for key creation is recorded and stored securely.
Rotate_Access_key file in Erratic’s data dump could suggest she had discovered the key or keys prior to the breach and used those to gain the required credentials. Alternatively, the file name could indicate the keys were discovered as part of the breach. It remains to be seen if more details are revealed as the case progresses through the courts. Either way, given the central role Access keys play in authentication in the AWS environment, the contents of
Rotate_Access_key.tar.xz will undoubtedly be of interest to investigators in the case.
What Can We Learn From the Capital One Breach?
The primary take away from the Capital One breach is that enterprises need to ensure that firewalls and Web Application Firewalls are properly configured and maintained, and that credentials are secure. The apparent speed with which Capital One were able to claim the configuration vulnerability had been fixed may suggest the remedy was obvious once known, and that in turn may indicate a simple oversight like not securing a Secret Access Key or failing to disable an older, disused key that could possibly have already become insecure.
On top of the immediate lessons, enterprises need to be mindful that Firewalls and WAFs do not offer a complete security solution, and with the ever-present possibility of insider threats or just human error allowing hackers access to protected resources, it is essential to have in place an autonomous endpoint security solution that can implement its own Firewall controls, Watchlist alerts to notify of unauthorized file access and real-time endpoint visibility for investigation.
The consequences of the hack on Capital One are likely to be greater than we can tell at this early stage. For Paige Thompson, aka Erratic, if found guilty she faces a maximum 5 years in prison and fine of $250,000. For Capital One, the company insists that there is no evidence to-date that the hacker had distributed the stolen data or tried to use it for fraudulent purposes. Even so, given the hefty fine meted out to Equifax by the FTC, the company may still face sanction after all the details have played out.