用默認(rèn)設(shè)置下的IPv6漏洞攻擊Windows系統(tǒng)
譯文【51CTO.com 獨家譯稿】默認(rèn)設(shè)置下的IPv6漏洞導(dǎo)致Windows系統(tǒng)計算機(jī)遭受入侵
如果大家看過太空堡壘卡拉狄加這部美劇,回想一下吧,它清楚地告訴我們,“六”這個數(shù)字可不是省油的燈??雌饋砗苊溃诖蠹颐γβ德?、按部就班地工作時,它卻悄悄將身形隱藏在其目標(biāo)之下。沒人意識到出了什么狀況,直到后果已經(jīng)嚴(yán)重到無法挽回。
互聯(lián)網(wǎng)上也有類似的六號現(xiàn)象,IPv6(新一代的IPng-IP)。眼下最新的操作系統(tǒng)通過它來進(jìn)行數(shù)據(jù)傳輸,一般情況下它都可以算是默認(rèn)配置了,但普及速度相對來說仍然非常緩慢。原因種種,不勝枚舉,目前的情況是它尚處于休眠期,等待著機(jī)會一鳴驚人,進(jìn)而一舉推翻IPv4并徹底統(tǒng)治網(wǎng)絡(luò)。
本文介紹的是一項關(guān)于IPv6概念層面的有趣應(yīng)用。我會在接下來的內(nèi)容中向大家展示,一個攻擊者如何對IPv6覆蓋之下的純IPv4網(wǎng)絡(luò)進(jìn)行攻擊,而借助這一點,中間人攻擊(簡稱MITM)將能夠順利對IPv4的網(wǎng)絡(luò)數(shù)據(jù)流展開侵襲。
這種新的無狀態(tài)自動地址分配(簡稱SLAAC)攻擊,如果大家接受這種稱呼,正是根據(jù)其產(chǎn)生過程而得名。
IPv6背景知識介紹
除了增加IP地址數(shù)量之外,IPv6在很多關(guān)鍵性的處理領(lǐng)域與IPv4可以說采用了完全不同的機(jī)制。本文并不打算對IPv6進(jìn)行過多的探討,但我會把與網(wǎng)絡(luò)攻擊有關(guān)的主要特點向大家做出說明。
首先,IPv6沒有使用ARP--而代替其功能的是一組稱為相鄰計算機(jī)發(fā)現(xiàn)協(xié)議(neighbour discovery protocols)的工具,當(dāng)我們執(zhí)行ICMPv6時,它允許主機(jī)發(fā)現(xiàn)本地連接中的其它物理地址。此外,具備無線功能的路由器也可以通過本地連接上的路由通告(Router Advertisement,簡稱RA)中的信息來探知其它計算機(jī),借以實現(xiàn)同樣的功能。
當(dāng)一臺應(yīng)用IPv6的主機(jī)接收到路由通告時,它可以通過一系列處理為其創(chuàng)建一個進(jìn)程,并為其分配一個有效的IPv6路由地址,這一過程即被稱為"無狀態(tài)地址自動配置(簡稱SLAAC)"。主機(jī)將根據(jù)路由通告所使用的源地址為其設(shè)置默認(rèn)網(wǎng)關(guān)。
通過對這種自動的主機(jī)地址分配機(jī)制的分析,我們可以看到,SLAAC的執(zhí)行原理更像是IPv4中的DHCP的處理方式。然而,單單SLAAC本身的話,是無法為接入的主機(jī)提供所有必要的配置參數(shù)信息(例如DNS服務(wù)器等詳細(xì)內(nèi)容)的,DHCPv6仍需要借助其它工具的幫助,才能正確填寫所有的匹配資料。事實證明,它所需要的數(shù)據(jù)可以由路由通告中的信息提供,SLAAC和DHCPv6相結(jié)合的話可以為IPv6實現(xiàn)DHCP能為IPv4所做的全部配置工作,但那又是另一回事,不在本文的討論范圍中。
操作原理
這種概念層面上的證明,我只在Windows 7系統(tǒng)的主機(jī)上實踐過,但理論上應(yīng)該適用于任何安裝并默認(rèn)執(zhí)行IPv6以管理其網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)牟僮飨到y(tǒng)。讓我們從一幅網(wǎng)絡(luò)目標(biāo)示意圖開始思考:
這幅圖其實相當(dāng)直觀,整個流程都是IPv4處理方式,邊界路由器所在執(zhí)行的也是常見的網(wǎng)址解析(簡稱NAT)及防火墻任務(wù)。對于這種方式,我們也可以假設(shè),如果各種安全措施都是針對IPv4中間人攻擊,例如ARP欺騙,這類危害所部署的。
現(xiàn)在我們要做的是引入一個物理路由器,向目標(biāo)網(wǎng)絡(luò)發(fā)送惡意接收請求。惡意接收請求具有兩個網(wǎng)絡(luò)端口--惡意信息所針對的只是IPv6端口,而網(wǎng)絡(luò)連接則只通過IPv4端口。我們的目的正是通過發(fā)送惡意接收請求,在IPv6所覆蓋的網(wǎng)絡(luò)下創(chuàng)建一個寄生的端口。這個端口可以由我們完全控制,具體情況如下圖所示:
惡意接收請求將向本地網(wǎng)絡(luò)發(fā)送路由通告,這將導(dǎo)致主機(jī)為其創(chuàng)建IPv6路由功能所匹配的IP地址。它還配備了DHCPv6服務(wù)來為我們提供DNS服務(wù)器信息,而這一切都在我們的控制之下(惡意的DNS服務(wù)器如上圖所示)。我們還無法做到的是將IPv6所管理的網(wǎng)絡(luò)直接通過IPv6連接到互聯(lián)網(wǎng)--惡意接收請求只能通過目標(biāo)計算機(jī)上的IPv4來接入互聯(lián)網(wǎng)。#p#
所謂Special Sauce
通過引入惡意接收請求所造成的影響目前來看還算是良性的。感謝惡意接收請求所提供的路由通告信息,所有目標(biāo)主機(jī)都在其IPv4的可經(jīng)路由發(fā)送的地址之外,同時提供了IPv6的地址,并且包含DNS服務(wù)器信息。但這些還遠(yuǎn)遠(yuǎn)不夠,要進(jìn)行實用性操作,我們還需要在攻擊中加入其它內(nèi)容,以使其取得更大的進(jìn)展。
這種稱為"Special Sauce(特別醬料)"的工具屬于附帶協(xié)議轉(zhuǎn)換器的網(wǎng)絡(luò)地址轉(zhuǎn)換器(以幫助IPv6與IPv4節(jié)點間互相連通,簡稱NAT-PT)。NAT-PT方案已經(jīng)在實際應(yīng)用中被攻擊得千瘡百孔、不成人形。它是由互聯(lián)網(wǎng)工程任務(wù)組(簡稱IETF)所研發(fā),用現(xiàn)在的眼光來看,它已經(jīng)被徹底丟進(jìn)了歷史的垃圾桶。但無論如何,盡管它既過時又亂七八糟,但并不代表它毫無可取之處。
NAT-PT是眾多IPv4到IPv6過渡機(jī)制中的一款,用來解決從舊有處理方式到新型方案的過渡問題。它的作用是將應(yīng)用IPv6的主機(jī)與應(yīng)用IPv4的主機(jī)之間的數(shù)據(jù)交互進(jìn)行處理,即將IPv6地址轉(zhuǎn)換為IPv4形式,反之亦然。單擊此處可以查看其運作原理的書面說明。這正是NAT-PT的功能,允許我們通過攻擊IPv6端口來將惡意接收請求傳輸?shù)接靡赃B接互聯(lián)網(wǎng)的IPv4端口上。
要使用NAT-PT,我們首先需要定義一個非鏈接的/96前綴;它可以是任何通過經(jīng)由路由器發(fā)出的,你樂于采用的前綴形式。任何被NAT-PT所發(fā)現(xiàn)的目標(biāo)地址,其所匹配的前綴名稱若是可以由IPv6的地址所解析,即會根據(jù)其末尾的三十二位字節(jié)內(nèi)容轉(zhuǎn)化為相應(yīng)的IPv4地址。
舉例說明,我可能會告知自己的NAT-PT,我所選用的前綴名為2001:6f8:608:ace::/96。我們通過DHCPv6為IPv6所提供的DNS服務(wù)器地址是2001:6f8:608:ace::c0a8:5802--這個地址與指定的前綴是完全匹配的,因此如果NAT-PT根據(jù)其最后三十二位字節(jié)檢索到了數(shù)據(jù)傳輸指向(即c0a8:5802),相應(yīng)內(nèi)容將會被提取并發(fā)送到真正的DNS服務(wù)器的IPv4地址192.168.88.2并進(jìn)行轉(zhuǎn)換。
以Special Sauce為起點進(jìn)一步嘗試
我們離成功只有一步之遙。有NAT-PT保駕護(hù)航,惡意接收請求現(xiàn)在已經(jīng)搭建了一道由IPv6目標(biāo)端口到IPv4互聯(lián)網(wǎng)端口的橋梁。如果我們能夠使通過IPv6的數(shù)據(jù)流同樣通過惡意請求(而不是通過合法途徑發(fā)送到IPv4的邊界路由器),我們就能夠享受自己的SLAAC攻擊所帶來的樂趣了。事實證明,這一步驟實行起來其實也非常容易。
感謝惡意接收請求,我們的目標(biāo)端口同時具備IPv4及IPv6地址;它們是"重疊的",即同時存在的。只要可能,具備這種重疊特性的主機(jī)會更傾向于使用本地的IPv6地址,因此可以說我們的計劃已經(jīng)成功了一半。而在最后的嘗試中,指引我們走完剩下的路途并最終到達(dá)終點的伙伴是DNS。
具備重疊特性的目標(biāo)端口既有一個IPv4的DNS服務(wù)器(由DHCP服務(wù)器合法提供)又有一個IPv6的DNS服務(wù)器(由惡意接收請求通過DHCPv6服務(wù)器提供)。當(dāng)目標(biāo)端口中的某一個試圖查詢谷歌網(wǎng)站時,它會向其IPv6的DNS服務(wù)器發(fā)出一個DNS查詢指令,即A(IPv4)以及AAAA(IPv6)。如果IPv6的DNS服務(wù)器能夠足夠迅速地返回查詢結(jié)果,那么目標(biāo)端口將會優(yōu)先采納IPv6所提供的地址,而不是IPv4。而我們所要做的,正是利用這種機(jī)制,將來自網(wǎng)絡(luò)的數(shù)據(jù)流轉(zhuǎn)移到惡意接收請求那邊。而實現(xiàn)這一計劃的前提是,我們IPv6的DNS服務(wù)器響應(yīng)速度一定要快--否則過長的響應(yīng)返回時間會令目標(biāo)端口轉(zhuǎn)而使用IPv4的DNS服務(wù)器作為替代,這樣一來讓數(shù)據(jù)流通過惡意接收請求的計劃也就破產(chǎn)了。
但我們要如何才能確保任何指定的DNS查詢都能通過IPv6地址加以響應(yīng)?
NAT-PT自有一套妙招,該方案通常包含一組應(yīng)用層面的網(wǎng)關(guān)(簡稱ALGs),它的作用是在應(yīng)用層面對IP地址的通信協(xié)議進(jìn)行檢查。DNS即是一個協(xié)議內(nèi)容基于ALG的實例,同文件傳輸協(xié)議(簡稱FTP)一樣。通過下面的內(nèi)容,讓我們一起來看看IPv6如何與NAT-PT協(xié)同合作,而DNS ALG又是如何玩弄它的欺騙把戲的:
#p#
需要注意的事項:
◆目標(biāo)端口DNS服務(wù)器的地址必須與惡意接收請求上的NAT-PT前綴名稱相匹配,也就是說最后三十二位字節(jié)的內(nèi)容必須包含DNS服務(wù)器的IPv4地址。
◆NAT-PT能夠?qū)Pv6及IPv4分別作為數(shù)據(jù)源及目的地進(jìn)行轉(zhuǎn)換,且此轉(zhuǎn)換過程可逆。
◆DNS ALG會將目標(biāo)端口的IPv6 地址的AAAA查詢轉(zhuǎn)換為IPv4地址的A查詢,此過程同樣可逆。
◆DNS ALG也會將IPv4地址的響應(yīng)轉(zhuǎn)換為IPv6地址類型,以與NAT-PT的前綴名稱相匹配。
而目前關(guān)于目標(biāo)端口,www.google.com 通過IPv6段位2001:6f8:608:ace::d155:8f63已經(jīng)可以連接了。這樣一來IPv4就完全無法發(fā)揮作用了,而目標(biāo)端口將以如下圖所示的方式連接到谷歌網(wǎng)站:
這樣一來,惡意接收請求如今已經(jīng)取得目標(biāo)端口與谷歌網(wǎng)站之間的中間人身份。
讓我們總結(jié)一下迄今為止所做的工作:
◆我們沒有對IPv4網(wǎng)絡(luò)機(jī)制的目標(biāo)端口進(jìn)行攻擊或執(zhí)行控制,而這正是要對通過IPv4端口的數(shù)據(jù)流實施中間人攻擊的前提。我們甚至不需要從DHCP服務(wù)器處獲取IPv4地址。
◆我們沒有對現(xiàn)有的IPv6網(wǎng)絡(luò)進(jìn)行攻擊,因為在我們進(jìn)行本次測試之前,目標(biāo)計算機(jī)是沒有IPv6地址的。
◆我們沒有對任何目標(biāo)主機(jī)進(jìn)行攻擊(至少目前來說還沒有)。每臺計算機(jī)都是根據(jù)其自身設(shè)定來優(yōu)先選擇IPv6而非IPv4的。
◆我們確實設(shè)法消除了目標(biāo)主機(jī)使用IPv4機(jī)制的潛在可能性,使其在處理網(wǎng)絡(luò)數(shù)據(jù)流時只使用IPv6機(jī)制。
攻擊活動同樣有充分的理由被偷偷執(zhí)行,因為:
◆我們正在設(shè)定一條新的互聯(lián)網(wǎng)訪問通路。任何與IPv4網(wǎng)絡(luò)邊界協(xié)議相沖突或受監(jiān)控的行為都會失效,并進(jìn)而導(dǎo)致攻擊失敗。
◆這種可能性依然存在,即目標(biāo)端口的安全系統(tǒng)(例如主機(jī)防火墻、網(wǎng)絡(luò)主入侵預(yù)防系統(tǒng)(簡稱HIPS)、安全信息與事件管理(簡稱SIEM)工具箱等等)會無法處理IPv6下的數(shù)據(jù)流。IPv6對這類安全保障體系的支持遠(yuǎn)不及IPv4。
◆因為目標(biāo)端口"沒有用到IPv6",因此利用IPv6的特性進(jìn)行攻擊也就成了紙上談兵了。
◆如果上述情況真的出現(xiàn)了,有一種辦法可以幫我們處理,并且既不需要專業(yè)培訓(xùn)、也不要求太多的IPv6使用經(jīng)驗。
惡意接收請求的建立
惡意接收請求的執(zhí)行并不復(fù)雜。必需的工具包只有三個,即radvd,dhcp6s以及naptd。要啟動及運行這些工具,我們需要建立自己的網(wǎng)絡(luò)端口。在下面的這個例子中,eth0是面向互聯(lián)網(wǎng)的IPv4端口,而我將假設(shè)它可以從DHCP服務(wù)器處獲得一個合法的地址。eth1則是使用IPv6的端口,具體配置方案如下:
root@evil-rtr:~# ifconfig eth1 inet6 add 2001:6f8:608:fab::1/64 root@evil-rtr:~# ifup eth1 root@evil-rtr:~# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:25:4b:fd:91:73 inet6 addr: 2001:6f8:608:fab::1/64 Scope:Global UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) |
#p#
我們還需要確保IPv6的轉(zhuǎn)發(fā)功能處于啟用狀態(tài):
root@evil-rtr:~# sysctl -w net.ipv6.conf.all.forwarding=1 net.ipv6.conf.all.forwarding = 1 |
好的,現(xiàn)在我們就可以安裝上面提到的那些IPv6小工具啦。
radvd
這個工具包負(fù)責(zé)向我們的目標(biāo)主機(jī)發(fā)送路由通告,點擊這里獲取。配置文件可謂相當(dāng)簡單:
interface eth1 { AdvSendAdvert on; AdvOtherConfigFlag on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix 2001:06f8:0608:fab::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; }; |
最重要的部分是前綴連接以及AdvOtherConfigFlag的設(shè)置。將這一項設(shè)為"開啟"狀態(tài),會向路由通告中發(fā)送O標(biāo)記。這個O標(biāo)記的作用是通知客戶端,使其盡量與DHCPv6相連通,以完成下一步的設(shè)定。根據(jù)說明文檔的提示啟動radvd,然后轉(zhuǎn)到…
dhcp6s
我從這里下載到了WIDE DHCPv6。我們打算通過DHCPv6所實現(xiàn)的操作內(nèi)容其實很少,因此配置文件也就只有如下所示的短短兩行:
option domain-name-servers 2001:6f8:608:ace::c0a8:5802; option domain-name "pwned.by.v6"; |
設(shè)置完成,運行工具,然后轉(zhuǎn)到…
naptd
點擊這里獲取該工具。根據(jù)其自帶的詳盡說明文本,我們只需要如下圖所示來配置iptables以及ip6tables:
root@evil-rtr:~# ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 1 -j DROP root@evil-rtr:~# ip6tables -A FORWARD -d 2001:6f8:608:ace:: -j DROP root@evil-rtr:~# iptables -A INPUT -i lo -j ACCEPT root@evil-rtr:~# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT root@evil-rtr:~# iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT root@evil-rtr:~# iptables -A INPUT -j DROP |
接下來我們運行 napt-confmaker。我依照默認(rèn)的答案認(rèn)真回答了幾乎所有的問題,除了端口選擇以及NAT-PT前綴名稱。
到這里,準(zhǔn)備工作已經(jīng)基本完成,一旦naptd開始運作,我們所精心布置的陷阱就要發(fā)揮作用了。
攻擊
下圖向我們展示了在被惡意接收請求寄生的IPv6端口連通互聯(lián)網(wǎng)之前,目標(biāo)主機(jī)的ip配置文件的輸出結(jié)果:
Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20) Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08 Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33 Default Gateway . . . . . . . . . : 192.168.0.251 DHCP Server . . . . . . . . . . . : 192.168.0.251 DHCPv6 IAID . . . . . . . . . . . : 285221771 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F DNS Servers . . . . . . . . . . . : 192.168.0.251 NetBIOS over Tcpip. . . . . . . . : Enabled |
#p#
本地連接狀態(tài)中所顯示出的IPv6地址,表明主機(jī)目前已經(jīng)在采用IPv6機(jī)制了。一旦我們連接到惡意接收請求所在的eth1端口,目標(biāo)主機(jī)就會收到路由通告,并從中為自身獲取一個IPv6地址,然后是向DHCPv6發(fā)送查詢請求以進(jìn)一步進(jìn)行配置。而幾乎在同一時間,ip配置文件的輸出結(jié)果已經(jīng)改變成如下圖所示:
Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : pwned.by.v6 Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20) Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2001:6f8:608:fab:119c:ea76:23d4:290d(Preferred) Temporary IPv6 Address. . . . . . : 2001:6f8:608:fab:687a:83f:caa7:8f9c(Preferred) Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08 Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33 Default Gateway . . . . . . . . . : fe80::225:4bff:fefd:9173%10 192.168.0.251 DHCP Server . . . . . . . . . . . : 192.168.0.251 DHCPv6 IAID . . . . . . . . . . . : 285221771 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F DNS Servers . . . . . . . . . . . : 2001:6f8:608:ace::c0a8:5802 192.168.0.251 NetBIOS over Tcpip. . . . . . . . : Enabled Connection-specific DNS Suffix Search List : pwned.by.v6 |
這下可憐的目標(biāo)主機(jī)徹底完蛋了:
◆它具備自己的可經(jīng)路由發(fā)送的IPv6地址
◆它具備IPv6的默認(rèn)網(wǎng)關(guān),而該網(wǎng)關(guān)實際上正是惡意接收連接eth1端口的本地連接地址,而并非我們之前手動為其分配的地址。
◆它具備一個與IPv6的DNS服務(wù)器地址相匹配的NAT-PT前綴名(由naptd所使用),而這正是我們的惡意DNS服務(wù)器所要進(jìn)行的IPv4地址類型轉(zhuǎn)換的關(guān)鍵。
我們已經(jīng)成功使目標(biāo)主機(jī)優(yōu)先采用IPv6所接入的網(wǎng)絡(luò)數(shù)據(jù)而不是IPv4。在實現(xiàn)這一目標(biāo)的過程中,我們沒有用到任何口令或采取任何黑客及暴力手段。我們所要做的只是引導(dǎo),將目標(biāo)一步步指向預(yù)期的方向。
運行動態(tài)
當(dāng)目標(biāo)主機(jī)瀏覽谷歌網(wǎng)站時,惡意接收請求的IPv6 eth1端口將接收到如下信息 (下載地址單擊此處):
在這里我們可以看到通過IPv6發(fā)往惡意DNS服務(wù)器的DNS查詢指令;IPv4的A型及IPv6的AAAA型查詢指令都被發(fā)出了,而響應(yīng)也分別返回。注意,返回的IPv6地址能夠與我們的NAT-PT前綴相匹配,表明其中包含一個嵌入的IPv4地址。而目標(biāo)主機(jī)一定會選擇IPv6返回的信息而非IPv4;惡意接收請求在這里則扮演了中間攻擊者的角色。#p#
惡意接收請求在IPv4的eth0端口上所進(jìn)行的相同轉(zhuǎn)換過程則如下圖所示(下載地址單擊此處):
請注意,所有的IP地址都是IPv4形式的,而所有的DNS查詢指令都以A的形式加以記錄,而非A與AAAA的組合形式,這就是eth1端口所反饋的情況。
進(jìn)一步發(fā)動攻勢
要發(fā)動進(jìn)一步的攻勢,我們有以下幾種選擇:
◆鑒于這一攻擊需要進(jìn)行硬件植入,我們采取這套方案的可能性非常非常小,但具體內(nèi)容仍然值得一提。Gumstix是一款很理想的執(zhí)行平臺;它體積小巧,運行于Linux環(huán)境下,并且在硬件支持方面有許多備選方案。一款OveroEarth,一款Tobi加上一塊USB型的3G網(wǎng)卡以及以太網(wǎng)接口,這個精致的硬件平臺組合就能為我們提供與目標(biāo)網(wǎng)絡(luò)連接的全部前提條件。我之前已經(jīng)用過Gumstix;一旦大家將這套運行環(huán)境建立起來,廣大的網(wǎng)絡(luò)世界可謂盡在掌握。
◆由于惡意DNS服務(wù)器是由我們控制的,因此我們可以通過設(shè)置使其返回任何指定的IP地址,正如前面對谷歌網(wǎng)站所做的一樣。通過這種手段,我們能夠制造許多釣魚的機(jī)會。
◆就目前的狀態(tài)看,惡意接收請求會以中間人攻擊的形式對全部DNS查詢指令的返回網(wǎng)絡(luò)數(shù)據(jù)流進(jìn)行侵襲,這還不夠精確。如果我們能夠讓惡意DNS有選擇性地只對某些網(wǎng)站返回地址,那么攻擊的效果就會好得多了。這種想法可以通過一種協(xié)議來實現(xiàn),即我們使惡意DNS服務(wù)器忽略掉那些我們不感興趣的DNS查詢指令,這樣被忽略的目標(biāo)端口信息會轉(zhuǎn)接入其IPv4服務(wù)端,而該過程中的網(wǎng)絡(luò)數(shù)據(jù)也是以正常路徑進(jìn)行傳輸?shù)摹?/p>
◆由于我們扮演的是中間攻擊者的角色,因此我們絕對有機(jī)會侵入客戶端與服務(wù)器之間的往來數(shù)據(jù)流。具體方法是,我們通過將新的https://鏈接更改為過時的http://鏈接等形式來向網(wǎng)頁應(yīng)用框架(即iframes)注入惡意信息。
◆當(dāng)然,上述只是一些我想到的辦法。無限的拓展性現(xiàn)在就把握在大家手中,想怎么做就看你的啦。
如何抵御惡意接收請求
這種攻擊很可能出現(xiàn),因為我們能夠?qū)阂庑畔⒆⑷氲綉?yīng)用IPv6的主機(jī)的路由通告中——這類攻擊與其它類似的攻擊之間的主要區(qū)別在于,我們不需要試圖改變現(xiàn)有的IPv6網(wǎng)絡(luò);我們所要做的只是建立一條新的合法傳輸路線。不過,我們的惡意路由通告是攻擊得以成功展開的關(guān)鍵。一旦傳輸路線被封堵,這類攻擊將無法實現(xiàn)。
在大部分情況下,惡意路由通告最多只能算是一種"侵犯"行為,基本上跟開啟Windows中的網(wǎng)絡(luò)連接共享功能所造成的后果差不多。然而,對于IETF組織來說,這種情形已經(jīng)相當(dāng)嚴(yán)重了,因此他們發(fā)布了單擊此處及此處進(jìn)行查看。
如果RFC6104文件中的內(nèi)容無法使我們成功阻止攻擊的發(fā)生,也許將它檢測定位也可以算是比較積極的備選應(yīng)對方案。NDPMon正是這么一款相當(dāng)于IPv6中的ArpWatch的工具,其設(shè)計目的在于幫助我們偵測來自網(wǎng)上鄰居或是路由器端的可疑數(shù)據(jù)流。
無論如何,無論是RFC6104還是NDPMon都無法有效地幫助我們抵御SLAAC類型的攻擊。為什么在部署應(yīng)對IPv6所帶來的各種安全問題的同時,就沒有人站出來建議"不使用"IPv6機(jī)制呢?SLAAC攻擊的目標(biāo)只能是由IPv6管理的IPv4網(wǎng)絡(luò),而無法作用原生的IPv6型或雙協(xié)議型網(wǎng)絡(luò)。由此可見,最簡單有效的防御手段,就是在所有的主機(jī)上禁用IPv6機(jī)制(只要沒有特殊的業(yè)務(wù)方面要求):
這種解決方案完全契合了"網(wǎng)絡(luò)防御"一文中所提到的"最小化"安全保障成本這一概念,雖然它對于盡快普及IPv6機(jī)制產(chǎn)生了些許不利的影響。不過管它呢,我們都了解哪種方法最適合自己。
原文鏈接:http://resources.infosecinstitute.com/slaac-attack/
【51CTO.com獨家譯稿,非經(jīng)授權(quán)謝絕轉(zhuǎn)載!合作媒體轉(zhuǎn)載請注明原文出處及出處!】
【編輯推薦】
- IPv6或誘發(fā)垃圾郵件和病毒爆發(fā)
- BreakingPoint推出全新方案替代IPv4/IPv6雙堆棧協(xié)議測試
- 淺析IPv6的安全威脅
- Hillstone山石網(wǎng)科喜獲IPv6 Ready認(rèn)證