云上黑暗森林：打爆云账单，只需要S3桶名
公有云上的黑暗森林法则出现了：只要你的 S3 对象存储桶名暴露，任何人都有能力刷爆你的云账单。
作者：Maciej Pocwierz[1] ，译者：冯若航
原文：https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1[2]
试想一下，你在自己喜欢的区域创建了一个空的、私有的 AWS S3 存储桶。第二天早上，你的 AWS 账单会是什么样子？
几周前，我开始为客户开发一个文档索引系统的概念验证原型 (PoC)。我在 eu-west-1 区域创建了一个 S3 存储桶，并上传了一些测试文件。两天后我去查阅 AWS 账单页面，主要是为了确认我的操作是否在免费额度内。结果显然事与愿违 —— 账单超过了 1300美元，账单面板显示，执行了将近 1亿次 S3 PUT 请求，仅仅发生在一天之内！
我的 S3 账单，按每天/每个区域计费
这些请求从哪儿来？
默认情况下，AWS 并不会记录对你的 S3 存储桶的请求操作。但你可以通过 AWS CloudTrail[3] 或 S3 服务器访问日志[4] 启用此类日志记录。开启 CloudTrail 日志后，我立刻发现了成千上万的来自不同账户的写请求。
为何会有第三方账户对我的 S3 存储桶发起未授权请求？
这是针对我的账户的类 DDoS 攻击吗？还是针对 AWS 的？事实证明，一个流行的开源工具的默认配置，会将备份存储至 S3 中。这个工具的默认存储桶名称竟然和我使用的完全一致。这就意味着，每一个部署该工具且未更改默认设置的实例，都试图将其备份数据存储到我的 S3 存储桶中！
备注：遗憾的是，我不能透露这个工具的名称，因为这可能会使相关公司面临风险（详情将在后文解释）。
所以，大量未经授权的第三方用户，试图在我的私有 S3 存储桶中存储数据。但为何我要为此买单？
对未授权的请求，S3也会向你收费
在我与 AWS 支持的沟通中，这一点得到了证实，他们的回复是：
是的，S3 也会对未授权请求（4xx）收费[1]，这是符合预期的。
因此，如果我现在打开终端输入：
aws s3 cp ./file.txt s3://your-bucket-name/random_key我会收到 AccessDenied 错误，但你要为这个请求付费。
还有一个问题困扰着我：为什么我的账单中有一半以上的费用来自 us-east-1 区域？我在那里根本没有存储桶！原来，未指定区域的 S3 请求默认发送至 us-east-1，然后根据具体情况进行重定向。而你还需要支付重定向请求的费用。
安全层面的问题
现在我明白了，为什么我的 S3 存储桶会收到数以百万计的请求，以及为什么我最终面临一笔巨额的 S3 账单。当时，我还想到了一个点子。如果所有这些配置错误的系统，都试图将数据备份到我的 S3 存储桶，如果我将其设置为 “公共写入” 会怎样？我将存储桶公开不到 30 秒，就在这短短时间内收集了超过 10GB 的数据。当然，我不能透露这些数据的主人是谁。但这种看似无害的配置失误，竟可能导致严重的数据泄漏，令人震惊！
我从中学到了什么？
第一课：任何知道你S3存储桶名的人，都可以随意打爆你的AWS账单
除了删除存储桶，你几乎无法防止这种情况发生。当直接通过 S3 API 访问时，你无法使用 CloudFront 或 WAF 来保护你的存储桶。标准的 S3 PUT 请求费用仅为每一千请求 0.005 美元，但一台机器每秒就可以轻松发起数千次请求。
第二课：为你的存储桶名称添加随机后缀可以提高安全性。
这种做法可以降低因配置错误或有意攻击而受到的威胁。至少应避免使用简短和常见的名称作为 S3 存储桶的名称。
第三课：执行大量 S3 请求时，确保明确指定 AWS 区域。
这样你可以避免因 API 重定向而产生额外的费用。
尾声
1.我向这个脆弱开源工具的维护者报告了我的发现。他们迅速修正了默认配置，不过已部署的实例无法修复了。2.我还向 AWS 安全团队报告了此事。我希望他们可能会限制这个不幸的 S3 存储桶名称，但他们不愿意处理第三方产品的配置不当问题。3.我向在我的存储桶中发现数据的两家公司报告了此问题。他们没有回复我的邮件，可能将其视为垃圾邮件。4.AWS 最终同意取消了我的 S3 账单，但强调了这是一个例外情况。
感谢你花时间阅读我的文章。希望它能帮你避免意外的 AWS 费用！
下云老冯评论
公有云上的黑暗森林法则出现了：只要你的 S3 对象存储桶名暴露，任何人都有能力刷爆你的 AWS 账单。只需要知道你的存储桶名称，别人不需要知道你的 ID，也不需要通过认证，直接强行 PUT / GET 你的桶，不管成败，都会被收取费用。
该特性被视为 Feature，而不是安全漏洞或者 Bug，可以用来咔咔爆用户的金币。同样的设计逻辑贯穿在 AWS 的产品设计逻辑中，例如，Route53 查询没有解析的域名也会收费，所以知道域名是 AWS 解析的话，也可以 DDoS。
我并不确定本土云厂商是否使用了同样的处理逻辑。但他们基本都是直接或间接借鉴 AWS 的。所以大概率也是一样的情况。作为信安专业出身，我很清楚业界的一些玩法，比如打DDoS 卖高防。
来自某群友的截图
在 《Cloudflare圆桌访谈》中，我也提到过安全问题，比如监守自盗刷流量的问题。
Well，总的来说，账单被刷爆，也算一种公有云上独有的安全风险了 —— 希望云用户保持谨慎小心，一点小失误，也许就会在账单上立即产生难以挽回的损失。
References
[1] Maciej Pocwierz: https://medium.com/@maciej.pocwierz[2] 原文地址: https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1[3] AWS CloudTrail: https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging.html[4] S3 服务器访问日志: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html