[psac]

深入瞭解「網路鄰居」的原理

訊息來源：bbs.hbhacker.net

有關網上的芳鄰的問題，問的人一直比較多，在理解上存在的錯誤認知也普遍較為嚴重。鑒於Microsoft的NETBIOS文檔不是很細緻，筆者四處收集了一些相關資料加上自己的實踐經驗寫了這個系列，希望能對大家有所幫助。


　　本來想為了增加可讀性，把這個系列寫成問答的形式，不過一時之間腦袋裡也編不出這麼多的問題，還是按部就班先感性的對微軟的瀏覽服務作一大致介紹，然後再深入剖析NETBIOS的具體工作機理，大家要是有什麼問題，可以提出來我們一起討論。

　　一、微軟網路瀏覽過程簡介

　　在「Windows NT系統管理技術內幕」一書中，講到了一個非常具有代表性的問題，我把它摘抄了下來：

　　問：什麼情況下會導致在網路鄰居中電腦能看見卻無法訪問或可以訪問卻看不見？請選擇最佳答案：


　　A.你的網路存在物理問題，比如網線
　　B.作為域主瀏覽器的Windows NTserver的瀏覽服務壞了
　　C.Windows NTserver網卡有問題
　　D.你的網路沒有問題，用戶描述的是正常的微軟瀏覽現象

　　正確答案，書上的解釋。微軟的網路瀏覽可能在使用中出現"中斷"，而實際上它們並沒有中斷， 這種誤解是由於用戶對微軟網路瀏覽的處理過程不熟悉造成的。


　　就像同學們經常在抱怨的「為什麼別人的網上的芳鄰可以用，我的卻不行？」「為什麼有時候可以瀏覽，有時候卻無法瀏覽網路？」解鈴還須繫鈴人，讓我們一起去看看微軟的網路瀏覽到底是如何實現的。鑒於大家可能對NT的「域」概念還不甚瞭解，出現瀏覽故障的也多為98的電腦，我將以98的「工作組模式」為大家講解

　　二、網路瀏覽

　　1.什麼是瀏覽列表（Browsing List）
　
　　在微軟網路中，用戶可以在瀏覽列表裡看到整個網路（何指？子網還是廣播域？大家可以考慮考慮）上所有的電腦。


當你通過網上的芳鄰視窗打開整個網路時，你將看到一個工作組列表，再打開某個工作組，你將看到裡面的電腦列表（也可在 DOS方式下用net view /domain:workgroupname命令得到），這就是我們所說的 Browsing List。工作組從本質上說就是共享一個瀏覽列表的一組電腦，所有的工作組之間都是對等的，沒有規定不可以讓所有的電腦同處於一個工作組中。

　　2.瀏覽列表在哪裡

　　有人說：網上的芳鄰裡的電腦列表是廣播查詢得來的。可有人舉反例說：我的同學都關機了，可我還是能在網上的芳鄰裡看到它，應該是從HUB或交換機之類較為固定的設備的快取記憶體中取得的。其實他們都只說對了一個方面，把他們二人的說法結合起來就是正確答案了--- 瀏覽列表是通過廣播查詢瀏覽主控服務器，由瀏覽主控服務器提供的。

　　3.瀏覽主控服務器又是什麼

　　瀏覽主控服務器是工作組中的一台最為重要的電腦，它負責維護本工作組中的瀏覽列表及指定其他工作組的主控服務器列表，為本工作組的其他電腦和其他來訪本工作組的電腦提供瀏覽服務，每個工作組都為會每個傳輸協議選擇一個瀏覽主控服務器，而我們經常遇到的無法瀏覽網路的錯誤大多是因為你所處的工作組沒有瀏覽主控服務器而造成的。



你可以在一個工作組中用NBTSTAT -a computername 命令找出使用NBT協議的瀏覽主控服務器，它的標識是含有\\_MSBROWSE_ 名字段。

　　4.瀏覽主控服務器是如何指定的

預設情況下，win98工作組中的瀏覽主控服務器是該工作組中第一台啟用文件及印表機共享功能的電腦，也允許手工將一台win電腦配置為瀏覽主控服務器（方法會在後面講述網路配置時具體介紹，但由於瀏覽主控服務器需要維護動態瀏覽列表，性能會受影響），如果一個工作組中有多台電腦配置了這個選項，或是當前的瀏覽主控服務器關閉了系統，又沒有其他電腦啟用主控設置時，就要進行主控瀏覽器的選舉。


