☆ 概述 ☆ 挑戰/響應模式 ☆ L0pht文件 ☆ Windows NT身份驗證機制的脆弱性 ☆ str_to_key()函式 ☆ 如何從明文口令生成LM Hash ☆ 標準DES加密 ☆ 如何從明文口令生成NTLM Hash ☆ 標準MD4單向雜湊 ☆ SMB報文中使用的是DES LM Hash和DES NTLM Hash ☆ 觀察一個例項 ☆ negotiate response解碼 ☆ session_setup_andx request解碼 ☆ 小結 ☆ 參考資源

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

☆ 概述

早期SMB協議在網路上傳輸明文口令。後來出現"LAN Manager Challenge/Response" 驗證機制，簡稱LM，它是如此簡單以至很容易被破解。微軟提出了WindowsNT挑戰/響 應驗證機制，稱之為NTLM。現在已經有了更新的NTLMv2以及Kerberos驗證體系。

微軟承認LM Hash的固有特性極大損害了安全性，但他們認為這是最初設計者IBM之過。

☆ 挑戰/響應模式

使用明文口令模式時，網路上傳輸的就是明文口令本身，這很容易被Sniffer捕獲。 挑戰/響應模式的企圖不洩露明文口令本身就能證明客戶機確實擁有正確的口令:

1. 伺服器隨機產生一個8位元組的挑戰，送往客戶機。

2. 伺服器、客戶機各自使用源自明文口令的DESKEY分別對8位元組挑戰進行加密。客戶 機將計算結果送往伺服器，這就是所謂響應(分成三組，總共24位元組)。

response = DES( key derived from plaintext password, challenge )

這裡使用的就是標準DES演算法。任何知道key的人都可以將reponse解密，從而獲取 challenge。

3. 如果響應與伺服器的計算結果匹配，伺服器認為客戶機擁有正確的明文口令。

☆ L0pht文件

1997年7月12日，L0pht的Mudge <[email protected]

+----------------------------+ | 14bytes Plaintext Password | +----------------------------+

+--------------------------------------------------------------------------+ | first 7bytes of Plaintext Password | second 7bytes of Plaintext Password | +--------------------------------------------------------------------------+

+-----------------+ | 16bytes LM Hash | +-----------------+

+----------------------------------------------------+ | first 8bytes of LM Hash | second 8bytes of LM Hash | +----------------------------------------------------+

+-------------------------+ | 16bytes NTLM Hash (MD4) | +-------------------------+

+------------------+ | 8bytes Challenge | +------------------+

+------------------+ | 24bytes Response | +------------------+

LM Hash的前8位元組源自對明文口令前7位元組的運算，LM Hash的後8位元組源自對明文口 令後7位元組的運算。如果明文口令最多7位元組，則第二部分LM Hash總是"AA D3 B4 35 B5 14 04 EE"(以後解釋這裡)。比如以"WELCOME"做為明文口令，則對應的LM Hash是 "C23413A8A1E7665FAAD3B435B51404EE"。

假設伺服器B向客戶機A傳送了一個8位元組挑戰"0001020304050607"

Server B -- 8bytes Challenge --> Client A

A現在有LM Hash，C23413A8A1E7665FAAD3B435B51404EE，在其後增加5個0x00變成 "C23413A8A1E7665FAAD3B435B51404EE0000000000"，然後劃分成三組，每組7位元組

+----------------+----------------+----------------+ | C23413A8A1E766 | 5FAAD3B435B514 | 04EE0000000000 | +----------------+----------------+----------------+

每組7位元組做為形參傳遞給str_to_key()函式，最終得到三組DESKEY，每組8位元組

+--------------------------------------------------------+ | 8bytes DESKEY1 | 8bytes DESKEY2 | 8bytes DESKEY3 | +------------------+------------------+------------------+ | C21A04748A0E9CCC | 5ED4B47642ACD428 | 0476800000000000 | +--------------------------------------------------------+

分別用三組DESKEY對8位元組挑戰"0001020304050607"進行標準DES加密後得到

C21A04748A0E9CCC -對0001020304050607進行標準DES加密-> CA1200723C41D577 5ED4B47642ACD428 -對0001020304050607進行標準DES加密-> AB18C764C6DEF34F 0476800000000000 -對0001020304050607進行標準DES加密-> A61BFA0671EA5FC8

