歡迎光臨
每天分享高質量文章

WAF 繞過的捷徑與方法

來自:信安之路(微信號:xazlsec)

本文作者:qiaoy(信安之路特約作者)

作者博客:https://www.qiaoyue.net

在企業架構中,安全體系同剝洋蔥一般,由外及內是由一層層的安全產品和規範構成,越處於外層承重越大,WAF 屬七層防護的第一道牆,隨著互聯網技術發展,業務對外提供服務的方式逐漸收攏,Web 接口與應用壟斷流量,WAF成了安全戰場中被炮火攻擊最慘烈的前線。

痼疾

雖然 WAF 屬於較成熟的安全產品,但不同公司,不同場景都可能衍生出不同的部署方式,一個關鍵原因就是安全、效率、成本的不可能三角,互聯網公司中,效率代表產品的易用性和響應時間,往往很難有較大犧牲,成本和安全的組合形式決定了安全產品架構的不同,即便在傾向選擇中安全成為首位,WAF 產品本身也有痼疾:HTTP 協議和業務場景的複雜性導致很難有統一的策略規範,加之 WAF 抽離於業務代碼邏輯以外,這些耦合上的瑕疵很容易成為繞過 WAF 防護的突破口。

再者,不管是基於正則匹配還是機器學習,考量 WAF 的指標永遠是相互矛盾的:誤報率,漏報率。在安全和效率(業務)的博弈中,沒有完美,只有適配,這也就決定了 WAF 的定位。

WAF 繞過

WAF 的痼疾在越來越複雜的系統對接中存在耦合缺漏,不同型別的漏洞,在 WAF 的 Bypass 測試中關註點自然也不同,本文嘗試找尋一些規則對抗以外的捷徑進行 bypass,通過以下幾個維度進行嘗試:

1、架構層面

2、協議/中間件層面

3、系統/資料庫/編程語言層面

架構層面

在千奇百怪的 WAF 架構中,始終脫胎換骨於兩種基礎的架構:串聯和旁路。

串聯

串聯 WAF 一般權重較高,對攻擊的請求和會話有優先於業務的一票否決權,是最為常見的 WAF 架構方式,不過串聯接入業務意味著 WAF 系統會捆綁、分擔業務指標,在日益追求高響應的複雜鏈路中強行增加了一個單點故障隱患,那考核運維健壯性的指標(可用性、響應耗時和故障率等)將是懸置 WAF 頭頂的達摩克利斯之劍。

串聯 WAF 根據產品形態又有多種變形,常見的區分方式看設備部署位置。

傳統的硬體盒子設備一般放置在網關入口後,業務中間件之前,串聯部署方式有透明樣式、反向代理樣式等,其前置於中間件,意味著 WAF 需預留很大一部分性能來處理 HTTP 拆解和封裝的工作,尤其是當下 HTTPS 已成為普遍場景,設備處理性能急劇下降,使得此類架構的成本投入極大。

透明連接樣式:

反向代理樣式:

當下雲廠商最常用修改域名 CNAME 做多維安全防護的架構同硬體類部署方式在應用場景視角是一致的,不過雲廠商的設備和網絡資源豐富,人才資源配備到位,又有大廠品牌背書,只要有足夠的用戶均攤成本,這種架構算在成本、效率、安全不可能三角中屬協調最優的解決方案。

CNAME 架構:

對於此類前置串聯架構的 ByPass 測試需找尋 WAF 與中間件、後端業務間的耦合性缺漏,比如:

1、在使用了 SSL 套接字的會話中,協商加密演算法屬請求方可控,WAF 和後端業務在演算法支持上可能存在差異的一個切入點,遍歷後端業務支持但 WAF 不支持的加密演算法,便可直接繞過 WAF 了,相關工具見 Github:

https://github.com/LandGrey/abuse-ssl-bypass-waf

SSL Bypass

2、針對 CNAME 方式接入 WAF 的系統,能否繞過的關鍵在於後端的業務配置是否嚴謹,如果後端業務未限制訪問源,很容易通過域名解析歷史和 [ 大規模的掃描 ] 定位到真實的 IP 地址,修改本地 HOST 便可以繞過 WAF 直接對後端系統進行攻擊;

