Analyzing the Capital One Data Breach
Last week, Capital One hit the news with one of the largest data breaches recorded. In this particular scenario, a hacker gained access to more than 100 million Capital One customers’ accounts and credit card applications in the US and about 6 million in Canada. While many data breaches come from misplaced data or external criminals – this appears to be an insider threat.
The hacker was a 33-year old woman living in Seattle who previously worked as a software engineer for Amazon Web Services (AWS). Capital One was hosting their data on an AWS server. It’s a little unclear in reports at this point, but it appears she may have been working on a project (with Amazon or with another cloud services company) that helped provide data services to Capital One possibly in 2015 and 2016. She was able to gain access by exploiting a misconfigured web application firewall. It appears she may have also accessed other companies including Michigan State University, Ford Motors, Ohio Department of Transportation, UniCredit (Italy’s largest bank), and many others who the FBI has reached out to. Once a vulnerability is in place it is easier to exploit other companies with the same vulnerabilities.
The hack occurred on March 22nd and 23rd. Capital One was not initially aware of the hack. It was brought to their attention when the hacker was bragging about it on public websites and chat rooms (Github and Slack). On July 17, a GitHub user alerted Capital One to the threat. The hacker did not disguise her identity and she told people exactly what she did to hack it. When they went to look at the claims, they were able to confirm that the boasting was true. On July 19, Capital One contacted the FBI. As soon as Capital One was aware of the security hole, they fixed their vulnerability. They believe it was unlikely that the information was used for fraud or was distributed out by the hacker. Capital One took 10 days to report the breach to the public (which is much faster than many other companies impacted by a breach).
One feather in Capital One’s cap was that they were using encryption technologies for some of their data so login credentials and credit card numbers were not compromised. Additionally, much of their SSN were also encrypted and 99% of them were not compromised.
The largest category of information was on consumers and small businesses who applied for credit card products from 2005 to 2019. It includes personal information including names, addresses, zip codes, phone numbers, email addresses, dates of birth, and self reported income.
Capital One anticipates that this breach will likely cost them between $100M – $150M.
How Did This Happen?
In this particular breach, the perpetrator was caught quickly and openly bragged about how the breach occurred. There are also court documents of the ongoing breach investigation that are openly available to the public.
For those who are looking for the detailed technical analysis:
- Krebs on Security did a nice article on what we can learn from the breach (along with some insights on how it occurred).
- Additionally, CloudSploit did a pretty good analysis on the technical aspects of the hack.
- Evan Johnson, manager of product security at Cloudfare, also wrote a blog to break down some of the terms into digestible bite-sized pieces.
But for a high level overview, the hacker was able to access a misconfigured firewall. The hacker then was able to get in and elevate her privileges so she could have access to sensitive documents (similar incidents have happened to the Pentagon and Facebook). She accessed an exposed vulnerability that allowed her to access the server as a remote user. Then, she was able to get to any area that the server had access to.
In the case of Capital One, the misconfiguration of the firewall granted too many permissions which listed all of the files and allowed the hacker to read the contents of those files. It’s important to note that this is not a flaw in Amazon/AWS/EC2, but rather it is a flaw in how permissions and identity management are configured (or in this case misconfigured).
In Kreb’s article, he lists several Amazon tools that could have mitigated this issue:
- Access Advisor, which helps identify and scope down AWS roles that may have more permissions than they need;
- GuardDuty, designed to raise alarms when someone is scanning for potentially vulnerable systems or moving unusually large amounts of data to or from unexpected places;
- The AWS WAF, which Amazon says can detect common exploitation techniques, including SSRF attacks;
- Amazon Macie, designed to automatically discover, classify and protect sensitive data stored in AWS.
My Thoughts
Hackers are going to become more savvy. Data Breaches are going to continue. On-premises servers have different vulnerabilities than cloud servers – but they are both vulnerable to similar attacks.
Attacks will continue to come from the outside, finding ways to break into your systems and exploit software vulnerabilities and gather your data to be used in nefarious ways. Attacks will come from the inside via disgruntled or malicious employees. Attacks will come in harmless mistakes like an employee leaving an unlocked laptop on a plane which is then picked up by someone looking to cause trouble.
Surveys of high level executives show anywhere between 60% – 90% of CIOs believe they are not prepared for a data breach. Of the CIOs who are prepared, most do not have a good response system in place. Companies should put measures in place to protect them from all the ways that people can access your information and data.
You can start by:
- Configuring your network (on-premises) or cloud services to protect intruders from accessing your information from the outside.
- Having good policies and procedures in place to remove employees or contractors access once they have left an organization or once they no longer need access.
- Using tools like SQL Secure for SQL Server to set up security checks and policies to ensure the right roles, users and principals have the right access to the right parts of your databases.
- Using tools like SQL Secure for SQL Server to configure policies on what data should be masked/encrypted and ensure it stays that way.
- Using tools like SQL Compliance Manager for SQL Server to audit and monitor your databases to ensure that no one is accessing/changing your data that shouldn’t be.
- Using tools like SQL Compliance Manager for SQL Server to ensure that no one is making security or administrative changes who shouldn’t be.
Once your data is breached, you can:
- Use tools like SQL Compliance Manager for SQL Server to forensically analyze when the breach occurred and what information was accessed.
- Have quick response systems in place to lock down your systems so that the breach can’t do more damage.
- Work quickly to remedy any vulnerabilities so that the hacker can’t come back and copycats can’t mimic the breach.
- Work quickly to restore any information that may have been deleted or tampered with.
In Conclusion
If you own your own home, there are things you can do to make a thief less likely to break into your house. You start by locking your doors. You can get a noisy dog that acts as a deterrent. You can put in a good alarm system in place that calls the police as soon as someone comes into your home. You can put up cameras to help monitor the area and let thieves know that they are being recorded. You can put up security gates that further restrict access to your property. If you wanted to go even further you could employ a security guard to guard your property. Old kingdoms had unpassable moats loaded with bitey alligators looking for dinner.
We do so much to protect our homes, so why aren’t we willing to take the same kinds of steps to protect our servers and databases and make it harder to hack our systems? No system is unhackable, but we can do things to not make it easy and deter someone to go hack another system.
Security and data breaches are the norm in our highly connected world. How are you protecting your data assets? How might you do better?