MITM6：用IPv6攻陷IPv4網路的工具

隨著IPv6概念的提出，互聯網上針對IPv6協議的使用也日漸增多，但即便如此IPv6在公司內部卻並不受歡迎，很少會有公司使用IPv6。然而，大多數公司可能都忽略了一個問題，雖然IPv6可能沒有被我們主動啟用，但自Windows Vista以來的所有Windows版本（包括伺服器版本）都默認啟用了IPv6，並且優先順序高於IPv4。

在本篇博文中，我將為大家介紹一種針對IPv6的攻擊：即利用Windows網路中的默認IPv6配置，偽裝DNS伺服器來欺騙DNS reply，並將流量重定向到攻擊者指定的端點。接著，我還會為大家提供一種新的利用（臭名昭著的）Windows代理自動發現（WPAD）功能，來傳遞憑證並對網路中的各種服務進行身份驗證的方法。Fox-IT在GitHub上創建了該工具並命名為mitm6，大家可以在這裡下載到。

IPv6攻擊

與IPv6的發展速度緩慢一樣，網上關於針對IPv6滲透測試的資料也少的可憐。儘管市面上有不少相關書籍也都或多或少的提到了諸如ARP欺騙之類的東西，但卻很少涉及IPv6，而可用於測試或利用IPv6配置的工具則更稀缺。這裡我要提及的一款工具是THC IPV6攻擊套件，這也是mitm6靈感的來源。本文中描述的攻擊是SLAAC攻擊其中的一個版本，最早是由Infosec研究所的Alex Waters在2011年提出的。SLAAC攻擊通過建立一個流氓IPv6路由器，並設置各種服務對網路中的所有流量實施中間人攻擊。之後，Neohapsis為這種攻擊開發了一個自動化工具名為suddensix。

對於SLAAC攻擊也有其弊端，由於SLAAC攻擊會嘗試在現有的IPv4網路為當前所有設備創建一個覆蓋網路。而在這滲透測試中並不是一個理想的情況，因為這麼做會導致網路穩定性受到明顯的影響。此外，攻擊者還需藉助相當多外部的軟體包和服務才能正常執行攻擊操作。mitm6專註於更快更好的解決方案，測試人員可以根據需求選擇攻擊主機和欺騙DNS reply，同時能最大限度的減少對網路正常運行帶來的影響。而且mitm6使用起來也非常簡單，幾乎不需要進行配置，並可在幾秒內執行攻擊。當攻擊任務完成後，則會根據工具中默認設置的超時時間，在較短時間內將網路恢復到之前的狀態。

mitm6攻擊

攻擊階段1 – 主DNS接管

首先讓mitm6開始在攻擊者機器的主介面上偵聽，並通過DHCPv6向 Windows客戶端請求IPv6配置。默認情況下，自Windows Vista之後，每台Windows計算機都會定期向該配置發起請求。我們可以通過Wireshark抓包來進行查看：

mitm6將會應答這些DHCPv6請求，並為受害者分配本地鏈路範圍內的IPv6地址。而在實際的IPv6網路中，這些地址由主機本身自動分配，不需要由DHCP伺服器來配置，這使得我們有機會將攻擊者IP設置為受害者的默認IPv6 DNS伺服器。需要注意的是，mitm6目前只針對基於Windows的操作系統，因為像macOS和Linux等其他操作系統，不使用DHCPv6來分配DNS伺服器。

mitm6不會對外宣稱自己是網關，因此主機不會嘗試與本地網段或VLAN之外的IPv6主機進行通信。mitm6也不會嘗試對網路中所有流量的中間人，而是選擇性地欺騙主機（在運行mitm6時可以指定過濾的域），這樣做也減少了對網路造成的影響。

以下截圖顯示了mitm6的攻擊過程。該工具自動檢測攻擊者計算機的IP配置，並以包含攻擊者IP作為DNS伺服器的DHCPv6應答回復網路中客戶端發送的DHCPv6請求。它將周期性的發送通告路由器（RA）消息來提醒客戶端存在IPv6網路，並且客戶端應該通過DHCPv6請求IPv6地址。這在某些情況下會加快攻擊速度，但這並不是必須要做的工作，我們可以在具有SLAAC攻擊防護的網路上執行此攻擊。

攻擊階段2 – DNS欺騙

在受害者機器上，我們看到我們的伺服器被配置為了DNS伺服器。由於Windows對IP協議的偏好，IPv6 DNS伺服器將優於IPv4 DNS伺服器。IPv6 DNS伺服器將會被用於查詢A（IPv4）和AAAA（IPv6）記錄。

