在安全測試的過程中，我們通常使用應用層工具直接測試待測目標，比如一個HTTP網站應用程式，我們可以直接傳送HTTP請求來對其進行模糊測試，而對於HTTPS，也可以建立SSL連線後直接傳送HTTP請求對其進行模糊測試

然而在某些黑盒測試中，由於資訊不對稱，我們無法獲悉應用層協議的具體格式，因此難以直接在應用層進行安全測試，這時我們需要對應用層協議本身進行FUZZ，這就需要使用更底層協議來進行安全測試

本文以著名的RTS遊戲魔獸爭霸3為例，介紹在網路層對TCP連線進行安全測試的基本工具、方法、以及漏洞挖掘思路

0x00 概述

---

我想測試魔獸爭霸3聯機遊戲的安全問題

然而魔獸爭霸3並沒有使用HTTP協議來進行通訊，因此我既不能用burp來proxy攔截，也不能直接用curl等常用工具來進行FUZZ

魔獸爭霸3聯機對戰使用了TCP連線，自己定義了一套資料包格式（已經有人分析過了，但在本文中我們假設資料包格式未知）

所以我要在傳輸層對魔獸爭霸3的TCP連線進行安全測試，重點測試以下內容：

1. 斷線重連
2. 網路的延遲與丟包
3. TCP原始資料的嗅探/修改
4. TCP連線的重放與互動式測試

0x01 斷線測試

---

由於魔獸爭霸3並沒有斷線重連機制，所以TCP連線斷開後會直接導致遊戲斷開，而在許多第三方對戰平臺上，玩家的離線等同於戰敗，因此也誕生了許多遊戲“踢人”外掛

下面使用WooyunWifi路由器上的dsniff工具包中的tcpkill工具為例進行測試：

