SQLMAP 例項COOKBOOK

wyzsk發表於2020-08-19
作者: lxj616 · 2014/03/30 10:52

提醒:本文章中的所有例子均已透過烏雲平臺通知廠商,並按照流程已經公開(未公開的會有標識並且隱藏資訊,請等待公開後自行檢視),請在閱讀文章的同時不要對文中所列漏洞重複測試,謝謝

0x00 概述


本文章面向 已經理解SQL注射基本原理、已經配置好並瞭解SQLMAP基本命令、但缺乏實踐的入門者。在文章中總結了自己在烏雲上釋出的近三十個SQL注射漏洞,對於SQLMAP在不同場景下的應用給出了 例項總結,對於SQLMAP的基本介紹、安裝配置、命令手冊請大家自行百度。

SQL注射原理傳送門/papers/?id=59

SQLMAP使用者手冊傳送門/tips/?id=143

0x01 從HelloWorld開始思考


WooYun: WanCMS 多處SQL注射(原始碼詳析+實站演示)

形如:

C:\Users\Administrator>sqlmap.py -u "http://?a=b" –tables

WooYun: 吉林市人力資源和社會保障局 Oracle injection

[email protected]:~# sqlmap -u "www.jljl.lss.gov.cn/ybcx.asp" --data="yblb=%D2%BD%C1%C6%B1%A3%CF%D5&ybxm=123&ybsfzh=123" --tables

相信大家都已經倒背如流,爛熟於心。

例子a)

SQLMAP首先測試a(唯一的引數),檢測結果如下

Type: boolean-based blind(heuristic test 基本測試就能發現)

Type: UNION query      (在至少發現其他一種注射存在時會擴大測試範圍,原始是1-10,而這裡測試到了20,這是自動擴充套件的)

Type: AND/OR time-based blind (正常等級測試即可發現)

效率很高,檢測很準確,跑表成功,一切都很好,這是一個完美的HelloWorld

例子b)

SQLMAP首先測試yblb,沒有發現注射,然後檢測ybxm,結果如下:

Error-based(直接會告訴你是oracle,然後根據提示測試會很順利)
Union query(正常測試就能測試出來)
And or time based(正常測試就能測試出來)

我們發現,在測試yblb的時候SQLMAP浪費了我們好多時間(這個漏洞我是手工fuzz的,我知道是ybxm打單引號報的錯,如果是掃描器掃描也同樣知道漏洞出在ybxm) 那麼,何必浪費時間呢?

改進方案:指定測試引數 –p ybxm

改良的例子:

WooYun: 今題網某分站SQL注射漏洞

C:\Users\Administrator>sqlmap.py -u "http://club.jinti.com/operation/setmoodinfo.aspx?bodyid=52164&channel=a&classid=0&mood=mood1rand=0.10818770481273532" -p channel –tables

避免了測試不必要的引數浪費時間

這也是本文章的目的,讓新手們少走彎路,快速順利地完成檢測任務。

0x02 需要登陸後訪問的頁面


有時注射點的位置需要登入(手動測試時發現、掃描器配置了登陸sequence掃描)

解決方案:使用—cookie選項(cookie是burpsuite或者tamperdata手工抓的)

WooYun: CSCMS V3.5 最新版 SQL注射(官方站演示+原始碼詳析)

形如:

C:\Users\Administrator>sqlmap.py -u "http://?a=b" -p a --dbms=mysql --cookie="cookie" –tables

0x03 總是提示302 redirect(重定向)


明明掃描器掃出來的,手工測試也過了,可一到sqlmap就是302。

可能是要重定向到error頁面,這種情況有時屬於正常狀況(部分boolean-based payload會導致),但是總是這樣,可能是referer中有限制,或者cookie要登陸,再或者是agent需要換

帶上referer(從掃描器請求中找)

解決方案:使用—referrer 選項

例子:

WooYun: 聯眾世界SQL注射漏洞可致資料庫資訊洩露

形如:

C:\Users\Administrator>sqlmap.py -u "http:// " --data="? " -p ? --referer="http:// " --tables

cookie見0x03

改變user-agent

解決方案:使用random-agent 選項

例子:

WooYun: 攜程網主站+分站多個SQL隱碼攻擊漏洞打包

形如:

C:\Users\Administrator>sqlmap.py -u "http:// " --referer="a" --level 3 --random-agent --dbms="microsoft sql server" --techniqu
e T --tables