5.如何通過瀏覽器選舉產生瀏覽主控服務器

　　關於瀏覽器的選舉報文，不太好抓包，我就只好按書上的東西來講述了.其實過程很簡單，首先由一台電腦發送一個選舉臨界報文，該報文包含了來自發送電腦的訊息(操作系統，版本及NET名等)，選舉報文向網路中廣播，工作組中的每一台電腦都會用自身訊息與選舉報文進行優先級比較，主要是操作系統起主要作用，記得好像是NT Server>NT Workstation>Win98>WFWG，反正到最後是那個自身條件最好的成為新的瀏覽主控服務器.

　　6.整個網路瀏覽的過程是怎樣的

　　當一台win98進入網路時，如果它帶有服務器服務（啟用了文件及印表機共享）會向網路廣播宣告自己的存在，而瀏覽主控服務器會取得這個宣告並將它放入自己維護的瀏覽列表中；而沒有在相應協議上綁定文件及印表機共享的電腦則不會宣告，因而也就不會出現在網路鄰居裡了。

當客戶電腦想獲得需要的網路資源列表時，首先會廣播發出瀏覽請求，瀏覽主控服務器收到請求後，如果請求的是本組的瀏覽列表，則直接將客戶所需的資源列表發回；如果請求的是其它工作組的瀏覽列表，瀏覽主控服務器會根據本身Browsing List中的記錄找到相應工作組的主控瀏覽器返回給用戶，用戶可從那裡得到它想要的瀏覽列表。至於如何去和另一台電腦共享交換資源，就不是我們這裡要討論的問題了。


　　明白了網路瀏覽的原理，下面我給大家講一個有用的應用，現在很多同學出於安全的考慮都不太歡迎陌生人通過網上的芳鄰訪問自己的電腦，可有時下部電影又需要給認識的同學共享出來，因而還不能刪除文件及印表機共享服務。

怎麼辦？
有些人給共享名加個$，以達到隱藏的效果，可這用DOS下的net share是可被看到的；有些人給共享加上密碼，可聽說這也是有辦法破解的，而且很容易激起「黑客同志」的好奇心。


有沒有辦法將自己的機器在網路鄰居裡隱藏起來呢？而對於認識的同學可以讓他用\\IP 來訪問。想對了，關鍵就是要阻止自己的機器向網路中去宣告自己，而且我知道我們其中的一些
人已經將此變成了現實，至於方法嘛，就不要來問我了。



　　註：因為有關win98瀏覽服務的資料很少，涉及的書籍也多為以NT的「域」模型進行介紹，因而我只能根據自己的理解結合netxray的實踐來測試，細節部分難 免有錯，歡迎大家指正。



7.在我的網上的芳鄰裡為什麼有些電腦訪問不了
　　如果微軟的網上的芳鄰真能做到所見即所得，相信抱怨它的人不會像現在這麼多，可通過前面對瀏覽服務的介紹，大家已經知道這是不可能的，因為瀏覽列表的獲得不是通過訪問其中每一台電腦得到的，很多時候網路中的電腦並不能正確更新瀏覽列表。


當一台電腦正常關機時，它會向網路發出廣播宣告，使瀏覽主控服務器及時將它從瀏覽列表中刪除；而非正常關機後，瀏覽列表裡仍會把該條目保持很長一段時間(NT下是45分鐘)，這就是我們仍能在網路鄰居裡看到它的原因.而98的穩定性是眾所周知的 ----在還沒來得及關機前就已經崩潰了
　　SMB（Server Message Block）協議在NT/2000中用來作文件共享，在NT中，SMB執行於NBT（NetBIOS over TCP/IP）上，使用137，139（UDP），139（TCP）連接阜。

在2000中，SMB可以直接執行在tcp/ip上，而沒有額外的NBT層，使用TCP 445連接阜。

因此在2000上應該比NT稍微變化多一些。 8P6ML+U0
　　可以在「網路連接/內容/TCPIP協議/內容/高階/WINS中設置啟用或者禁用NBT（NetBIOS over TCP/IP）。

　　當2000使用網路共享的時候，就面臨著選擇139或者445連接阜了。下面的情況確定會話使用的連接阜：

