通過分析關于互聯(lián)網(wǎng)攻擊增長的幾個潛在因素，提到了關于個人信息已被明碼標價在互聯(lián)網(wǎng)上進行非法購買，而更多的黑客開始將精力投入到企業(yè)網(wǎng)站攻擊這樣的一個高回報率的攻擊行為中。也提到了關于web應用防火墻對于保護企業(yè)網(wǎng)站和防止數(shù)據(jù)竊取方面的獨到之處。今天我們就通過一個攻擊實例來具體了解攻擊是怎么發(fā)生的，又是如何進行數(shù)據(jù)竊取。另外，部署專業(yè)的web應用防火墻加上嚴格的安全管理策略才能真正為企業(yè)提供細致到位的安全防護。

 

文中引用的攻擊實例發(fā)生在一家國外已部署WEB應用防火墻產(chǎn)品的企業(yè)，由于處在網(wǎng)絡調(diào)整階段，所以防火墻被臨時置于“被動模式”（被動模式：只監(jiān)控并記錄對網(wǎng)站的訪問，任何攻擊防護都未啟用），正是由于一時的疏忽，給黑客侵入該公司市場部數(shù)據(jù)庫制造了機會。分析顯示，發(fā)起該攻擊的黑客采用了多項應用攻擊手段，并且從亞洲和歐洲兩個區(qū)域分別發(fā)起攻擊。竊取了一部分資料，由于企業(yè)及時發(fā)現(xiàn)了攻擊行為，并將防火墻恢復到了主動模式（主動模式：監(jiān)控記錄對網(wǎng)站的訪問，并且提供安全防護），沒有造成更嚴重的數(shù)據(jù)泄漏。

 

小貼士1：Web 應用的設計保證了數(shù)據(jù)能夠透明地穿過網(wǎng)絡防火墻，因此傳統(tǒng)的四層網(wǎng)絡防火墻無法檢測并阻止七層（應用層）的攻擊；然而，許多企業(yè)都還沒有充分意識到四層安全措施已經(jīng)不能滿足當前的需求，從而使得這些企業(yè)極易受到針對各種應用的攻擊行為。 

 

小貼士2：不管動機如何，針對 Web 應用的攻擊，尤其是 SQL 注入攻擊，都被證明是滲透網(wǎng)絡并竊取數(shù)據(jù)的最有效途徑：

Web 應用攻擊僅占全部數(shù)據(jù)泄露事件的 54%，但被竊取的數(shù)據(jù)占92％

SQL 注入攻擊僅占 Web 應用攻擊的25%，但是被竊取的數(shù)據(jù)占89%

 

數(shù)據(jù)泄露事件說明：

 

此次數(shù)據(jù)泄露事件的主要原因有以下幾點：

1. 網(wǎng)站的PHP 代碼存在錯誤

2. 原本應定期進行的代碼漏洞掃描被忽略，導致沒有及時發(fā)現(xiàn)PHP代碼問題

3. 網(wǎng)站維護人員沒有開啟Web應用防火墻的安全防護功能

對有漏洞的代碼未加以保護，受到攻擊只是個時間問題。根據(jù)Web應用防火墻的記錄和報告，攻擊的過程記錄如下：

 

時間                                         描述

2011-04-10 00:07:59 GMT 第一個IP開始對網(wǎng)站主頁進行探測

2011-04-10 00:16:15 GMT 攻擊者在嘗試了175個URL后找到了存在漏洞的URL，開始探測數(shù)據(jù)庫

2011-04-10 03:10:43 GMT 第二個IP地址開始對存在漏洞的URL進行探測

2011-04-10 10:10:00 GMT 攻擊開始，黑客試圖檢索數(shù)據(jù)庫用戶

2011-04-10 10:16:00 GMT 攻擊者放棄針對用戶的攻擊，轉(zhuǎn)而嘗試獲取數(shù)據(jù)庫的列表(list)和架構(schema)

2011-04-10 10:19:00 GMT 攻擊者開始盜取數(shù)據(jù)

2011-04-10 17:30:00 GMT 發(fā)現(xiàn)網(wǎng)站被攻擊

2011-04-10 17:37:00 GMT 發(fā)現(xiàn)WEB應用防火墻針的防護功能暫未開啟

2011-04-10 17:39:59 GMT 開啟WEB應用防火墻的防護功能， 此后沒有再發(fā)現(xiàn)任何攻擊行為發(fā)生

2011-04-10 21:00:00 GMT 源自這些IP地址的攻擊不再進行停止

 

數(shù)據(jù)泄露事件具體過程：我們將以圖解的方式結(jié)合各式日志來分解這次攻擊。

 

 

 

 

