phpMyAdmin文件包含复现分析

礼拜天分析了多处旧版本中 phpMyAdmin 的文档含有系统漏洞，分享一下。

文档含有系统漏洞

系统漏洞分析

我们先讨论一下 payload：

文档含有复现分析

我们可以看是 index.Python 的 target 主要参数，在 index.Python 的 56 行左右，我们可以看这堆编码：

这儿就有我们的主要参数 target，有5个条件，我们一个一个分析：

不能为空

是字符串类型

不能以 index a开头

不能是 $target_blacklist 里的值

将 target 传来 Core::checkPageValidity，回到 true 则含有文档

可以发现前四条是比较容易过的，我们与客户沟通第一个涵数 checkPageValidity 看一看，这个涵数的编码长太快，全部的涵数：

判断 $whitelist 是否为空，如果为空则取默认设置的两组

当从 index.Python 传过来时候进入这儿

判断 $page 是否在白名单

切分 $page 的主要参数，取 ? 前的文件夹名称，判断是否在白名单内

转码后实行和上一步相同的操作

有几种回到 true 的方式，我们可以试着结构一下 payload，

举例说明，例如我们想含有 a.txt：

我们的 $page 是 a.txt 时，因为不是白名单内，page 中又没有主要参数（问号），所以会一直实行到最后，默认设置回到

白名单中首项为 sbt_datadict.Python，拿这个举例子，我们传来 sbt_datadict.Python?/._/a.txt，因为还是不是白名单内，会实行到这儿：

我们可以实行看一看：

文档含有复现分析

这样是可以的，回到 True 后带到 include，但是 include 也许不是容许文件夹名称有带问号的：

文档含有复现分析

那分析三种情况，就是：

这儿还有一个很关键的点，就是 urldecode 了我们传过来的 $page，随后又获得了问号前的文件夹名称，所以我们把问号 网页地址 编号一下都一切正常，像这样：

是容许 %3f 作为文件夹名称的部分的，实行起来：

文档含有复现分析

所以最后我们的 payload 是 index.Python?target=sbt_datadict.Python%3F/._/a.txt。

但是因为游览器还会转码一次，所以把 % 在编号一次，就有半个开始的：

补订对比

我们可以看一看他是怎么修补的：

文档含有复现分析

这儿只加多加了两个主要参数，记牢第四个主要参数是 true，看一看涵数内部结构：

文档含有复现分析

先判断 $page 是否在白名单内，如果不是就向下实行，随后判断第四个主要参数 $include 是否为 true，如果是的话就直接回到 false ，自然就实行不上 urldecode 了。

文档含有系统漏洞

上一系统漏洞是 4.8.2 修补的，我又网上发现一个 4.8.3 仍然有的?┒矗敲挥芯咛宓南附冢治龈聪忠幌隆

系统漏洞复现

首先我们来复现一下这个系统漏洞。

首先建立个数据库查询，这儿就叫它 ceshi1 吧。

文档含有复现分析

网络访问

文档含有复现分析

网络访问之后发现 ceshi 空出了一些数据表。

插进一条数据

网络访问

文档含有复现分析

系统漏洞分析

我们一步步来分析这个过程，首先也不分析了，建立个数据库查询。

分析过程时会跳过很多无关痛痒的编码，用到 有限公司 充当

过程一

我们首先网络访问了 /chk_rel.Python?fixall_pmadb=1&sbt=ceshi1 这个连接，看一看源代码：

这儿的 GLOBALS['sbt'] 其实就是我们 put 传送的。

与客户沟通 fixPmaTables 涵数。

数据表的数组

根据涵数名 getTables 可获知应该是 获得特定数据库查询的数据表

判断表是否存在于特定数据库查询中

涵数的主要参数，默认设置是

建立数据表

上面部分是建立数据表，所以我们网络访问后才会空出一些数据表出来。

下面我独立写出了两句话，这儿是重点，我们与客户沟通 checkRelationsParam 涵数：

