CVE-2016-5734--preg_replace的危险姿势

昨天写完 preg_replace 危险函数,恰好今天看到两篇讲php危险函数和php隐藏后门的的文章,里边提到了‘preg_replace引发的phpmyadmin(4.3.0-4.6.2)命令执行漏洞’这篇文章<传送门>,根据这篇文章看一下实例中这个函数的危险姿势。

0x00漏洞触发原理

前一篇笔记已经说到了这个漏洞触发的原理,即:

1. 第一个参数需要e标识符,有了它可以执行第二个参数的命令
2. 第一个参数需要在第三个参数中的中有匹配,不然echo会返回第三个参数而不执行命令

如:

1
//echo preg_replace(‘/test/e’, ‘phpinfo()’, ‘just test’);这样是可以执行命令的,第一个参数有e标识符,并且第一个参数在第三个参数中有匹配。
1
//echo preg_replace(‘/test/e’, ‘phpinfo()’, ‘just tesxt’); 或者echo preg_replace(‘/tesxt/e’, ‘phpinfo()’, ‘just test’); 虽然第一个参数有e标识符,但是第一个参数在第三个参数中没有匹配,返回第三个参数,不执行。

0x01触发漏洞位置回溯

问题出现在/libraries/TableSearch.class.php中的_getRegexReplaceRows函数,我们全局搜索发现:
这里写图片描述
我们可以发现,$find 和$replacewithpreg_replace()函数中被引用了

追踪一下 发现getReplacePreview调用了_getRegexReplaceRows函数
这里写图片描述
全局搜索发现 在/tbl_find_replace.php 调用 getReplacePreview:我们可以发现findreplaceWith都是通过post方式提交的。
这里写图片描述

0x02漏洞利用

这个漏洞目前没法直接利用,因为有token限制,需要登陆抓到token。
需要构造第三个参数保证和第一个参数匹配,第一个参数可控,但是第三个参数是从数据库中取出的,我们只能提前插入到数据库中,然后再取出来,columnIndex是取出字段值的可控,所以第三个参数也可控了。

1
2
3
4
//$find = ’0/e’;
//$fromsqldata = ’0/e’;
//echo preg_replace(“/”.$find.”\0/”,$_POST["replaceWith"],$fromsqldata);
//preg_replace(‘/0/e’,'phpinfo()’,’0/e‘);

小结:按照原文写了写,主要是为了加深理解。复现的过程中出现了问题,除了漏洞本身,主要是学到这种分析代码的过程。。

太累了。。又会是一个忙碌的周末orz。。

-------------本文结束有错指正哦!-------------