Travis CI API 漏洞暴露了数以千计的用户访问令牌

在我们最新的研究中，Nautilus 团队发现数以万计的用户令牌通过 Travis CI API 暴露，任何人都可以访问历史明文日志。超过 7.7 亿免费层级用户的日志可用，您可以从中轻松提取令牌、机密和其他与流行的云服务提供商（如 GitHub、AWS 和 Docker Hub）相关的凭证。攻击者可以使用这些敏感数据发起大规模网络攻击并在云中横向移动。

我们向 Travis CI 披露了我们的发现，Travis CI 回应说这个问题是“设计的”，所以所有的秘密目前都是可用的。所有 Travis CI 免费层用户都有可能暴露，因此我们建议立即轮换您的密钥。

我们还向各自的服务提供商报告了我们的调查结果。几乎所有人都惊慌失措，迅速做出反应。一些人发起了广泛的密钥轮换，而另一些人则证实我们的发现至少有 50% 仍然有效。一些供应商甚至为我们提供了奖励以披露调查结果。

在本博客中，我们介绍了我们的研究结果，这些结果揭示了云中的横向运动流。

Travis CI API：过去和当前的研究

这个问题过去曾向 Travis CI 报告过，并在 2015 年和 2019 年在媒体上发表过，但从未完全修复。2015 年，Travis CI 发布了一份关于事件报告的通知，指出：

“目前正在对我们的公共 API 进行分布式攻击，我们认为该攻击旨在泄露 GitHub 身份验证令牌。对策正在实施，我们将相应更新。”

当 Travis CI 解决了这个问题时，他们发表了：
“最近引入的自适应速率限制和阻塞一直在正确执行。”

2019 年，一组研究人员（Justin Gardner、 Corben Leo和EdOverflow）撰写了一篇关于 Travis CI API以及如何利用它来提取令牌、机密和凭证的博客。他们的研究集中在漏洞赏金以及黑客如何利用 Travis CI 日志中的秘密。

在我们的研究中，我们复制了他们的一些步骤，但也添加了一些其他步骤，并对原始数据进行了深入分析。我们的目标是了解 CI 平台上的数据是否可用于发起网络攻击，以及我们是否可以观察到云中合理的横向移动。

持续集成、持续部署和访问令牌

如今，持续集成 (CI) 和持续交付/部署 (CD) 已成为现代开发和云原生应用程序管道的主要部分。对于应用程序的每次更改，都会定期构建、测试代码并将其合并到共享存储库中。因此，这些环境通常存储许多秘密，例如访问令牌，以自动到达云或管道中的其他部分。在某些情况下，这些访问令牌被设置为具有读取、写入、管理等的高权限。如果受到损害，此类访问令牌可能导致数据泄露、帐户接管，甚至跨多个云帐户横向移动。

Travis CI 研究：主要步骤

现在我们知道了 CI/CD 和访问令牌是什么，让我们深入研究我们的研究细节。

我们的目标是分析 CI 管道，以更好地了解使用 CI 服务可能产生的风险水平。我们专注于Travis CI，建立在现有研究的基础上，即其 API 如何以明文形式向未经身份验证的匿名用户呈现历史日志（最多可追溯到 7 年前）。

获取日志

我们想检查云中潜在的攻击媒介。在我们的研究中，我们使用了以下 API：

https://api.travis-ci.org/v3/job/[4280000-774807924]/log.txt
比如
https://api.travis-ci.org/v3/job/5248126/log.txt

根据Travis CI API 手册，我们发现获取明文日志的有效 API 调用将需要日志编号。在这种情况下，我们可以轻松地应用枚举脚本来获取零到无穷大之间的所有可用日志。这对其他供应商来说并不容易，因为他们需要在 URL 中提及应用程序 ID 或客户 ID（或两者），这使得在日志上运行枚举变得困难。