3、WAF 與中間件的耦合缺漏在後續的中間件層面做詳細講解,此處不做贅述。

還有另一類串聯的部署方式,即 WAF 設備位置後移,嵌套到中間件上,這樣 WAF 的損耗將分攤到業務機器,這樣的捆綁意味著一榮俱榮,一損皆損,又因位置後移到了業務側,策略下發和管理都極其複雜,且中間件種類繁多,規模一大,這種架構堪稱災難,而隨著業務架構的逐漸優化,一般的互聯網業務架構會前置越來越輕的轉發層,將 WAF 嵌到轉發層,或在轉發層通過 openresty 等方式將請求過一遍旁掛的 WAF 集群,這屬對業務鏈路侵入最輕的一種方式,很多互聯網公司自建的 WAF 採用該架構。

中間件部署:

OpenResty 部署:

對於此類嵌套於中間件的 WAF 架構測試需針對 WAF 模塊的系統耗能和超時為切入點,當中間件或 WAF 模塊達到一定的性能損耗指標,一般 WAF 系統會預留類似硬體設備斷電 bypass 的功能來保障業務可用性的強指標,通過這種途徑即可突破 WAF,比如:

1、針對中間件本身的漏洞(例如: CVE-2018-1336 )/配置錯誤來觸發 DOS,當系統能耗達到閾值,自動關閉 WAF 模塊;

2、針對 WAF 系統的正則策略進行攻擊,通過 ReDoS:

https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS

使策略檢測超時,單條會話跳過 WAF 集群響應,直接通聯後端業務。

旁路

旁掛 WAF 一般不在會話鏈路以內,這意味著針對命令執行、Getshell 類的一條陳述句拿權限的攻擊束手無策,滿足業務性能,犧牲了較多的安全指標,做出這種妥協,一方面是業務/運維強勢,可用性是相關部門較重的 KPI 指標,另一方面可能是 WAF 系統開發和運營人力資源緊張,旁路離線分析提供了一定的緩和空間。

旁路 WAF 可以理解為一套離線分析系統,在各類配置和引數設置上很難同業務機器同步,這導致兩者之間的耦合缺漏會更大,且旁路部署的後置阻斷措施也極具多樣性:IP 維度(4 層封禁、7 封封禁),session 維度(業務路由基於登陸的 cookies 等),給繞過也提供了一些方法,常見的繞過方法有:

1、若系統是通過分光等方式旁掛,那針對前置串聯 WAF 的 SSL 證書繞過方法在這裡一樣通用;

2、通過攻擊測試,很容易判斷出旁路 WAF 同阻斷組件的通聯時間,獲取海量且廉價的代理 IP,控制好單 IP 的測試存活時間,較低成本便可繞過;

3、針對異常協議和中間件特效的攻擊將在後續章節講述,在旁掛 WAF 上均可實現繞過。

WAF 產品架構多樣,除了串聯和旁路外,基於業務特性還有各種各樣的組合方式,之前所在公司基於業務架構單一的特點(系統、語言、中間件、資料庫版本等相關信息全域性一致),只需要關註固定版本的系統/應用漏洞情報,便可採用平日旁掛,漏洞爆發打開串聯開關,漏洞批量修複後恢復旁掛的方式,在安全、效率、成本的博弈中發揮一點能動性。

協議/中間件層面

HTTP 協議是一個漸進工程。

1991 初版草案 (HTTP/0.9) 僅有不足一頁半的內容,在經歷 5 年時間和若干版本的更替後,第一個正式版 HTTP/1.0 標準誕生,這時它已經變成一份密密麻麻長達 50 頁的文件,期望能彌補過往標準里的諸多缺陷。很快到了 1999 年,HTTP/1.1 的 7 位署名作者顯然指望該協議能涵蓋到方方面面,導致的結果就是一份長達 150 頁的大作。但這些越來越宏偉的文件里很大篇幅的內容和我們當下實際使用的 Web 並不特別相關,因為他們對新功能的追逐比修複舊有缺陷更感興趣。—— 《Web 之困》

