持续集成服务(CI)漏洞挖掘

原文链接：https://edoverflow.com/2019/ci-knew-there-would-be-bugs-here/

在挖漏洞的时候，熟悉供应商和公司所依赖的技术至关重要。引起我们注意的一个特别有趣的环境是各种开源项目使用的流行集成，

主要是作为其开发生命周期的一部分。包括Travis CI，Circle CI和GitLab CI在内的持续集成服务（“CI服务”）的一些主要示例对于我们

来说是非常有益的，因为它们是bug赏金猎人的目标。

我们开始自动从这些CI服务中获取和搜索大型数据集。这篇技术文章将涉及我们面临的众多挑战，我们如何减少搜索中的误报数量，显着的发现，

最后列出我们在此过程中采取的一些技巧。

关于这一研究工作的团队包括贾斯汀·加德纳（@Rhynorater），Corben狮子座（@hacker_）和EdOverflow（@EdOverflow） -由卡里姆·拉哈尔（一些测试和有益的建议@KarimPwnz），@streaak，@ d0nutptr和BBAC。

持续集成服务简介

持续集成（CI）是提交代码更改并自动构建和测试每个更改的实践。如今，很少有人偶然发现在开发周期的某个阶段没有使用持续集成服务的开源项目。各种服务提供简单的设置配置步骤和漂亮的界面，可以持续快速测试和构建代码。

该security.txt项目，例如，使用特拉维斯CI只要提交代码推到建立新的文件草案。

这允许团队快速确定对规范的任何进一步更改是否可能在编译时破坏Internet草稿kramdown-rfc2629-

一种工具使得人们可以在Markdown中编写所有内容，然后将其转换为XML2RFC XML标记。

信息收集

读者过去所要求的是有一个指定部分，介绍作者如何提出研究主题，例如我们在这里展示的工作类型。本节将有希望说明这个想法最初的起源。

本文的所有作者都有很多在GitHub上开源项目的经验，并且多年来学习了简化开源项目维护者开发过程的技术。

GitHub在https://github.com/marketplace上提供了大量集成，其中一个特定类别脱颖而出：[“持续集成”](https://github.com/marketplace/category/continuous-integration)。

这就是我们发现由于许多开源团队在开发过程中争取完全透明和开放的方式，项目对于在持续集成平台上隐藏构建日志数据犹豫不决。不可否认

像Travis CI这样的集成确实提供私人资料作为travis-ci.com的高级功能，但在我们的研究中，绝大多数项目似乎只使用公共实例

travis-ci.org - 请注意“.org “顶级域名。

值得注意的是，持续集成服务过去已成为赏金猎人和第三方敏感信息的目标，如“在Travis CI构建日志中暴露的HackerOne员工的GitHub个人访问令牌”和“API下的”攻击“ Travis CI事件报告：

“我们目前正在对我们的公共API进行分布式攻击，我们认为这些攻击旨在揭示GitHub身份验证令牌。应对策略正在讨论中，我们将进行相应的更新。“

Travis CI（2015年9月）

因此Travis CI等平台引入了内置机密检测，以防止敏感信息的意外泄露，如下所示。[1]

Travis CI [secure]在运行时使用关键字替换潜在的敏感信息。

为了防止这些组件发生泄漏，我们会自动过滤运行时超过三个字符的安全环境变量和标记，从而有效地将它们从构建日志中删除，[secure]而不是显示字符串。

自动化检测

手动接近大型攻击面（例如Travis CI提出的）将是一项非常繁琐的任务。因此，我们必须使用这些CI供应商提供的可用API文档，并开发工具来自动快速获取构建日志。

为了更好地说明从bug赏金计划到广泛的数据集以进行进一步调查的过程，我们将使用Travis CI的API文档作为示例。

首先是获取bug赏金计划的GitHub组织，有多种方法可以做到这一点，但为了获得最佳效果，谷歌搜索“公司名称”和“GitHub”就可以完成这项工作。

接下来，我们必须检查GitHub是否在Travis CI上。为了使这个过程更顺畅，我们使用了一个浏览器书签，它使用GitHub将我们从GitHub重定向到Travis CI。

javascript:window.location="https://travis-ci.org"+window.location.pathname;

书签将从GitHub页面重定向到Travis CI

如果目标存在于GitHub上，我们就会访问Travis CI上的项目API端点并检索所有项目的列表。

https://api.travis-ci.org/owner/%s/repos?limit=100&offset=%d

Travis CI的API区分大小写; 由于，bookmarklet需要确保你在发出API请求时使用正确的语句要收集构建日志的内容，我们需要点击构建ID API端点然后/log.txt。

1. https://api.travis-ci.org/repo/%s/builds?limit=100&offset=%d
1. https://api.travis-ci.org/job/%d/log.txt

现在属于目标的所有构建日志的内容都存储在本地，我们可以开始grepping。由于我们正在分析的数据大小，我们ripgrep在本地筛选日志时采取了措施。

$ rg -ia "$1" -j 12 --no-filename --no-line-number --pretty

除了bug赏金计划的GitHub帐户，作者还收集了属于GitHub组织所有成员的构建日志。事实证明，有些成员在他们的帐户上运行构建而没有意识到他们的秘密在构建日志中暴露。

