在安全測試的過程中，我們通常使用應用層工具直接測試待測目標，比如一個HTTP網站應用程序，我們可以直接發送HTTP請求來對其進行模糊測試，而對于HTTPS，也可以建立SSL連接后直接發送HTTP請求對其進行模糊測試
然而在某些黑盒測試中，由于信息不對稱，我們無法獲悉應用層協議的具體格式，因此難以直接在應用層進行安全測試，這時我們需要對應用層協議本身進行FUZZ，這就需要使用更底層協議來進行安全測試
本文以著名的RTS游戲魔獸爭霸3為例，介紹在網絡層對TCP連接進行安全測試的基本工具、方法、以及漏洞挖掘思路
我想測試魔獸爭霸3聯機游戲的安全問題
然而魔獸爭霸3并沒有使用HTTP協議來進行通信，因此我既不能用burp來proxy攔截，也不能直接用curl等常用工具來進行FUZZ
魔獸爭霸3聯機對戰使用了TCP連接，自己定義了一套數據包格式（已經有人分析過了，但在本文中我們假設數據包格式未知）
所以我要在傳輸層對魔獸爭霸3的TCP連接進行安全測試，重點測試以下內容：
由于魔獸爭霸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的連接
由于魔獸爭霸3是一個實時對戰的游戲，因此網絡狀態也會影響游戲的進行，魔獸爭霸3本身對于實時操作的要求并不高，但是形如DOTA之類的自定義游戲模式對網絡的延遲極為敏感，如果玩家在DOTA游戲中有很大延遲，可能會直接導致團滅并且游戲失敗
下面使用WooyunWifi路由器上的tc工具中的netem內核模塊為例進行測試：
tc qdisc add dev wlan0 root netem delay 1s
由于網絡延遲，玩家控制的英雄在延時時間內無法響應玩家的操作
當然，您也可以用包過濾表達式指定任意ip的延時規則，包括隨機浮動的延時時間
如何嗅探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
如果只是想要重放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
而對于游戲主機來說，確實看起來有玩家跑進來說了兩句話
雖然在本文中對魔獸爭霸3測試時發現了一些潛在問題，但都只是程序邏輯的小問題，而非安全性bug，因此在不會影響游戲平衡性的條件下，不需要把它們當做漏洞進行報送（雖然對于11對戰平臺而言，用戶名是不可以修改的，但是你改了又能怎樣，并沒有用），寫出本文來分享思路，供同道中人一起學習討論