當然,如果你知道它要求你用某一種agent,你也應當用user-agent選項自己指定所需的agent(比如說ie6)

0x04 偽靜態中的注射


很多網站會使用偽靜態,引數形式經過變化後比較隱蔽,這給工具自動化注射帶來了難度

先說一個悲慘的反面案例:

WooYun: phpweb建站程式可導致大量政府網站受到安全影響

在這個例子裡,我為了跑表不惜自己寫了一個php的轉發請求的指令碼,結果勞民傷財。

諷刺的是,我居然用的是SQLMAP。

正確的解決方案:

使用“*”符號來自定義注射位置(米字鍵、星號、小鍵盤像雪花那個鍵)

正確的案例:

WooYun: 鐵友網某站SQL注射可致所有資料庫資訊洩露

形如:

C:\Users\Administrator>sqlmap.py -u "http://*" –tables

會提示發現“*”號,是否處理,選擇y

0x05 注射referer


一般情況下,指定level 3以上才會檢查referer

例項:

WooYun: 攜程旅行網主站 SQL注射可致大量資料庫資訊洩露

形如:

C:\Users\Administrator>sqlmap.py -u "" --level 3 --referer="a" --random-agent --tables

我其實曾經悲慘地又用轉發請求的方式發過一個referer漏洞

Referer中也是可以使用“*”來自訂的

0x06 手工構造注射語句自動化


有時候我們需要對注射語句手工調整,比如閉合各種括號單引號,比如補全後面的語句(常見於insert中的注射),以及在偽靜態中的調整等等

解決方案:手工構造後,使用“”號指定注射點(好像也可以指定prefix和surfix來實現,不過我自己習慣於用“”號)

之後會提示:“在url中發現疑似手動測試遺留的詞法,建議……”,選擇繼續測試

例子:

WooYun: 久遊網SQL注射 可致資料庫資訊全部洩漏(跑表演示)

形如:

C:\Users\Administrator>sqlmap.py -u "http:// " --data=" &?=a' or 1=1* --&…… " -p ? –tables

這個我後來想想構造的不妥,不過跑表正常,不深究了

0x07 提示unexploitable point detected


測試時報告injectable,但是又提示不能注射,可能是服務端做了某些防護措施(比如過濾了少量的關鍵字)但是明顯過濾做的不嚴格

或者是掃描器掃描出了盲注問題,但是SQLMAP檢測不出injectable而我們又不想放棄

那麼,可以使用—level 選項增加測試項(由於大量的測試會大大減緩測試速度,所以一般情況下不要開這個選項)

例子:

 WooYun: 螞蜂窩主站SQL注射可致資料庫資訊洩露 

完全公開

C:\Users\Administrator>sqlmap.py -u "www.mafengwo.cn/shop/mgr_item.php?act=add&item_name=lgkcaleg&item_price=1&shop_id=100597" -p item_name --tables --dbms=mysql --technique T --level 5

0x08 指定dbms


在上一節中增加level會使檢測速度難以忍受,這時就要進一步的縮短測試流程,其中很重要的一項就是指定dbms(這樣可以跳過其他無關dbms的檢測程式,和error-based發現dbms型別後提示你是否略過其他dbms的檢測同理)

解決方案:

使用--dbms選項

例子:還是上面0x08那個例子

0x09 指定方法盲注測試

進一步加快測試速度?使用--technique T指定盲注吧(當然如果不是盲注的你可以換其他引數)可以跳過大量的union測試(level高時會擴充套件到1-100,這是很漫長的等待)

例子:還是上面0x08那個例子

0x0a 過濾了空格


有些時候網站會“不小心”過濾掉各種字元,可以用tamper來解決(對付某些waf時也有成效)

例子:

WooYun: phpweb建站程式可導致大量政府網站受到安全影響

把空格過濾掉了(應該還有所有不可見字元)

--tamper=”space2comment.py”

理論是用/**/代替空格

同時如果過濾了其他字元,也可查閱手冊可用的tamper選項

0x0b 過濾了逗號


查詢了大量資料後,決定手注……

例子:

WooYun: iSiteCMS釋出安全補丁後仍然有幾處注射漏洞(原始碼詳析+實站演示)

裡面還轉義了“>”和“<”,不過可以透過Rlike繞過,但是逗號始終解決不了

各位有沒有帶著SQLMAP成功繞過逗號的經歷?交流一下?