在我们的研究中，我们检查了各种 API 调用来获取日志。我们使用了上述研究中的那个。但是，我们还在https://api.travis-ci.org/logs/XXX中通过文档化 API 找到了另一个 API 调用，它允许我们访问以前无法访问的新日志（可能已删除历史日志）

“XXX”标记了一个特定的日志编号，范围在一到数亿之间。此 API 调用旨在通过指向 Travis CI S3 存储桶来获取归档日志，同时为该存储桶生成一次性令牌。运行一些 API 调用后，我们推测此方法允许未经身份验证的匿名用户获取所有日志。

我们发现在发送此 API 调用时，您可以访问零星的日志：

https://api.travis-ci.org/logs/1
重定向到： https://s3.amazonaws.com/archive.travis-ci.org/jobs/4670478/log.txt ?X-Amz- Expires =30&X-Amz-日期=202206...

可以使用相应的日志编号从此 API 获取相同的日志：

https://api.travis-ci.org/v3/job/4670478/log.txt

有趣的发现是我们可以通过 API https://api.travis-ci.org/v3/job/<log_number>/log获取以前不可用的日志。现在，我们也可以访问和分析这些日志并在其中找到秘密。

示例：https ://api.travis-ci.org/logs/6976822重定向到： https ://s3.amazonaws.com/archive.travis-ci.org/jobs/13575703/log.txt?X-Amz -Expires=30&X-Amz-Date=202206…

通过第二种方法访问 Travis CI 日志

无法通过此 API 获取具有相应日志号
https://api.travis-ci.org/v3/job/13575703/log.txt 的相同日志

通过第一种方法无法访问 Travis CI 日志

我们进行了一些实验，发现最早的日志来自 2013 年 1 月，最新的日志来自 2022 年 5 月，日志的有效范围在大约 4,280,000 到 774,807,924 之间。这意味着可能有大约 7.7 亿条日志被暴露。

从日志中提取凭据

作为下一步，我们制作了两个随机样本。首先，我们随机抽样了 20,000 条日志，发现虽然并非此范围内的所有日志都可用，但有些以明文形式返回，有些则显示访问令牌和凭据。然后，我们对大约 800 万个请求（大约 1%）进行了另一个样本，在我们清理了数据之后，我们最终在这些日志文件中得到了大约 73,000 个令牌、机密和各种凭据。这些秘密与各种云服务相关联，包括 GitHub、AWS 和Docker Hub。下面是一些例子：

笔记本的屏幕截图显示了用户、Travis CI API 链接、项目明星、密钥和秘密

Travis CI 减慢了 API 调用的速度，从而阻碍了查询 API 的能力。然而，在这种情况下，这还不够。熟练的威胁参与者可以找到绕过此问题的解决方法。此外，历史日志中的部分数据被屏蔽；您偶尔会看到一个字符串“[secure]”，其中曾经有一个明文秘密。

毫无疑问，Travis CI 努力混淆日志中显示的秘密和令牌。事实上，在我们的研究过程中，日志中的大多数令牌都被审查了。此外，Travis CI 提供了有关如何避免泄露秘密的建议，例如手动删除构建日志和定期轮换秘密。

然而，结合通过 API 访问日志的便利性、不完整的审查、访问“受限”日志，以及对 API 的限速和阻塞访问的弱流程，再加上大量潜在暴露的日志，导致关键情况。

尽管如此，在日志中打印秘密、密码和令牌有很多约定，其中大多数仍然以明文形式存在。例如，我们发现在很多情况下“ github_token”被屏蔽了，没有泄露任何秘密。然而，我们发现了这个令牌的大约 20 种变体，它们没有被 Travis CI 掩盖：

使用 Aqua Trivy 扫描日志以查找机密

即使开发人员遵循编码最佳实践，他们有时也会在不知不觉中发布密码等硬编码秘密，或使用可能引入它们的第三方代码和容器映像。使用 Trivy Open Source，您可以轻松扫描目标以查找硬编码的秘密。Trivy 会扫描任何容器映像、文件系统或 Git 存储库以查找暴露的密码、API 密钥或令牌。我们使用 Trivy 来扫描我们获得的日志。