發(fā)現(xiàn)漏洞

 

  第一次攻擊的開始時間為4月9日下午5:07，攻擊者的IP地址為 115.134.249.15，來自馬來西亞的吉隆坡，該日志條目證實了認為攻擊來自馬來西亞的在線報告。我們還注意到，攻擊者用以探測 Web 網(wǎng)站SQL 注入缺陷的是White hats設計的滲透工具的一個修改版；

 

  第一個攻擊者使用自動工具逐步遍歷網(wǎng)站，并對每個允許輸入的參數(shù)項注入一系列 SQL 命令，查找可能的漏洞。SQL 注入工具于下午 5:16 找到了第一個漏洞，但沒有繼續(xù)深入該網(wǎng)頁；下午 8:10，IP地址為 87.106.220.57 的第二個客戶端加入了攻擊行列。經(jīng)追蹤發(fā)現(xiàn)，第二個IP地址的服務器在德國，但尚不清楚該服務器是一個代理，還是第二個攻擊者。

 

 

 從Web應用防火墻的日志發(fā)現(xiàn)，攻擊者似乎利用了第二個客戶端對已發(fā)現(xiàn)的漏洞進行了手動攻擊，而主要攻擊仍然集中在繼續(xù)對Web 站點進行掃描，以獲取其它漏洞。最終，攻擊者們集中力量攻擊非主頁的一個WEB 頁面上的一行弱代碼，其輸入?yún)?shù)并未進行控制審查。以下是那段代碼：<?=Foo_Function( $_GET[‘parameter’] )?> //獲得用戶輸入

 

     因未對輸入值進行限定，該代碼錯誤讓攻擊者們得以向 HTML的輸入?yún)?shù)進行注入 SQL 命令來攻擊后臺數(shù)據(jù)庫。網(wǎng)站開發(fā)者們被告知絕對不要信任用戶的輸入；所有的用戶輸入在發(fā)送到后臺服務器之前必須進行審查。然而，通過上述案例，你可以發(fā)現(xiàn)僅僅用眼睛很難發(fā)現(xiàn)所有的代碼錯誤。這就是為什么除了必要的防范性代碼設計以外，企業(yè)還需要使用漏洞掃描工具和Web應用防火墻設備來為可能的缺陷提供保護。由于自動式掃描攻擊的存在，在一個含有成千上萬條代碼的 Web 站點中，只要有一個簡單的錯誤就能讓攻擊得逞。所以還需要添加了一條代碼，對受影響的頁面上的輸入進行限定審查，以保護未來的可能攻擊。

 

從漏洞到數(shù)據(jù)泄露

 

  攻擊者們發(fā)現(xiàn)了存在漏洞的頁面后，企圖竊取數(shù)據(jù)庫用戶賬號。在接下來的 10個小時里，攻擊者們嘗試了數(shù)種方法來強行闖入后臺數(shù)據(jù)庫，但是每次都以失敗告終。上午3:06，攻擊者們改變了策略，集中攻擊后臺數(shù)據(jù)庫Schema。事實證明，正是這個方法。到 3:19am，攻擊者們已經(jīng)竊取了第一批電子郵箱賬號。

 

  網(wǎng)站管理員在10:30am 發(fā)現(xiàn)網(wǎng)站被攻擊，并于10:39am將Web應用防火墻切換到主動模式開啟保護，阻止了來自 IP 地址為 115.134.249.15 的所有后續(xù)攻擊。接下來的數(shù)小時里，攻擊者們繼續(xù)對剩下的 Web 頁面進行定時攻擊，Web應用防火墻設備將所有這些攻擊拒之門外。從攻擊文件證實了我們的結(jié)論，即：攻擊者們使用了一種自動掃描滲透工具，大范圍地注入 SQL 命令。最終，攻擊者們從兩個攻擊IP地址總共對 175 個URL 發(fā)送了 110,892 個 SQL 注入式命令，其頻率為每分鐘 42次。

 

  追蹤Web應用防火墻上的防火墻日志和訪問日志時，確定攻擊者們竊取了市場部數(shù)據(jù)庫中的兩套記錄，包含 21,861 個用戶名和電子郵件記錄。因為這兩套記錄還存在副本，并且當中有許多用戶已離開原先的公司，所以受影響的用戶數(shù)比被竊取記錄的總數(shù)要小得多。

 

 任何數(shù)據(jù)泄露都是嚴重的問題。盡管這次攻擊的后果還沒有進一步的顯現(xiàn)，但是類似的泄漏數(shù)據(jù)中的郵件帳號，可能被用來對受影響的用戶進行釣魚攻擊。 

 

結(jié)論

 

   這次攻擊事件，是一個非常有借鑒意義的教材；為企業(yè)和網(wǎng)管人員分享了經(jīng)驗，從多個角度驗證對于網(wǎng)站攻擊或者數(shù)據(jù)竊取，部署專業(yè)的設備和嚴格的安全管理策略必不可少。

梭子魚Web應用防火墻設備產(chǎn)品能夠為網(wǎng)站提供對包括SQL注入在內(nèi)的各種攻擊的防護。即使網(wǎng)頁中包含PHP代碼漏洞，但只要開啟梭子魚Web應用防火墻的防護功能，所有的攻擊都在幾秒鐘內(nèi)都被阻止。而且，梭子魚Web應用防火墻的日志和報告提供了完整的攻擊記錄以及失竊數(shù)據(jù)的記錄，從而為分析和研究Web應用安全提供了一個很好的案例。為了保障網(wǎng)站的安全，在編寫高質(zhì)量的代碼和進行漏洞測試的同時，梭子魚Web應用防火墻設備應該成為防御應用層攻擊的第一道防線。