[email protected]:~# tcpkill -i br-lan port 6112
tcpkill: listening on br-lan [port 6112]
192.168.1.143:59892 > 192.168.1.163:6112: R 2875503812:2875503812(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504063:2875504063(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504565:2875504565(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875503812:2875503812(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504063:2875504063(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504565:2875504565(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970133:2041970133(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970389:2041970389(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970901:2041970901(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875503818:2875503818(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504069:2875504069(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504571:2875504571(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970133:2041970133(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970389:2041970389(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970901:2041970901(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875503824:2875503824(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504075:2875504075(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504577:2875504577(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970142:2041970142(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970398:2041970398(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970910:2041970910(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875503824:2875503824(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504075:2875504075(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504577:2875504577(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970151:2041970151(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970407:2041970407(0) win 0
192.168.1.163:6112 > 192.168.1.143:59892: R 2041970919:2041970919(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875503830:2875503830(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504081:2875504081(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875504583:2875504583(0) win 0
192.168.1.143:59892 > 192.168.1.163:6112: R 2875503830:2875503830(0) win 0

這裡演示的是全域性切斷，在實際應用場景中也可以使用包過濾表示式切斷特定IP的連線

0x02 網路的延遲與丟包

---

由於魔獸爭霸3是一個實時對戰的遊戲，因此網路狀態也會影響遊戲的進行，魔獸爭霸3本身對於實時操作的要求並不高，但是形如DOTA之類的自定義遊戲模式對網路的延遲極為敏感，如果玩家在DOTA遊戲中有很大延遲，可能會直接導致團滅並且遊戲失敗

下面使用WooyunWifi路由器上的tc工具中的netem核心模組為例進行測試：

tc qdisc add dev wlan0 root netem delay 1s

由於網路延遲，玩家控制的英雄在延時時間內無法響應玩家的操作

當然，您也可以用包過濾表示式指定任意ip的延時規則，包括隨機浮動的延時時間

0x03 TCP原始資料的嗅探/修改

---

如何嗅探TCP資料包已經是婦孺皆知的常識了，用wireshark或者tcpdump之類的都可以

至於如何修改TCP資料包，我推薦使用TCP透明代理模式來進行操作，原理其實和HTTP透明代理相似

至於工具我測試了3款，各有千秋：netsed簡單實用少依賴，mitmproxy無比強大有擴充套件，bettercap則是替代ettercap的ruby工具

首先，我們在11對戰平臺上新建一個房間，然後開啟wireshark，抓取war3的伺服器埠（11對戰平臺使用的是伺服器建主策略，並不是玩家建立主機，而是在伺服器上有一個proxy專門用來與各個客戶端通訊）

我們可以看到建主伺服器ip為119.188.39.137，埠為2012，而聊天資料以及最開始交換使用者名稱的資料都是明文的，而且後來測試發現也沒有資料完整性驗證

下面使用WooyunWifi路由器上的netsed工具為例進行測試：

iptables -t nat -A PREROUTING -p tcp --dport 2012 -j REDIRECT --to 10101

netsed tcp 10101 119.188.39.137 2012 s/lxj616/wooyun



netsed 1.2 by Julien VdG <[email protected]>
  based on 0.01c from Michal Zalewski <[email protected]>
[*] Parsing rule s/lxj616/wooyun...
[+] Loaded 1 rule...
[+] Using fixed forwarding to 119.188.39.137,2012.
[+] Listening on port 10101/tcp.
[+] Got incoming connection from 192.168.1.163,53956 to 119.188.39.137,2012
[*] Forwarding connection to 119.188.39.137,2012
[+] Got incoming connection from 192.168.1.143,50527 to 119.188.39.137,2012
[*] Forwarding connection to 119.188.39.137,2012
[+] Caught client -> server packet.
[*] Forwarding untouched packet of size 771.
[+] Caught client -> server packet.
[*] Forwarding untouched packet of size 791.
[+] Caught server -> client packet.
[*] Forwarding untouched packet of size 24.
[+] Caught server -> client packet.
[*] Forwarding untouched packet of size 24.
[+] Caught client -> server packet.

於是整局遊戲裡lxj616都在其他使用者眼裡變成了wooyun，包括聊天和玩家列表

當然，netsed只有簡單的替換功能，下面介紹一些更靈活的解決方案（不再以war3為例）

mitmproxy的官方示例介紹瞭如何修改TCP資料

https://github.com/mitmproxy/mitmproxy/blob/master/examples/tcp_message.py

下面使用Woobuntu系統上的mitmproxy工具為例進行測試：

bettercap的官方示例介紹瞭如何修改TCP資料：

https://www.bettercap.org/docs/proxying/tcp.html#sample-module

下面使用Woobuntu系統上的bettercap工具為例進行測試：

注：tcp-proxy剛開始時顯示未啟動，後面在輸出資訊中後續啟動的tcp-proxy

0x04 TCP連線的重放與互動式測試

---

如果只是想要重放TCP的資料包本身而非TCP連線，使用tcpreplay工具直接重放即可，這種方式確實可以把之前抓取的pcap資料包全部重放到指定的interface上，這在測試一些IDS裝置或者有抓包業務邏輯的應用時能起到預期的效果

下面使用Woobuntu系統上的tcpreplay工具為例進行測試：

tcpreplay -i enp0s3 test.pcap

然而僅僅重放抓取的資料包並不能建立有效的tcp連線，因此也不會被服務端正確的響應，這樣就起不到FUZZ服務端應用的作用了，我們如果想要和服務端模擬一次真正的TCP會話，就必須在建立新連線後重新填寫資料包對應的TCP序列號。形象的比喻一下就是你在重放HTTP請求時要修改你自己cookie裡面的session-id

如果要重放tcp連線，可以使用tcpreplay系列工具中的tcpliveplay工具：

http://tcpreplay.appneta.com/wiki/tcpliveplay.html

不過我必須說這工具相容性太差了，必須要按照官方文件中的Fresh Install Guide來配置特殊依賴，而且核心不可以用新版本，因此在Woobuntu 16.04上根本無法正常執行該工具

不過使用tcpliveplay並不是最好的辦法，因為它的原理是解析並修改tcp協議包，而實際上我們的目標並不是解析並修改傳輸層的tcp協議包，我們只是要FUZZ上層應用，因此我們直接新建一個tcp連線，然後重放tcp承載的資料就可以了

下面以基於Ubuntu的Woobuntu系統為例進行測試，首先安裝所需的tcptrace，以及可能需要的tcpslice

apt install tcptrace tcpslice

之後我們抓取我們想要重放的tcp資料包，這裡我們用wireshark進行抓取，抓取的是玩家lxj616加入房間然後在聊天欄裡面說了兩句話整個過程

您也可以在WooyunWifi路由器上透過tcpdump工具進行抓包

tcpdump -i br-lan dst port 6112 -C 100 -z "gzip" -w lxj616.pcap

抓完的包可能會很大，而路由器儲存空間較小，所以設定了檔案分段，分段的檔案形如：

lxj616.pcap

lxj616.pcap1.gz

lxj616.pcap2.gz

（可選）我們可以把他們透過以下命令合在一起：

tcpslice -w full.pcap lxj616.pcap*

在抓到足夠的資料包後，我們從中解析出各條tcp連線的資料：

tcptrace -e lxj616.pcap

1 arg remaining, starting with 'lxj616.pcap'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004

18 packets seen, 18 TCP packets traced
elapsed wallclock time: 0:00:00.027297, 659 pkts/sec analyzed
trace file elapsed time: 0:00:10.018743
TCP connection info:
  1: FullMatelErLuLu.lan:51416 - alkaid-PC.lan:6112 (a2b)   10>    8<

Warning : some extracted files are incomplete!
          Please see -l output for more detail.

這個警告是發現了不完整的TCP資料流，因為我測試時沒點退出遊戲就關閉抓包了

然後在當前目錄下會生成形如a2b_contents.dat或者b2a_contents.dat的檔案，找到哪一個是我們需要重放的流資料（同時注意資料方向）

最後我們來重放TCP連線請求測試：

cat a2b_contents.dat | nc 192.168.1.163 6112

而對於遊戲主機來說，確實看起來有玩家跑進來說了兩句話

0x05 總結

---

雖然在本文中對魔獸爭霸3測試時發現了一些潛在問題，但都只是程式邏輯的小問題，而非安全性bug，因此在不會影響遊戲平衡性的條件下，不需要把它們當做漏洞進行報送（雖然對於11對戰平臺而言，使用者名稱是不可以修改的，但是你改了又能怎樣，並沒有用），寫出本文來分享思路，供同道中人一起學習討論