羅文宗

（桂林八進(jìn)制信息科技有限公司 浙江 315000）

1 原理說明

這里說的HTML注入并不是什么偽靜態(tài)注入，而是通過向瀏覽器插入額外的字段代碼，混入其他的登陸表單中，從而讓用戶看起來額外的代碼是合法的，一種說白了就是竊取一切用戶信息的手段。類似行為的比如Zeus、Fakelas、還有我天朝的11wer等。

2 攻擊手法

（1）MIM（中間人攻擊）手法實現(xiàn)HTML注入

中間人攻擊，意思是把我們發(fā)起攻擊的主機(jī)放置在web服務(wù)器和受害者 PC之間的通信中。從而可以在服務(wù)器響應(yīng)報文到達(dá)受害者PC之前，我們可以替換或者插入數(shù)據(jù)來修改報文。從而達(dá)到了欺騙的效果。

但是現(xiàn)在一般由于SSL復(fù)雜性以及要做到MIM攻擊需要一個獨立的網(wǎng)絡(luò)位置偵察點，所以MIM攻擊注入HTML也只是一種雞肋的手法。不管在windows下還是linux下，有興趣的朋友可以自己測試下。

（2）修改IE瀏覽器的文檔模型（DOM）實現(xiàn)HTML注入

首先向部分不清楚DOM的朋友簡單解釋一下DOM。DOM，全稱Document Object Model，即文檔對象模型，它是組成web網(wǎng)頁多個元素的集合。

因為網(wǎng)頁中的元素，比如鏈接、表單、文本框、表格等都是可以通過特殊的接口進(jìn)行操作，所以我們才說是基于DOM的HTML注入，這里要引入兩個與操作DOM最相關(guān)的接口，分別是IWebBrowser2和IHTMLDocument2。

當(dāng)我們構(gòu)造好惡意代碼，連接到瀏覽器網(wǎng)頁的DOM后，可以執(zhí)行一些監(jiān)視用戶訪問過的URL、強(qiáng)行操控瀏覽器發(fā)送POST數(shù)據(jù)報文到我們控制的接收地址、從HTML表格中刪除一些余額明細(xì)報表的交易數(shù)據(jù)等（銀行木馬竊取用戶信息的基本手法）。

我們要先通過加載一個DLL（動態(tài)鏈接庫）到IE瀏覽器，用來訪問我們需要的接口，或者直接從IE的獨立進(jìn)程中訪問需要的接口。

這里演示一下，一個簡單的HTML登陸表單，如圖，地址是：http：//localhost/login.php

提交表單的method為POST，action為checklogin.php。我們知道了這個表單的行為，那么就要開始分析如何進(jìn)行攻擊。方法是對其進(jìn)行HTML注入來改寫表單中的action，這樣當(dāng)用戶點擊Login按鈕時，瀏覽器可以將證書發(fā)送到我們控制的接收地址。

確定了方向，開始構(gòu)造惡意代碼，讓它來完成我們所需要的行為。簡單寫了一個程序，運行后將等待用戶訪問http：//localhost/login.php，然后使用DOM的接口挖掘表單中的元素，最后將表單里的action地址更改為我們偽造的另一個接收地址http：//localhost/nandi.php，這樣就完成了一次偽造的基于瀏覽器DOM實現(xiàn)的HTML注入。

項目源代碼參考：http：//ruo.me/doc.php

（3）利用API鉤子實現(xiàn)HTML注入

API鉤子來實現(xiàn)HTML注入簡單并且有效，但是非常容易被檢測出來，任何反rootkit的掃描器都可以列出被攔截的函數(shù)。我們所利用的API鉤子通常攔截的可疑函數(shù)是IneternetReadFile和HttpSendRequest。