0x0c 重新測試時異常


有時在測試的過程中,需要做少許調整重新再來一遍,但是重來時發現了異常

WooYun: 今題網某分站SQL注射漏洞

注意截圖中的提示:

Sqlmap identified the following injection points with a total of 0 HTTP(S) requests

一看覺得奇怪,沒有發請求怎麼知道的注射點?

其實是之前執行過測試,由於某些原因重新又來了一遍,但是重來的這一遍完全使用了之前儲存的檢測結果

雖然這個例子中一切都正常,但我親自碰到過因為這個原因造成無法重新調整測試的情況,解決方式是刪除掉output中的對應記錄檔案(建議用手冊中的安全方法,儘管我一直習慣直接刪資料夾……)

0x0d 取回資料異常


有時發現跑出的資料都是毫無意義的字元

解決方案:

a)SQLMAP會提示你加—hex或者—no-cast,有時會有幫助
b)如果你用的是time-based注射,建議增加延時—time-sec等引數,即使你的網速比較好,但是伺服器可能遇見各種奇怪環境
c)增加level 值得一試

由於烏雲上都是成功跑表的結果,暫無例項

0x0e 從burpproxy到sqlmap的捷徑


有時從proxy上截到的包想要放進sqlmap中,需要複製很多項(cookie、referer、post)等,解決方案:使用 -l 選項 把burpproxy的記錄直接匯入sqlmap

由於這種帶著檔案的漏洞難以提交烏雲平臺(難以復現除非給檔案),所以我提交的漏洞都轉成了一行命令形式,因此沒有例項

而且有些時候我們需要先手工構造一下(比如說json裡面的注射需要自定義注射點)

這種情況下如果盲目整包丟進SQLMAP,會導致漏報

例項:

WooYun: 國家獸藥基礎資訊查詢系統 SQL注射

0x0f 暴力猜表


在遇到access的站的時候,總是要猜測表名

在\txt下儲存著common-tables.txt,是猜測時使用的表名(SQLMAP在猜測時會根據頁面資訊自動組裝字首什麼的)

我的經驗是:如果你知道大概會存在什麼表,那麼自己去構造common-tables.txt吧,比如掃描時出現的soucecode-exposure(原始碼洩露)、頁面錯誤資訊、或者你的靈感

Txt下的其他檔案正如其名,同理猜測其他資料

例項:

WooYun: 高郵市某網站修補不當 仍然存在SQL注射

由於GOOGLE到之前的某些漏洞資料,知道部分表名後更改common-tables猜測

0x10 總是unable to connect to the target url


第一種情況可能是time-out設定的太小,但是這個可能性已經不大了,可以試試增加--time-out嘗試

解決方案:增加--time-out,可能最好清掉output遺留檔案(見0x13)

例子:

WooYun: 國家獸藥基礎資訊查詢系統 SQL注射

裡面的unable to connect to the target url提示完全是由響應過慢導致的,不過由於沒有嚴重影響跑表的過程,所以直接忽視掉了

再有可能就是WAF直接把請求攔截掉了,因此得不到響應

有些waf比較友善,過濾後會提示“引數不合法”,但是也有些waf則直接把請求攔下來無提示導致應答超時,這樣在測試時會消耗大量的時間等待響應

解決方案:減少time-out進行檢測,在跑資料時改回time-out

由於烏雲上只給出跑表結果,因此暫無例項

0x11 提示possible integer casting detected


意思是檢測到了類似intval的過濾,常見於形如http://xxx.x?a=1在SQLMAP檢測dynamic和basic test 時頁面毫無弱點,比如手工測試時a=1 和 a=2 顯示不同頁面,但是a=1’ 或者a=1sdf 或者 a=1 and 1=2 都返回原來的a=1的響應,因此SQLMAP推測可能伺服器端有intval的過濾。

如果你是在手工測試,建議到這裡可以停止了,節省時間。

如果你是在掃描器掃描的盲注,那麼到這裡堅決無視警告繼續下去。

例項:

忘記是哪個漏洞有這麼回事了,但是當時掃描器報告有盲注,所以無視警告繼續後成功跑表,現在想想可能伺服器端是用了intval後再次使用了沒有intval的引數(日誌記錄 insert),所以跑出來的表都是日誌資料庫(當時沒截intval提示的圖,所以目前找不到是哪一個了)

本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!