25 分钟攻陷 Baseten 生产环境 GitHub
We got admin access to Baseten's production GitHub in 25 minutes
我们本想将数据交给 Baseten 进行推理，出于安全考虑，先让 Strix 对其进行了扫描。仅 25 分钟后，Strix 就获取了 Baseten 内部仓库的管理员权限。起因是一个 2023 年构建的 Docker 镜像被公开托管在 Harbor 上，其构建历史中意外泄露了一个有效的 GitHub 个人访问令牌。这个令牌拥有对 Baseten 核心产品代码、GitOps 基础设施仓库以及 Homebrew 源的完全控制权限。Baseten 安全团队反应迅速，确认问题后立刻修复并轮换令牌。这一案例警示我们：旧版容器镜像的构建历史中可能隐藏着致命漏洞，必须定期检查并清理。
如果代理能在 25 分钟内从旧镜像中找到一个有效的管理员令牌，你肯定希望你的代理先于坏人发现它。
HN 评论区
184- philipkiely
大家好，我是 Baseten 的 Philip。
代表我们的安全团队发帖。我想确认，我们与 Strix 合作解决了所报告的漏洞。感谢 Strix 负责任地披露。我们立即采取措施使泄露的密钥失效，并删除了公开的容器镜像。我们的日志证实该漏洞从未被利用，也没有任何客户数据泄露。
- swyx
> Baseten 处理得当。时间线如下：
> 7 月 13 日 晚上 11:10：我报告了 live basetenbot 令牌、公开的 Harbor 项目以及仓库权限。
> 7 月 14 日 上午：Baseten 将 Harbor 项目设为私有。我指出令牌本身仍然有效。
> 7 月 14 日 下午 4:34：Baseten 安全团队的 Anton 确认该问题为严重级别，并表示已将 Harbor 项目设为私有并轮换令牌。他还要求我们安全删除我们拉取的镜像。
> 7 月 14 日 下午 5:05：我们确认了删除操作，并发送了来自同一扫描的两个低严重性问题发现。
> 7 月 17 日：Baseten 关闭了剩余的问题发现。
> 9 月：我们告知 Baseten 我们计划公开披露该发现，并发送了此帖子的草稿。
他们还送了我们一些 T 恤和卫衣，以感谢我们发现这个严重漏洞。
各方面都做得很好。我想我唯一未解决的问题是，作为我们从中学到的教训，所有基于 vibe coding 的内部代理应该遵循哪些默认安全边界？
- ivraatiems
这完美契合“一个没有动机的人类不会费心去寻找，但如果感兴趣，人类绝对能找到”这一类别。
越来越觉得，这些代理的力量不在于它们能发现人类无法发现的东西，而在于它们能比人类愿意花费的时间更快地发现许多东西。
我不确定这是否是 Strix 相对于其他代理的绝佳广告——他们的代理做了什么而 Claude 或 Codex 做不到的？如果我想做的话，它并没有做任何我做不到的事。
- wxw
> [渗透测试代理] 返回了一个用于 basetenbot 的活跃 GitHub 个人访问令牌。该令牌拥有对 Baseten 主产品仓库、驱动其集群的 GitOps 仓库以及他们的 Homebrew tap 的管理员和推送权限，此外还拥有对其他私有仓库（包括特定客户仓库）的读写权限。
代理在找到 Baseten 镜像仓库后，在 Docker 构建历史中发现了该令牌。
我不禁好奇，如今有多少这类由代理驱动的安全漏洞利用（即由恶意行为者驱动）是我们没有听到的，令人担忧。
- aatd86
这对 Strix 来说是很好的营销，对 Baseten 来说则相当糟糕。
我不认为有人能编出更好的故事来宣传自己的安全产品。
之前不知道 Strix，但我现在要去查一下。
可能会把它加入我的技术栈。
- SaucyWrong
作为一名安全软件工程师，我非常重视并拥有丰富的此类披露经验。在我之前工作的两家 B2B 公司，我也会亲自与想要对我们进行红队测试（在获得批准和交战规则下）的潜在客户安全团队合作。
这是一次有价值的披露，但我对两件事有疑问：
a) 决定将 Strix 针对潜在供应商域名运行，是否是事先协商好的？
b) 如果 a) 的答案是“否”，那么很明显，虽然 Strix 希望确保他们的客户仅将其运行在他们拥有的域名上（完全合理），但他们对自己使用的标准却有所不同。
我不确定，我习惯于通过漏洞赏金计划等渠道收到来自任何普通人的披露，但在潜在客户让他们的代理黑客放手去干之前，发个礼貌的通知似乎会更好。
编辑：修正拼写错误。
- codemog
这合法吗？我知道，即使我没有进去偷东西的意图，我也不能试图闯入邻居家，哪怕只是撬开锁。
- nrmitchi
无论是否有效，一家安全工具公司利用真实的客户/供应商作为营销活动，总让我感到不舒服。这个“故事”本可以讲述而不必直白地点名他们的“受害者”。
如果这是一个复杂的多步骤利用，情况会不同，但语气更接近于“看看 Baseten 搞砸得多离谱！”。
Strix 此时也越界了：
> Strix 决定拉取一个镜像，看看里面有什么。
当你开始主动外泄数据并查看它时，你就已经越过了白帽的界限。一旦你开始使用从外泄数据中获得的凭证，并开始列出和探查内部系统，你就远远越界了。
听着，我理解，他们的产品是“旨在”用于自测，因此假设挖掘是安全的。毕竟，这是自我检查。这正是为什么将其指向第三方是不负责任的，甚至处于违法边缘。即使他们获得了“许可”，我也怀疑该许可是否延伸到了“如果你能的话，也搜索和/或下载我们的仓库”。
整体语气不够专业。诸如（加粗部分）“将如此多的访问权限留在一个可公开下载的镜像中，简直是疯了”这样的陈述。大家都心知肚明，这种措辞仿佛这是一个故意的决定。
由那些主动贬低他们本应“帮助”的人的团队开发的安全工具，感觉不对劲。
编辑：为了澄清我关于“拉取仓库”的观点，这篇帖子包含了关于目的和功能的描述 o […]