軟體 - 視窗作業系統密碼體系的弱點及對策

[psac]

視窗作業系統密碼體系的弱點及對策
一、問題的提出
本文僅就此處所列的幾個在實際工作裡發現的問題，對目前普遍使用的視窗作業系統裡隱藏的幾個有關密碼體系的危險弱點進行了分析並指出相應對策，這些危險弱點導致的電腦安全隱患，希望能引起相關用戶的重視。
1、視窗作業系統「用戶登入」對話視窗問題
圖A是大家熟悉的「用戶登入」對話視窗：

圖A
大家都知道，只要願意，現在可以通過很多能方便從網際網路上下載的實用程式對圖A所顯示的「TesT」用戶進行「Crack」以獲得其原先設定在TesT.PwL文件內的正確密碼，儘管這需要耗些時間，目的是能假冒用戶「TesT」登入作業系統或套用系統，以逃避安全審計系統。
問題是視窗作業系統其內裝的密碼安全體系存在很多弱點甚至缺陷，導致對於上述作業系統起碼的安全環節——用戶登入，只需對一個名為「■spwL」的系統動態連接庫文件，僅僅修改其「一個」字元後，視窗作業系統這個起碼的安全環節就告失效！利用這個弱點相比上述「Crack」方法幾乎沒有「時間成本」。
相關實驗：
在視窗作業系統內找到名為「■spwL」的系統動態連接庫文件，然後在一般的十六進制編輯器裡搜尋十六進制串{ B9 10 00 00 00 2B }後將其間的{ 10 }改為{ 00 }即上述十六進制串被改動一個字元後變為{ B9 00 00 00 00 2B }，即：
搜尋 → B9 10 00 00 00 2B
替為 → B9 00 00 00 00 2B
儲存這個改動，然後嘗試再次登入，就會發現，所有在系統啟始化文件裡記錄的用戶，都可以任意的密碼甚至僅僅一個Enter鍵鍵的形式輕鬆登入，而「合法」用戶很難察覺。
2、視窗作業系統「標幟登入」對話視窗問題
圖B是大家熟悉的「標幟登入」對話視窗：

圖B
這個「標幟登入」對話視窗最一般的是在用戶試圖使用視窗作業系統內裝的OutLooK Express電子郵件元件時由視窗作業系統彈出。當用戶選項自己的標幟並輸入正確的密碼後即可通過OutLooK Express收發電子郵件。
同樣地，大家可以在網際網路上下載一些相關的實用程式來「Crack」上述「TesT」 標幟的密碼，然後可以假冒合法用戶的標幟收發郵件，但是通過這些實用程式執行後需要消耗時間才能獲得結果。
同樣地，我們發現視窗作業系統內裝的密碼安全體系存在的相關弱點，導致用戶的「標幟密碼」形同虛設——只需對一個名為「■sidenT」的系統動態連接庫文件，僅僅修改其「二個」字元後，視窗作業系統的這個安全環節也告失效。
相關實驗：
在視窗作業系統內找到名為「■sidenT」的系統動態連接庫文件，然後在一般的十六進制編輯器裡搜尋十六進制串{ 8A188AD33A19751A84D274128A5801}後將其間的{ 18 }改為{ 19 }及{ 58 }改為{ 59 }即上述十六進制串被改動二個字元後變為{ 8A198AD33A19751A 84D27412 8A5901 }，即：
搜尋 → 8A 18 8AD3 3A19 751A 84D2 7412 8A 58 01
替為 → 8A 19 8AD3 3A19 751A 84D2 7412 8A 59 01
儲存這個改動，然後嘗試再次登入，就會發現，所有標幟，都可以任意的密碼甚至僅僅一個Enter鍵鍵的形式輕鬆登入！而被冒認的「標幟」所有者很難察覺！
3、視窗作業系統「連接登入」對話視窗問題
圖C大家熟悉的「連接登入」對話視窗：

