Part1 前言
大家好，上期分享了一次MS12-020藍屏漏洞的巧用。這篇文章源于之前做的一個銀行紅隊項目，遇到到了一個Oracle資料庫的SQL注入漏洞，但是網上能搜尋到的各種SQL語句都沒法出資料，是以客戶不認可這個漏洞的危害性，于是就開始了對這個Oracle的SQL注入繞WAF的探索過程：
Part2 研究過程
- SQL注入判斷過程
經過對Web應用一系列的手工漏洞測試，發現這個網站對Web漏洞的攔截至少有兩層防護：
1. 外網部署了WAF裝置攔截，對正常的SQL注入關鍵字有攔截；
2. 繞過外圍的Waf裝置後，發現應用程式本身也對SQL注入漏洞進行了嚴格的過濾；
這相當于兩個WAF串聯的情況，非常難解決。接下來看一下這個注入點情況：
使用burpsuite不斷地抓包重放，當看到這個POST請求的時候，proCode=002&specIds=8866@871（防止洩露項目資訊，原來的資料包就不貼圖了），發現參數的值中有一個@符号，直覺和經驗告訴我，就覺得這裡面會存在安全問題。因為我猜想，參數值為了保留@這個特殊字元，一定會對很多危險字元做出讓步。是以重點對specIds參數進行了測試，還真發現了SQL注入漏洞。這個注入漏洞是這樣判斷出來的：
proCode=002&specIds=8866@871*(1-0)，傳回正常
proCode=002&specIds=8866@871*(1-1)，傳回錯誤
- SQL注入攔截關鍵字判斷
這些都是SQL注入漏洞的基礎，這裡就不細講了。接下來要做的是通過這個注入漏洞跑出資料，否則客戶不認可這個漏洞。
首先看一下這個注入點過濾了哪些字元，specIds參數經過大量的手工測試，發現至少有以下過濾：
1. and、or 、xor、like、true等常見SQL語句的關鍵字通通不能用，大小寫轉換也不行。
2. substr、ascii、CHR、wm_concat、lower、upper等Oracle常見sql語句出資料的關鍵函數不能用。
3. | 、<、>、!等被幹掉。（對于Oracle注入來講，|豎杠被過濾掉，受限是非常大的）
4. select、from等SQL注入出資料的關鍵字被幹掉。
看到這裡感覺挺難的，但是比較幸運的是，這個specIds參數的單引号、（）左右括号、*沒有過濾。尤其是單引号沒被過濾，這個非常關鍵，為這個注入漏洞能夠跑出資料留下了一線生機！
- 檢視Oracle資料庫手冊
select、from這兩個關鍵字被過濾了，想要出資料很難的。于是我從網上各種搜尋，把Oracle資料庫的關于資料查詢的各種函數都找出來了，測試了一遍，幾乎全被攔截掉了。但是幸運的是有一個instr函數成功繞過了所有防護，沒被攔截。
接下來看看Oracle資料庫手冊上對INSTR函數的用法怎麼描述的（這些翻譯過來的中文使用說明看起來非常難以了解，我看了大半天才看明白）：
文法: INSTR（string1, string2[a,b]）
功能: 得到在string1中包含string2的位置。string1是從左邊開始檢查的，開始的位置為a，如果a是一個負數，那麼string1是從右邊開始進行掃描的。第b次出現的位置将被傳回。a和b都預設設定為1，這将會傳回在string1中第一次出現string2的位置。如果string2在a和b的規定下沒有找到，那麼傳回0。位置的計算是相對于string1的開始位置的，不管a和b的取值是多少。
根據手冊構造出了以下SQL注入語句：specIds=816Q@Q871*(instr(sql插入點,'%s',%s)-(%s-1))
“sql插入點”需要替換成我們想要查詢的sql語句，這裡需要找一個不包含select、from的語句寫法，最終經過測試，發現以下語句可行：
utl_inaddr.get_host_address()，組合起來就是：
specIds=8866@871*(instr(utl_inaddr.get_host_address(),'%s',%s)-(%s-1)) &channelId=128
- python腳本編寫
以下是我寫的python腳本的一個片段，我把域名、url位址都給打碼了，大家可以照着改出一版自己的小腳本：
Part3 總結
1. Oracle注入、Mysql注入等等遇到過不了的WAF，多去查查相關資料庫的各種特殊函數，非常有用。
2. SQL注入漏洞的防護最好使用預編譯，對于不能使用預編譯的情況，記得過濾的關鍵字一定要全面。
3. SQL注入漏洞深挖，總會有的。業務複雜度越來越高，各種研發人員更替，研發人員水準參差不齊，業務着急上線疏忽了安全問題整改等原因造成了這一現象。
專注于紅隊、藍隊技術分享
每周一篇，敬請關注