Trivy 扫描结果的屏幕截图，显示文件中的机密检测

我们的数据显示，在 42% 的情况下，我们可以在随机 API 调用之后获得有效日志，这意味着对于每 100 次 API 调用，我们最终可以获得 42 条有效日志。从这些日志中，我们可以提取秘密。

在整理了这些秘密之后，我们发现了很多各种环境的访问令牌。这里有一些例子：

对 GitHub 的访问令牌，可能允许对代码存储库进行特权访问
AWS 访问密钥
一组凭据，通常是电子邮件或用户名和密码，允许访问 MySQL 和 PostgreSQL 等数据库
Docker Hub 密码，如果未激活多因素身份验证，可能会导致帐户被接管

与暴露的 Travis CI 日志中的明文令牌相关联的服务提供者

云中的攻击：几个用例

我们从问自己开始这项研究，“我们如何检测云中的横向移动？” 我们分析了CI/CD环境，那么我们现在如何在其中找到秘密呢？我们惊讶地看到以前通过 Travis CI API 发布的关于明文日志的出版物，并惊讶地发现在向 Travis CI 披露问题后这仍然是可能的。

利用我们研究期间获得的令牌，我们模拟了一些在云中横向移动的攻击场景。以下是一些关键场景。

用例：云中的横向移动

我们发现了数千个 GitHub OAuth 令牌。可以安全地假设其中至少有 10% 到 20% 是活的，尤其是在最近的日志中发现的那些。我们在云实验室中模拟了横向移动场景，该场景基于以下初始访问场景：

通过暴露的 Travis CI 日志提取 GitHub OAuth 令牌
使用公开的令牌在私有代码存储库中发现敏感数据（即 AWS 访问密钥）
使用 AWS S3 存储桶服务中的 AWS 访问密钥进行横向移动尝试
通过桶枚举发现云存储对象
数据从目标 S3 泄露到攻击者 S3

使用受损令牌在云中模拟横向移动

用例：发现和情报收集

日志通常可能包含受限的敏感信息，例如代码包的名称及其依赖项。攻击者可以收集代码包的名称并查找丢失或有问题的代码包或其依赖项。然后，攻击者可以认领这些代码包并将它们植入包管理器中，从而导致用户下载恶意代码包。

在一些 Travis CI 日志中，我们发现了可以帮助攻击者发现更多资产的 IP 范围。此外，我们还看到了内部域名系统 (DNS) 指示，熟练的攻击者也可以利用这些指示来扩大攻击面。

此外，我们还发现了一些带有访问令牌的 S3 存储桶的 URL。如果网络规则不限制到存储桶的入站流量，这些可能会导致这些特定存储桶的数据泄漏。

用例：使用代码存储库和注册表进行软件供应链攻击

我们发现了数十对特定容器映像注册表的凭据。其中一些可能属于大型组织或流行的开源项目。就其本身而言，这些凭据看起来与安全最佳实践（长密码、大写字符、特殊字符和数字）一致。对于普通的威胁参与者来说，猜测这些密码将是一项挑战。但是，如果这些凭据落入坏人之手，攻击者将能够获得对公共和私有注册表的特权访问。

一种可能的情况是从私人注册中心窃取专有数据。一个更险恶的目标可能是用恶意代码（例如后门或恶意软件）毒化这些容器镜像，以允许访问它们部署的环境。如果是流行的开源项目，这可能会导致旨在感染更广泛社区的更大攻击。

用例：源代码盗窃

2022 年 4 月 15 日，GitHub 发布了严重警告，指出攻击者能够通过窃取的发给 Travis CI 和 Heroku 的 OAuth 令牌访问某些存储库。在大多数情况下，他们发现攻击者只列出了所有用户的组织。然后，攻击者选择性地选择目标并列出感兴趣的用户帐户的私有存储库。最后，攻击者继续克隆其中一些私有存储库。