【51CTO.com 獨家譯稿】默認設置下的IPv6漏洞導致Windows系統計算機遭受入侵

如果大家看過太空堡壘卡拉狄加這部美劇，回想一下吧，它清楚地告訴我們，“六”這個數字可不是省油的燈。看起來很美，但在大家忙忙碌碌、按部就班地工作時，它卻悄悄將身形隱藏在其目標之下。沒人意識到出了什么狀況，直到后果已經嚴重到無法挽回。

互聯網上也有類似的六號現象，IPv6（新一代的IPng-IP）。眼下最新的操作系統通過它來進行數據傳輸，一般情況下它都可以算是默認配置了，但普及速度相對來說仍然非常緩慢。原因種種，不勝枚舉，目前的情況是它尚處于休眠期，等待著機會一鳴驚人，進而一舉推翻IPv4并徹底統治網絡。

本文介紹的是一項關于IPv6概念層面的有趣應用。我會在接下來的內容中向大家展示，一個攻擊者如何對IPv6覆蓋之下的純IPv4網絡進行攻擊，而借助這一點，中間人攻擊（簡稱MITM）將能夠順利對IPv4的網絡數據流展開侵襲。

這種新的無狀態自動地址分配（簡稱SLAAC）攻擊，如果大家接受這種稱呼，正是根據其產生過程而得名。

IPv6背景知識介紹

除了增加IP地址數量之外，IPv6在很多關鍵性的處理領域與IPv4可以說采用了完全不同的機制。本文并不打算對IPv6進行過多的探討，但我會把與網絡攻擊有關的主要特點向大家做出說明。

首先，IPv6沒有使用ARP--而代替其功能的是一組稱為相鄰計算機發現協議（neighbour discovery protocols）的工具，當我們執行ICMPv6時，它允許主機發現本地連接中的其它物理地址。此外，具備無線功能的路由器也可以通過本地連接上的路由通告（Router Advertisement，簡稱RA）中的信息來探知其它計算機，借以實現同樣的功能。

當一臺應用IPv6的主機接收到路由通告時，它可以通過一系列處理為其創建一個進程，并為其分配一個有效的IPv6路由地址，這一過程即被稱為"無狀態地址自動配置（簡稱SLAAC）"。主機將根據路由通告所使用的源地址為其設置默認網關。

通過對這種自動的主機地址分配機制的分析，我們可以看到，SLAAC的執行原理更像是IPv4中的DHCP的處理方式。然而，單單SLAAC本身的話，是無法為接入的主機提供所有必要的配置參數信息（例如DNS服務器等詳細內容）的，DHCPv6仍需要借助其它工具的幫助，才能正確填寫所有的匹配資料。事實證明，它所需要的數據可以由路由通告中的信息提供，SLAAC和DHCPv6相結合的話可以為IPv6實現DHCP能為IPv4所做的全部配置工作，但那又是另一回事，不在本文的討論范圍中。

操作原理

這種概念層面上的證明，我只在Windows 7系統的主機上實踐過，但理論上應該適用于任何安裝并默認執行IPv6以管理其網絡數據傳輸的操作系統。讓我們從一幅網絡目標示意圖開始思考：

這幅圖其實相當直觀，整個流程都是IPv4處理方式，邊界路由器所在執行的也是常見的網址解析（簡稱NAT）及防火墻任務。對于這種方式，我們也可以假設，如果各種安全措施都是針對IPv4中間人攻擊，例如ARP欺騙，這類危害所部署的。

現在我們要做的是引入一個物理路由器，向目標網絡發送惡意接收請求。惡意接收請求具有兩個網絡端口--惡意信息所針對的只是IPv6端口，而網絡連接則只通過IPv4端口。我們的目的正是通過發送惡意接收請求，在IPv6所覆蓋的網絡下創建一個寄生的端口。這個端口可以由我們完全控制，具體情況如下圖所示：

