思科 Talos 與多家情報合作伙伴共同發(fā)現(xiàn)了有關“VPNFilter”的更多詳細信息。在我們最初發(fā)布活動調(diào)查結果的幾天里，我們已發(fā)現(xiàn) VPNFilter 所瞄準的設備品牌/型號比最初想象得更多，而且還具有其他的功能，例如向終端進行攻擊的能力。思科 Talos 最近發(fā)布了一篇博客（詳情），其主題關于在小型家庭辦公網(wǎng)絡設備以及網(wǎng)絡連接存儲設備中部署 VPNFilter 的廣泛活動。正如我們在這篇帖文中所述，我們對于這一威脅的研究是持續(xù)性的。發(fā)布這篇帖文之后，我們擁有了許多合作伙伴，他們提供了更多的信息來幫助我們開展此項工作。這篇帖文是過去一周內(nèi)我們的最新調(diào)查結果。
首先，我們確定了此攻擊者還瞄準其他設備，包括目標列表中新出現(xiàn)供應商的一些設備。這些新供應商包括 ASUS、D-Link、華為、Ubiquiti、UPVEL 和中興。另外還發(fā)現(xiàn)了 Linksys、MikroTik、Netgear 和 TP-Link 的新設備。我們目前的研究表明，沒有任何思科網(wǎng)絡設備受到影響。下面提供了更新的設備列表。
我們還發(fā)現(xiàn)了一個新的第 3 階段模塊，它可在通過網(wǎng)絡設備時向網(wǎng)絡流量中注入惡意內(nèi)容。在最初發(fā)布時，我們并沒有掌握關于可疑第 3 階段模塊的所有信息。新模塊允許攻擊者通過中間人功能向終端進行攻擊（例如，它們可以在用戶不知曉的情況下攔截網(wǎng)絡流量并向其中注入惡意代碼）。通過這一新的發(fā)現(xiàn)，我們可以確認，威脅已超過攻擊者在網(wǎng)絡設備本身執(zhí)行操作的范疇，它可以將威脅擴展到受侵害網(wǎng)絡設備所支持的網(wǎng)絡中。我們在下面提供了此模塊（稱為“ssler”）的技術詳情。
此外，我們還發(fā)現(xiàn)了另一個第 3 階段模塊，其中提供了任何缺乏用于禁用設備的 kill 命令功能的第 2 階段模塊。在執(zhí)行時，此模塊特意從設備中刪除 VPNFilter 惡意軟件的痕跡，然后致使設備無法可用。下面還提供了此模塊（稱為“dstr”）的分析。
最后，我們對第 3 階段數(shù)據(jù)包嗅探器進行了進一步研究，包括深入分析它如何尋找 Modbus 流量。
技術詳情
新的第 3 階段模塊
“Ssler”（終端漏洞攻擊模塊 JavaScript 注入）
ssler 模塊（讀作“Esler”）通過攔截通過設備且流往端口 80 的所有流量來提供數(shù)據(jù)泄漏和 JavaScript 注入功能。預計此模塊將使用參數(shù)列表執(zhí)行，參數(shù)列表決定了模塊的行為以及應瞄準的網(wǎng)站。第一個定位參數(shù)控制設備中應存儲被盜數(shù)據(jù)的文件夾。其他指定參數(shù)的用途如下：
? dst：- 所創(chuàng)建的 iptables 規(guī)則使用該參數(shù)來指定目標 IP 地址或者應該應用此規(guī)則的 CIDR 范圍。
? src：- 所創(chuàng)建的 iptables 規(guī)則使用該參數(shù)來指定源 IP 地址或者應該應用此規(guī)則的 CIDR 范圍。
? dump：- dump 參數(shù)中所傳遞的所有域會將其所有 HTTP 頭記錄在 reps_*.bin 文件中。
? site：- 當某個域通過“site”參數(shù)提供時，此域會使其網(wǎng)頁成為 JavaScript 注入目標。
? hook：- 此參數(shù)確定所注入 JavaScript 文件的 URL。
ssler 模塊所采取的第一個操作是配置設備的 iptables，以將流往端口 80 的所有流量重新定向到在端口 8888 上監(jiān)聽的本地服務。它首先使用 insmod 命令將三個 iptables 模塊插入內(nèi)核（ip_tables.ko、iptable_filter.ko、iptable_nat.ko），然后執(zhí)行以下 shell 命令：
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8888
示例：./ssler logs src:192.168.201.0/24 dst:10.0.0.0/16
-A PREROUTING -s 192.168.201.0/24 -d 10.0.0.0/16 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8888
注意：為了確保這些規(guī)則不被刪除，ssler 會先將其刪除，然后在大約每 4 分鐘后再重新添加。
端口 80 上的任何傳出 Web 請求現(xiàn)在都會被 ssler 攔截，并可先進行檢查和操作然后再被發(fā)送到合法的 HTTP 服務。所有 HTTP 請求都會執(zhí)行 sslstrip 操作。也就是說，在將請求發(fā)送到真正的 HTTP 服務器之前會對其進行以下更改：
? 任何 https:// 字符串實例都會被替換為 http://，安全 HTTP 資源請求被轉(zhuǎn)換為不安全請求，以便從中提取敏感數(shù)據(jù)（例如憑證）。
? 如果請求中包含報頭“連接：保持活動狀態(tài)”，則將被替換為“連接：關閉”；
? 如果請求中包含報頭“接受含有 gzip 值的編碼”，則將被轉(zhuǎn)換為“接受編碼：純文本/無”，從而不會使用 gzip 壓縮任何響應（對于圖像等某些文件類型會有例外情況）。
如果主機位于其中一個 dump: 參數(shù)中，則會將請求詳細信息保存到磁盤中以進行泄漏，包括 URL、端口和所有請求報頭。如果主機不存在于 dump: 參數(shù)中，將僅會轉(zhuǎn)儲其中包含憑證的授權報頭或 URL 請求。如果 URL 中包含字符串 assword= 或 ass= 以及以下任一字符串，則可確定其中包含憑證：
? sername=
? ser=
? ame=
? ogin=
? ail=
? hone=
? session%5Busername
? session[password
任何發(fā)送至 accounts.google.com 的包含字符串 signin 的 POST 請求也將被轉(zhuǎn)儲。
作出這些修改之后，ssler 將會使用端口 80 上修改后的請求數(shù)據(jù)來與真正的 HTTP 服務器建立連接。ssler 會從 HTTP 服務器接收響應，并在將其傳遞給受害者之前對該響應進行以下更改：
? “位置”報頭值為 https:// 的響應將被轉(zhuǎn)換為 http://
? 系統(tǒng)忽略以下報頭，即不會發(fā)送至客戶端：
Alt-Scv
Vary
Content-MD5
content-security-policy
X-FB-Debug
public-key-pins-report-only
Access-Control-Allow-Origin
? 整個響應已 sslstrip - 也即，包括 \x20http:// 的所有 https:// 的實例。
? 如果系統(tǒng)提供參數(shù) site: 的域（或域的一部分，例如“google”），其會嘗試將 JavaScript 注入所有 Content-Type: text/html 或 Content-Type: text/javascript 響應中，但要求是字符串<meta name= …>存在且足夠長以適于 hook: 參數(shù)中的字符串。<meta name = ...>標簽將被替換為<script type="text/javascript" src="[hook value]">。之后，系統(tǒng)將與網(wǎng)站相結合的受害者 IP 加入 ssler 內(nèi)部白名單中，且在清除白名單（每四天清除一次）前不會再次成為注入目標。
響應中已 sslstrip 的各域（例如，可見于鏈路中的域）均會被添加到剝離域列表中。后續(xù)由 ssler 模塊攔截到此列表中的域的請求將通過端口 443 上的 HTTPS 發(fā)生，而不是通過端口 80 上的 HTTP 發(fā)生。默認情況下，此列表中有四個域，因此 ssler 將始終通過端口 443 上的 HTTPS 連接至這些域：www.google.com、twitter.com、www.facebook.com 或 www.youtube.com。
“dstr”（設備破壞模塊）
dstr 模塊用于通過刪除正常操作所需的文件使受感染設備無法操作。在刪除系統(tǒng)中的其他文件前，該模塊首先刪除與自身操作相關的所有文件和文件夾，可能為了在調(diào)查分析期間隱藏自己的存在。
深入分析 x86 版本 dstr 模塊后發(fā)現(xiàn)，此模塊首先從磁盤中將其自身刪除，然后停止執(zhí)行父級第 2 階段進程，再搜索所有正在運行的進程，查找名為 vpnfilter、security 和 tor 的進程并終止它們。接下來，顯式地刪除以下文件和目錄：
? /var/tmp/client_ca.crt
? /var/tmp/client.key
? /var/tmp/client.crt
? /var/run/vpnfilterm/htpx
? /var/run/vpnfilter
? /var/run/vpn.tmp
? /var/run/vpn.pid
? /var/run/torrc
? /var/run/tord/hidden_ssh/private_key
? /var/run/tord/hidden_ssh/hostname
? /var/run/tor
? /var/run/msvf.pid
? /var/run/client_ca.crt
? /var/run/client.key
? /var/run/client.crt
? /var/pckg/mikrotik.o
? /var/pckg/.mikrotik.
? /var/msvf.pid
? /var/client_ca.crt
? /var/client.key
? /var/client.crt
? /tmp/client_ca.crt
? /tmp/client.key
? /tmp/client.crt
? /flash/nova/etc/loader/init.x3
? /flash/nova/etc/init/security
? /flash/nova/etc/devel-login
? /flash/mikrotik.o
? /flash/.mikrotik.
? /var/run/vpnfilterw/
? /var/run/vpnfilterm/
? /var/run/tord/hidden_ssh/
? /var/run/tord/
? /flash/nova/etc/loader/
? /flash/nova/etc/init/
dstr 模塊通過使用 0xFF 字節(jié)覆蓋所有可用 /dev/mtdX 設備的字節(jié)來清除閃存。最后，執(zhí)行 shell 命令 rm -rf /* 來刪除文件系統(tǒng)的其余文件，并重啟設備。此時，設備無任何需操作的文件，且無法啟動。
第三階段數(shù)據(jù)包嗅探器的進一步研究
“ps”（第 3 階段數(shù)據(jù)包嗅探器）
第 3 階段數(shù)據(jù)包嗅探模塊的一個示例是 R600VPN MIPS-like（Lexra 架構）示例。本示例中的數(shù)據(jù)包嗅探器正在查找基本身份驗證并監(jiān)控 ICS 流量，且特定于 TP-LINK R600-VPN。惡意軟件使用原始套接字查找預先指定的 IP 地址的連接，僅查看 150 個字節(jié)或更大的 TCP 數(shù)據(jù)包（注意：這是含報頭的完整數(shù)據(jù)包大小。根據(jù) TCP 報頭的大小，PDU 可能約為 56 到 96 個字節(jié)，且仍符合記錄的標準）。惡意軟件可查看，但不可修改網(wǎng)絡流量。要實施能夠修改流量的功能，需要進行非常重大的更改。
對不在端口 502 上的數(shù)據(jù)包進行 BasicAuth 掃描，并記錄該信息。
? 其他：（非 Modbus 流量）：sniffing HTTP basic auth credentials
Destination IP Address == command line argument IP address
Source port > 1024
Source port != 8080
Source port != 8088
Packet Data length > 20 bytes
Packet does not contain
? </ and >
? <?xml
? Basic Og==
? /tmUnblock.cgi
? Password Required
? <div
? <form
? <input
? this. and .get
? {
? }
? 200 OK
? <span
? <SPAN
? <DIV
數(shù)據(jù)包包含“授權：基本”或一個用戶/密碼組合
? 用戶
? User=
? user=
? Name=
? name=
? Usr=
? usr=
? Login=
? login=
? Pass
? Pass=
? pass=
? Password=
? password=
? Passwd=
? passwd=
? 日志記錄：記錄 IP 和端口，但不記錄端口 502 上的數(shù)據(jù)包內(nèi)容。不驗證 Modbus 流量。
Modbus - 記錄 SourceIP、SourcePort、DestinationIP 和 DestinationPort，并將其標記為 *modbus*
所有其他 - 僅在通過基本身份驗證檢查時才將完整數(shù)據(jù)包寫入日志文件
結論
這些新發(fā)現(xiàn)告訴我們來自 VPNFilter 的威脅持續(xù)增長。除了在其他目標設備和供應商中發(fā)現(xiàn)威脅表面更加廣泛之外，還發(fā)現(xiàn)惡意軟件能夠?qū)K端設備進行漏洞攻擊，說明這一威脅的范圍擴展到了設備本身之外，并擴展到了這些設備支持的網(wǎng)絡中。如果成功，攻擊者將能夠?qū)⑷魏嗡韪郊庸δ懿渴鹬镰h(huán)境中，以支持其目標，包括 rootkit、泄漏功能和破壞性惡意軟件。
IOC更新列表
如前所述，我們高度懷疑還有其他我們目前尚未發(fā)現(xiàn)的這一惡意軟件的其他 IOC 和版本。點擊https://www.cisco.com/c/zh_cn/products/security/talos.html，查看思科 Talos 已掌握的及新的 IOC！
已知受影響設備
已知受到此威脅影響的設備如下所列。由于這項研究的規(guī)模之大，我們的許多觀察結果是遠程而非在設備上得出的，因此在很多情況下難以確定具體的版本號和型號。
鑒于對此威脅的觀察結果，據(jù)估計，此列表并不完整且可能有其他設備受到影響。
華碩設備：
RT-AC66U（新）
RT-N10（新）
RT-N10E（新）
RT-N10U（新）
RT-N56U（新）
RT-N66U（新）
D-LINK 設備：
DES-1210-08P（新）
DIR-300（新）
DIR-300A（新）
DSR-250N（新）
DSR-500N（新）
DSR-1000（新）
DSR-1000N（新）
華為設備：
HG8245（新）
LINKSYS 設備：
E1200
E2500
E3000（新）
E3200（新）
E4200（新）
RV082（新）
WRVS4400N
MIKROTIK 設備：
CCR1009（新）
CCR1016
CCR1036
CCR1072
CRS109（新）
CRS112（新）
CRS125（新）
RB411（新）
RB450（新）
RB750（新）
RB911（新）
RB921（新）
RB941（新）
RB951（新）
RB952（新）
RB960（新）
RB962（新）
RB1100（新）
RB1200（新）
RB2011（新）
RB3011（新）
RB Groove（新）
RB Omnitik（新）
STX5（新）
NETGEAR 設備：
DG834（新）
DGN1000（新）
DGN2200
DGN3500（新）
FVS318N（新）
MBRN3000（新）
R6400
R7000
R8000
WNR1000
WNR2000
WNR2200（新）
WNR4000（新）
WNDR3700（新）
WNDR4000（新）
WNDR4300（新）
WNDR4300-TN（新）
UTM50（新）
QNAP 設備：
TS251
TS439 Pro
運行 QTS 軟件的其他 QNAP NAS 設備
TP-LINK 設備：
R600VPN
TL-WR741ND（新）
TL-WR841N（新）
UBIQUITI 設備：
NSM2（新）
PBE M5（新）
UPVEL 設備：
未知型號*（新）
中興通訊設備：
ZXHN H108N（新）
* 以供應商 Upvel 為目標的惡意軟件已被發(fā)現(xiàn)，但我們無法確定所針對的特定設備。
思科 Talos 感謝來自世界各地的所有個體研究人員、公司和情報合作伙伴，他們已站出來主動共享信息和應對這一威脅。您的行動幫助了我們更好地理解這場“戰(zhàn)役”，而且在某種情況下，您的行動直接改善了我們所處的境地。此外，我們深知這是項團隊運動，衷心感謝您的傾情援助。
隨著威脅不斷發(fā)展，我們將繼續(xù)監(jiān)控 VPNFilter，并與我們的合作伙伴合作，以確保我們的客戶持續(xù)受到保護并向公眾公布調(diào)查結果。
思科高級惡意軟件保護（AMP）、云網(wǎng)絡安全（CWS）、網(wǎng)絡安全、ThreatGrid、Umbrella 和網(wǎng)絡安全設備（WSA）均可保護思科客戶免受此威脅的侵害。此外，StealthWatch 和 StealthWatch Cloud 可用于查找與已知 C2 IP 地址和域進行通信的設備。
京公網(wǎng)安備 11010502049343號