把SQL服務器黑了是件很有趣的事兒。今年的時候，我發佈過一篇有關於《無需密碼黑掉mssql服務器》的文章。我利用Ettercap製作了一箇中間人攻擊，並將它放在了微軟SQL服務器和用戶之間。利用Ettercap過濾器，我展示瞭如何立刻將SQL的查詢替換成你自己的惡意查詢。這允許你去運行一系列的攻擊，比如創建一個數據庫的管理員用戶來幫助你獲得數據或者執行功能。我寫了一個腳本來使得整個過程能夠更加自動化，給大家學習使用。
當腳本工作時，它會有一些限制。第一，你必須知道數據庫正在運行的SQL查詢。一般來講，你不大可能有這樣的信息。第二，腳本依賴於Ettercap來運行MITM攻擊。最後，它只支持微軟SQL服務器。雖然它是一個很流行的數據庫引擎，但它只代表了數據庫種類中的一小部分。
在最近的一個對於Anitian用戶的滲透測試中，我決定重寫一下整個工具，來將我所進行的一些測試變成自動化。目標是做成一個一體化的SQL MITM工具。你可以用一下的表格來下載這個Python原程序。（這裡是對於你要進行的下載的條款）
表格地址：https://blog.anitian.com/hacking-sql-servers-without-password/
由於之前的文章已經詳細說明漏洞以及如何補救的方法，這篇文章就主要講解如何利用這個工具來查找SQL MITM漏洞。
Options
這個工具使用有幾個必須的條件：
交互界面：要去監聽的網絡交互界面。
SQL 類型：第二個項目需要提供具體的SQL服務器類型。目前，工具支持MSSQL，MySQL，Oracle和PostgreSQL.這是目前最為流行的四種數據庫引擎。
用戶 IP：發送請求SQL用戶的IP地址。
服務器IP：SQL服務器的IP地址。這兩個IP地址允許腳本進行ARP毒化攻擊。這表明這個程序能自己執行MITM攻擊而不需要諸如Ettercap的外部工具。
新請求：新的SQL請求。這是一個有害SQL字符串，它們會被植入到連接中。
同樣，還有兩個可選條目
開始關鍵字：腳本搜索的第一個關鍵字。
結束關鍵字：腳本所要搜索的最後一個關鍵字（或者字符）。
這兩個項目是原始SQL字符串中的開始和結束關鍵字。從這些關鍵字可以辨認出SQL請求而不需要提前知道整個請求。比如說，開始關鍵字的默認值是“選擇”，而結束關鍵字的默認值是分號。這滿足所有如下的例子：
這使得這個腳本擁有較好的通用型。你不需要知道具體的SQL請求來插入有害請求。
Scapy
我使用Python來進行這個項目，原因是它用起來很簡單，並且我能利用它所擁有的Scapy操作庫。Scapy有對於很多協議的內在支持，在這個情形下，重要的是TCP和ARP協議支持。它能夠用來當作獨立的數據包操作程序，或者是其他項目的庫文件。
ARP投毒
攻擊的第一步是毒化用戶和服務器的ARP緩存。這一步欺騙你的服務器將主機當作用戶，反之亦然。你所有需要做的僅僅是將用戶和服務器IP地址輸入就好了。這個腳本利用ARP來辨認相應的MAC地址。然後，腳本調用arp_spoof()函數。這個函數能夠構建正確的ARP數據包來毒化用戶和服務器緩存。利用一個計時器，arp_spoof()函數每15秒被調用一次。這保證緩存器能夠在攻擊期間保持被毒化的狀態。
Scap_sniff()函數被用來嗅探數據包。這個函數會一直嗅探輸入的數據包並一直循環下去，直到攻擊者按下了ctrl+c來跳出程序的執行。每當線上有數據包被探測到的時候，sniff()函數會利用過濾器來分辨這個數據包是發送給SQL服務器IP的還是用戶IP 的。如果不是，那麼這個數據包會被忽略掉。如果真是這樣，那麼數據包會被送到processPacket()函數。
數據包處理
這兒是所有神奇的事情發生的地方。腳本會根據攻擊者所選擇的SQL引擎類型來處理數據。它在整個數據包中搜索開始和結束字符。如果找不到，那麼就將數據包正常發送出去。
如果它找到了，那麼它會比較原始請求的長度和新請求的長度。如果新請求比較長，那麼腳本給出個錯誤，然後將原始數據包送出並不做改變。這是因為TCP的工作方式。被改變的數據包必須要和原始數據包一樣長，不然則會打破TCP連接，並導致重啟。結果就是，原始請求越長，你能擁有的替換空間就越大。
如果新的請求比原始請求要小，那麼一切都很好。腳本用新的請求更新數據包，並在數據包的尾部增加一些補丁，用以將數據包保持原有的長度。然後，修改好了的數據包會被送到服務器。
Re-ARPing
在攻擊的最後，按下ctrl+c來停止程序。腳本會檢測到這個反應，並在結束前調用undo_arp_spoof()函數。這會重置ARP存儲器，如此一來，受害者會正常地接受消息。如果沒有這一步，用戶和服務器會有聯網問題，並且攻擊會被簡單地發現。
例子
MSSQL
首先，我會用Microsoft SQL來測試這個軟件。我創建了一個簡單的測試數據庫，如下所示：
你可以看到在產品表中有三條輸入項。下面我會運行一個基本的命令來從表中抽取一個簡單的目標。
你會看到我查找了名為ProductZero的內容。服務器僅僅返回了一個匹配的輸入。然後我運行了sqlmitm.py腳本來注入有害命令。
利用這些聲明，腳本會替換SELECT為我所選擇的的命令。意思是說，不管我用SELECT從數據庫中查詢了什麼，服務器的返回值永遠是ProductOne這個輸入項。
你可以看到我運行了一個請求來查詢 ProductZero數據，但是服務器返回了ProductOne！這個返回並不正確！MITM腳本在傳輸中替換了請求。客戶並不知道這一事件發生了。這一過程允許所有目的的惡意程序。
MySQL
現在，我們來試試MySQL。我構建了一個類似的數據庫來測試MySQL服務器：
下一步，我運行了sqlmitm.py腳本，但是這次我設置成攻擊MySQL服務器。
你可以在輸出發現腳本分辨出了一個匹配的數據包並替換了語句。
但是在用戶端看是什麼樣子？
你會發現我試圖去查詢“Test Product 1”的信息，但是服務器卻給了我“Test Product 2”。同樣，客戶端並沒有發現任何問題。
Oracle
下面，我們來測試Oracle。這裡是測試用的數據庫：
然後，繼續來運行這個腳本。
當它已經被設置好並在運行時，我執行了另一個相似的命令
服務器又給了錯誤的返回
PostgreSQL
過程依然是相似的。這裡是測試用的數據庫：
運行腳本。
執行命令。
腳本又一次替換了數據並且用戶端不會知道發生了什麼。
創建一個MySQL用戶
之前的例子都是無害的。下面我來試試比較有危害性的事兒：來建一個MySQL上的用戶？這需要三步操作。
第一步，我們來創建數據庫用戶。
這一請求會創建一個名為“anitian”的用戶，並允許這個用戶從任何地方登錄。用戶的密碼是“hacked”。在運行完mitm腳本之後，我回到MySQL用戶，並執行一個無害的SELECT請求。
注意到，沒有行真正被返回了。我們的返回值與請求並不相符。但是，如果這個請求時從一個應用程序發出的，估計誰都不會發現。
下面，我們來提高用戶的權限。這會給我們創建的用戶所有的權限，只要目標擁有這些權限。
我又執行了一次SELECT請求
沒有返回錯誤。看來命令執行成功了。最後我們需要去掉這些權限
最後執行一次SELECT請求
現在用戶已經被創建了，可以試著登錄看看：
登錄成功，它開始工作了！現在我們創建的用戶擁有數據庫的控制權限。當然，這意味著你可以所任何事情，例如偷點受保護的數據什麼的。這僅僅是這個腳本能做的其中一個事情。
如何防範
- 避免SQL MITMM攻擊的最簡單方法就是要求所有的SQL通信都是有加密且有認證的；
- 永遠遵守最低權限原則。遠程賬戶只能擁有最基本的功能。管理員權限需要做嚴格限制；
- 請保證你的系統和固件都打上了漏洞補丁。
*原文：anitian Mottoin翻譯發佈
原創文章，作者：Moto，轉載自：http://www.mottoin.com/article/web/89825.html
相關推薦