惡意接收請求將向本地網絡發送路由通告，這將導致主機為其創建IPv6路由功能所匹配的IP地址。它還配備了DHCPv6服務來為我們提供DNS服務器信息，而這一切都在我們的控制之下（惡意的DNS服務器如上圖所示）。我們還無法做到的是將IPv6所管理的網絡直接通過IPv6連接到互聯網--惡意接收請求只能通過目標計算機上的IPv4來接入互聯網。#p#

所謂Special Sauce

通過引入惡意接收請求所造成的影響目前來看還算是良性的。感謝惡意接收請求所提供的路由通告信息，所有目標主機都在其IPv4的可經路由發送的地址之外，同時提供了IPv6的地址，并且包含DNS服務器信息。但這些還遠遠不夠，要進行實用性操作，我們還需要在攻擊中加入其它內容，以使其取得更大的進展。

這種稱為"Special Sauce（特別醬料）"的工具屬于附帶協議轉換器的網絡地址轉換器（以幫助IPv6與IPv4節點間互相連通，簡稱NAT-PT）。NAT-PT方案已經在實際應用中被攻擊得千瘡百孔、不成人形。它是由互聯網工程任務組（簡稱IETF）所研發，用現在的眼光來看，它已經被徹底丟進了歷史的垃圾桶。但無論如何，盡管它既過時又亂七八糟，但并不代表它毫無可取之處。

NAT-PT是眾多IPv4到IPv6過渡機制中的一款，用來解決從舊有處理方式到新型方案的過渡問題。它的作用是將應用IPv6的主機與應用IPv4的主機之間的數據交互進行處理，即將IPv6地址轉換為IPv4形式，反之亦然。單擊此處可以查看其運作原理的書面說明。這正是NAT-PT的功能，允許我們通過攻擊IPv6端口來將惡意接收請求傳輸到用以連接互聯網的IPv4端口上。

要使用NAT-PT，我們首先需要定義一個非鏈接的/96前綴；它可以是任何通過經由路由器發出的，你樂于采用的前綴形式。任何被NAT-PT所發現的目標地址，其所匹配的前綴名稱若是可以由IPv6的地址所解析，即會根據其末尾的三十二位字節內容轉化為相應的IPv4地址。

舉例說明，我可能會告知自己的NAT-PT，我所選用的前綴名為2001:6f8:608:ace::/96。我們通過DHCPv6為IPv6所提供的DNS服務器地址是2001:6f8:608:ace::c0a8:5802--這個地址與指定的前綴是完全匹配的，因此如果NAT-PT根據其最后三十二位字節檢索到了數據傳輸指向（即c0a8:5802），相應內容將會被提取并發送到真正的DNS服務器的IPv4地址192.168.88.2并進行轉換。

以Special Sauce為起點進一步嘗試

我們離成功只有一步之遙。有NAT-PT保駕護航，惡意接收請求現在已經搭建了一道由IPv6目標端口到IPv4互聯網端口的橋梁。如果我們能夠使通過IPv6的數據流同樣通過惡意請求（而不是通過合法途徑發送到IPv4的邊界路由器），我們就能夠享受自己的SLAAC攻擊所帶來的樂趣了。事實證明，這一步驟實行起來其實也非常容易。 

感謝惡意接收請求，我們的目標端口同時具備IPv4及IPv6地址；它們是"重疊的"，即同時存在的。只要可能，具備這種重疊特性的主機會更傾向于使用本地的IPv6地址，因此可以說我們的計劃已經成功了一半。而在最后的嘗試中，指引我們走完剩下的路途并最終到達終點的伙伴是DNS。

