文章目錄
一、問題的提出 本文僅就此處所列的幾個在實際工作裡發現的問題，對目前普遍使用的視窗作業系統裡隱藏的幾個有關密碼體系的危險弱點進行了分析並給出相應對策，這些危險弱點導致的電腦安全隱患，希望能引起相關使用者的重視。
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 |
儲存這個改動，然後嘗試再次登入，就會發現，所有在系統初始設定檔案裡記錄的使用者，都可以任意的密碼甚至僅僅一個斷行符號鍵的形式輕鬆登入，而“合法”使用者很難察覺。
2、視窗作業系統“標識登入”對話方塊問題圖B是大家熟悉的“標識登入”對話方塊：
圖B 這個“標識登入”對話方塊最常見的是在使用者試圖使用視窗作業系統內建的OutLooK Express電子郵件組件時由視窗作業系統彈出。當使用者選擇自己的標識並輸入正確的密碼後即可通過OutLooK Express收發電子郵件。 同樣地，大家可以在互連網上下載一些相關的實用程式來“Crack”上述“TesT” 標識的密碼，然後可以假冒合法使用者的標識收發郵件，但是通過這些實用程式執行後需要消耗時間才能獲得結果。 同樣地，我們發現視窗作業系統內建的密碼安全體系存在的相關弱點，導致使用者的“標識密碼”形同虛設——只需對一個名為“■sidenT”的系統動態連結程式庫檔案，僅僅修改其“
二個”位元組後，視窗作業系統的這個安全環節也告失效。
相關實驗： 在視窗作業系統內找到名為“■sidenT”的系統動態連結程式庫檔案，然後在常見的十六進位編輯器裡搜尋十六進位串{ 8A
188AD33A19751A84D274128A
5801}後將其間的{ 18 }改為{ 19 }及{ 58 }改為{ 59 }即上述十六進位串被改動二個位元組後變為{ 8A
198AD33A19751A 84D27412 8A
5901 }，即：
| 搜尋 → 8A 18 8AD3 3A19 751A 84D2 7412 8A 58 01替為 → 8A 19 8AD3 3A19 751A 84D2 7412 8A 59 01 |
儲存這個改動，然後嘗試再次登入，就會發現，所有標識，都可以任意的密碼甚至僅僅一個斷行符號鍵的形式輕鬆登入！而被冒認的“標識”所有者很難察覺！
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, FFFFFFFF7FA71DA7 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]本文所附圖之具體地址數值不必拘泥。