　　1、如果客戶端啟用了NBT，那麼連接的時候將同時訪問139和445連接阜，如果從445連接阜得到回應，那麼客戶端將發送RST到139連接阜，停止這個連接阜的連接，接著就從445連接阜進行SMB的會話了；如果沒有從445連接阜而是從139得到回應，那麼就從139連接阜進行會話；如果沒有得到任何回應，那麼SMB會話失敗。


　　2、如果客戶端禁用了NBT，他就將只從445連接阜進行連接。當然如果服務器（開共享端）沒有445連接阜進行SMB會話的話，那麼就會訪問失敗了，所以禁用445連接阜後，對訪問NT機器的共享會失敗。


　　3、如果服務器端啟用NBT，那麼就同時監聽UDP 137、138連接阜和TCP139，445。如果禁用NBT，那麼就只監聽445連接阜了。　所以對於2000來說，共享問題就不僅僅是139連接阜，445連接阜同樣能夠完成。

三、關於空會話

　　The NULL session，關於空會話
　　NULL會話（空會話）使用連接阜也同樣遵循上面的規則。NULL會話是同服務器建立的無信任支持的會話。一個會話包含用戶的認證訊息，而NULL會話是沒有用戶的認證訊息，也就好比是一個匿名的一樣。


　　沒有認證就不可能為系統建立安全通道，而建立安全通道也是雙重的，第一，就是建立身份標誌，第二就是建立一個臨時會話密匙，雙方才能用這個會話進行加密保護資料交換（比如RPC和COM的認證等級是PKT_PRIVACY）。

不管是經過NTLM還是經過Kerberos認證的票據，終究是為會話創建一個包含用戶訊息的令牌。


（這段來自Joe Finamore）
　　根據WIN2000的訪問控制模型，對於空會話同樣需要提供一個令牌。但是空會話由於是沒有經過認證的會話，所以令牌中不包含用戶訊息，因此，建立會話雙方沒有密匙的交換，這也不能讓系統間發送加密保護訊息。


這並不表示空會話的令牌中不包含SID，對於一個空會話，LSA提供的令牌的SID是S-1-5-7，這就是空會話建立的SID，用戶名是ANONYMOUS LOGON。


這個用戶名是可以在用戶列表中看到的。但是是不能在SAM資料庫中找到，屬於系統內置的帳號。



　　（關於這部分對NULL SESSION的分析，可以參照：《NULL Sessions InNT/2000》http://rr.sans.org/win/null.php）
　　NULL會話幾乎成為了微軟自己安置的後門，但是微軟為什麼要來設置這樣一個「後門」呢？
我也一直在想這個問題，如果NULL會話沒有什麼重要的用途，那麼微軟也應該不會來設置這樣一個東西。好不容易才在微軟上找到這個： 當在多域環境中，要在多域中建立信任關係，首先需要找到域中的PDC來通過安全通道的密碼驗證，使用空會話能夠非常容易地找到PDC，還有就是關於一些系統服務的問題。



而且LMHOSTS的#Include就需要空會話的支持，可以參考文章： http://support.microsoft.com/default...;EN-US;q124184
　　其實建立一個空會話的條件也非常嚴格。首先要能夠滿足上面的，也就是打開TCP 139和TCP 445連接阜。我們可以從一次關閉這兩個連接阜的情況中看得出來。服務器關閉445和139連接阜，然後我們來進行空會話的連接。


首先，客戶端打算連接的是445連接阜，然後再試圖連接139連接阜。當然最後還是失敗了。



　　僅僅開放這兩個連接阜還不行，服務器還必須得打開IPC$共享。如果沒有IPC共享，即使共享一個文件，有權限為Anonymous Logon，也不能建立會話，即使權限設置為完全控制，出現的連接錯誤依然是權限不夠。這和其他帳號是不一樣的。如果要允許一個資料夾共享能夠類似IPC$（命名管道而非共享）能夠使用空會話，那麼需要修改註冊表： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\中的：NullSessionShares，新增新的共享名，這樣才能建立一個共享的空會話。這時，將不依賴IPC的存在了。



　　（即使這樣的空會話對於後面的突破也是一點沒可取之處的，因為沒有了IPC$命名管道，RPC不可取了，這下知道IPC這個命名管道的具體實現了。

呵呵）
　　雖然空會話建立的要求很嚴格，但是那都是預定建立的。


