Submitted via IRC for AnonymousLuser
The Technical Side of the Capital One AWS Security Breach
On July 19th, 2019 Capital One got the red flag that every modern company hopes to avoid - their data had been breached. Over 106 million people affected. 140,000 Social Security numbers. 80,000 bank account numbers. 1,000,000 Social Insurance Numbers. Pretty messy right?
Unfortunately, the 19th wasn't when the breach occurred. It turns out that Paige Thompson, aka Erratic, had done the deed between March 22nd and March 23rd 2019. So almost 4 months earlier. In fact, it took an external tip for Capital One to realize something had happened.
Though the former Amazon employee has been arrested and is facing $250k in fines and 5 years in prison...it's left a lot of residual negativity. Why? Because of many of the companies who've suffered data breaches try to brush off the responsibility of hardening their infrastructures and applications to the increased cyber crime.
ANYHOW. You can read more about the case by just asking Google. We won't go into that anymore. We're here to talk about the TECHNICAL side of things.
Related Stories
The law firm Tycko & Zavareei LLP filed the lawsuit on Thursday, arguing that GitHub and Capital One demonstrated negligence in their response to the breach.
The firm filed the class-action complaint on behalf of those impacted by the breach, alleging that both companies failed to protect customer data.
Personal information for tens of millions of customers was exposed after a firewall misconfiguration in an Amazon cloud storage service used by Capital One was exploited.
[...] “As a result of GitHub’s failure to monitor, remove, or otherwise recognize and act upon obviously-hacked data that was displayed, disclosed, and used on or by GitHub and its website, the Personal Information sat on GitHub.com for nearly three months,” the law firm alleged in its complaint against GitHub and Capital One.
The firm also alleged that computer logs “demonstrate that Capital One knew or should have known” about the data breach when it occurred in March, and criticized Capital One for not taking action to respond to the breach until last month.
Previously:
Capital One Target of Massive Data Breach
The Technical Side of the Capital One AWS Security Breach
(Score: 1, Interesting) by Anonymous Coward on Saturday August 03 2019, @06:55PM (3 children)
Is it on the technical side of things that Capital One, a bank flush with your money, used Someone Else's Computer rather than use in-house expertise (supposing they hadn't laid them off already) and equipment?
And when doing so, they did not use Someone Else's Computer for data that was accessible via private VPN ("private cloud") only, but one that was listening on the open internet?
I'm sure some of us have written web services before. As a matter of course, only the web server has a port open for incoming requests, the database server is on the internal network. Capital One on the other hand like bottom barrel talent did the equivalent of setting up the web server to talk to the database server on the open internet, and someone then pulled the data off of the database server.
(Score: 2) by GDX on Saturday August 03 2019, @07:12PM (1 child)
Welcome to the greatness of cloud computing, specifically the one of clueless bosses that dance in the hands of commercial agents.
(Score: 0) by Anonymous Coward on Saturday August 03 2019, @10:47PM
Gta V cloud computing AD [youtube.com]. LOL Your are fired Internet.
(Score: 5, Interesting) by JoeMerchant on Saturday August 03 2019, @07:13PM
As AC implies: technically, this is about massive lazy greedy corporations shifting liability and hassle off on their little-guy captive customers who can't do anything about it.
Technically: it's well known _how_ to secure these things, the problem is that, like pollution reduction in the energy industry, it's more expensive to build, maintain, and operate truly secure banking systems than it is to roll with the status quo, particularly in the short term.
There's never enough time to fix it before the breach, but there's always enough time to run around picking up the pieces afterwards. They're viewing it as a risk-benefit problem and they're not entirely wrong. However, they are probably not factoring in the time cost and anxiety and occasional real monetary damages suffered by their customers.
I'll put in a pitch for transparency: transparency of the security architecture, transparency of the actual security performance, otherwise there's no real choice in banking, they all look the same until you wake up with your identity stolen one morning and spend the next 90 days sorting out one mess after another.
🌻🌻🌻 [google.com]
(Score: 1) by jrbrtsn on Sunday August 04 2019, @01:24PM
Every time complexity is added to a security model, new exploits become possible. Apparently AWS is subject to "IAM" security restrictions, and Paige just exploited a misconfiguration.
(Score: 1) by warsen on Monday August 05 2019, @05:16AM
I'm starting to think we're seeing the signs of AWS becoming a monoculture.
If you go beyond the initial entry (which was a misconfigured "firewall"; no details available), the rest of it was in how AWS is used and how to get information out of it to use it. If CapOne had their own in-house system it would almost certainly have been harder. Not impossible, of course, but harder.
The part about "how to get information out of it" is also something to think about. The capability of reflection (or introspection) may may well be a necessity -- I don't know enough about any cloud system so I can't say. But a home grown system may (a) not have such a capability, or (b) implemented it using some other mechanism which the attacker would need to discover. Which again brings us back to the "monoculture" question.