Capital One has suffered a major data breach. The sensitive data of over 100 million users was apparently downloaded from a poorly configured web application connected to a AWS bucket by software engineer and former AWS worker Paige Thompson, who was caught after dumping the cache to a GitHub account containing documents listing her real name.
“Thompson was previously an Amazon Web Services employee. She last worked at Amazon in 2016, AWS spokesman Grant Milne confirmed.
The breach didn’t require insider knowledge, he added.
Capital One Hack: What was Stolen?
The firm discovered on July 19 that its systems had been breached.
Capital One said: “The largest category of information accessed was information on consumers and small businesses as of the time they applied for one of our credit card products from 2005 through early 2019.
It includes names, addresses, zip codes/postal codes, phone numbers, email addresses, dates of birth, and self-reported income. Some 80,000 payment card details were also among the bundle, the company added.
The breach affects 100 million Americans and roughly six million Canadians. The banking firm estimates that 140,000 of their US clients have had their social security number compromised, while at the same time it is warning that roughly one million Canadian Social Insurance Numbers were compromised.
Content from our partners
The breach appears to have been made easier by the fact that Capital One does not appear to have locked down its AWS privileges tightly enough. Court papers suggest this error, without naming the cloud provider.
Capital One CEO Richard D. Fairbank commented in a release that: “While I am grateful that the perpetrator has been caught, I am deeply sorry for what has happened. I sincerely apologize for the understandable worry this incident must be causing those affected and I am committed to making it right.”
Sloppy OPSEC, or a Desire to be Caught?
The breach was first discovered by a GitHub user who spotted the S3 Data stored in Thompson’s GitHub account. Thompson is understood to have been widely discussing the breach in Slack chats and other forums. Despite having reportedly used Tor and a VPN during the download, she left the files in a forum that included her full name.
Capital One examined the GitHub files in question and determined that an April 21 file contained the IP address of a specific server. Upon analysis they discovered that a firewall misconfiguration permitted commands to reach and be executed by that server. This gave Thompson access to the data stored in Capital One’s cloud storage space. For the US authorities this wasn’t a hard solve: the GitHub account into which the April 21 File was posted also contained Thompson’s full name.
The U.S Attorney’s Office reported that: “Cyber investigators were able to identify THOMPSON as the person who was posting about the data theft. This morning agents executed a search warrant at THOMPSON’s residence and seized electronic storage devices containing a copy of the data.”
Thompson’s case is now being investigated by the FBI. She could face up to five years in prison and a $250,000 fine. Capital One may face substantially larger fines.
Justin Fier, Director of Cyber Intelligence at Darktrace, said: “Cloud is not going anywhere and this event in particular is not going to make everyone dust off our NAS boxes and come back to on-prem, but I think this will wake companies up to evaluating the risks associated with cloud computing.”
Matt Walmsley, EMEA Director at Vectra noted: “Capital One didn’t even know they’d been breached until an external party notified of them on Wednesday 17th July that their customer data appeared to be showing up on GitHub. Yet again we see another big breach where defensive controls fail and detection capabilities are found wanting. In this case it seems that technical configuring mistakes in firewalls provided an opening and a motivated insider within the cloud service provider.
“Cloud services, with all their many benefits, also come with unique security risks to be managed such as attacks directly aimed at Cloud PaaS using stolen credentials, which would remain invisible to workload and cloud instance-centric security controls. Pervasive visibility across the enterprise, agnostic of environment type, is fundamental to security success.”
For service roles, remove s3:ListAllMyBuckets and similar List/Describe privs. Code normally knows what buckets it needs to work with, and does not need to list them.
— Scott Piper (@0xdabbad00) July 30, 2019
