请测试 瑞星的主防 是否存在下述bug
众所周知，WINDOWS 2000/XP/2003 SP0系统上，提供了一个\Device\PhysicalMemory的Section对象，可以直接操作物理内存对象。直接操作此对象映射的物理内存，可以操作RING0内存，达到无驱进入RING0的目的。这已是很多年前就被用烂了的技术了，大部分驱动防火墙、绝大部分HIPS软件、AntiVirus软件等都对此进行了防御。不过，老树也能开新花，我们来看看这个东东的新利用方法:1).CreateSymbolicLink,这也是很古老的方法，很多安全软件也已经防御。因为一些安全软件只防御了NtOpenSection,并根据打开的对象名是否是\Device\PhysicalMemory来进行拦截，但是只要对\Device\PhysicalMemory创建符号链接，那么一样可以使用NtOpenSection打开2).Duplicate法，大部分目前的安全软件，都是拦截\Device\PhysicalMemory并判断DesiredAccess是否包含SECTION_MAP_WRITE（除了一些极端无聊的没人用的HIPS外，这种的完全可以无视）,因为一些正常的软件，也需要打开\Device\PhysicalMemory进行物理内存读入（例如微软Wga~)。但这就让攻击者有空可钻，攻击者可以先以SECTION_MAP_READ打开物理内存对象，再以SECTION_MAP_WRITE方式duplicatehandle，这样就可以获取对物理内存的写权限，进行物理内存写入了。大部分安全软件都没有防御这种方式（例如瑞*),这样，攻击者又重新获得了对于系统至高无上的权利~
2、[0Day]Windows 2000/XP（全补丁）内核任意地址写入漏洞，绕过HIPS、驱动防护类软件、内核加固软件等。
Windows 2000开始，win32k.sys体内的两个函数存在着内核任意地址写入漏洞，可以允许用户态程序直接读写内核内存，直到WIN2003才修补，同时存在另外几个函数，可以引发内核崩溃、内核内存泄露或内核地址写入。由于这一手段从未公开，攻击者可以利用它编写ShellCode,进入Ring0，或者恢复内核钩子，用来绕过HIPS、驱动防护类软件、内核加固软件等。下面公布利用其中一对函数实现的内核任意地址写入DEMO，这个DEMO运行后，点击确定，会对内核地址0x804d8002(XP下通常是ntoskrnl的DOS头偏移+2）写入一个数值：0X12345678DEMO由于做了一些硬编码，只在WINDOWS XP下生效可以使用RootkitUnhooker的内核内存DUMP，或者Icesword的内存编辑，或者windbg本机或双机调试来查看修改的情况具体代码为了安全起见，就不公开放出了，如果大家有兴趣，以后可以考虑放出注意：DEMO执行过程中，你的HIPS软件可能会对其的某些前期操作报警，选择允许即可DEMO下载地址：http://mj0011.ys168.com漏洞演示目录下CsrssVuln.rar
3、这方面的攻击方法绕过COMODO的很多，功能上说，比较丰富，但是从防护强度上说，可能尚不如瑞星或xxx大部分函数判断都是直接丢进程（或目标进程）到RING3去走黑白名单或规则，这种做法有好处就是比较可靠，反正参数也不判断，直接告诉用户谁谁谁在XXX谁谁谁。但都丢给用户了，没什么意思。用户全选拒绝，于是很安全，但是大部分程序都挂了，用户全允许，就没安全了，而且貌似默认模式下很多钩子都没效果了~剩下那些做了一些判断处理的函数里（因为要是这些不处理，弹框就弹死人了）也有一些问题：驱动拦截时路径名分析有一些问题，可以绕过消息拦截时对其他进程采用部分拦截，不是很全面，但是对自己进程的拦截采用部分放行，比较可靠。但是窗口的保护拦截不是很全面。虽然对进程本身没有影响。SetHook中有我之前说的那个漏洞的问题LPC拦截很遗憾地没有做svc的绕过的漏洞应该不少，从功能上说，比较丰富，但是从防护强度上说，可能尚不如瑞星或xxx。由于过分依赖XXXX，所以面对MAX法很脆弱，这方面的攻击方法绕过COMODO的很多自我保护不够完善，例如RING3下用MAX法绕过拦截，再用TerminateJob即可结束。其中也有一些有意思的小技巧，例如hdc to hwnd，IoSetTopLevelIrp , CallHwndParamLock拦EnableWindow等http://hi.baidu.com/mj0011/blog/item/afa02ac7e124a5d5d10060f6.html#comment4、xxx雷人的系统文件防修改，xxx的驱动，真是看哪个函数，哪个函数就有漏洞啊~2009-02-05 20:24 看到xxx可以拦截RING3 常规的disk level文件删除和修改，并报警为 试图篡改系统文件，还以为有什么高招，例如FS解析等分析了一下，原来是Hook了NtWriteFile,然后判断如果FileObject的FileName为空，然后驱动对象是disk或ftdisk（这个判断做得很啰嗦很山寨），就认为是篡改系统文件，这么不负责的判断，太雷人了~随便什么程序写写磁盘就是试图篡改系统文件的未知木马~ 这么乱判，还做什么主动防御~另外RING3程序还会获得一下Explorer.exe和Userinit.exe的磁盘簇位置，发现如果是在写这两个文件的簇就认为是机器狗，做一些特殊处理这里也做得很雷人，xxx认为Explorer.exe和Userinit.exe的磁盘簇分布一定是连续的，所以就设定了一个范围。。。另外NtWriteFile的HOOK判断中还有一处也相当雷人的本地拒绝访问漏洞，稍候放出，话说xxx的驱动，真是看哪个函数，哪个函数就有漏洞啊~其实绕过这个也很简单，不过要注意xxx在atapi的internal dispatch上还有一处很挫的钩子请测试 瑞星是否存在此类问题啊
http://bbs.kafan.cn/thread-584158-1-1.html用户系统信息：Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.92 Safari/537.1 LBBROWSER
shulun743 最后编辑于 2013-08-28 07:24:33