IE瀏覽器調(diào)用InternetReadFile獲取來自服務(wù)器的數(shù)據(jù)字節(jié)，然后在瀏覽器中顯示，所以可以通過來接這個函數(shù)，讓我們的程序可以在數(shù)據(jù)回顯給用戶之前更改應(yīng)答數(shù)據(jù)。另一面，HttpSendRequest發(fā)送了一個包含POST的請求到web服務(wù)器，通過攔截HttpSendRequest函數(shù)，我們構(gòu)造的惡意代碼可以從POST中提取出證書，即使是HTTPS，也就是經(jīng)過SSL加密的網(wǎng)頁也會存在該注入。

稍微懂一點的人都清楚，InternetReadFile接收的是解密后的數(shù)據(jù)，而HttpSendRequest接收的是加密前的數(shù)據(jù)。所以我們構(gòu)造的代碼編譯好依然可以截獲到一切數(shù)據(jù)。

項目源代碼參考：http：//ruo.me/api.php

3 防范與檢測HTML注入

一般來說，API鉤子是很容易被反rootkit掃描器檢測出來的，這一點前面我也說到過。相對于API鉤子，DOM修改更加具有欺騙性，因為一般沒有什么正當(dāng)理由去攔截InternetReadFile和HttpSendRequest，而修改DOM不會攔截任何函數(shù)。

這說明了什么呢？有些朋友可能已經(jīng)想到了，那就是說，無論用的是API鉤子還是修改DOM，對于HTML的注入都僅僅是在瀏覽器進(jìn)程的內(nèi)存中顯示。特別是瀏覽器開啟的緩存功能會在緩存文件夾下生成用戶訪問頁面的原始副本。于是當(dāng)我們執(zhí)行doc.exe后（相關(guān)代碼請參考前面，后綴名為php只是為了方便大家在網(wǎng)絡(luò)上查看相關(guān)代碼，實際需要編譯。），我們再來訪問http：//localhost/login.php，選擇“查看源代碼”，這個時候瀏覽器將訪問磁盤中的緩存頁面而不是從內(nèi)存中訪問修改后頁面。

所以如果通過”查看源代碼“的方式并不能分辨出瀏覽器中的頁面元素是否已被修改。如圖1所示：

圖1 頁面

對于檢測HTML注入，我這里編譯了一個工具，思路原理如下：

（1）針對我們指定需要檢查的每個頁面啟動一個新的IE進(jìn)程，并等待加載，并且額外等待幾秒鐘，目的為了讓我們的惡意代碼執(zhí)行HTML注入。

（2）訪問瀏覽器的DOM，使用和惡意代碼相同的API，但是不執(zhí)行任何修改，只是把頁面內(nèi)容副本轉(zhuǎn)存到程序目錄，并命名為url_dom.txt。

（3）檢查瀏覽器是否使用GetUrlCacheEntryInfo API緩存了指定頁面的副本。如果是，那么將Internet臨時文件夾中的緩存文件以url_cache.txt復(fù)制到程序目錄中。

（4）截取IE窗口，并保存到程序目錄，以便查看瀏覽器中Html頁面的外觀。

下面是程序演示示例：

C：>echo http：//localhost/login.php ->url.txt

C：>HtmlInjectionDetector.exe -f url.txt -s

結(jié)果如下：

圖2 演示結(jié)果

現(xiàn)在應(yīng)有三個文件：

a -- url_dom.txt -- IE瀏覽器中顯示的Html副本。

b -- url_cache.txt -- web服務(wù)器返回的原始Html副本。

c -- url.bmp -- 訪問頁面的屏幕截圖

如圖所示，通過瀏覽這些文件，可以很容易確定頁面的修改情況

圖3 頁面修改情況

不過如果替換了Https網(wǎng)頁中的表單并以POST方式將數(shù)據(jù)提交到Http網(wǎng)頁，那么瀏覽器會彈出提示或警告。但是我們可以再加入一些代碼來通過修改IE設(shè)置中的錯誤消息模式來禁用這些提示或警告，這里就不多贅述。

工具項目地址參考：http：//pan.baidu.com/share/link?shareid=3656562106&uk=1412640330

（注意：工具會自動打開需檢查的url，在頁面上停留2秒左右不要關(guān)閉，否則無法抓取緩存和當(dāng)前副本?。?/p>