Windows 名稱解析機制探究及缺陷利用

wyzsk發表於2020-08-19

Windows

作者： Her0in · 2015/12/01 12:30

本文作為一篇科普文章，闡述了 Windows 系統中的名稱解析機制，同時也提及了幾種利用名稱解析機制的缺陷進行內網攻擊的方式。

0x00 Windows 名稱解析簡介

TCP 協議的通訊是基於 IP 地址的，“名稱解析”就是把需要訪問的計算機的名字解析為 IP 地址的過程。

Windows 中的名稱型別

在 Windows 作業系統中，有兩種名稱，分別為：主機名稱和 NetBIOS 名稱。

主機名稱

從狹義上來說，主機名稱正如它的字面意思一樣就是一臺主機的名字。從廣義來說，它又不僅僅包含計算機的名字，也包含網際網路中的域名。

由於域名是以樹狀的形式所表現的，同時也是主機名稱的一種，所以主機名稱是有層次的，最大長度為 255 個字元，允許的字元有 A～Z，a～z 和字元“－”。在域名系統中有一種標識一臺主機的 DNS 名字的域名叫做完全限定域名（FQDN），FQDN 是由“.”連線主機名字和主域名字尾組合成的，例如，seclab.her0in.org 的 FQDN 名稱就是 seclab 。

NetBIOS 名稱

在 Windows 系統中的另外一種名稱就是 NetBIOS 名稱，準確的說 NetBIOS 名稱並非是一種名字系統，而是 Windows 作業系統網路的一個程式設計介面，允許主機之間使用 NetBIOS 名稱進行通訊，通訊過程是建立在 NetBIOS 協議之上的。在安裝完 Windows 系統後系統會預設使用計算機的名字做為當前主機的 NetBIOS 名稱。它的最大長度為 16 個字元，其中最後一位是不可配置的，用於指定 NetBIOS 的服務型別。如果計算機名稱不足 15 位則使用空格補全到 15 位，反之，如果計算機名稱超過 15 位則會擷取前 15 位。常見的 NetBIOS 字尾有 0x20（檔案和列印服務）、0x00（工作站服務）、0x03（報信者服務）等。

使用nbtstat -n命令檢視本機的 NetBIOS 名稱。

使用nbtstat -A ipaddress命令檢視指定 IP 主機的 NetBIOS 名稱。

0x01 Windows 名稱解析相關協議

在 Windows 系統中有三種與名稱解析相關的協議。

Windows 名稱解析之 DNS協議

DNS 協議是一種最主要的也是作業系統首選的進行名稱解析的協議，幾乎每一種作業系統都支援 DNS 協議，同時， DNS 協議支援 IP v4 和 IP v6。DNS 協議在實現名稱解析的過程中，在客戶機上沒有任何本地的資料庫檔案，完全依賴於 DNS 伺服器，所監聽的埠是 UDP/53 。在客戶機上可以使用ipconfig /displaydns命令來檢視本機的 DNS 快取，使用ipconfig /flushdns命令清除本機的 DNS 快取。

DNS 的名稱解析過程如下：

讀取本機 DNS 快取（已經包含本機 hosts 檔案內容）
如果快取中沒有，則會請求網路配置中配置的 DNS 伺服器
如果 DNS 伺服器未作出響應，則請求失敗。反之，DNS 伺服器則會處理使用者請求。

Windows 名稱解析之 NetBIOS 協議

除了 DNS 之外，在早先版本的 Windows 中也使用 NetBIOS (network basic input/output system，網路基本輸入輸出系統)進行名稱解析。本文介紹的 NetBIOS 協議名稱解析是微軟後來定義的 nbt 即 NetBIOS over TCP/IP 的名稱解析型別。

nbt 服務監聽的埠為 UDP/137，其進行名稱解析的形式為向當前主機所在的子網域傳送廣播包。所以，當你使用抓包工具在區域網中抓包時總會收到很多 NBNS 資料包。

由於 NetBIOS 協議進行名稱解析是傳送的 UDP 廣播包。這樣做雖然速度快且無需額外的配置，但是廣播包不能跨越網域同時也會增加一些網路流量，因此微軟在後來推出了 WINS（Windows Internet Name Service）伺服器，當計算機配置為使用 WINS 伺服器進行名稱解析時，客戶機將直接和 WINS 伺服器進行單播通訊，這樣就可以彌補 NetBIOS 協議使用廣播進行名稱解析的不足。

綜上所述，NetBIOS 協議進行名稱解析的過程如下：

檢查本地 NetBIOS 快取
如果快取中沒有請求的名稱且已配置了 WINS 伺服器，接下來則會向 WINS 伺服器發出請求
如果沒有配置 WINS 伺服器或 WINS 伺服器無響應則會向當前子網域傳送廣播
如果傳送廣播後無任何主機響應則會讀取本地的 lmhosts 檔案

lmhosts 檔案位於C:\Windows\System32\drivers\etc\目錄中。

使用nbtstat -c命令檢視本機的 NetBIOS 快取

使用nbtstat -R命令清除本機的 NetBIOS 快取

Windows 名稱解析之 LLMNR 協議