圖C
大家都知道，目前可以方便地通過實用程式，對密碼形式的文本框進行「透視」。這裡我們不討論這些內容，我們希望通過對視窗作業系統的密碼安全體系裡存在的危險弱點進行討論，讓大家在自己的套用系統裡避免類似的疏漏，讓我們自己的的套用系統更為安全。
我們發現視窗作業系統內裝的密碼安全體系存在的相關弱點，導致上述「TesT」用戶的密碼在記憶體裡竟以明碼出現，根本無須「透視」而只要在記憶體裡稍微探查一下即可。
相關實驗：
使用執行在系統級的記憶體探查程序或偵錯器，我們可以輕而易舉地在系統記憶體探查到圖C的連接登入密碼（圖C「TesT」用戶事先設定的密碼是「Chinese!10-01-1949」 ）：
視窗作業系統之「連接登入」密碼記憶體探查結果[2]
位址80FD9E2A起
00 00 00 00 00 00 00 00-00 00 3F 03 8C 03 26 01 ..........?...&.
43 68 69 6E 65 73 65 21-31 30 2D 30 31 2D 31 39 Chinese!10-01-19
34 39 00 00 00 00 00 00-00 00 00 00 00 00 00 00 49..............
00 00 67 03 B4 03 22 01-54 65 73 54 00 00 00 00 ..g...".TesT....
在上述探查結果裡，我們可以輕易發現「TesT」用戶的連接密碼為「Chinese!10-01-1949」。
4、視窗作業系統「共享登入」設定對話視窗問題
圖D是大家熟悉的「共享登入」設定對話視窗：