具備重疊特性的目標端口既有一個IPv4的DNS服務器（由DHCP服務器合法提供）又有一個IPv6的DNS服務器（由惡意接收請求通過DHCPv6服務器提供）。當目標端口中的某一個試圖查詢谷歌網站時，它會向其IPv6的DNS服務器發出一個DNS查詢指令，即A（IPv4）以及AAAA（IPv6）。如果IPv6的DNS服務器能夠足夠迅速地返回查詢結果，那么目標端口將會優先采納IPv6所提供的地址，而不是IPv4。而我們所要做的，正是利用這種機制，將來自網絡的數據流轉移到惡意接收請求那邊。而實現這一計劃的前提是，我們IPv6的DNS服務器響應速度一定要快--否則過長的響應返回時間會令目標端口轉而使用IPv4的DNS服務器作為替代，這樣一來讓數據流通過惡意接收請求的計劃也就破產了。

但我們要如何才能確保任何指定的DNS查詢都能通過IPv6地址加以響應？

NAT-PT自有一套妙招，該方案通常包含一組應用層面的網關（簡稱ALGs），它的作用是在應用層面對IP地址的通信協議進行檢查。DNS即是一個協議內容基于ALG的實例，同文件傳輸協議（簡稱FTP）一樣。通過下面的內容，讓我們一起來看看IPv6如何與NAT-PT協同合作，而DNS ALG又是如何玩弄它的欺騙把戲的：

#p#

需要注意的事項：

◆目標端口DNS服務器的地址必須與惡意接收請求上的NAT-PT前綴名稱相匹配，也就是說最后三十二位字節的內容必須包含DNS服務器的IPv4地址。

◆NAT-PT能夠將IPv6及IPv4分別作為數據源及目的地進行轉換，且此轉換過程可逆。

◆DNS ALG會將目標端口的IPv6 地址的AAAA查詢轉換為IPv4地址的A查詢，此過程同樣可逆。

◆DNS ALG也會將IPv4地址的響應轉換為IPv6地址類型，以與NAT-PT的前綴名稱相匹配。

而目前關于目標端口，www.google.com 通過IPv6段位2001:6f8:608:ace::d155:8f63已經可以連接了。這樣一來IPv4就完全無法發揮作用了，而目標端口將以如下圖所示的方式連接到谷歌網站：

這樣一來，惡意接收請求如今已經取得目標端口與谷歌網站之間的中間人身份。

讓我們總結一下迄今為止所做的工作：

◆我們沒有對IPv4網絡機制的目標端口進行攻擊或執行控制，而這正是要對通過IPv4端口的數據流實施中間人攻擊的前提。我們甚至不需要從DHCP服務器處獲取IPv4地址。

◆我們沒有對現有的IPv6網絡進行攻擊，因為在我們進行本次測試之前，目標計算機是沒有IPv6地址的。

◆我們沒有對任何目標主機進行攻擊（至少目前來說還沒有）。每臺計算機都是根據其自身設定來優先選擇IPv6而非IPv4的。

◆我們確實設法消除了目標主機使用IPv4機制的潛在可能性，使其在處理網絡數據流時只使用IPv6機制。

攻擊活動同樣有充分的理由被偷偷執行，因為：

◆我們正在設定一條新的互聯網訪問通路。任何與IPv4網絡邊界協議相沖突或受監控的行為都會失效，并進而導致攻擊失敗。

◆這種可能性依然存在，即目標端口的安全系統（例如主機防火墻、網絡主入侵預防系統（簡稱HIPS）、安全信息與事件管理（簡稱SIEM）工具箱等等）會無法處理IPv6下的數據流。IPv6對這類安全保障體系的支持遠不及IPv4。

◆因為目標端口"沒有用到IPv6"，因此利用IPv6的特性進行攻擊也就成了紙上談兵了。

◆如果上述情況真的出現了，有一種辦法可以幫我們處理，并且既不需要專業培訓、也不要求太多的IPv6使用經驗。

惡意接收請求的建立

惡意接收請求的執行并不復雜。必需的工具包只有三個，即radvd，dhcp6s以及naptd。要啟動及運行這些工具，我們需要建立自己的網絡端口。在下面的這個例子中，eth0是面向互聯網的IPv4端口，而我將假設它可以從DHCP服務器處獲得一個合法的地址。eth1則是使用IPv6的端口，具體配置方案如下：

