前段时间沸沸扬扬的Jenkins RCE漏洞概念验证（PoC）利用代码已公开发布，安全研究人员称“攻击者正在积极利用该漏洞发起攻击”，用户迫切需要采取相应的安全措施来保持对系统的控制。

漏洞详情

影响范围

• Jenkins 版本<= 2.441
• Jenkins 版本<= LTS 2.426.2

安全措施

• 1.升级版本：目前该漏洞已经修复，受影响用户可升级到Jenkins 2.442、LTS 2.426.3。链接：https://www.jenkins.io/download/
• 2.临时缓解措施
• 如果无法立即更新到 Jenkins 2.442、LTS 2.426.3，管理员可禁用对 CLI 的访问来缓解该漏洞。

Jenkins是一个开源软件项目，最开始被称作 Hudson，基于Java开发的一种使用非常广泛的持续集成工具，用于监控持续重复的工作。由于易于使用并且具有良好的扩展性，Jenkins深受用户喜爱，在持续集成领域的市场份额居于主导地位，其被各种规模的团队用于各种语言和技术的项目中，比如：.NET、Java、Ruby、Groovy、Grails、PHP 等。同时，Jenkins 开源社区的规模和活跃度也让该工具进一步被推广。Jenkins 社区的发展速度非常快，每周都会有新功能、新特性、以及 bug 修复和插件更新发布出来，该社区包含开放态的讨论群、活跃的邮件列表、IRC 频道、有知名度的博客区和 Twitter 账户等等。

Jenkins RCE漏洞PoC发布

2023年年底，一个名为SonarSource的安全研究人员发现了Jenkins中的两个漏洞，这些漏洞在特定条件下，可能允许攻击者访问易受攻击服务器中的数据并执行任意CLI命令。

第一个漏洞CVE-2024-23897，它允许未经认证的攻击者拥有“overall/read”权限，从而读取Jenkins服务器上任意文件中的数据。即使没有这个权限的攻击者也能读取文件的前几行，具体行数取决于可用的CLI命令。

这个漏洞源自Jenkins中args4j命令解析器的默认行为，当参数以"@"字符开始时，它会自动将文件内容扩展为命令参数，这允许未经授权的任意文件读取行为在Jenkins控制器文件系统上发生。

利用这个漏洞可用来读取包含加密密钥的二进制文件，虽然漏洞利用需要特定的条件，但是提取秘密为各种攻击提供了便利，例如：

• 通过资源根 URL 远程执行代码；
• 通过“记住我”cookie 远程执行代码；
• 通过构建日志使用XSS攻击（跨站脚本，XSS） 远程执行代码；
• 通过绕过CSRF（跨站请求伪造）保护来远程执行代码；
• 解密 Jenkins 中存储的秘密；
• 删除Jenkins中的任何元素；
• 下载Java堆转储等等。

Jenkins第二个漏洞CVE-2024-23898，是一个跨站WebSocket劫持问题，攻击者可以通过诱导用户点击恶意链接来执行任意CLI命令。这个漏洞带来的风险本应通过网络浏览器中现有的保护策略来缓解，但由于这些策略没有得到普遍执行，风险依然存在。

1月24日，Jenkins发布了修复这两个漏洞的版本2.442和LTS 2.426.3，并发布了对应的公告，分享了黑客利用漏洞发起攻击的各种场景和利用途径，以及修复描述和可能的替代方案，供无法进行安全更新的用户参考。

关于Jenkins漏洞的丰富信息现已公开，国外许多安全研究者复现了一些攻击场景，制作了PoC利用代码并发布在GitHub上。注意，这些PoC仅针对的是CVE-2024-23897，它允许攻击者在未打补丁的Jenkins服务器上执行远程代码。

非常不幸的是，安全人员在对上述PoC进行验证后，发现可以轻松入侵未进行安全更新的系统。不少安全公司也发布公告称，部署的Jenkins蜜罐已经捕获到一些攻击活动，这也意味着越来越的黑客尝试利用该漏洞发起攻击。

CVE-2024-23897漏洞分析

漏洞原理

CVE-2024-23897漏洞的原理比较简单，Jenkins提供了一个命令行的接口，用户可以在下载一个命令行客户端jenkins-cli.jar到本地，并调用该客户端来执行一些Jenkins的功能。本来是一个很常见的功能，但设计中神奇的是，用户使用jenkins-cli.jar时，命令行是传到服务端解析的，而不是在jenkins-cli.jar里解析。

