攻击者是如何攻击持续集成系统Jenkins的
“持续集成（CI）是指团队成员提交更新时自动完成代码的构建和测试的过程。”——Sam Azure Guckenheimer，Microsoft Azure
简介
Jenkins是一款先进的开源自动化服务器，在开发团队中非常流行。根据最近的观察，攻击者已经开始利用众多的Jenkins服务器来部署加密货币挖矿软件了。除此之外，他们还通过Jenkins发动了有针对性的攻击，以维护对开发人员环境的持久访问权限。目前，网络上面已经有文章讨论了如何利用漏洞攻击Jenkins，以及如何通过Web控制台和后续利用工具来维护相应的访问权限。
对于本文来说，我们将侧重于介绍最常见的获取访问权限、维护访问权限和泄露数据的相关技术。CrowdStrike的红队就是利用这些技术对开发环境进行模拟演练的。
定位Jenkins
根据应用场景的不同，定位和识别Jenkins服务器的方法也会有所不同。对于大多数红队来说，Jenkins可以在内部网络的某个地方找到。攻击者可以通过多种方式来获得对这些服务器的访问权限。根据我们的观察，最常见方法是使用针对最近披露的漏洞的利用代码、身份验证插件中的错误配置以及之前获得的登陆凭证。
Java反序列化漏洞
攻击者可以利用Java反序列化漏洞（CVE-2017-1000353），在未打补丁的Jenkins服务器上获得远程代码执行权限。Exploit-db（https://www.exploit-db.com/exploits/41965/）网站上提供了相关的概念验证（POC），经过适当修改就可用于测试该漏洞。
在未使用漏洞利用代码的情况下，攻击者通常利用之前获取的相关凭证或错误配置的Jenkins服务器来获取访问权限。默认情况下，Jenkins是需要进行身份验证的，但这项设置通常会被开发团队所修改，从而导致服务器容易受到攻击，不过，具体情况取决于相关的配置方式。Jenkins支持各种身份验证插件，包括LDAP、Kerberos单点登录（SSO）、SAML等。其中，最常见的错误配置，就是全局安全配置中的匿名读访问委派，具体如下图所示。
在默认情况下，系统并不会启用匿名读取权限，但是，一旦启用的话，攻击者就可以利用它来访问构建历史记录和凭证插件。在某些情况下，有些系统还启用了匿名脚本控制台访问权限，这样的话，攻击者就能够全权使用Java运行时来执行命令了。我们强烈建议关闭对Jenkins的访问权限，尤其是Web控制台，因为配置不当的身份验证插件是攻击者获取Jenkins访问权限，从而发动其他攻击的常见方式。
身份验证插件允许开发团队自定义其环境的登录过程。这些插件会因组织而异，例如，没有Active Directory的组织可能会选择使用Google登录插件。需要注意的是，无论这些身份验证方法是如何实现的，都要严加保护。我们已经观察到有攻击者利用身份验证方法来获取Web控制台访问权限，因此，我们应该针对边缘情况，对这些保护措施进行彻底的安全测试。例如，如果使用Active Directory插件的话，那么，是否所有活动目录用户都对Web控制台进行身份验证呢？如果是这样的话，已获得域凭证的攻击者将能够通过身份验证，从而对Jenkins服务器发动进一步的攻击。
后续利用Jenkins
Jenkins是一款支持各种操作系统的Java应用程序，其中包括Windows、Ubuntu/Debian和Red Hat/CentOS。虽然Jenkins Web应用程序的功能几乎完全相同，但该软件的Windows和Linux安装还是存在一些显著差异的，具体如下所述：
Windows平台
在默认情况下，当该软件安装到Windows平台上时，Jenkins将使用NT AUTHORITY\SYSTEM帐户。但是，我们强烈建议大家修改这个用户帐户，对Windows系统来说，SYSTEM帐户具有全部的权限。一旦获取脚本控制台的访问权限，攻击者就可以轻松地接管整个系统。通常来说，我们建议您使用本地系统上只有有限权限的服务帐户。
Linux平台
在默认情况下，当安装到Linux上时，Jenkins将创建一个服务帐户。在默认情况下，该用户帐户没有sudo或root访问权限，但是，安全人员还是要仔细检查为妙。攻击者一旦获得了脚本控制台的访问权限，他们就会获得与Jenkins服务帐户相同的权限。
脚本控制台
Jenkins脚本控制台是一款基于Web控制台的应用程序，用户可以通过它来执行Jenkins Groovy脚本。攻击者可以利用脚本控制台来全权访问Java，并且可以利用它在Java运行时进程中执行任意操作。最值得注意的是，它具有执行命令的能力，具体如下所示；并且，Linux和Windows的安装都具备这种能力。
利用它，攻击者可以创建beacon、显示文件、对存储的密码进行解密，等等。请注意，使用execute方法时，所有的命令都将作为Java进程（在Windows系统上为Java.exe；在Ubuntu系统上为/usr/bin/Java）的子进程来运行。
在检测恶意的Jenkins服务器活动时，查找可疑的进程树是一个非常有用的方法。例如，通过脚本控制台生成PowerShell命令时，能看到：
有时候，攻击者可能会通过使用内置的Java方法来避免运行C2（command and control），而不是依靠PowerShell进行后期利用。在许多Jenkins攻击案例中，攻击者都会访问文件credentials.xml、master.key和hudson.util.Secret。这些文件负责对机密信息进行加密，在某些情况下，甚至还会存储相关的凭据。master.key文件用于加密hudson.util.Secret文件，该文件用于对凭证插件中的机密信息进行加密处理。credentials.xml文件包含Jenkins用户的加密密码和密钥。
当然，获得这些文件的途径有多种。如果获得了对服务器的SSH访问权限或C2访问权限，则可以直接从服务器复制这些文件并导出。在本例中，攻击者可以使用内置的Java方法，通过下面的Groovy脚本来获取这些文件：
使用上面的Groovy脚本，攻击者能够检索每个文件，而不会产生潜在的恶意子进程。攻击者还可以使用Base64类方法检索二进制格式的hudson.util.Secret文件。同时，还可以通过Jenkins测试实例来了解该脚本的用法。
对于存储在credentials.xml文件中的加密密码，也可以使用下面的脚本，在脚本控制台中直接进行解密：
只要能够访问Jenkins脚本控制台，攻击者就能通过各种方法来获取Jenkins服务器上的各种敏感文件，因此，我们应禁止或限制访问该控制台。
作业的配置/创建
在无法访问脚本控制台的情况下，对于可以查看Web控制台并能调度作业或查看构建历史记录的用户来说，仍有机会获取各种有价值的信息，这具体取决于系统的配置情况。CrowdStrike的红队发现，有些情况下可以重新配置作业但无法创建作业，有些情况下正好相反。
通过查看默认页面，可以利用Web控制台来确定经过身份验证的用户所具有的权限，具体如示例所示。在本例中，用户无需进行身份验证即可配置/创建作业。
获得创建作业的权限后，攻击者就可以在Jenkins服务器上创建本地作业，并使用它来执行命令，进而在控制台输出中查看相应的结果了。如果系统允许用户访问构建历史记录和控制台输出的话，那么任何具有Web控制台访问权限的人都可利用这一点来获取机密信息、源代码、密钥等。所以，我们应严格检查控制台输出和构建历史记录，以查找可能被攻击者利用的敏感信息。
如果需要在具有作业创建权限的Jenkins服务器上执行命令的话，可以创建一个以给定项目名称命名的Freestyle项目。
创建后，可以在该Freestyle项目中配置相关的选项。为简单起见，这里将忽略所有选项，然后，单击“Add build step”。
对于该测试实例，我们将其配置为“Execute Windows batch command”，并运行一些基本的命令，包括添加本地管理员帐户的命令，但是，这些都可以利用Windows批处理文件（.bat）来完成。
单击“save”后，从Web控制台选择“Build Now”选项，以构建新创建的Freestyle项目。
构建完成后，可以在控制台输出上查看输出内容，具体如下所示。
需要注意的是，由于Jenkins服务器配置为允许匿名创建，因此，创建Freestyle项目的用户是未知的。
实际上，获得创建作业的权限的情况下，攻击者所能做的事情与获得脚本控制台访问权限的情况下几乎是一样的，但是，如果攻击者只能重新配置作业的话，情况又会如何呢？即使这些情况下，区别也不大，只不过，这时攻击者必须编辑现有作业并安排构建作业。在下面的示例中，我们将重新配置Freestyle项目“BackupProject”，以输出存储在凭证插件中的机密信息。首先，为可修改项目选择“Configure”选项。
这样的话，攻击者就可以重新配置构建环境，以便在环境变量中存储机密信息和凭证了。之后，就可以在构建步骤中使用这些环境变量并将其输出到文件中了。在这个场景中，攻击者可以将结果输出到全局可访问的userContent文件夹中（C:/Program Files (x86)/Jenkins/userContent/）。
在Windows系统环境中，可以通过%字符来访问这些环境变量；在Unix系统上，可以通过$字符来访问这些变量。
一旦对修改后的项目完成构建，就可以在http://jenkins/userContent/out.txt文件中查看相关结果了。
userContent文件夹是一个特殊的文件夹，其中的内容不受Overall/Read访问之外的任何访问控制的约束。在攻击者可能将后门植入现有构建项目的情况下，该文件夹可以作为存储凭证/机密信息等控制台输出的可行位置。每次构建后，控制台输出结果（包括凭据/机密信息）都可以重定向到该文件夹。
小结
像Jenkins这样的自动化系统，在对手眼里是一个非常有价值的目标。管理员必须尽心尽力来保护和审计Jenkins的安装，这是至关重要的，因为这些系统很可能成为网络内鬼的攻击目标。
为了解决这个问题，CrowdStrike建议Jenkins的管理员密切关注以下几点:
- 任何人都可以访问Jenkins Web控制台而不进行身份验证吗?
- 包括脚本控制台访问吗?
- 他们能查看凭证或构建历史记录吗?
- 他们能创造构建或调度作业吗?
- 经过身份验证的用户拥有哪些权限？
- 包括脚本控制台访问吗?
- 他们能查看凭证或构建历史记录吗?
- 他们能创造构建或调度作业吗?
- 在构建历史记录或控制台输出中是否存储了任何敏感信息?
- Jenkins能通过互联网访问吗?真的需要这样做吗?
- Jenkins服务帐户是否以执行其功能所需的最少权限运行?
- 凭证是是如何存储的?
- 谁可以访问凭证。xml,主人。关键,hudson.util.Secret ?
当然，对于上面的列表来说，还没有全面到足以确保Jenkins的安全，此外，具体情况还要视不同的组织而定，所以，这里仅供参考。