#p#

我們還需要確保IPv6的轉發功能處于啟用狀態：

好的，現在我們就可以安裝上面提到的那些IPv6小工具啦。

radvd

這個工具包負責向我們的目標主機發送路由通告，點擊這里獲取。配置文件可謂相當簡單：

最重要的部分是前綴連接以及AdvOtherConfigFlag的設置。將這一項設為"開啟"狀態，會向路由通告中發送O標記。這個O標記的作用是通知客戶端，使其盡量與DHCPv6相連通，以完成下一步的設定。根據說明文檔的提示啟動radvd，然后轉到…

dhcp6s

我從這里下載到了WIDE DHCPv6。我們打算通過DHCPv6所實現的操作內容其實很少，因此配置文件也就只有如下所示的短短兩行：

設置完成，運行工具，然后轉到…

naptd

點擊這里獲取該工具。根據其自帶的詳盡說明文本，我們只需要如下圖所示來配置iptables以及ip6tables：

接下來我們運行 napt-confmaker。我依照默認的答案認真回答了幾乎所有的問題，除了端口選擇以及NAT-PT前綴名稱。

到這里，準備工作已經基本完成，一旦naptd開始運作，我們所精心布置的陷阱就要發揮作用了。

攻擊

下圖向我們展示了在被惡意接收請求寄生的IPv6端口連通互聯網之前，目標主機的ip配置文件的輸出結果：

#p#

本地連接狀態中所顯示出的IPv6地址，表明主機目前已經在采用IPv6機制了。一旦我們連接到惡意接收請求所在的eth1端口，目標主機就會收到路由通告，并從中為自身獲取一個IPv6地址，然后是向DHCPv6發送查詢請求以進一步進行配置。而幾乎在同一時間，ip配置文件的輸出結果已經改變成如下圖所示：

這下可憐的目標主機徹底完蛋了：

◆它具備自己的可經路由發送的IPv6地址

◆它具備IPv6的默認網關，而該網關實際上正是惡意接收連接eth1端口的本地連接地址，而并非我們之前手動為其分配的地址。

◆它具備一個與IPv6的DNS服務器地址相匹配的NAT-PT前綴名（由naptd所使用），而這正是我們的惡意DNS服務器所要進行的IPv4地址類型轉換的關鍵。

我們已經成功使目標主機優先采用IPv6所接入的網絡數據而不是IPv4。在實現這一目標的過程中，我們沒有用到任何口令或采取任何黑客及暴力手段。我們所要做的只是引導，將目標一步步指向預期的方向。

運行動態

當目標主機瀏覽谷歌網站時，惡意接收請求的IPv6 eth1端口將接收到如下信息 (下載地址單擊此處)：

在這里我們可以看到通過IPv6發往惡意DNS服務器的DNS查詢指令；IPv4的A型及IPv6的AAAA型查詢指令都被發出了，而響應也分別返回。注意，返回的IPv6地址能夠與我們的NAT-PT前綴相匹配，表明其中包含一個嵌入的IPv4地址。而目標主機一定會選擇IPv6返回的信息而非IPv4；惡意接收請求在這里則扮演了中間攻擊者的角色。#p#

惡意接收請求在IPv4的eth0端口上所進行的相同轉換過程則如下圖所示(下載地址單擊此處)：

請注意，所有的IP地址都是IPv4形式的，而所有的DNS查詢指令都以A的形式加以記錄，而非A與AAAA的組合形式，這就是eth1端口所反饋的情況。

進一步發動攻勢

要發動進一步的攻勢，我們有以下幾種選擇：