这就导致了一个问题，因为Jenkins服务端解析命令行时使用了一个第三方库args4j，这个库实现了Linux中一个常见的功能——如果一个参数是以@开头，则会被自动认为是一个文件名，文件内容会被读取作为参数。

那么就会造成以下两个后果：

• 命令行接口文件读取：攻击者能够读取Jenkins控制器文件系统上的任意文件。
• 权限绕过：拥有Overall/Read权限的攻击者可以读取完整文件，而没有该权限的攻击者也可以读取部分文件内容。

远程代码执行及其它影响

攻击依赖攻击者能通过漏洞读取到二进制形式密钥以及其它前提条件，虽然攻击者可以读取包含二进制数据的文件，但是由于功能限制，某些字节无法成功读取并被占位符值替换，导致攻击者在读取部分密钥后仍然需要推算一定数量的字节（字节数根据Jenkins » System Information中file.encoding值的不同而存在差异）。虽然条件较多，但是仍存在一定利用可能性。

常见利用方式

使用POST请求/cli接口，且包体中含有help、who-am-i命令以及@文件名。

根据长亭安全研究员的发现，除了官方给出的help、who-am-i两个命令外，还可以调用下面一批命令（默认匿名环境下）来进行任意文件读取：

keep-build

restart

shutdown

safe-shutdown

disable-job

enable-job

上述命令是通过另一种方式加载的，相关的 main 方法位于 CLIRegisterer 类中。这个CLIRegisterer#main 方法与 CLICommand#main 方法的主要区别在于处理顺序：CLIRegisterer#main 会先对参数进行解析，然后进行权限校验，而 CLICommand#main 则是先进行权限校验，再对参数进行解析。因此，通过引发参数解析阶段的错误，可以在权限校验之前获取到文件读取的部分结果。这揭示了程序逻辑上的一个缺陷。

同时值得注意的是Jenkins CLI 支持三种访问模式，分别是 SSH、HTTP、Websocket，因此如果要依赖流量特征缓解此漏洞，可能会相对繁琐。

尝试读取内容

Jenkins文件读取漏洞的原理是args4j在解析命令行的时候会把@后面的字符作为文件名，并读取文件内容作为参数的值。因此，攻击者必须想办法让Jenkins或args4j将读到的文件内容返回，才能最终达到任意文件读取的目的。有意思的时，当用户调用命令行出错时，args4j就会把错误返回给客户端，错误信息中就包含文件的内容。

这里有个问题，如果使用@将文件内容加载成命令行参数，文件中的空白字符会分割参数。举个例子，一个文件内容有4行，那么报错时只会出现相关参数，从而导致只能读取文件的前几行。

这么来看，这个漏洞似乎比较“废”，只有前几行的信息被读取意义不大？当然不是，黑客在攻击时会人为地给help命令后增加一个新参数，比如：

java -jar jenkins-cli.jar -s http://localhost:8080/ -http help 1 "@/var/jenkins_home/secret.key"

此时help后有两个参数，参数个数太多导致出错，第二个参数被爆出，就可以读取更多的文件

如果Jenkins开启了“匿名用户可读”选项，则大部分命令都可以被调用，其中包括connect-node命令和reload-job命令。这俩命令可以用来读取文件全部内容：

如果拿到Jenkins的根目录，还可以来尝试读取这些敏感文件：

/var/jenkins_home/users/*/config.xml

/var/jenkins_home/secret.key

/var/jenkins_home/secrets/master.key

/var/jenkins_home/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac

漏洞PoC

首先我们需要先下载jenkins-cli.jar，

Jenkins官方下载链接http://jenkins:8080//jnlpJars/jenkins-cli.jar

社区公布PoC如下：

https://twitter.com/shoucccc/status/1750601321831633026

最终使用命令如下：

java -jar jenkins-cli.jar -s http://jenkins:8080/ connect-node "@/etc/passwd"

注意，CVE-2024-23897漏洞的利用有两个比较核心条件，安全人员需警惕：

• 是否开启“匿名用户可读”选项
• 服务端字符集是否兼容读取二进制文件

参考链接

https://mp.weixin.qq.com/s/8HPev-rrN7p1LIUsQAHxjQ