處於尚未完結的漸進工程中,強制的向下兼容,加之各類中間件對協議的解讀和實現花樣百出,導致整個協議骨幹健壯清晰,細枝末節處卻錯綜繁雜,越是複雜有異議的地方,越是存在安全隱患。

如《Web 之困》書中所描述,協議版本的升級,大多數精力都投入到了新花樣和動人功能的開發上,缺陷的修補向來是不受人待見的,而協議側的缺陷卻往往是致命的。

DEFCON 24 會議上,regilero 有一篇名為《Hiding Wookiees In Http》的演講,詳細分析了 HTTP 協議中 Keepalives 和 Pipelines 組合使用上的缺漏,可導致會話註入和快取投毒,在 WAF 繞過上也提供了一條路徑。

Keepalives 雖然在 HTTP1.0 版本便可以使用,但並沒有得到官方的確認,是瀏覽器爆炸發展階段的民間戰勝官方的勝利,HTTP1.1 版本後才開始作為預設引數參與到請求中,這條引數也屬於新版本令人心動的嶄新功能,引入的原因也是為瞭解決請求量級鬥升,新建立連接帶來的系統和網絡損耗,功能大致如下所示:

HTTP Pipeline:

HTTP KeepAlive:

HTTP 1.0:

功能設計本身的意圖是多請求單連接,但‘多請求’這個場景又有多般演繹,比如下圖這種請求,在 WAF 端的識別上,這屬於一個請求,邏輯也是通過拆解 Key、value 的樣式以 Body 內容讀取第二個請求的內容,當然是屬於異常的 Key-Value 結構,這樣第二個包的內容便很容易繞過 WAF 策略直接進行攻擊了。

Keeplive 繞過:

關於 HTTP 協議特性的安全缺陷,還有一個值得說道的漏洞,2011 年 BlackHat 大會有一篇名為《Checkmate with Denial of Service》的演講,闡述了一系列 DOS 漏洞,其中有部分是關於 HTTP 慢速攻擊的分析,此後漫長的一段時間中,slowloris 都是諸多大型 DDOS 事件中的主角,關於慢速 DOS 的原理其實就是利用了 HTTP 的特性,通過 Keepalives 特性,發起大量請求,修改 Content-Length,Hold 住會話,在超時前定期發送小包,保持存活狀態,使服務端執行緒數打滿,又不得釋放,服務便處於不可用狀態,這種攻擊在前文所述的針對中間件的 DOS 中不失為一種有效的攻擊繞過方式。

除了協議特性以外,異變的 HTTP essay-header 也有可能提供繞過 WAF 的捷徑,2018 年的 AppSec 大會上,有一篇《hacker WAF bypass techniques》的演講,通過以下幾個方式進行 WAF 繞過:

1、字符集編碼;Content-Type 頭中使用 charset 定義字符集的應用場景不只有在 responses 中,request 中同樣可以使用,而變換字符編碼集以後,基於規則引擎的 WAF 則徹底失控。

1、內容型別格式;在特定中間件版本下 Key-value 可以通過檔案上傳的型別 multipart/form-data 進行提交,而 WAF 針對此型別側檢測一般是只針對上傳漏洞,導致常規的 xss、sqli 便可以通過該方式進行 bypass,即使存在各通用型別的漏洞檢測,也可通過 Fuzz 異變上傳型別的格式,達到 WAF 無法識別,後端中間件可以解析的目的:

當然以上 Bypass 的路徑並非通用的,很大情況與不同中間件對 HTTP 的理解和運用有關,詳細中間件系統和版本測試情況可參見表格:

https://drive.google.com/file/d/0B5Tqp73kQStQU1diV1Y0dzd1QU0/view

基於協議/中間件的安全缺陷並不全然是功能帶來的,有時帶業務特性的配置也會有缺漏,且這種缺漏是前端 WAF 和後端業務中間件功能差異所必然存在的,也是大多數通用 WAF 產品很難和業務適配的死角,突出的例子如:

1、請求包大小限制;很多後端業務存在上傳功能,所以請求資料限制上往往會較大,而前置 WAF 系統,需要有較高的響應時間,請求包較大時往往超過內置的性能和耗時閾值,所以可直接發送大量無意義的引數,尾端帶攻擊引數便可直接繞過 WAF 系統。

