5 ms·

What's crazier is that turning on Requester Pays does not actually mean requester pays when the request is a 403 [1][2]. Essentially every S3 bucket, public or

What's crazier is that turning on Requester Pays does not actually mean requester pays when the request is a 403 [1][2]. Essentially every S3 bucket, public or private, whose name is discovered can be DDoSed creating an insane bill... That's a platform level security issue for AWS to resolve. We do not need another Bucketgate. [1]: https://twitter.com/Lauramaywendel/status/1785074986396291515 https://twitter.com/Lauramaywendel/status/178507498639629151... [2]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/RequesterPaysBuckets.html#ChargeDetails https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...

martin-lim 2y ago
For me it looks like AWS has mainly different scenarios to handle. First, unauthenticated users are a big security pain for AWS and S3 because S3 is used for everything. But S3 was not designed for "secure" public access. As a result billing attacks are possible (e.g. [1]) and will not be fixed (by design). Second, authenticated AWS users are kind of trustworthy and these are never assumed to do any DDoS stuff or similar. Here, we have even more surface for billing attacks. I am waiting for the moment when this assumption breaks because credit cards do not make users trustworthy. My personal suggestion is that you should never use S3 for public access. Public buckets are an open gate to your AWS bill. If you have private buckets the attack surface is reduced but even in this situation you cannot prevent billing attacks. Try to reduce the damage by activating Cost Anomaly Detection. [1] https://blog.limbus-medtec.com/the-aws-s3-denial-of-wallet-amplification-attack-bc5a97cc041d https://blog.limbus-medtec.com/the-aws-s3-denial-of-wallet-a... [2] https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/ https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-...
- indigodaddy 2y ago
  private in the sense that the connection will never make it to the S3 bucket, is that correct? private in the sense that it is locked down to allowed source IP's or IAM-- then the connection still gets there and AWS incurs a charge for the Access Denied response, etc
  - martin-lim 2y ago
    Yes, private in the sense of "block public access" (your second point) (https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/access...) Sadly, the private in the sense of "never make it to the S3 bucket" is nearly impossible. May this can be achieved by choosing some "secret" S3 bucket name.
- tedmiston 2y ago
  > I am waiting for the moment when this assumption breaks because credit cards do not make users trustworthy. IMO it is already broken, or beginning to crack at least, with the advent of throwaway virtual cards. > Try to reduce the damage by activating Cost Anomaly Detection. Yeah, this sounds like it could be a better solution than just using CloudWatch Billing alarms and billing alerts that I mentioned elsewhere. It's hard to tell at-a-glance if Cost Anomaly Detection is built on top of CloudWatch Billing alarms, or if they're just totally separate products. I don't seed the latter mentioned in the docs for the former. [1]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitori....
EE84M3i 2y ago
What is bucketgate? Your comment comes up when searching...
- tedmiston 2y ago
  I'm referring to the endless amounts of S3 buckets that ended up inadvertently exposing sensitive data publicly due to how complicated and confusing the various access control methods were / are. And also, Amazon very eventually doing something about, probably a decade after it was needed. [1][2][3] [1]: https://cloudsecurityalliance.org/blog/2023/04/06/the-data-on-the-danger-of-publicly-exposed-s3-buckets https://cloudsecurityalliance.org/blog/2023/04/06/the-data-o... [2]: https://news.ycombinator.com/item?id=18468753 https://news.ycombinator.com/item?id=18468753 [3]: https://news.ycombinator.com/item?id=34585670 https://news.ycombinator.com/item?id=34585670
Bombthecat 2y ago
That's why AWS doesn't allow pentesting of this (S3) service.

martin-lim 2y ago

For me it looks like AWS has mainly different scenarios to handle. First, unauthenticated users are a big security pain for AWS and S3 because S3 is used for everything. But S3 was not designed for "secure" public access. As a result billing attacks are possible (e.g. [1]) and will not be fixed (by design). Second, authenticated AWS users are kind of trustworthy and these are never assumed to do any DDoS stuff or similar. Here, we have even more surface for billing attacks. I am waiting for the moment when this assumption breaks because credit cards do not make users trustworthy. My personal suggestion is that you should never use S3 for public access. Public buckets are an open gate to your AWS bill. If you have private buckets the attack surface is reduced but even in this situation you cannot prevent billing attacks. Try to reduce the damage by activating Cost Anomaly Detection. [1] https://blog.limbus-medtec.com/the-aws-s3-denial-of-wallet-amplification-attack-bc5a97cc041d https://blog.limbus-medtec.com/the-aws-s3-denial-of-wallet-a... [2] https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/ https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-...

indigodaddy 2y ago
private in the sense that the connection will never make it to the S3 bucket, is that correct? private in the sense that it is locked down to allowed source IP's or IAM-- then the connection still gets there and AWS incurs a charge for the Access Denied response, etc
- martin-lim 2y ago
  Yes, private in the sense of "block public access" (your second point) (https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/access...) Sadly, the private in the sense of "never make it to the S3 bucket" is nearly impossible. May this can be achieved by choosing some "secret" S3 bucket name.
tedmiston 2y ago
> I am waiting for the moment when this assumption breaks because credit cards do not make users trustworthy. IMO it is already broken, or beginning to crack at least, with the advent of throwaway virtual cards. > Try to reduce the damage by activating Cost Anomaly Detection. Yeah, this sounds like it could be a better solution than just using CloudWatch Billing alarms and billing alerts that I mentioned elsewhere. It's hard to tell at-a-glance if Cost Anomaly Detection is built on top of CloudWatch Billing alarms, or if they're just totally separate products. I don't seed the latter mentioned in the docs for the former. [1]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitori....

EE84M3i 2y ago

What is bucketgate? Your comment comes up when searching...

tedmiston 2y ago
I'm referring to the endless amounts of S3 buckets that ended up inadvertently exposing sensitive data publicly due to how complicated and confusing the various access control methods were / are. And also, Amazon very eventually doing something about, probably a decade after it was needed. [1][2][3] [1]: https://cloudsecurityalliance.org/blog/2023/04/06/the-data-on-the-danger-of-publicly-exposed-s3-buckets https://cloudsecurityalliance.org/blog/2023/04/06/the-data-o... [2]: https://news.ycombinator.com/item?id=18468753 https://news.ycombinator.com/item?id=18468753 [3]: https://news.ycombinator.com/item?id=34585670 https://news.ycombinator.com/item?id=34585670

Bombthecat 2y ago

That's why AWS doesn't allow pentesting of this (S3) service.