视窗操作系统密码体系的弱点及对策(图)_漏洞研究

一、问题的提出

       本文仅就此处所列的几个在实际工作里发现的问题，对目前普遍使用的视窗操作系统里隐藏的几个有关密码体系的危险弱点进行了分析并给出相应对策，这些危险弱点导致的计算机安全隐患，希望能引起相关用户的重视。

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 }，即：

       保存这个改动，然后尝试再次登录，就会发现，所有在系统初始化文件里记录的用户，都可以任意的密码甚至仅仅一个回车键的形式轻松登录，而“合法”用户很难察觉。

2、视窗操作系统“标识登录”对话框问题

图B是大家熟悉的“标识登录”对话框：

图B

       这个“标识登录”对话框最常见的是在用户试图使用视窗操作系统内置的OutLooK Express电子邮件组件时由视窗操作系统弹出。当用户选择自己的标识并输入正确的密码后即可通过OutLooK Express收发电子邮件。

       同样地，大家可以在互联网上下载一些相关的实用程式来“Crack”上述“TesT” 标识的密码，然后可以假冒合法用户的标识收发邮件，但是通过这些实用程式执行后需要消耗时间才能获得结果。

       同样地，我们发现视窗操作系统内置的密码安全体系存在的相关弱点，导致用户的“标识密码”形同虚设——只需对一个名为“■sidenT”的系统动态链接库文件，仅仅修改其“二个”字节后，视窗操作系统的这个安全环节也告失效。

相关实验：

       在视窗操作系统内找到名为“■sidenT”的系统动态链接库文件，然后在常见的十六进制编辑器里搜索十六进制串{ 8A188AD33A19751A84D274128A5801}后将其间的{ 18 }改为{ 19 }及{ 58 }改为{ 59 }即上述十六进制串被改动二个字节后变为{ 8A198AD33A19751A 84D27412 8A5901 }，即：

       保存这个改动，然后尝试再次登录，就会发现，所有标识，都可以任意的密码甚至仅仅一个回车键的形式轻松登录！而被冒认的“标识”所有者很难察觉！

3、视窗操作系统“连接登录”对话框问题

图C大家熟悉的“连接登录”对话框：

图C

       大家都知道，目前可以方便地通过实用程式，对密码形式的文本框进行“透视”。这里我们不讨论这些内容，我们希望通过对视窗操作系统的密码安全体系里存在的危险弱点进行讨论，让大家在自己的应用系统里避免类似的疏漏，让我们自己的的应用系统更为安全。

       我们发现视窗操作系统内置的密码安全体系存在的相关弱点，导致上述“TesT”用户的密码在内存里竟以明码出现，根本无须“透视”而只要在内存里稍微探查一下即可。

相关实验：

       使用运行在系统级的内存探查程序或调试器，我们可以轻而易举地在系统内存探查到图C的连接登录密码（图C“TesT”用户事先设定的密码是“Chinese!10-01-1949” ）：

视窗操作系统之“连接登录”密码内存探查结果^[2]

在上述探查结果里，我们可以轻易发现“TesT”用户的连接密码为“Chinese!10-01-1949”。

4、视窗操作系统“共享登录”设置对话框问题

图D是大家熟悉的“共享登录”设置对话框：

图 D

       大家知道，上述对话框同样可以方便地通过实用程式，对密码形式的文本框进行“透视”。这里我们不讨论这些内容，我们换一个角度来讨论。

       我们发现视窗操作系统内置的密码安全体系存在的相关弱点，同样导致上述“TesT”用户的“只读”密码以及“完全访问”密码在内存里以明码出现，根本无须“透视”而只要在内存里稍微探查一下即可。

相关实验：

       使用运行在系统级的内存探查程序或调试器，我们可以轻而易举地在系统内存探查到图D的共享登录设置密码（图D“TesT”用户事先设定的“只读”密码以及“完全访问”密码分别是“TesTTesT” 及“!!GoTo!!”——最多八个字符）：

视窗操作系统之“共享登录”设置密码内存探查结果

       在上述探查结果里，我们可以轻易地发现“TesT”用户的“只读”密码为“TesTTesT”同时其 “完全访问”密码为“!!GoTo!!”）。

二、问题的分析及对策

1、关于视窗操作系统“用户登录”对话框问题

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

从上述分析可见，当我们将密码比对的长度由“0x10H” 改为“0”——也就是将上述

仅仅改动“一个”字节，“用户登录”密码的比对结果就将“永远”正确。

       仅仅依赖一条“repz cmpsb”指令对系统级的密码进行决定性研判是相当危险的，而仅仅通过一条件语句来选择视窗操作系统的密码安全类指令的决定性流向，其实是很“传统”的低级做法，保护效果相当脆弱。因为不论操作系统采用的单向HasH结果长度多么“惊人”也不论操作系统在执行“repz cmpsb”这条研判指令之前进行了多少轮大负荷的迭代编码，我们只要在这一条“关键路径”上实施“点穴”——这个层次的安全保护即告失效。

对策：

       视窗操作系统在这里的最大“疏忽”就是对“苦心积虑”最后获得的128位HasH串仅仅参与简单的比对，并没有进行更有效的利用，建议：

       将上述最后运算出来的128位HasH串不论其对错都作为新一轮解码迭代运算的输入算子，对后续的部分关键代码或数据实施解码，这样用户输入正确的密码后自然能正确地继续装载视窗操作系统，否则只能导致错误提示而无法继续正确地装载视窗操作系统。

       事实上这是一个明显的安全漏洞。不要认为存储设备上的系统级文件设置了“只读”、“隐藏”等权限，就可以高枕无忧。事实上，只要系统的存储设备可以被“物理”地读写，那么对其上敏感的系统级文件进行“篡改”就不会是一件“相当”困难的事情。而在大多数情况下，这件事还是比较容易做到的。有关这个安全漏洞的更进一步讨论，我们将在《脆弱的软件著作权保护方式及对策》一文里进行，并相应地给出一个有效的解决方案。

2、关于视窗操作系统“标识登录”对话框问题

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

       从上述分析可见，当我们将密码比对的二个指针EAX、ECX均指向同一个地址——也就是将上述

       仅仅改动“二个”字节，“标识登录”密码的比对结果就将“永远”正确。这同样是一个明显的安全漏洞。这个漏洞源自明文密码比较的指令过于接近，很容易通过对有关的指令代码进行“篡改”达到“冒名”攻击的目的。

对策：

      首先我们要尽可能避免明文密码的比较，并尽可能地将明码密码“暗码”化，即将明文密码通过稳健的摘要密码算法“撕碎”后“淹没”在长度至少在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 }，即：

保存这个改动，然后尝试以超级用户“Administrator”登录，就会发现相关的密码安全弱点。

对策：

       这个例子所揭示的安全弱点的有关对策请参考我们完成的《脆弱的软件著作权保护方式及对策》一文，里头有更为详尽的分析。

       事实证明，对于不借助可热插拔的移动存储介质保存密码（密钥）以及缺乏稳健的密码安全体系的视窗操作系统，目的明确并具备起码专业技能的人员“入侵”视窗操作系统并不是一件困难的事情。（作者单位  Abusys公司）

^[1] 本文仅供参考，如果读者希望重复实验及数据，请一定严格按照本文依照原样提供的所有指令执行，尽管我们知道本文的所有实验例子都可以安全地被重复，但是读者行动之前请记住，我们对因此产生的结果不作任何形式的担保。

^[2]本文所附图之具体地址数值不必拘泥。