既然是預定的，對於使用WIN2K系統的服務器來說，就還是有利用的價值。最明顯的就是空會話可以很方便地連接到其他的域，枚舉用戶、機器等。這也就是掃瞄軟件進行探測的原理。
四、共享技巧

　　1.有些人給共享名加個$，以達到隱藏的效果，可這用DOS下的net share是可被看到的；
　　這種隱藏只是微軟Windows標準客戶端net view的限制，不是服務端的限制，網路傳輸過程中是一視同仁的，所以直接修改客戶端解除這種限制或者使用第三方客戶端軟件均可看到所謂的隱藏共享，比如smbclient就是典型代表。
　　2.有些人給共享加上密碼，可聽說這也是有辦法破解的
　　這個破解要看是什麼層面上的，純暴力破解的就不必說了，那當然總是可以的。而9598另有漏洞，就是他那個著名的vredir.vxd，服務端驗證密碼時所用長度居然是客戶端提供的，這就意味著至多猜測256次(事實上沒這麼多，考慮可印表字元範圍)即可進入。當初N多人用這種辦法非法瀏覽別人的機器。2000年報告微軟，現在已修補。



http://security.nsfocus.net/inde ... o=view&adv_id=6
　　順便說一句，利用該漏洞可以快速窮舉出原始口令，雖然在攻擊中這是不必要的。
　　3. 因而我只能根據自己的理解結合netxray的實踐來測試，細節部分難免有錯，推薦http://www.ethereal.com提供的Ethe...��供源碼。 



　　4. 在2000中，SMB可以直接執行在tcp/ip上，而沒有額外的NBT層，使用TCP 445連接阜。因此在2000上應該比NT稍微變化多一些。


　　事實上正相反，在ssaxh_capabilities字段中指明不使用"擴展安全驗證"，此時使用原有身份驗證機制，只需去掉NBT層的Session Request，將139/TCP改成445/TCP，一樣可以成功建立空會話，並且成功打開\\IPC$。


　至於更高層的RPC Over SMB，更是不必作任何變動。換句話說，從139/TCP換到445/TCP，整個通信過程中減少了一對NBT Session Request/Response，後面的報文對於兩者來說是完全一致的。


　　而所謂的NBT層，即使在445通信中也未去掉，一直存在著，區別只是上面這段話。
　　5. 如果客戶端啟用了NBT，那麼連接的時候將同時訪問139和445連接阜，微軟並沒有讓139/TCP與445/TCP公平競爭。發起連接的SYN包在巨集觀上是同時發出的，具體起來，有時是先向139/TCP發起連接請求，有時是先向445/TCP發起連接請求，有點隨機性。 



　　在向139/TCP發送三次握手的最後一個ACK報文時，Windows順手攜帶了資料，這裡以一個刻意弄錯的NetBIOS名(*SMBSERV<00...(8)>做了一次NBT Session Request。而445/TCP不需要NBT層的會話。


　　由於刻意弄錯的NetBIOS名，139/TCP很難競爭過445/TCP。服務端返回Negative NBTSession Response，並且執行了close()操作。這使得必須重新增立到139/TCP的連接(傳輸層的TCP連接)。



　　可以看出，那個刻意弄錯的NetBIOS名僅僅是為了給445/TCP製造搶先的機會。遺憾的是，445/TCP不爭氣，這個連接阜上的任務繁重、負載較高，即使在這種不公平競爭的情況下，139/TCP仍有可能重新搶在445/TCP之前建立NBT會話(注意，不是TCP連接)。於是445口會回送RST，後續SMB會話建立在139/TCP連接之上。


　　微軟自己的操作系統不認"*SMBSERV<00...(8)>"，但是Samba Server 2.2.5認，居然返回Positive Session Response。這成為精確識別Samba Server的方法之一。


　　微軟在<>中不會提這些的，只是說139/TCP、445/TCP公平競爭，優先使用最早返回的響應報文。不要相信它的鬼話。
　　話說回來，如非需求所致，完全不必關心這種差別。有需求的時候，這種差別是致命的。


　　6. 最明顯的就是空會話可以很方便地連接到其他的域，枚舉用戶、機器等。這也就是掃瞄軟件進行探測的原理。
　　XP、2003預設禁止在空會話上進行PolicyAccountDomainInformation查詢，可以看到LsarOpenPolicy2(44)失敗，權限否定。如果事先指定有效帳號、口令建立SMB會話，而非空會話，LsarOpenPolicy2(44)將成功返回