Hacker News new | past | comments | ask | show | jobs | submit login

I'll preface this by saying that I haven't seen any official resources confirming that it was an S3 bucket issue (although the statement from hacker mentioned releasing "buckets" so it very well could be).

S3 provides server side encryption that encrypts the files at rest. This is done entirely on the server side and does not require any additional keys from the client. However, it is possible to do your own file encryption using your own keys ahead of time, but I imagine that a very small subset of AWS users actually do that.

The way these hacks usually happen is that someone configures the bucket to enable public access, either to the entire bucket or certain files within it, and then someone stumbles upon the bucket's endpoint.

The mitigation is simply not to configure your buckets to be publicly available. That used to be relatively more difficult than it sounds because of a confusing S3 UI, but AWS has recently pushed a number of changes that try to address this issue, including putting a very clear "Public" label next to buckets with these settings, sending emails to users with public buckets, and providing configurations that allow account owners to prevent users from setting buckets to public access.

Some articles are referencing a WAF configuration issue, in which case the above may not fully apply here. The commenter below me mentioned the use of temporary AWS access keys, which can be obtained from an internal AWS service known as the metadata endpoint. Typically this endpoint is only accessible from EC2 nodes (or services that rely on EC2 like Lambda or CodeBuild) and allows AWS to deliver short-lived credentials to the node that can rotate frequently. If this truly was the issue, then it's possible a WAF issue allowed the remote attacker to query the internal endpoint from an external source and obtain credentials that were previously only available to the node itself. From there, the attacker could make AWS API calls to the S3 buckets and download the files.




> it's possible a WAF issue allowed the remote attacker to query the internal endpoint from an external source

But then it's literally a configuration issue, right? WAF is just Rule -> Block/Allow. It doesn't proxy traffic or anything, it just attaches to a load balancer, API Gateway or CloudFront.

More puzzling, what is the WAF-Role they're talking about? WAF doesn't use IAM roles, so is this just a role they used to configure the WAF (and also had S3 permissions?)


Yeah, that part is confusing. Since I posted the above a few more details came out, but it seems like the WAF may have been involved because it wasn't configured to block requests to the IAM instance metadata endpoint, which would have allowed the attacker to operate in the scope of the instance, which seems to have had the S3 permissions. But again, entirely conjecture on my part at this point.


That's not a "full disclosure", that's spam.


I added that because CapitalOne has an open source tool that has similar functionally, but point taken and post edited.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: