Read MySQL Client's File - lightless blog

这应该是一个比较老的问题了，前几天看到其他人聊到这个问题，拿出来分析一下。

简单的讲，就是我们可以伪造一个MySQL的服务端，甚至不需要实现MySQL的任何功能（除了向客户端回复greeting package），当有客户端连接上这个假服务端的时候，我们就可以任意读取客户端的一个文件，当然前提是运行客户端的用户具有读取该文件的权限。

在复现的时候，有些地方踩到了一些坑，原作者没有说明，特此记录一下。

0x00 LOAD DATA INFILE

这个问题主要是出在LOAD DATA INFILE这个语法上，这个语法主要是用于读取一个文件的内容并且放到一个表中。通常有两种用法，分别是：

load data infile "/data/data.csv" into table TestTable;
load data local infile "/home/lightless/data.csv" into table TestTable;

有时候也会与FIELDS TERMINATED BY '\n'一起使用，效果更佳。这两种用法的区别就是差了一个local，第一个SQL语句的意思是，读取服务器上/data/data.csv文件，并写入到TestTable中；第二个SQL语句的意思则是，读取本地（客户端）这边的/home/lightless/data.csv文件，并写入到TestTable中。而我们这次要利用的也就是LOAD DATA LOCAL INFILE这种形式。

通过查阅MySQL的官方文档，在文档上，官方也指出了这个语法的问题：

image.png-100kB

那么接下来，我们来看下如何构造一个恶意的MySQL服务端来读取客户端的文件。

0x01 Capture The Package

如果想构造这样的服务端，首先要搞明白MySQL的交互流程，测试环境如下：

Ubuntu 18.04
MySQL官方APT仓库安装的5.7.23

通过Wireshark抓取3306端口的数据包，一开始发现MySQL的数据包全部走了SSL通信。

image.png-245.9kB

仅有一开始的两个MySQL的包，后面全是SSL数据了，这样也就没法搞明白是怎么读客户端文件的了。我们需要把SSL关掉，只需要关闭MySQL Client端的SSL即可，在配置文件的[mysql]节添加skip_ssl（或者关掉服务端的SSL支持也可以）：

image.png-3.4kB

这样Wireshark中就可以抓到正常的数据包了。会发现一共有这样几步：

greeting包，获取服务端的banner；
登录请求包；
初始化的一些查询，比如select @@version_comment limit 1之类的；

接下来我们找到关键的LOAD DATA INFILE数据包，第一个包看起来比较正常，是客户端发起的Request Query，如果你无法使用LOAD DATA INFILE语法的话，考虑在连接MySQL的时候加上--enable-local-infile选项，或者设置local_infile全局变量为ON

image.png-206.7kB

但是紧接着，服务端回复了一个包含刚刚请求中文件名的包，这里把/etc/passwd又给发回去了：

image.png-203.5kB

然后客户端向服务端发送了/etc/passwd文件的内容：

image.png-241kB

看到这里，也许开始有点想法了，如果我们在客户端发送查询之后，返回一个Response TABULAR数据包，并附上我们指定的文件，是不是就可以读取客户端的文件了，答案是肯定的。正如官方文档中提出的安全风险，"In theory, a patched server could be built that would tell the client program to transfer a file of the server's choosing rather than the file named by the client in the LOAD DATA statement."，可以看到，客户端读取哪个文件其实并不是自己说了算的，是服务端说了算的，形象一点的说就是下面这个样子：

客户端：hi~我将把我的data.csv文件给你插入到test表中！
服务端：OK，读取你本地data.csv文件并发给我！
客户端：这是文件内容：balabal！

正常情况下，这个流程不会有什么问题，但是如果我们制作了恶意的客户端，并且回复服务端任意一个我们想要获取的文件，那么情况就不一样了。

客户端：hi~我将把我的data.csv文件给你插入到test表中！
服务端：OK，读取你本地的/etc/passwd文件并发给我！
客户端：这是文件内容：balabal（/etc/passwd文件的内容）！

看到这里可能有同学会问，“即便可以读任意文件，那也要等到客户端发起LOAD DATA INFILE”的时候才能回复呀！如果你刚才仔细阅读官方文档上的安全风险的话，会发现有这么一句："A patched server could in fact reply with a file-transfer request to any statement, not just LOAD DATA LOCAL"

伪造的服务端可以在任何时候回复一个file-transfer请求，不一定非要是在LOAD DATA LOCAL的时候。这里有一点要说明的是，如果想要利用此特性，客户端必须具有CLIENT_LOCAL_FILES属性，这一点也会在下文提到的官方数据包格式文档中有所说明，这也是为什么在前面测试的时候需要添加--enable-local-infile的原因。

0x02 Pseudo Server

那么我们现在可以开始制作我们的服务端了，主要是以下几个步骤：

向MySQL Client发送Server Greeting
等待Client端发送一个Query Package
回复一个file transfer请求

现在要解决的就是两个问题，分别是Server Greeting包和file transfer包的格式，不过也不难，这些包的格式都可以在MySQL的官方文档上找到，首先来看File Transfer的包格式，Protocol::LOCAL_INFILE_Request，这幅图也可以发现，我们需要等待一个来自Client的查询请求，才能回复这个读文件的请求

image.png-10.3kB

官方文档上还贴心的准备了一个Example：

0c 00 00 01 fb 2f 65 74    63 2f 70 61 73 73 77 64    ...../etc/passwd

数据包的内容其实是从\xfb开始的，这个字节代表包的类型，后面紧跟要读取的文件名。前面的0x0c是数据包的长度（从\xfb开始计算），长度后面的三个字节\x00\x00\x01是数据包的序号。

同理，我们很容易就能根据这份文档获取Greeting的数据包结构。如果感觉自己伪造比较困难的话，可以直接提取前面通过Wireshark抓到的包，修改一下长度、文件名之类的字节即可。

这里给一个Greeting包的样例，每个字段的作用均已表明，参考文档不难理解。

'\x0a',  # Protocol
'6.6.6-lightless_Mysql_Server' + '\0',  # Version
'\x36\x00\x00\x00',  # Thread ID
'ABCDABCD' + '\0',  # Salt
'\xff\xf7',  # Capabilities, CLOSE SSL HERE!
'\x08',  # Collation
'\x02\x00',  # Server Status
"\x0f\x80\x15", 
'\0' * 10,  # Unknown
'ABCDABCD' + '\0',
"mysql_native_password" + "\0"

接下来就是动手写PoC了，如果不想自己动手，可以参考“参考文档”中的PoC。

一开始构造好的时候，用客户端去连接，总是提示ERROR 2026 (HY000): SSL connection error: protocol version mismatch或者ERROR 2027 (HY000): Malformed packet。如果你在构造PoC的时候也出现了这种问题，很大可能是握手包构造的有问题，对照文档仔细检查。客户端默认是支持SSL的，服务端需要告诉客户端服务端不支持，我通过两次分别抓“服务端支持SSL”和“服务端不支持SSL”的包进行比对，再参考文档，找到了关闭SSL的方法，就是Capabilities这两个字节，\xf7则表示不支持SSL，如果不明白，抓个包比对一下就懂了。

仔细观察下图中的各种字段，避免踩坑。
image.png-217.9kB