最終獲得一個24位元組響應"CA1200723C41D577AB18C764C6DEF34FA61BFA0671EA5FC8"， 送往伺服器B。在伺服器B上進行同樣的計算，並將計算結果與來自A的響應進行比較， 如果匹配則身份驗證通過。

考慮明文口令不超過7位元組的情況。

首先檢查明文口令是否少於8位元組。用str_to_key()函式處理"04EE0000000000"，得 到8位元組的DESKEY，"0476800000000000"，用它對挑戰"0001020304050607"進行標準 DES加密，如果結果與網路上傳輸的"A61BFA0671EA5FC8"相符，明文口令很可能少於8 位元組，當然不能絕對肯定。

接下來用str_to_key()函式處理"??AAD3B435B514"，得到8位元組DESKEY，用它對挑戰 進行標準DES加密，如果與網路上傳輸的"AB18C764C6DEF34F"相符，則找到匹配，此 時我們可以絕對肯定明文口令少於8位元組。這裡"??"由迴圈產生，窮舉256種可能。

由於LM Hash的一些固有特性，窮舉運算量已大幅下降。

考慮明文口令為8位元組或更多，假設最後的LM Hash如下

+----------------+----------------+----------------+ | C23413A8A1E766 | AC435F2DD90417 | CCD60000000000 | +----------------+----------------+----------------+

首先檢查明文口令是否少於8位元組。用str_to_key()函式處理"04EE0000000000"，得 到8位元組的DESKEY，"0476800000000000"，用它對挑戰進行標準DES加密，如果結果與 網路上傳輸的內容不相符，明文口令必然大於等於8位元組。

接下來用str_to_key()函式處理"????0000000000"，得到8位元組DESKEY，用它對挑戰 進行標準DES加密，如果與網路上傳輸的內容相符，則找到匹配。這裡"????"由迴圈 產生，窮舉65536種可能。

上面實際在介紹如何根據Challenge/Response暴力破解獲取LM Hash。

即使到了NT4 SP3，DES LM Hash Response還是與DES NTLM Hash Response一起傳送， 這種情況下NTLM Hash強度再高也是沒有意義的。

如果禁用DES LM Hash Response，Windows 95無法與NT進行正常的SMB通訊。

如果你所使用的Windows系統支援口令超過14位元組，就儘量使用超過14位元組的口令。

☆ Windows NT身份驗證機制的脆弱性

1997年2月6日，Dominique Brezinski <[email protected]>對外 釋出了一份關於Windows NT身份驗證機制脆弱性的文件(參考資源[8])。

假設有主機B與A

(1) A向B發起連線請求

(2) B向A傳送挑戰(一組隨機資料)

(3) A用源自明文口令的DESKEY對挑戰進行標準DES加密得到響應，併發往B

(4) B從SAM中獲取A的LM Hash、NTLM Hash，計算出DESKEY，並對前面發往A的挑戰進 行標準DES加密

(5) 如果(4)中計算結果與A送過來的響應匹配，A被允許訪問B

現在假設一個攻擊者C捲入其中

(1) C向B發起連線請求

(2) B向C傳送挑戰D(一組隨機資料)

(3) C等待A向B發起連線請求

(4) 當A向B發起連線請求時，C偽造成B向A傳送挑戰D

(5) A用源自明文口令的DESKEY對挑戰D進行標準DES加密得到響應E，併發往B

(6) C截獲到響應E，將它做為針對(2)中挑戰D的響應發往B，並聲稱自己是A

(7) B從SAM中獲取A的LM Hash、NTLM Hash，計算出DESKEY，並對挑戰D進行標準DES 加密

(8) 如果(7)中計算結果與C送過來的響應匹配，C被允許以A的身份訪問B

下面我們詳細分析一下這個過程。攻擊者C捲入A與B的通訊中，C向B建立NBT會話併發 送SMB_COM_NEGOTIATE(0x72)請求報文，指定使用"NT LM 0.12" dialect。在使用者級 共享(與之相對的是共享級共享)中"NT LM 0.12"是首選SMB dialect。B將在響應報文 的encryption key(其實應該叫Challenge)欄位中返回8位元組的挑戰。C儲存這8位元組的 挑戰並開始等待，如果B因為超時終止了這次連線，C必須重複前面的步驟。當A試圖 連線B時，也會建立NBT會話併發送SMB_COM_NEGOTIATE(0x72)請求報文，就dialect進 行協商。一般最終協商結果都是使用"NT LM 0.12"