空會話

根據WIN2000（以win2000為例）的訪問控制模型，空會話的建立同樣需要提供一個令牌，可是空會話在建立過程中並沒有經過用戶信息的認證，所以這個令牌中不包含用戶信息，因此，這個會話不能讓系統間發送加密信息，但這並不表示空會話的令牌中不包含安全標識符SID（它標識了用戶和所屬組），對於一個空會話，LSA提供的令牌的SID是S-1-5-7，這就是空會話的SID，用戶名是：ANONYMOUS LOGON（這個用戶名是可以在用戶列表中看到的，但是是不能在SAM資料庫中找到，屬於系統內置的帳號），這個訪問令牌包含下面偽裝的組：

Everyone

Network

在安全策略的限制下，這個空會話將被授權訪問到上面兩個組有權訪問到的一切信息。

對於NT，在默認安全設置下，藉助空連接可以列舉目標主機上的用戶和共享，訪問everyone許可權的共享，訪問小部分註冊表等，並沒有什麼太大的利用價值；對2000作用更小，因為在Windows 2000 和以後版本中默認只有管理員和備份操作員有權從網路訪問到註冊表，而且實現起來也不方便，需藉助工具。

從這些我們可以看到，這種非信任會話並沒有多大的用處，但從一次完整的ipc$入侵來看，空會話是一個不可缺少的跳板，因為我們從它那裡可以得到戶列表，而大多數弱口令掃描工具就是利用這個用戶列表來進行口令猜解的，成功的導出用戶列表大大增加了猜解的成功率，僅從這一點，足以說明空會話所帶來的安全隱患，因此說空會話毫無用處的說法是不正確的。以下是空會話中能夠使用的一些具體命令：

1 首先，我們先建立一個空連接（當然，這需要目標開放ipc$）

命令：net use \\ip\ipc$ "" /user:""

注意：上面的命令包括四個空格，net與use中間有一個空格，use後面一個，密碼左右各一個空格。

2 查看遠程主機的共享資源

命令：net view \\ip

解釋：前提是建立了空連接后，用此命令可以查看遠程主機的共享資源，如果它開了共享，可以得到如下面的結果，但此命令不能顯示默認共享。

在 \\*.*.*.*的共享資源

資源共享名 類型 用途 註釋

NetlogonDisk Logon server share

SYSVOL Disk Logon server share

命令成功完成。

3 查看遠程主機的當前時間

命令： net time \\ip

解釋：用此命令可以得到一個遠程主機的當前時間。

4 得到遠程主機的NetBIOS用戶名列表（需要打開自己的NBT）

命令：nbtstat -A ip

用此命令可以得到一個遠程主機的NetBIOS用戶名列表，返回如下結果：

Node IpAddress: [*.*.*.*] Scope Id: []

NetBIOS Remote Machine Name Table

Name Type Status

SERVER <00> UNIQUE Registered

OYAMANISHI-H <00> GROUP Registered

OYAMANISHI-H <1C> GROUP Registered

SERVER <20> UNIQUE Registered

OYAMANISHI-H <1B> UNIQUE Registered

OYAMANISHI-H <1E> GROUP Registered

SERVER <03> UNIQUE Registered

OYAMANISHI-H <1D> UNIQUE Registered

..__MSBROWSE__.<01> GROUP Registered

INet~Services <1C> GROUP Registered

IS~SERVER......<00> UNIQUE Registered

MAC Address = 00-50-8B-9A-2D-37

5.有些人給共享名加個$，以達到隱藏的效果，可這用DOS下的net share是可被看到的；

這種隱藏只是微軟Windows標準客戶端net view的限制，不是服務端的限制，網路傳輸過程中是一視同仁的，所以直接修改客戶端解除這種限制或者使用第三方客戶端軟體均可看到所謂的隱藏共享，比如smbclient就是典型代表。

6.有些人給共享加上密碼，可聽說這也是有辦法破解的

這個破解要看是什麼層面上的，純暴力破解的就不必說了，那當然總是可以的。而95、98另有漏洞，就是他那個著名的vredir.vxd，服務端驗證密碼時所用長度居然是客戶端提供的，這就意味著至多猜測256次(事實上沒這麼多，考慮可列印字元範圍)即可進入。當初N多人用這種辦法非法瀏覽別人的機器。2000年報告微軟，現在已修補。

順便說一句，利用該漏洞可以快速窮舉出原始口令，雖然在攻擊中這是不必要的。

7. 在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通信中也未去掉，一直存在著，區別只是上面這段話。

8. 如果客戶端啟用了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公平競爭，優先使用最早返回的響應報文。不要相信它的鬼話。

話說回來，如非需求所致，完全不必關心這種差別。有需求的時候，這種差別是致命的。

9. 最明顯的就是空會話可以很方便地連接到其他的域，枚舉用戶、機器等。這也就是掃描軟體進行探測的原理。

XP、2003預設禁止在空會話上進行PolicyAccountDomainInformation查詢，可以看到LsarOpenPolicy2(44)失敗，許可權否定。如果事先指定有效帳號、口令建立SMB會話，而非空會話，LsarOpenPolicy2(44)將成功返回。

以上就是我們經常使用空會話做的事情，好像也能獲得不少東西喲，不過要注意一點：建立IPC$連接的操作會在Event Log中留下記錄，不管你是否登錄成功。