Hacker News Reader

Comment by cfors | Hacker News Reader

Well, the main cloud Capital One uses is Amazon as far as I know.

If you think about the attack vectors here, it was most definitely the virtual server that got attacked. If it was the cloud provider (Amazon), there are a lot of safeguards that these banks use to make sure that any data that touches the shared server persistent storage is encrypted. And when I say safeguards, I mean automation to make sure that this sort of scenario shouldn't ever happen.

This is a huge blow for the public cloud and financial services companies, unfortunately.

Edit: Seemingly a WAF firewall issue. I wonder what happened. These rules should be applied automatically for Capital One using Cloud Custodian [0], so a config issue definitely occurred somewhere.

Final edit: A leaked account with access to IAM permissions. Good lord was occam's razor correct here.

[0] https://github.com/cloud-custodian/cloud-custodian

View on HN

so I wrote the majority of cloud custodian and still maintain it. I no longer work at capitalone (since jan 2019). afaics the suspect (https://www.linkedin.com/in/paige-t-704a29188/) worked at AWS 3 years ago is also irrelevant which its why its not part of the filing.

the best link for understanding what happened is actually the court case filing not the media reports. https://www.justice.gov/usao-wdwa/press-release/file/1188626...

so this isn't a case of s3 bucket being public/wide open, its a case of a waf iam permissions being overly broad if I'm parsing the filing correctly. Its unclear how the waf product was hacked/bypassed and its credentials obtained.

wrt to custodian in this equation, its not really related afaics, custodian has lots of filters to help determine stuff like is my ec2 or anything with iam role (lambda, etc) overly permissive wrt to permissions (check-permissions filter). it also has the ability to filter individual statements and access on any resource (s3, lambda, etc there are many) with an embedded iam policy on a fine grained basis (allow y accounts but not x accounts) to protect against account level access (cross-account filter). And the ability on ec2 via guard duty alerts to auto remediate (suspend, memory snapshot, yank role, volume snapshot). its used by lots of users/enterprises across the governance, security, cost-optimization domains because its flexible and supports many clouds.

Thanks for writing Cloud Custodian. What are you working on these days?

Still working on custodian, k8s integration up next. else atm. trying to ensure that the next 20 years of opensource are open.

AWS has Macie to catch this sort of thing, not to mention the usual AWS security automation tools available like Security Monkey. Or the fact that a pen test should have caught this, or employees following the data use policy.

Where did you see it was a leaked account?

Attacker had access to the account. It is in the complaint posted by user iancarroll.

"there are a lot of safeguards that these banks use to make sure that any data that touches the shared server persistent storage is encrypted. And when I say safeguards, I mean automation to make sure that this sort of scenario shouldn't ever happen." ROTFLMAO....you have clearly never worked for a bank, no offense mate. Capital left this shit in plain text on an S3 bucket, I guarantee you

If you took ten seconds to look at the posted source note above, you would see Cloud Custodian has a policy to enforce bucket encryption.

Bucket encryption doesn't protect against anything except someone getting access to the hard drives underlying S3 and somehow recovering data.

If you've somehow left access to a bucket open the odds are that you also have it configured to let anyone with access to the bucket decrypt the files. AWS calls this server side encryption, where S3 automatically encrypts and decrypts files for you. You can also do client side encryption, of course, but it's much more difficult to manage because you have to deal with keys in your application.

I am well aware how S3 works, I just mean you can use custodian to enforce SSE on the bucket as well as KMS based encryption, so the original commenter is just being a troll was the point I was getting at.

Default bucket encryption would require you to misconfigure two controls instead of one. S3 only automatically decrypts if you are an authorized principal on the KMS key, having S3 permission is not enough.

"You can also do client side encryption, of course, but it's much more difficult to manage because you have to deal with keys in your application."

Well,SSE-KMS is not difficult to manage if you have sensitive customers data like Capital One does. I use it all the time. You can pretty much audit the buckets and see what is going on.

And if Capital One has used SSE-KMS on the buckets,we might not be talking about this data breach today.Incompetence? Complacency?

And if you knew anything of what you were talking about, you would see how easy it is for an engineer to make a mistake and there is 0 auditing or oversight. Also, if YOU actually took 10 seconds, you would see all the data was un-encrypted and in plain text. So where is all this "safety" the dude is speaking of? Cloud Custodian does shit when implemented incorrectly -and that's my point. You think banks are making all this effort, but in reality, the security team is completely understaffed, often not listened to, and in the end - we find this stuff happening all the time.

There, I gave you more than 10 seconds. Trying keeping up.

Reply on news.ycombinator.com