在过去的6年里，使用Travis CI的私人Github存储库很容易受到特权升级漏洞的攻击。在某些配置下，具有只读的Github仓库访问权限的攻击者可以通过提交请求来更改代码。

本文所提及的漏洞已经报告给了Travis CI安全团队，并且已经修复。

介绍

大约两个月前，专业服务部门的同事Dane Powell发来消息，要求我帮助他确认Travis CI允许他访问私人SSH密钥的问题。我查看了构建过程，并确认在Travis CI容器上运行构建过程时，可以访问公钥和私钥对。

研究其他的存储库和构建过程，很明显，SSH密钥只存在于私人的Github存储库中。这是有道理的，因为Travis CI可以简单地通过HTTP克隆一个公共的repo，而无需授权。

有了这些信息，我开始在脑海中构造一个有趣的攻击过程。

Github，Pull Requests和Travis CI

如果你还不熟悉使用Travis CI和pull请求的持续集成测试方法，那么这里有一些你需要了解的背景知识。

Github是互联网上最常用的代码存储服务之一。其中一个帮助它获得普及的功能是拉取请求的概念。开发人员可以创建一个项目（公共或私人），并允许其他开发人员访问该项目的代码。如果另一个开发人员发现问题或想要将新功能添加到项目中，则更改代码的唯一方法是提交一个请求。这要求项目所有者要从其他开发人员那里获取新的代码更改。使用这种方法，项目所有者可以仔细检查建议的变更，并根据需要批准或拒绝变更。

在一个私人的Github项目中，开发者必须明确地指定了访问权限后才能访问它。这种访问可以以只读或读/写的形式出现。除非开发人员正在与项目所有者一起帮助维护项目，否则绝大多数开发人员只能获得只读权限。这允许项目所有者充分利用上述的拉取请求工作流程。

Travis CI是一个持续集成服务，与Github紧密集成，并允许项目所有者在创建拉取请求时针对任何提议的代码更改运行自动化测试。这可以使得代码经过更改通过或失败评级的过程，并有助于减少人为错误，如错别字和代码格式的问题。它甚至可以测试项目的功能。

“Pull Request灾难”

一旦我知道Travis CI创建的用于审查一个拉取请求的环境能够访问并写入Github存储库所需的SSH密钥，那么整合一个漏洞就很简单了。（开发人员会认识到，在这种情况下，“PR关系灾难”具有双重意义：公共关系混乱，是的，但也是一个“拉取请求”的问题，因为拉取请求是攻击的方法。

要利用这个漏洞需要满足3个条件：

· 一个私有的Github存储库

· 攻击者需要被授予对存储库的读取权限

· Travis CI被配置为在拉取请求上运行

问题的关键在于Travis CI配置步骤是存储在GitHub存储库之内的。这意味着一个拉取请求不仅可以对项目进行代码更改，还可以改变Travis CI的实际操作。把它和SSH密钥放在一起意味着一个拉取请求可以让Travis CI容器在任何分支上写入任何东西到Github仓库中。这完全超越了拉取请求的工作流程和授予攻击者的只读访问所能做的事情。

创建一个拉取请求，添加类似于.travis.yml的内容，导致主分支被更改。

before_script：

· - git checkout master
· - echo "# This is a direct change to README.md" >>      README.md
· - git add README.md
· - git commit -m "Commit from TravisCI"
· - git push origin master

这个例子只是在README.md文件中增加了额外的文本，但是显然这可以做一个恶意的改变，比如在php应用程序中增加一个后门程序。

漏洞修复

我在9月底向Travis CI发送了一封电子邮件来描述这个安全问题。Travis CI安全团队迅速作出了回应，并开始着手解决问题。

他们最终的解决方案是批量更新所有已有的密钥为只读访问权限，并且更新了集成过程，使用Github提供的新方法为所有的新项目创建只读密钥，这个方法在Travis CI最初创建时不存在。这在Travis-CI博客上有详细介绍。

这篇博文写道，Travis CI团队认为“这个漏洞不太可能被利用”。虽然我没有理由怀疑他们的判断，但我会建议你审查满足攻击条件的任何Github项目的提交请求。如果一个项目有很多开发者可以访问，那么这种情况更加需要重视。