DNS 協議的名稱解析雖然高效但是需要在區域網中單獨配置一臺伺服器作為 DNS 伺服器，NetBIOS 協議的名稱解析在一些情況下也需要單獨配置一臺 WINS 伺服器，而且 NetBIOS 協議不支援 IP v6。因此，為了彌補這些不足，微軟在 Windows Vista 之後推出了基於端到端的名稱解析協議 — 本地鏈路多播名稱解析（Link-Local Multicast Name Resolution）簡稱為 LLMNR。

LLMNR 也稱作多播 DNS ，因為其資料包格式類似於 DNS 的資料包。監聽的埠為 UDP/5355，支援 IP v4 和 IP v6 ，並且在 Linux 上也實現了此協議。其解析名稱的特點為端到端，IPv4 的廣播地址為 224.0.0.252，IPv6 的廣播地址為 FF02:0:0:0:0:0:1:3 或 FF02::1:3。

LLMNR 進行名稱解析的過程為：

檢查本地 NetBIOS 快取
如果快取中沒有則會像當前子網域傳送廣播
當前子網域的其他主機收到並檢查廣播包，如果沒有主機響應則請求失敗

0x02 Windows 系統名稱解析順序

影響 Windows 系統名稱解析的兩個因素

作業系統版本

從上述一小節中，可以發現，並非所有的作業系統版本都支援上述三種協議。

Windows 2K , XP , 2K3 只支援 DNS 和 NetBIOS。所以此類版本的 Windows 都是先進行 DNS 名稱解析，如果 DNS 解析名稱失敗，才會進行 NetBIOS 名稱解析。

Windows Vista 之後（包括 2K8 ， Win7，Win8.x，Win 10）都支援上述三種協議，在這類 Windows系統中的名稱解析順序為：先進行 DNS 名稱解析，如果 DNS 解析名稱失敗，則會使用 LLMNR 進行名稱解析，最後才會使用 NetBIOS 名稱解析。

網路節點模式

還有一種影響 Windows 系統名稱解析的一個因素就是當前主機的網路節點模式。可以使用ipconfig /all命令檢視本機的網路節點模式，如下圖：

圖 1 檢視本機網路節點模式

網路節點模式最主要會影響 NetBIOS 名稱解析過程，是優先查詢 WINS 伺服器還是先在子網域中進行廣播。具體的及節點模式描述如下：

B-節點(broadcast，廣播)

　　Windows 使用廣播來進行名稱註冊和名稱解析，依據閘道器的配置，一個 B 節點客戶機傳送的資料包不能夠超出區域網的範圍。但是，B 節點並不適合於大型網路，實際上微軟修改了標準的 B 節點型別，當 Windows 嘗試解析名稱時，首先檢查 LMHOSTS 名稱快取，如果此行不通，Windows 就會傳送廣播，如果廣播依然失敗的話，那Windows 才會檢查實際的 LMHOSTS 檔案。

P-節點(per-to-per，對等)

　　這種方法並不使用廣播，而是在計算機啟動時，在網路中的 WINS 伺服器上註冊它們的名稱，當計算機需要解析名稱時，它會傳送一個解析請求給 WINS 伺服器。這種方法只在 WINS 伺服器正常執行時有效，如果 WINS 伺服器失敗，則無法進行名稱解析。

M-節點(mixed，混合)

　　Windows 聯合使用 B 節點和 P 節點，並且預設使用 B 節點，如果 M 節點不能利用廣播進行名稱解析，它就使用 P 節點的 WINS 伺服器來完成工作。

H-節點(hybrid，混合)

　　同樣也是聯合使用 B 節點和 P 節點，但工作方式相反，如果使用 WINS 伺服器方式不能成功，則使用 B 節點的工作來完成工作。此節點模式也是目前 Windows 系統預設使用的節點模式。

0x03 利用 Windows 名稱解析機制的缺陷進行內網攻擊

常見的利用 Windows 名稱解析機制的缺陷進行攻擊的技術有 DNS Spoof ，NBNS Poison ，LLMNR Poison ， ICMP Redirection。

可以使用 SpiderLabs 出的 Responder，或者 ZARP 工具包進行上述攻擊。

LLMNR Poison 攻擊環境如下：

攻擊者主機（Linux）IP 192.168.237.133
受害者主機（Windows 8.1） IP 192.168.237.129
兩臺主機處於同一個區域網中

攻擊者在啟動 Responder 後，當受害者去訪問一個在當前區域網中不存在的主機時就會觸發 LLMNR Poison 攻擊，如下圖所示：

圖 1 ：受害者主機 PING 一臺區域網中並不存在的主機

圖 2 ：Responder 會響應 LLMNR 的廣播包並進行了 Poison 攻擊

圖 3 ：在受害者的主機中 NetBIOS 快取中已經加入了被 Poison 攻擊的主機 IP 記錄

上述攻擊演示中，已經證實了 LLMNR Poison 攻擊的效果，可以利用讓受害者訪問不存在的主機的共享進行 LLMNR Poison 攻擊，這樣可以獲得受害者主機的 HASH ，拿到 HASH 就可以進行暴力破解了，如果是弱口令的話，就可以爆破出密碼。同樣也可以利用讓受害者訪問不存在的 HTTP 伺服器進行 401 認證拿到客戶端的 HASH，如下圖所示：