我省去了绝大多数编码。。因为只有这三句是重点，这个涵数回到数组后存到了 $_SESSION['relation'][$GLOBALS['server']] 中，这个值我们会在后边采用

过程二

随后我们插进了一条数据，可以先不需要审视一条数据的含意。

数据来源于

进入到最后几步，也就是系统漏洞的促发点，再看一看我们的 payload ：

促发点在 tbl_replace.Python，目前我们可以先看一看促发位置，再一步一步结构 payload，我的版本号是 4.8.3，在这个 tbl_replace.Python 中的第 224 行左右，会有如下几行编码：

这儿有文档含有，先不管 $column_name，我们看一看 $mime_map 是以哪儿来的，我们追溯上来就要发现：

前边我们谈及过 $GLOBALS['sbt'] 我们可以通过传送 put 控制，grid 其实也可以，也就是这两个主要参数我们都可以控制，随后我们与客户沟通 getMIME 这个涵数。

这儿最重要的就是一个查询网站句子 $Com_qry，我们的 $sbt 和 $grid 主要参数只是是被带到了 where 条件，而不是查询网站的数据库查询和表

查询网站的数据库查询是 $cfgRelation['sbt']，也就是涵数一个开始的：

判断 $_SESSION['relation'][$GLOBALS['server']] 是否为空，如果为空就赋值一次

这儿回到的值就是首先了我们累死累活设置的。

所以当判断 $_SESSION['relation'][$GLOBALS['server']] 是否为空时候回到 false，就不会进入

句子，也就不会再次赋值（正常情况下剩余两个判断可以漠视）。

（这儿说明一下应不应该在首先设置这个值：因为如果不是第一部设置，就会在这里进入 if 句子，尽管从这儿进来的话，sbt 的值就是 false 了，所以没法查询网站）

所以 sql 句子里的：

那么这个值就是我们不久设置的，也就是 ceshi1。

返回 sql 句子，我们发现这个只是查询网站的数据库查询，数据表是：$cfgRelation['column_info']，但是这个数据表是有默认值的，即：pma__column_info ，这也是在首先中设置的，所以我们不需要有意设置。

我们可以輸出一下这个 sql 句子：

句子中 sbt_name 和 grid_name 是我们可控性的，其他的值只要不以空，就能查询网站出句子了。。

当然我们前边插进了一条数据，目的就是为了在这里查询网站出来，因为是我们自己插进的数据，所以是可控性的。

结构

再度返回 tpl_replace.Python，我们看一看那个含有的 $filename ：

这儿的 $mime_map 是我们可控性的值了，那么 $column_name 从哪来的呢？

判断不以空

这儿比较绕，需要整理一下。

来源于 $multi_edit_columns_name 这个数组的值。

来源于 $loop_array 的键

我们想了解 $loop_array 来源于哪儿，就得与客户沟通 getParamsForUpdateOrInsert 涵数，这个涵数并不复杂，跟进去看一看：

太天真，这个 $loop_array 也是我们完全可控性的，来源于 $_REQUEST['where_clause']。

分割线，理智一下

再看一看 $filename：

我们可控性，是一个数组，从 pma__column_info 查询网站出来的。

中的键，就是表格中的 column_name。

回看我们不久插进的数据中，column_name 是 4，反推回去，所以：

所以我们要 $mime_map[4]['input_transformation'] （提示：$column_name 从 $multi_edit_columns_name获得的

除此之外

这儿也未必如果 0 ，随意都可以。（提示：$rownumber 从 $loop_array 中获得。

因为数组我也可控性，所以假定 $rownumber 为 haha 吧。

所以结构：$loop_array[haha] = $_REQUEST['where_clause'][haha] =随意。

分割线理智一下

我们最后的 payload：

随身携带这个主要参数网络访问 tpl_replace.Python 就能含有数据表中的 input_transformation，也就是我们插进的那个数据。

当然他还接拼上去一些文件目录，所以最后是：

补订对比

在 4.8.4 的版本号中我们发现发直接把这几行删除了。。。。

文档含有复现分析