昨天写完 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 和$replacewith
在preg_replace()
函数中被引用了
追踪一下 发现getReplacePreview
调用了_getRegexReplaceRows
函数
全局搜索发现 在/tbl_find_replace.php
调用 getReplacePreview:
我们可以发现find
和 replaceWith
都是通过post方式提交的。
0x02漏洞利用
这个漏洞目前没法直接利用,因为有token限制,需要登陆抓到token。
需要构造第三个参数保证和第一个参数匹配,第一个参数可控,但是第三个参数是从数据库中取出的,我们只能提前插入到数据库中,然后再取出来,columnIndex是取出字段值的可控,所以第三个参数也可控了。
构
1 | //$find = ’0/e’; |
小结:按照原文写了写,主要是为了加深理解。复现的过程中出现了问题,除了漏洞本身,主要是学到这种分析代码的过程。。
太累了。。又会是一个忙碌的周末orz。。