1. #!/bin/bash
1. 
1. users=$(curl -s -H "application/vnd.github.hellcat-preview+json" -H "Authorization: token $GH_TOKEN" https://api.github.com/orgs/"$1"/members | jq -r .[].login);
1. 
1. while read -r hehe; do 
1. secretz -t "$hehe"; 
1. done <<< "$users"

该项目背后的团队决定不发布任何为获取构建日志而构建的工具，因为我们不希望直接对CI平台性能的任何中断负责。这种写作将不可避免地

引起一些CI平台存在的大型攻击面的关注; 因此，作者想提醒读者，在使用平台的API时，请注意不要立即接收每个端点的大量请求。

我们非常谨慎，不会在整个过程中取消任何服务。

漏洞发现

总的来说，最有影响力的发现主要是GitHub访问令牌泄漏。在本节中，我们将介绍我们团队提交的四份值得注意的报告。

在公共程序中点击员工帐户的Travis CI构建日志时，我们发现了一个GitHub访问令牌，具有对GitHub组织的读写权限。

此令牌将允许我们将代码推送到GitHub组织下列出的任何存储库。根据他们的HackerOne “Program Statistics”，该计划授予我们迄今为止最高的奖金。

为扩大我们漏洞的影响范围，我们考虑了多个平台。在2013年的私人Bugcrowd计划的Travis CI构建日志中，我们发现了一个GitHub访问令牌，

并获得了P1严重性支付 - Bugcrowd上可能的最高严重性分数。[2]

我们报告调查结果的所有供应商最令人惊讶的回应是Discourse的bug赏金计划。Karim Rahal发现了一个员工的GitHub访问令牌，

该令牌具有对Discourse GitHub组织下所有公共存储库的读写访问权限。为了证明这个问题的潜在影响，我们将一个无害的文件推送到该组织

最不活跃的存储库之一，以免引起太多关注。随后从存储库中删除了该文件。

话语授予卡里姆最低可能的128美元奖金。我们要求进一步确定赏金金额，但我们尚未收到Discourse团队的回复 - 这是60天没有回复。[3]

另一个关键错误是在HackerOne上的公共加密货币程序中发现的。该程序在Travis CI中使用秘密变量来创建SSH密钥。

此配置的详细信息可在此处和此处找到。在挖掘了数千个日志后，Justin Gardner写道，工具检测到以下行：

-----BEGIN RSA PRIVATE KEY-----

开发人员cat deploy_key在他们的CI配置文件中添加了在日志中输出SSH密钥的文件。使用SSH密钥，

攻击者可以登录到程序基础结构中并且部署多个服务器。由于漏洞涉及到服务器，因此获得了1000美元的奖励。

小技巧

通常，export构建日志中的语句的简单grep 将是一个很好的起点。该export命令用于在日志提示中设置环境变量，因此可以公开敏感信息。

$ rg -ia "export " -j 12 --no-filename --no-line-number --pretty

当然，不应仅限于使用该export命令设置的变量; 将搜索术语精炼为 “token”, “key”, “password”和“secret”可以帮助发现特定的泄漏。

为了减少误报的数量，我们建议搜索词中追加"="和":"

我们鼓励读者使用[secure]关键字创建所有变量的列表，然后在所有项目中使用这些变量名称进行搜索。这将使用常见的变量命名约定帮助您

查找不安全的敏感数据实例。Karim Rahal收集[secure]了5,302,677个构建日志中的变量，其中最常见的50个可以在下面看到。

完整列表可以在这里找到。

此外，设置连续监控您最喜欢的bug赏金计划的CI构建，并在每次团队向GitHub推送新提交时运行您的工具，这是在团队在行动之前实时捕获暴露的秘密的好方法。

不要局限于keys 和 tokens; CI平台也是侦察信息的重要来源。通过日志筛选以查找属于目标的隐藏端点和URL。

检查GitHub上的CI配置文件，以确定目标使用的CI集成。可能还有其他CI平台在这篇文章中没有涉及秘密暴露的内容。

我们在grep过程中包含的一个有趣的任务是查找通常与缺失或损坏的依赖项相关联的字符串和错误消息。由于缺少npm包，

这有时可以通过在远程注册表中声明包名来导致代码执行，如https://hackerone.com/reports/399166中所示。一些示例错误消息包括：

“不在npm注册表中。”（npm）

“没有匹配的发行版”（PyPI）

“找不到有效的宝石”（RubyGems）

结论和进一步的研究

这项研究帮助我们更好地了解了连续整合服务所呈现的大型攻击面 - 几乎隐藏在普通视线中 - 并且当bug赏金时已经证明是非常富有成效的。

由于本研究中包含了相当有限的平台数量，未来的研究和项目可以考虑进一步覆盖CI平台和集成。

我们赞赏Travis CI等平台，允许用户在其日志中隐藏敏感的环境变量。在我们看来，这是朝着正确方向迈出的一步，以防止我们遇到的安全泄漏类型。

这项工作不仅为我们提供了许多成功的bug赏金故事和有效的发现，而且还表明，与此项目一起看到的协作可以在bug赏金狩猎的同时取得很大进展。