空會話

根據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

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

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

資源共享名 類型 用途 註釋

-----------------------------------------------------------

NETLOGON Disk 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中留下記錄，不管你是否登錄成功。