◆鑒于這一攻擊需要進行硬件植入，我們采取這套方案的可能性非常非常小，但具體內容仍然值得一提。Gumstix是一款很理想的執行平臺；它體積小巧，運行于Linux環境下，并且在硬件支持方面有許多備選方案。一款OveroEarth，一款Tobi加上一塊USB型的3G網卡以及以太網接口，這個精致的硬件平臺組合就能為我們提供與目標網絡連接的全部前提條件。我之前已經用過Gumstix；一旦大家將這套運行環境建立起來，廣大的網絡世界可謂盡在掌握。

◆由于惡意DNS服務器是由我們控制的，因此我們可以通過設置使其返回任何指定的IP地址，正如前面對谷歌網站所做的一樣。通過這種手段，我們能夠制造許多釣魚的機會。

◆就目前的狀態看，惡意接收請求會以中間人攻擊的形式對全部DNS查詢指令的返回網絡數據流進行侵襲，這還不夠精確。如果我們能夠讓惡意DNS有選擇性地只對某些網站返回地址，那么攻擊的效果就會好得多了。這種想法可以通過一種協議來實現，即我們使惡意DNS服務器忽略掉那些我們不感興趣的DNS查詢指令，這樣被忽略的目標端口信息會轉接入其IPv4服務端，而該過程中的網絡數據也是以正常路徑進行傳輸的。

◆由于我們扮演的是中間攻擊者的角色，因此我們絕對有機會侵入客戶端與服務器之間的往來數據流。具體方法是，我們通過將新的https://鏈接更改為過時的http://鏈接等形式來向網頁應用框架（即iframes）注入惡意信息。

◆當然，上述只是一些我想到的辦法。無限的拓展性現在就把握在大家手中，想怎么做就看你的啦。

如何抵御惡意接收請求

這種攻擊很可能出現，因為我們能夠將惡意信息注入到應用IPv6的主機的路由通告中——這類攻擊與其它類似的攻擊之間的主要區別在于，我們不需要試圖改變現有的IPv6網絡；我們所要做的只是建立一條新的合法傳輸路線。不過，我們的惡意路由通告是攻擊得以成功展開的關鍵。一旦傳輸路線被封堵，這類攻擊將無法實現。

在大部分情況下，惡意路由通告最多只能算是一種"侵犯"行為，基本上跟開啟Windows中的網絡連接共享功能所造成的后果差不多。然而，對于IETF組織來說，這種情形已經相當嚴重了，因此他們發布了單擊此處及此處進行查看。

如果RFC6104文件中的內容無法使我們成功阻止攻擊的發生，也許將它檢測定位也可以算是比較積極的備選應對方案。NDPMon正是這么一款相當于IPv6中的ArpWatch的工具，其設計目的在于幫助我們偵測來自網上鄰居或是路由器端的可疑數據流。

無論如何，無論是RFC6104還是NDPMon都無法有效地幫助我們抵御SLAAC類型的攻擊。為什么在部署應對IPv6所帶來的各種安全問題的同時，就沒有人站出來建議"不使用"IPv6機制呢？SLAAC攻擊的目標只能是由IPv6管理的IPv4網絡，而無法作用原生的IPv6型或雙協議型網絡。由此可見，最簡單有效的防御手段，就是在所有的主機上禁用IPv6機制（只要沒有特殊的業務方面要求）：

這種解決方案完全契合了"網絡防御"一文中所提到的"最小化"安全保障成本這一概念，雖然它對于盡快普及IPv6機制產生了些許不利的影響。不過管它呢，我們都了解哪種方法最適合自己。

原文鏈接：http://resources.infosecinstitute.com/slaac-attack/

【51CTO.com獨家譯稿，非經授權謝絕轉載！合作媒體轉載請注明原文出處及出處！】

【編輯推薦】

1. IPv6或誘發垃圾郵件和病毒爆發
2. BreakingPoint推出全新方案替代IPv4/IPv6雙堆棧協議測試
3. 淺析IPv6的安全威脅
4. Hillstone山石網科喜獲IPv6 Ready認證