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

简单的讲,就是我们可以伪造一个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中就可以抓到正常的数据包了。会发现一共有这样几步:

  1. greeting包,获取服务端的banner;
    image.png-201.9kB

  2. 登录请求包;
    image.png-254.5kB

  3. 初始化的一些查询,比如select @@version_comment limit 1之类的;
    image.png-192.8kB

接下来我们找到关键的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

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

  1. 向MySQL Client发送Server Greeting
  2. 等待Client端发送一个Query Package
  3. 回复一个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

0x03 Exploit it!

a. MySQL Client

使用MySQL Client进行测试,效果拔群:
image.png-210.8kB

b. PHP with mysqli

PHP通过mysqli连接恶意数据库,效果拔群:
image.png-190.8kB

image.png-132.3kB

c. PHP with PDO

默认未开启MYSQL_ATTR_LOCAL_INFILE属性,需要手工开启才可以以。

image.png-113kB

image.png-143.4kB

d. Python with MySQLdb

原作者说无效,但是我测试了一下,效果拔群。

image.png-55.7kB

image.png-126.6kB

e. Python3 with mysqlclient

效果拔群。

image.png-56.9kB

f. Java with JDBC Driver

效果拔群。

image.png-130.1kB

image.png-176.3kB

image.png-115.4kB

z. Others

其他语言各位可以自行测试。

0x04 Defense And Thinking

对于这种攻击的防御,说起来比较简单,首先一点就是客户端要避免使用LOCAL来读取本地文件。但是这样并不能避免连接到恶意的服务器上,如果想规避这种情况,可以使用--ssl-mode=VERIFY_IDENTITY来建立可信的连接。

当然最靠谱的方式还是要从配置文件上根治,关于配置上的防御问题,可以参考这篇文档进行设置。

用途的话,做蜜罐是肯定可以的,但是受众面好像不太完整,各种语言的支持都不太一样,比如Python中的MySQLdb包,原作者说这个包不受影响,但是我测试的时候确是受影响的,而PHP+PDO的方式又不受影响,所以能否中招还是要靠一些运气。

而且这些语言中的三方包在连接MySQL的时候,基本上在连接成功之后都会发出一下SELECT语句来查询一些版本号、编码之类的数据,这就达成了前面提到过的第二个攻击条件:等待客户端发来一个QUERY请求,所以如果这些第三方包允许执行LOAD DATA INFILE,危害还是比较大的。

0xFF 参考文档