圖 D
大家知道，上述對話視窗同樣可以方便地通過實用程式，對密碼形式的文本框進行「透視」。這裡我們不討論這些內容，我們換一個角度來討論。
我們發現視窗作業系統內裝的密碼安全體系存在的相關弱點，同樣導致上述「TesT」用戶的「唯讀」密碼以及「完全訪問」密碼在記憶體裡以明碼出現，根本無須「透視」而只要在記憶體裡稍微探查一下即可。
相關實驗：
使用執行在系統級的記憶體探查程序或偵錯器，我們可以輕而易舉地在系統記憶體探查到圖D的共享登入設定密碼（圖D「TesT」用戶事先設定的「唯讀」密碼以及「完全訪問」密碼分別是「TesTTesT」 及「!!GoTo!!」——最多八個字串）：
視窗作業系統之「共享登入」設定密碼記憶體探查結果
位址816B55D2起
00 00 B6 0F 00 00 00 40-00 00 E7 02 64 03 2A 01 .......@.
54 65 73 54 54 65 73 54-00 00 00 00 00 00 00 00 TesTTesT.
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 .........
00 00 3F 03 8C 03 26 01-00 00 00 00 00 00 00 00 ..?...&..
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 .........
00 00 00 00 00 00 00 00-00 00 67 03 B4 03 22 01 .........
54 65 73 54 00 00 00 00-00 00 00 00 00 00 00 00 TesT.....
位址816B57F2起
00 00 06 00 00 00 00 00-05 00 57 04 74 06 2E 01 .........
21 21 47 6F 54 6F 21 21-00 00 00 00 00 00 00 00 !!GoTo!!.
在上述探查結果裡，我們可以輕易地發現「TesT」用戶的「唯讀」密碼為「TesTTesT」同時其 「完全訪問」密碼為「!!GoTo!!」）。
二、問題的分析及對策
1、關於視窗作業系統「用戶登入」對話視窗問題
我們將視窗作業系統內「用戶登入」密碼研判的核心程式碼列出來分析如下。
： ：
以上進行了多次單向HasH運算並得到長度為128位的HasH串（具體算法分析略）然後與儲存在對應PWL文件內的正確值比對，詳見以下程式碼。
： ：
7FA71D97 B910000000 mov ecx, 00000010 ；HasH串為128位即16個字元
7FA71D9C 2BC0 sub eax, eax ；啟始化EAX暫存器
7FA71D9E F3 repz
7FA71D9F A6 cmpsb ；進行128位HasH串比對
7FA71DA0 7405 je 7FA71DA7 ；相等，系統認為用戶密碼正確
7FA71DA2 1BC0 sbb eax, eax ；否則置密碼比對錯誤標誌
7FA71DA4 83D8FF sbb eax, FFFFFFFF
7FA71DA7 85C0 test eax, eax ；測試密碼比對標誌位
7FA71DA9 B8261C0000 mov eax, 00001C26 ；預置密碼錯誤消息
7FA71DAE 7502 jne 7FA71DB2 ；密碼比對錯誤，則轉
7FA71DB0 33C0 xor eax, eax ；否則置密碼比對正確位
7FA71DB2 5F pop edi ；恢復現場
7FA71DB3 5E pop esi ；恢復現場
7FA71DB4 5B pop ebx ；恢復現場
7FA71DB5 8BE5 mov esp, ebp ；恢復現場
7FA71DB7 5D pop ebp ；恢復現場
7FA71DB8 C20400 ret 0004 ；返回
： ：
從上述分析可見，當我們將密碼比對的長度由「0x10H」 改為「0」——也就是將上述
將 mov ecx, 00000010
改為 → mov ecx, 00000000
僅僅改動「一個」字元，「用戶登入」密碼的比對結果就將「永遠」正確。
僅僅依賴一條「repz cmpsb」指令對系統級的密碼進行決定性研判是相當危險的，而僅僅通過一條件語句來選項視窗作業系統的密碼安全類指令的決定性流向，其實是很「傳統」的低級做法，保護效果相當脆弱。因為不論作業系統採用的單向HasH結果長度多麼「驚人」也不論作業系統在執行「repz cmpsb」這條研判指令之繼續行了多少輪大負荷的迭代編碼，我們只要在這一條「關鍵路徑」上實施「點穴」——這個層次的安全保護即告失效。
對策：
視窗作業系統在這裡的最大「疏忽」就是對「苦心積慮」最後獲得的128位HasH串僅僅參與簡單的比對，並沒有進行更有效的利用，建議：
將上述最後運算出來的128位HasH串不論其對錯都作為新一輪解碼迭代運算的輸入算子，對後續的部分關鍵程式碼或資料實施解碼，這樣用戶輸入正確的密碼後自然能正確地繼續安裝載入視窗作業系統，否則只能導致錯誤提示而無法繼續正確地安裝載入視窗作業系統。
事實上這是一個明顯的安全漏洞。不要認為儲存於設備上的系統級文件設定了「唯讀」、「隱藏」等權限，就可以高枕無憂。事實上，只要系統的儲存於設備可以被「物理」地讀寫，那麼對其上敏感的系統級文件進行「篡改」就不會是一件「相當」困難的事情。而在大多數情況下，這件事還是比較容易做到的。有關這個安全漏洞的更進一步討論，我們將在《脆弱的軟體著作權保護方式及對策》一文裡進行，並相應地指出一個有效的解決方案。
2、關於視窗作業系統「標幟登入」對話視窗問題
我們將視窗作業系統內「標幟登入」密碼研判的核心程式碼列出來分析如下。
： ： ┌ ECX、EAX分別指向用戶輸入密碼及正確密碼
797972C3 8D4DE8 lea ecx, dword ptr [ebp-18]
797972C6 8D85E8FDFFFF lea eax, dword ptr [ebp+FFFFFDE8]
797972CC 8A18 mov bl, byte ptr [eax] ；獲取第一個密碼字串
797972CE 8AD3 mov dl, bl ；儲存起副本
797972D0 3A19 cmp bl, byte ptr [ecx] ；與正確的密碼比對
797972D2 751A jne 797972EE ；第一個密碼字串不正確
797972D4 84D2 test dl, dl ；為最後一個密碼字串？
797972D6 7412 je 797972EA ；是則轉
797972D8 8A5801 mov bl, byte ptr [eax+01] ；獲取下一密碼字串
797972DB 8AD3 mov dl, bl ；儲存其副本
797972DD 3A5901 cmp bl, byte ptr [ecx+01] ；與正確的密碼比對
797972E0 750C jne 797972EE ；比對不成功則轉
797972E2 40 inc eax ；調整當前密碼字串游標
797972E3 40 inc eax ；調整當前密碼字串游標
797972E4 41 inc ecx ；調整正確密碼字串游標
797972E5 41 inc ecx ；調整正確密碼字串游標
797972E6 84D2 test dl, dl ；為最後一個密碼字串？
797972E8 75E2 jne 797972CC ；尚未比對完則轉
797972EA 33C0 xor eax, eax ；比對結束並且全部正確
797972EC EB05 jmp 797972F3 ；轉後續測試標誌位
797972EE 1BC0 sbb eax, eax ；比對結束但是不正確
797972F0 83D8FF sbb eax, FFFFFFFF ；置錯誤標誌位
797972F3 85C0 test eax, eax ；測試標誌位
797972F5 7434 je 7979732B ；密碼比對正確則轉
： ：
從上述分析可見，當我們將密碼比對的二個游標EAX、ECX均指向同一個位址——也就是將上述
將 mov bl, byte ptr [eax]
改為 → mov bl, byte ptr [ecx]
將 mov bl, byte ptr [eax+01]
改為 → mov bl, byte ptr [ecx+01]
僅僅改動「二個」字元，「標幟登入」密碼的比對結果就將「永遠」正確。這同樣是一個明顯的安全漏洞。這個漏洞源自明文密碼比較的指令過於接近，很容易通過對有關的指令程式碼進行「篡改」達到「冒名」攻擊的目的。
對策：
首先我們要盡可能避免明文密碼的比較，並盡可能地將明碼密碼「暗碼」化，即將明文密碼通過穩健的摘要密碼算法「撕碎」後「淹沒」在長度至少在128位的高強度單向散列串裡（具體參考我們發表的《大型Web應用軟體系統的安全登入隱患及對策》一文），如果實在沒有這個「耐性」做這項工作，那至少要考慮將密碼研判的有關指令「離散」化而不像現在這般前後「緊密」相連，更為安全的做法請參考我們完成的《脆弱的軟體著作權保護方式及對策》一文，裡頭相應地指出一個有效的解決方案。
3、關於視窗作業系統「連接登入」對話視窗問題
原因在於視窗作業系統對這類密碼解碼及研判，既沒有如「用戶登入」對話視窗般採用比較安全的「OpeNPassworDCachE」方法對有關記憶體進行分配，也沒有對有關密碼儲存於的記憶體在研判後進行必要「清零」。所以我們可以輕而易舉地通過記憶體探查，找到用戶的上述敏感資料。
對策：
首先考慮啟用較安全的「OpeNPassworDCachE」方法對有關記憶體進行分配，並確保密碼比較後必須立即執行有關密碼記憶體單元的「清零」工作，以抵禦記憶體探查工具「窺視」攻擊。如果需要更安全的密碼研判，就應該盡可能避免在記憶體裡出現明文密碼，具體做法請參考我們完成的《脆弱的軟體著作權保護方式及對策》一文，裡頭相應地指出一個有效的解決方案。
4、關於視窗作業系統「共享登入」設定對話視窗問題
原因在於視窗作業系統對這類密碼解碼及研判，既沒有採用比較安全的「OpeNPassworDCachE」方法對有關記憶體進行分配，也沒有對有關密碼儲存於的記憶體在研判後進行必要「清零」。所以我們可以輕而易舉地通過記憶體探查，找到用戶的上述敏感資料。
對策：
首先考慮啟用較安全的「OpeNPassworDCachE」方法對有關記憶體進行分配，並確保密碼比較後必須立即執行有關密碼記憶體單元的「清零」工作，以抵禦記憶體探查工具「窺視」攻擊。如果需要更安全的密碼研判，就應該盡可能避免在記憶體裡出現明文密碼，具體做法請參考我們完成的《脆弱的軟體著作權保護方式及對策》一文，裡頭相應地指出一個有效的解決方案。
三、結論
對於被具有起碼強度的穩健單向HasH算法保護的產品，簡單並可能有效但是未必高效的攻擊當然首先考慮的是窮舉，當然其規模不能太大，但是對於視窗作業系統產品而言，在大多數情況下就連窮舉都可以省略，直接「Crack」或直接進行記憶體探查就能達到目的，這是因為其沒有對系統指令程式碼及密碼等敏感資料所在記憶體的安全性進行必要的維護以及保護：
（1）對於系統指令程式碼而言，視窗作業系統大都以一般形式讀寫、執行，缺乏對關鍵指令程式碼進行必要的校驗，以防止其在系統記憶體裡被「篡改」。
（2）對於密碼資料而言，視窗作業系統將「還原」後的密碼在「使用」完畢後仍以明碼形式遺留在系統記憶體裡，而「密碼儲存於記憶體在密碼研判後進行清零」——這是稍有些密碼安全知識的人的常識性做法，何以視窗作業系統生產商卻出現如此疏忽？
目前我們尚未獲得視窗作業系統生產商在其本土銷售的版本，如果相關的分析表明僅僅在其國際版本裡才存在本文討論的這些密碼安全體系弱點，拋開其開發成本或穩定性等托詞，其真正用意值得大家深思。
大家也不要認為視窗2K等版本相對而言較安全，就抱著僥倖心理以為沒有上述有關密碼安全體系方面的弱點。我們的分析包括了視窗2K等版本，就「用戶登入」對話視窗問題而言，視窗2K等版本作業系統同樣存在上述安全隱患。只需對一個名為「■sv1_0」的系統動態連接庫文件，僅僅修改其「一個」字元後，視窗2K等版本作業系統起碼的安全環節就告失效。可輕鬆以超級用戶「Administrator」登入，利用這個弱點無須「Crack」，有關的「時間成本」幾乎為零！所以本文的討論還是有代表性的。希望能引起大家必要的重視。
視窗2K版本的相關實驗：
在視窗2K版本作業系統內找到名為「■sv1_0」的系統動態連接庫文件，然後在一般的十六進制編輯器裡搜尋十六進制串{ F8 10 0F 84 71 FF FF }後將其間的{ 10 }改為{ 00 }即上述十六進制串被改動一個字元後變為{ F8 00 0F 84 71 FF FF }，即：
搜尋 → F8 10 0F 84 71 FF FF
替為 → F8 00 0F 84 71 FF FF
儲存這個改動，然後嘗試以超級用戶「Administrator」登入，就會發現相關的密碼安全弱點。
對策：
這個例子所揭示的安全弱點的有關對策請參考我們完成的《脆弱的軟體著作權保護方式及對策》一文，裡頭有更為詳盡的分析。
事實證明，對於不借助可熱插拔的移動儲存於介品質保證存密碼（密鑰）以及缺乏穩健的密碼安全體系的視窗作業系統，目的明確並具備起碼專業技能的人員「入侵」視窗作業系統並不是一件困難的事情。（作者服務機構 Abusys公司）
[1] 本文僅供參考，如果讀者希望重複實驗及資料，請一定嚴格按照本文依照原樣提供的所有指令執行，儘管我們知道本文的所有實驗例子都可以安全地被重複，但是讀者行動之前請記住，我們對因此產生的結果不作任何形式的擔保。
[2]本文所附圖之具體位址數值不必拘泥。