我们在25分钟内获取了Baseten生产GitHub的管理员访问权限

# 我们本想用 Baseten 做推理，结果却拿到了 Baseten GitHub 仓库的管理员权限 来源：https://www.strix.ai/blog/baseten-harbor-github-pat-takeover **我们差点就把自己的数据和客户数据托付给 Baseten 了。为确保安全，我们先运行了 Strix 检测他们的安全性。约 25 分钟后，它就拿到了一个具有内部仓库级管理员权限的实时 GitHub 令牌。** 我们开发了 Strix（https://github.com/usestrix/strix），一个自主黑客智能体，这意味着我们当然需要（廉价且快速的）推理服务。我们正在评估各种选择，而 Baseten 是显而易见的选项之一。这是一个优秀的产品，估值达 130 亿美元（https://www.baseten.co/blog/announcing-our-series-f/），许多重要企业都依赖它。 但是……我们是一家安全公司。在向第三方提供我们的数据、模型或代码之前，我们会先扫描他们。我们宁愿在开始依赖某项服务之前就发现问题并帮助修复（我们几乎对所有供应商都这样做，且经常能发现严重问题）。 于是……我们将 Strix 指向了 `\*\.baseten\.co`，让它在无凭证或源代码的情况下运行。 它返回了一个用于 `basetenbot` 的活跃 GitHub 个人访问令牌。该令牌拥有**对 Baseten 主产品仓库、驱动其集群的 GitOps 仓库以及他们的 Homebrew 仓库的管理员和推送访问权限**，同时还包括对其他私有仓库（包括按客户划分的特定仓库）的读写权限。 镜像构建日期为**2023 年 3 月**，而当我们于 2026 年 7 月发现时，该令牌仍然有效。 但在深入细节之前，我们要向 Baseten 的安全团队表示敬意。他们确认了该问题的严重性，锁定了注册中心项目，并于次日下午更换了令牌。他们处理得非常专业且迅速（这种情况通常并非如此）。 ## Strix 是如何发现的 Strix 像任何优秀的渗透测试一样开始：侦察。很多时候，基础设施上最严重的漏洞可能出现在你忘记的某个子域服务上（这就是为什么我们总是建议在拥有代码访问权限的测试之外，进行黑盒测试）！因此 Strix 枚举了主机，查阅了证书日志，映射了整个攻击面。最终，它在 `gcp\-us\-east4\-zlw\.registry\.baseten\.co` 发现了一个 Harbor 注册中心。 Harbor 存储容器镜像，并将仓库分组到项目中。其中一个项目是公开的。在没有任何令牌或认证的情况下，Strix 就能列出仓库、获取匿名拉取令牌，并下载实际的镜像清单和层数据。这包括一个名为 `baseten/baseten\-app` 的镜像。 此时，简单报告一个暴露的注册中心然后继续前进很容易。但公司是故意发布镜像的，而 Strix 从不想报告误报。重要的问题是这些暴露的镜像有什么影响。 Strix 决定拉取一个镜像看看里面有什么。以下是 Strix 运行中的那部分内容（是的，智能体自身的文字听起来像 AI，原因显而易见）： **Harbor 暴露影响审查** **思考** 如果这些 Harbor 项目本不应公开，那么这就是真正的暴露，而非元数据噪音。关键在于这一链条：枚举公开项目、读取制品元数据、生成一个针对 `repository:baseten/baseten\-app:pull` 范围的匿名 `service/token`、拉取清单，然后通过签名的存储重定向获取层数据。这证明了真实的匿名拉取访问权限。要让分类处理认真对待此事，需要从拉取的镜像中证明一件事：专有代码、内部二进制文件、硬编码凭据或内部主机名。 第一个有希望的线索是在 `baseten/baseten\-app` 中发现的一对 AWS 密钥。Strix 尝试了一个只读的 `sts:GetCallerIdentity` 调用，该调用会告诉你凭据属于哪个账户。响应是 `InvalidClientTokenId`。 那个密钥已失效，于是 Strix 继续寻找。 ## 然后，一个真正有效的令牌 它拉取了层数据，运行了 TruffleHog (https://github.com/trufflesecurity/trufflehog)（向我们开源安全界的朋友们致敬！），并直接检查了镜像配置。然后它就在那里：一个经典的 GitHub 个人访问令牌，位于 `history\[\].created_by` 中。 我不是 Docker 运行时专家，但幸运的是 Strix 是（得益于它几乎掌握了人类的所有知识）。因此它知道该字段记录了构建步骤是如何创建的。在这个例子中，它包含一个 `RUN` 命令，其中 `GITHUB_TOKEN` 的值被直接展开。 Strix 使用该令牌向 GitHub 发送了一个只读的 `GET /user` 请求，结果……**成功了**。返回 `200`，账户名为 `basetenbot`。 Docker 构建历史中的令牌，随后 GitHub 确认其为 basetenbot。凭据已做遮蔽处理。(https://www.strix.ai/baseten-blog/token-match-redacted.png)Docker 构建历史中的令牌，随后 GitHub 确认其为 basetenbot。凭据已做遮蔽处理。点击查看完整图片。注意令牌被发现的位置。据我了解，Docker 镜像有文件系统层，但它也有一个包含镜像及其构建历史信息的配置。该配置可与镜像一起下载。如果构建历史中仍然保留着令牌的另一份副本，那么清理凭据文件就无济于事。 而这个令牌在三年多后仍然有效。 ## 那么，basetenbot 能做什么？ 任务尚未完成。一个有效的令牌很有趣，但显然权限更重要。这个令牌可能有 0 权限，因此影响为 0。于是 Strix 检查了该账户及其组织成员关系。GitHub 返回了 `X\-OAuth\-Scopes: repo`，且该账户属于 `basetenlabs`。 GitHub 为 basetenbot 返回了 repo 范围，并列出 basetenlabs 为其组织。(https://www.strix.ai/baseten-blog/github-account-and-scope.png)GitHub 为 basetenbot 返回了 repo 范围，并列出 basetenlabs 为其组织。点击查看完整图片。然后它再次使用只读请求检查了单个仓库的权限： | 仓库 | 访问权限 | |----------------------|------------------------------| | `basetenlabs/b***` | **`admin: true`**, `push: true` | | `basetenlabs/f***` | **`admin: true`**, `push: true` | | `basetenlabs/h***` | **`admin: true`**, `push: true` | | `basetenlabs/r***` | 私有仓库，读写权限 | | `basetenlabs/b***` | 私有仓库，读写权限 | | `basetenlabs/t***` | 私有仓库，读写权限 | | `basetenlabs/b***` | 私有仓库，读写权限 | **在一个公开可下载的镜像中留下如此巨大的访问权限，简直令人难以置信。** `basetenlabs/b***` 是他们的产品。拥有此令牌的人对推理平台的主源代码仓库拥有管理员和推送权限。他们可以篡改其他公司赖以运行模型的代码。我们正考虑将自己的代码和模型发送给这家公司，而这正是我们首先要进行此类检查的原因。 `basetenlabs/f***` 可能更可怕。这是他们的 GitOps：该仓库包含集群的期望状态，并将该状态应用到基础设施。在此处的管理员权限，为从泄露的构建令牌到生产基础设施变更创造了一条路径。 `basetenlabs/h***` 是他们的 CLI 如何安装到开发者机器上的。篡改分发渠道可能使其成为针对安装 Baseten 工具的人员的供应链攻击。 然后还有 `basetenlabs/f***`。该私有仓库的目录列表显示了一个顶层的 `customers/` 目录，其中包含一个又一个以 Baseten 客户命名的子目录。 此时，我们已有足够的信息进行报告，并确信这不是误报。我们没有克隆客户仓库、推送任何内容或更改任何配置。我们到此为止，并立即撰写了披露邮件。 ## 令牌是如何出现在那里的？ 构建历史有时间戳。包含令牌的步骤运行于**2023 年 3 月 3 日**。这是一个旧的构建凭据，当我们在 2026 年 7 月测试时，它仍然拥有所有这些权限。 根本原因相当常见。构建需要从 GitHub 获取私有依赖项，因此有人将令牌作为构建参数传递进来。相关模式如下： ``` ARGGITHUB_TOKEN RUNGITHUB_TOKEN=${GITHUB_TOKEN}bash \-c'\\ if [[ "${GITHUB_TOKEN}" != "" ]]; then \\ git config \-\-global \-\-add \\ url."https://${GITHUB_TOKEN}@github\.com/".insteadOf "git@github\.com:"; \\ fi' ``` 我能理解一个人是如何写出这个的。你需要一个私有依赖项，传入令牌，Git 进行认证，构建就能成功。但 Docker 可以将该构建参数记录在镜像的元数据和历史中。在这个案例中，它记录了实际的令牌值。Docker 明确警告过这一点 (https://docs.docker.com/build/building/variables/)。 这种模式还有第二个问题：`git config \-\-global` 会将带认证的 URL 写入 Git 的配置文件。即使你更改令牌进入构建的方式，你仍然需要避免将其保存到镜像中。 修复方法是使用 BuildKit secret 挂载 (https://docs.docker.com/build/building/secrets/) 和临时认证，以避免凭据持久化。然后检查镜像的层和历史记录。并且撤销旧令牌！更改 Dockerfile 对已经被人下载的镜像没有任何作用。 ## Strix 自主完成了什么 Baseten 拥有响应迅速的安全团队，并且已经在使用 AI 安全工具 (https://www.runsybil.com/blog/runsybil-raises-40m-to-build-the-ai-native-platform-for-offensive-security#:~:text=Cursor%2C%20Turbopuffer%2C%20Notion%2C-,Baseten,-%2C%20and%20Thinking%20Machines)。尽管如此，当我们发现这个来自 2023 年构建的令牌时，它仍然对其产品和部署仓库拥有管理员访问权限。 人们很容易关注应用程序和源代码仓库，而忘记了一个旧的容器镜像。即使你扫描了镜像中的文件，你仍然需要检查其构建历史记录。 我喜欢这次扫描的地方在于 Strix 持续追踪了发现。它发现了一个注册中心，检查是否真的能拉取镜像，测试了一个凭据并发现已失效，然后在构建历史中找到了另一个凭据，并检查了那个凭据能访问什么。 我们没有告诉它去查找 Harbor，也没有给它任何关于令牌的提示。**它在大约 25 分钟内自主完成了整个流程。** 这就是我们开发 Strix 的原因。AI 驱动的攻击在过去几周变得异常可怕，我们相信保护自己的唯一方法是在坏人之前，不断攻击自己以发现这些问题（因为问题总会存在）。 ## 披露 Baseten 处理得很好。时间线如下： - **7 月 13 日，晚上 11:10：** 我报告了有效的 `basetenbot` 令牌、公开的 Harbor 项目以及仓库权限。 - **7 月 14 日上午：** Baseten 将 Harbor 项目设为私有。我指出令牌本身仍然有效。 - **7 月 14 日，下午 4:34：** Baseten 安全团队的 Anton 确认该问题为关键问题，并表示他们已将 Harbor 项目设为私有并轮换了令牌。他还要求我们安全删除已拉取的镜像。 - **7 月 14 日，下午 5:05：** 我们确认已删除，并提供了来自同一扫描的两个低严重性发现。 - **7 月 17 日：** Baseten 关闭了剩余发现。 - **9 月：** 我们通知 Baseten 我们计划公开披露此发现，并向他们发送了本文的草稿。 他们还送给我们一些 T 恤和卫衣，以感谢我们发现了这个关键漏洞。 ## 去检查你的旧镜像 如果你运行容器并使用 GitHub，这值得在你自己的基础设施中检查： 1. 查看有人在不登录的情况下能拉取什么，包括旧的标签和你很久没想过的项目。 2. 使用 `docker history \-\-no\-trunc` 读取构建历史，或检查配置层的 `history\[\].created_by` 字段。也要检查各层。 3. 将密钥从构建参数中移除。使用 secret 挂载，并确保消费这些密钥的命令不会将它们写回镜像中。 4. 检查你的构建令牌实际能做什么。获取依赖项需要对该依赖项的读取权限。给你产品和部署仓库的令牌管理员权限会使泄露更加严重。限制权限并设置有效期。 并在你自己的系统上运行像 Strix 这样的工具。整个扫描的开始是因为我们想使用一个推理服务提供商。我们提供了一个域名，就得到了一个 Baseten 在次日早上就能处理的关键漏洞。 AI 攻击者可以遵循同样的路径。如果一个智能体能在 25 分钟内在一个旧镜像中找到一个有效的管理员令牌，那么你会希望你的智能体先找到它。