系統/資料庫/編程語言層面

系統、資料庫和編程語言層面,屬於對抗 WAF 策略的正面戰場,這類文章網上佳作不勝列舉,但其達成繞過的功效並不具通用性,比如系統級別的繞過可能圍繞命令執行、LFI 之類的漏洞,資料庫相關的繞過是圍繞 Sqli 類漏洞,且兩者的繞過思路大致相同,即利用系統/資料庫特性或不常用函式繞過 WAF 策略特征,至於編程語言的繞過方式則相對靈活,這也是動態語言的特性決定的,本文主旨是 WAF 繞過的捷徑,正面對抗策略內容便不多做贅述(正面硬剛 WAF 規則也有成熟工具,詳細內容參見參考文件中 2016 blackhat 大會上的《Another Brick off The Wall: Deconstructing Web Application Firewalls Using Automata Learning》一文),每個型別各介紹一類比較有代表性的 Bypass 方法:

1、系統層面,利用 Linux 通配符特性繞過 WAF 策略;在 bash 語法中,可以使用與系統檔案相同數量的 “?”, “/” 來匹配該檔案;用未初始化的變數隔離特征字符;用 ‘ 字符拆解再拼貼,繞過字符匹配。

1、資料庫層面,利用 mysql 註釋和註釋特性繞過 WAF 策略;在 ModSecurity (最常見的開源 WAF 框架)預設策略中,union select 這類 Sqli 註入語法一般是貪婪匹配 union 和 select 之間的字符、數字、下劃線、左括號,很容易通過插入 /* */註釋繞過;當變更規則過濾掉註釋,依然可以通過在註釋中使用 ! 加版本號包裹關鍵詞來繞過檢測,因為只要 mysql 的當前版本等於或大於該版本號,則該註釋中的 sql 陳述句將被 mysql 執行;

1、編程語言層面,利用 PHP 陣列特性繞過 WAF 策略;在 PHP 中每個字串都可以當作陣列,這樣基於字串的正則匹配就很容易被繞過了。

限於文章篇幅,簡單描述了 WAF Bypass 測試的整體框架,相當一部分繞過方法未能展示,由於議題寬泛,時間緊迫,故倉促收尾,算理清框架脈絡,避免後來者按圖索驥的浪費時間。

參考文件

Abuse-ssl-bypass-waf:

https://github.com/LandGrey/abuse-ssl-bypass-waf

Bypassing Web-Application Firewalls by abusing SSL/TLS:

https://0x09al.github.io/waf/bypass/ssl/2018/07/02/web-application-firewall-bypass.html

WAF Bypass Techniques – Using HTTP Standard and Web Servers’ Behaviour:

https://www.slideshare.net/SoroushDalili/waf-bypass-techniques-using-http-standard-and-web-servers-behaviour

基於 Openresty 的雲 WAF 工作原理:

https://www.yqfy.net/base-on-openresty-waf

Regular expression Denial of Service – ReDoS:

https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS

《Web之困》:

https://book.douban.com/subject/25733421/

DEFCON 24 《Hiding Wookiees In Http》:

https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Regilero-Hiding-Wookiees-In-Http.pdf

Checkmate with Denial of Service:

https://media.blackhat.com/bh-dc-11/Brennan/BlackHat_DC_2011_Brennan_Denial_Service-Slides.pdf

Web Application Firewall (WAF) Evasion Techniques:

https://medium.com/secjuice/waf-evasion-techniques-718026d693d8

Web Application Firewall (WAF) Evasion Techniques #2:

https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0

Web Application Firewall (WAF) Evasion Techniques #3:

https://www.secjuice.com/web-application-firewall-waf-evasion/

Another Brick off The Wall: Deconstructing Web Application Firewalls Using Automata Learning:

https://www.blackhat.com/docs/eu-16/materials/eu-16-Argyros-Another-Brick-Off-The-Wall-Deconstructing-Web-Application-Firewalls-Using-Automata-Learning.pdf


●編號803,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

 

Linux學習

更多推薦25個技術類微信公眾號

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

    閱讀原文

    赞(0)

    分享創造快樂