查看原文
科技

云上黑暗森林:打爆云账单,只需要S3桶名

冯若航 非法加冯 2024-04-30

公有云上的黑暗森林法则出现了:只要你的 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



云计算泥石流
曾几何时,“上云“近乎成为技术圈的政治正确,整整一代应用开发者的视野被云遮蔽。就让我们用实打实的数据分析与亲身经历,讲清楚公有云租赁模式的价值与陷阱 —— 在这个降本增效的时代中,供您借鉴与参考。
点一个关注 ⭐️,精彩不迷路
云盘是不是杀猪盘?

云数据库是不是智商税

云计算:菜就是一种原罪
为什么这两年的舆论战,云厂商总是节节败退
包年包月的云还能叫云原生吗?
腾讯真的走通云原生之路了吗?

云SLA是安慰剂还是厕纸合同?

为什么我们的云老是故障
你用的公有云都没做过测试
腾讯云/阿里云故障背后:投入不足
转载:从头到尾复盘腾讯云故障
故障不是腾讯云草台的原因,傲慢才是
腾讯云:颜面尽失的草台班子
从降本增笑到真的降本增效
我们能从阿里云史诗级故障中学到什么
阿里云周爆:云数据库管控又挂了
【阿里】云计算史诗级大翻车来了

牙膏云?您可别吹捧云厂商了

罗永浩救不了牙膏云
赛博菩萨Cloudflare圆桌访谈与问答录
吊打公有云的赛博佛祖 Cloudflare
云计算为啥还没挖沙子赚钱?
FinOps终点是下云
卡在政企客户门口的阿里云
云厂商眼中的客户:又穷又闲又缺爱 
阿里云降价背后折射出的绝望
迷失在阿里云的年轻人
互联网故障背后的草台班子们 
门内的国企如何看门外的云厂商
剖析云算力成本,阿里云真的降价了吗?
Redis不开源是“开源”之耻,更是公有云之耻
公有云厂商卖的云计算到底是什么玩意?
重新拿回计算机硬件的红利
扒皮云对象存储:从降本到杀猪
垃圾腾讯云CDN:从入门到放弃
云SLA是不是安慰剂?
杀猪盘真的降价了吗?
范式转移:从云到本地优先
云计算反叛军
下云高可用的秘诀:拒绝智力自慰
半年下云省千万:DHH下云FAQ答疑
是时候放弃云计算了吗?
下云奥德赛
RDS阉掉了PostgreSQL的灵魂
DBA会被云淘汰吗?
更好的开源RDS替代:Pigsty
驳《再论为什么你不应该招DBA》
云RDS:从删库到跑路
数据库应该放入K8S里吗?





继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存