我们将视窗操作系统内“标识登录”密码研判的核心代码列出来分析如下。

 

：   ：          ┏ 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应用软件系统的安全登录隐患及对策》一文），如果实在没有这个“耐性”做这项工作，那至少要考虑将密码研判的有关指令“离散”化而不象现在这般前后“紧密”相连，更为安全的做法请参考我们完成的《脆弱的软件著作权保护方式及对策》一文，里头相应地给出一个有效的解决方案。

 

       原因在于视窗操作系统对这类密码解码及研判，既没有如“用户登录”对话框般采用比较安全的“OpeNPassworDCachE”方法对有关内存进行分配，也没有对有关密码存储的内存在研判后进行必要“清零”。所以我们可以轻而易举地通过内存探查，找到用户的上述敏感数据。

 

       首先考虑启用较安全的“OpeNPassworDCachE”方法对有关内存进行分配，并确保密码比较后必须立即执行有关密码内存单元的“清零”工作，以抵御内存探查工具“窥视”攻击。如果需要更安全的密码研判，就应该尽可能避免在内存里出现明文密码，具体做法请参考我们完成的《脆弱的软件著作权保护方式及对策》一文，里头相应地给出一个有效的解决方案。

 

       原因在于视窗操作系统对这类密码解码及研判，既没有采用比较安全的“OpeNPassworDCachE”方法对有关内存进行分配，也没有对有关密码存储的内存在研判后进行必要“清零”。所以我们可以轻而易举地通过内存探查，找到用户的上述敏感数据。

 

      首先考虑启用较安全的“OpeNPassworDCachE”方法对有关内存进行分配，并确保密码比较后必须立即执行有关密码内存单元的“清零”工作，以抵御内存探查工具“窥视”攻击。如果需要更安全的密码研判，就应该尽可能避免在内存里出现明文密码，具体做法请参考我们完成的《脆弱的软件著作权保护方式及对策》一文，里头相应地给出一个有效的解决方案。

       对于被具有起码强度的稳健单向HasH算法保护的产品，简单并可能有效但是未必高效的攻击当然首先考虑的是穷举，当然其规模不能太大，但是对于视窗操作系统产品而言，在大多数情况下就连穷举都可以省略，直接“Crack”或直接进行内存探查就能达到目的，这是因为其没有对系统指令代码及密码等敏感数据所在内存的安全性进行必要的维护以及保护：

 

（1）对于系统指令代码而言，视窗操作系统大都以常规形式读写、执行，缺乏对关键指令代码进行必要的校验，以防止其在系统内存里被“篡改”。

 

（2）对于密码数据而言，视窗操作系统将“还原”后的密码在“使用”完毕后仍以明码形式遗留在系统内存里，而“密码存储内存在密码研判后进行清零”——这是稍有些密码安全知识的人的常识性做法，何以视窗操作系统生产商却出现如此疏忽？

 

       目前我们尚未获得视窗操作系统生产商在其本土销售的版本，如果相关的分析表明仅仅在其国际版本里才存在本文讨论的这些密码安全体系弱点，抛开其开发成本或稳定性等托词，其真正用意值得大家深思。

 

       大家也不要认为视窗2K等版本相对而言较安全，就抱着侥幸心理以为没有上述有关密码安全体系方面的弱点。我们的分析包括了视窗2K等版本，就“用户登录”对话框问题而言，视窗2K等版本操作系统同样存在上述安全隐患。只需对一个名为“■sv1_0”的系统动态链接库文件，仅仅修改其“一个”字节后，视窗2K等版本操作系统起码的安全环节就告失效。可轻松以超级用户“Administrator”登录，利用这个弱点无须“Crack”，有关的“时间成本”几乎为零！所以本文的讨论还是有代表性的。希望能引起大家必要的重视。

 

       在视窗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]本文所附图之具体地址数值不必拘泥。