接著我們要做的是讓客戶端連接到攻擊者機器，我們的最終目標是讓用戶或瀏覽器自動向攻擊者機器進行身份驗證，這就是為什麼我們要欺騙內部域testsegment.local中URL的原因。在步驟1的截圖中你可以看到，客戶端在分配了IPv6地址後立即開始請求有關wpad.testsegment.local的信息。這是我們在這次攻擊當中將要利用的一部分。

WPAD利用

WPAD利用的簡短史

Windows代理自動檢測功能一直以來都存在著巨大爭議，而且多年來一直被滲透測試人員所利用。它本意的用途是用於在企業環境中自動檢測用於連接到互聯網的網路代理。歷史上，提供wpad.dat文件的伺服器地址（提供這些信息）將使用DNS解析，如果沒有條目返回，地址將通過不安全的廣播協議解析，如鏈路本地多播名稱解析 (LLMNR)。攻擊者可以回復這些廣播名稱解析協議並對其進行欺騙，讓其認為WPAD文件位於攻擊者伺服器上，然後提示進行身份驗證以訪問WPAD文件。這種認證是Windows默認提供的，無需用戶交互。這將會向攻擊者提供登錄在該計算機上的用戶的NTLM憑據，可被用於在NTLM中繼的過程中對服務進行認證。

然而在2016年微軟發布了安全公告MS16-077，通過增加兩項重要的保護措施來緩解這一攻擊：

WPAD文件的位置不再需要通過廣播協議請求，而只能通過DNS；
即使伺服器請求，也不會自動進行認證。

雖然在網路中，我們仍能碰到一些未完全修復的機器仍在通過LLMNR請求WPAD並自動進行認證，但我們也發現越來越多的公司開始開始注意到了這點並進行了很好的改善。

MS16-077之WPAD的利用

針對微軟的第一個安全措施僅通過DNS，mitm6可以幫助我們輕鬆繞過。一旦受害者機器將攻擊者設置為IPv6 DNS伺服器，它將開始查詢網路的WPAD配置。由於這些DNS查詢被發送給了攻擊者，它只能用自己的IP地址（是IPv4或IPv6取決於受害者機器請求的是什麼）進行回復。

要想繞過第二個防護，我們需要做一些更複雜的操作。當受害者請求一個WPAD文件時，我們將不會請求驗證，而是提供一個攻擊者機器上設置作為代理的有效的WPAD文件。此時，當受害者運行任何使用Windows API連接到互聯網的應用程序或是瀏覽網頁，都將使用攻擊者機器作為代理。這在Edge，Internet Explorer，Firefox和Chrome中都可以使用，因為默認情況下它們都遵循WPAD系統設置。

現在當受害者連接到我們的代理伺服器，我們可以通過CONNECT HTTP或GET後的完整URI識別，我們使用HTTP 407代理身份驗證進行回復。這與通常用於請求驗證的HTTP代碼HTTP 401不同。

IE/Edge和Chrome（使用IE設置）將自動向代理進行身份驗證，即使在最新的Windows版本上也是如此。在Firefox中，可以對該配置進行設置，默認情況下是啟用狀態。

此時，Windows將會毫無防備的將NTLM challenge/response發送給攻擊者，攻擊者可以將其轉發給不同的服務。通過這種中繼攻擊，攻擊者可以對服務進行身份驗證，訪問網站和共享信息，如果受害者的許可權足夠大，攻擊者甚至可以在計算機上執行代碼，並接管整個Windows域。關於NTLM中繼的相關內容，在我之前的博文中有過介，點擊這裡查看。

完整的攻擊

在前面的幾節內容我對該類攻擊做了一個大致的描述和解釋。執行此攻擊本身非常簡單。首先我們啟動mitm6，它將開始中繼DHCPv6請求，然後開始在內部網路中向DNS查詢請求名稱。在攻擊的第二部分，我們將使用到中繼工具ntlmrelayx。這個工具是Core Security impacket Python庫的一部分，是smbrelayx工具的一個改進版支持多種協議。Core Security和Fox-IT最近共同改進了ntlmrelayx，增加了幾項新功能（其中包括）使其能夠通過IPv6進行中繼，提供WPAD文件，自動檢測代理請求並提示受害者進行正確的身份驗證。如果你想進一步的了解這些新功能，請點擊relay-experimental分支查看。

要提供WPAD文件，我們需要在命令提示符中-wh參數後添加主機，並指定WPAD文件所在的主機。由於mitm6讓我們可以控制DNS，因此受害網路中的任何不存在的主機名都可以執行。為了確保ntlmrelayx在IPv4和IPv6上偵聽，我們可以使用-6參數。以下截圖為我們展示了兩個工具當前的運行情況，顯示了兩個工具正在運行，mitm6有選擇地欺騙DNS回復，ntlmrelayx服務於WPAD文件，然後將身份驗證轉發到網路中的其它伺服器。