Was Capital One an aberration?

Recently released data from the 2019 IBM/Ponemon Cost of a Data Breach Report identifies financial services institutions as one of the top two industry groups targeted by cyber threats (healthcare being the other). The financial services industry is also second only to healthcare with an average total cost per breach incident of $5.86 Million.

One of the reasons behind this is the corporate network, server, and storage systems in financial services are becoming more open, federated, cloud-enabled, and complex. Financial institutions are also hoarding vast sums of personal and financial information, spread across all of these disparate environments, which by the volume of sensitive (and therefore valuable) records alone puts them at a much higher cost per breach.

It should come as no surprise that all these factors also make these organizations more attractive and vulnerable to cyberattacks. On top of all these challenges, attacks are also becoming more sophisticated, to say nothing of the risks presented by insider threats.

The Elephant in the Room

One can consider the most recent breach of Capital One’s credit card application data as the most current anecdotal evidence of the challenge of protecting financial enterprises, and the cost and complexity of a financial services breach. Records from approximately 100 million customers in the United States and 6 million customers in Canada were affected. Over 140,000 Social Security numbers linked to at least 80,000 bank account numbers were also exfiltrated. The sheer size of the breach puts it well above the average with an initial price tag in excess of $100 million.

So how did it happen? Was Capital One an aberration – just a coincidental coalescence of unlikely and unfortunate factors – or something more easily attributed to the risk factors that are increasingly affecting nearly every financial institution?

At the most basic level, the breach was initiated with three commands executed via a misconfigured web application firewall (WAF). The attacker initiated access to the WAF from Capital One’s network, a trusted connection spoofed via VPN using TOR to obscure their location. From there, the attacker was able to access a cloud provider’s server/storage destination network (behind the WAF), containing highly sensitive customer card application data.

First Command: Entry

The attacker obtained non-expired, non-refreshed security credentials for a ****-WAF-Role account, enabling access to Capital One’s S3 bucket folders on AWS. This was only possible by using a Server-Side Request Forgery (SSRF) exploiting the excessive permissions erroneously assigned to the misconfigured WAF. These excessive permissions may have been assigned due to a wide array of accessibility needs for the web-based data. Whether they knew it or not, Capital One had created many cloud silos of sensitive data with one shared feeder: the vulnerable WAF.

Second Command: Infiltration

As a part of the SSRF, the attacker may have been able to exploit the WAF to gather metadata on all of the hosted application data. Amazon exposes an internal service every EC2 instance can query for instance metadata about the host, and it is more than likely that this metadata was how the attacker mapped out the various buckets of data. The AWS command “list-buckets” could have been used to return the names of folders (in AWS S3 buckets) that contained sensitive credit card application data – 14 years’ worth.

Third Command: Exfiltration

Once the data was exposed, the attacker then executed the AWS command “sync” to exfiltrate the credit card application data back over the bidirectional VPN back channel and saved (to be later exposed on social media). Only a small subset of the data was encrypted or tokenized, thus leaving the thousands of exposed records open to exploit.

Now that we’ve covered the tactics, in my next post I’ll cover the autopsy of these events and the insecurities that allowed the breach to happen.