En

phpMyAdmin SQL注入漏洞(CVE-2016-5703)分析

作者:Wester公布时间:2016-08-24阅读次数:223156评论:8

分享

0x00.影响版本

Version 4.6.x (<4.6.3)
Version 4.4.x (<4.4.15.7) 

 

0x01.漏洞描述 

phpMyAdmin是一个web端通用MySQL管理工具,上述版本在central_columns.lib.php文件里的db参数存在sql注入漏洞,攻击者利用此漏洞可以获取数据库中敏感信息,甚至可以执行任意命令

0x02.测试环境 

Windows7(X64)+PHP5.5.12+Apache/2.4.9+phpMyAdmin4.6.2 


0x03.漏洞详情 

从官方的补丁ef6c66dca1b0cb0a1a482477938cfc859d2baee3来看,其对libraries\central_columns.lib.php中某几个function中的$db参数进行了转义,由此我们可以初步判定注入点就出现在这几个函数的$db参数处 ; 



我们全局搜索一下引入了central_columns.lib.php的文件


总共四个文件包含了central_columns.lib.php,其中三个文件为库函数文件,因此最直接与用户交互的文件还是db_central_columns.php 
我们来到db_central_columns.php,搜索一下打补丁的几个函数: 

PMA_deleteColumnsFromList出现在大约89行
PMA_getColumnsList出现在大约135行
PMA_getCentralColumnsCount出现在大约94行
PMA_getCentralColumnsListRaw出现在大约49行

我们应该尽量选择不需要满足过多if条件语句以及位置尽量靠前的不危险函数分析,跟进PMA_getCentralColumnsCount函数:



我们能在函数91行之前打印出任意字符串,而在if语句之后无法打印出字符串,我们看到函数93~95行出现了if语句判断,因此我们跟进if语句if(empty($cfgCentralColumns)),其中$cfgCentralColumns是从PMA_centralColumnsGetParams获取到的,继续跟进PMA_centralColumnsGetParams函数:
该函数同样在central_columns.lib.php文件里大约17行


我们在25行之后打印一下$cfgRelation变量




根据接下来的if语句,我们需要使得$cfgRelation['centralcolumnswork']不为false,才能使程序完整执行下去,那么$cfgRelation['centralcolumnswork']是个什么变量呢?
跟进函数PMA_getRelationsParam(在libraries\relation.lib.php大约61行)



继续跟进函数PMA_checkRelationsParam(在libraries\relation.lib.php大约451行)



我们可以看到,我们需要的变量在这个foreach语句中被定义成了false,我们继续向下跟进,从大约563行起,出现了如下语句: 


官方文档http://docs.phpmyadmin.net/zh_CN/latest/config.html,我们可以知道PMA_checkRelationsParam函数的作用就是检查用户是否自定义了配置文件,只有用户自定义了配置文件,我们需要的$cfgRelation['centralcolumnswork']才能为True 

那么,如何自定义配置文件呢?

我们知道,phpMyAdmin在没有自定义配置文件时会默认加载libraries\config.default.php中的配置;要自定义配置文件,我们只需要在phpMyAdmin根目录将config.sample.inc.php文件copy为config.inc.php,并将41~44/47~68行取消注释,43以及44行改为MySQL用户(需要与攻击时phpMyAdmin的登录用户一致):



然后创建一个名为phpmyadmin的数据库,选中该数据库然后点击导航栏“操作”,根据页面错误提示即可自动创建phpMyAdmin自身的数据库

接下来回到central_columns.lib.php文件PMA_centralColumnsGetParams函数中,
我们在与之前同样的位置打印一下$cfgCentralColumns变量,我们发现页面已经能让你能够dump出数据了,说明程序已经能够向下执行,$cfgRelation['centralcolumnswork']变量为True



接下来我们到存在漏洞的函数PMA_getCentralColumnsCount中打印查询语句以及结果集: 




我们发现打印在页面上的sql语句存在很典型的注入类型,如下图所示: 



最后需要明确的一个问题,central_columns是什么?
我们知道之前我们创建的数据库phpmyadmin存在一个数据表pma_central_columns,而任意一个数据表的任何字段都可以添加进入pma_central_columns,在创建新的表或者添加字段时就能从此表中直接选取插入,所以我们能看出central_columns是作为储存一些关键字段,以方便添加外键时使用。

0x04.漏洞修复 

1.使用Utils::sqlAddSlashes函数对libraries\central_columns.lib.php的$db参数转义,
或者升级phpMyAdmin Version4.6至4.6.3,Version4.4 升级至4.4.15.7以修复此漏洞

0x05.漏洞总结 

phpMyAdmin本身作为数据库管理工具,登录后的注入显得相当鸡肋,最近的无需登录漏洞也是出在2.8.3左右版本。而从出现漏洞的文件来看,同一个文件仅仅部分函数进行了转义防护,这也可以看出开发人员在修复漏洞时“指哪修哪”,而最近以色列安全研究人员@e3amn2l提交的近20个漏洞中也出现了相似的未转义引起的漏洞,更加印证了这一点。
因此我认为安全从业人员在接收到安全漏洞时,应该首先构思最优的安全修复指南,而不是直接交给开发人员进行修复,多一个流程也可尽量避免在同一个地方重复跌倒。

0x06.参考资料 

http://smita786.blogspot.com/2014/06/gsoc14-coding-week-3-using-central-list.html
2016年phpMyAdmin漏洞统计


评论留言

提交评论 您输入的漏洞名称有误,请重新输入