\x78\x03\x00\x00 而NFR的攻击签名库却是 HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15"; 明显是正常TDS 0x12预登陆包的一部分,这就难怪会有这么多报警了,那NFR的这个攻击签名是如何得到的呢? 我们还是从它的漏洞说明入手吧! 5. 漏洞说明 下面是NFR N-CODE中对这个漏洞的说明: FALSE POSITIVES False positives are unlikely due to the nature of the attack REFERENCES Bugtraq Post http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html Exploit http://www.scan-associates.net/papers/sql2kx2.txt 我们可以看到这个漏洞来自于http://www.immunitysec.com/ 的Dave Aitel,而从http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html所列的MS SQL Server Hello Overflow NASL script中我们可以看到这个漏洞的关键就在于以下几个语句: <snip> pkt_hdr = raw_string( 0x12 ,0x01 ,0x00 ,0x34 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x15 ,0x00 ,0x06 ,0x01 ,0x00 ,0x1b, 0x00 ,0x01 ,0x02 ,0x00 ,0x1c ,0x00 ,0x0c ,0x03 ,0x00 ,0x28 ,0x00 ,0x04 ,0xff ,0x08 ,0x00 ,0x02, 0x10 ,0x00 ,0x00 ,0x00 ); pkt_tail = raw_string ( 0x00 ,0x24 ,0x01 ,0x00 ,0x00 ); <snip> ….. if(get_port_state(port)) { soc = open_sock_tcp(port); if(soc) { attack_string=crap(560); sql_packet = pkt_hdr+attack_string+pkt_tail; send(socket:soc, data:sql_packet); r = recv(socket:soc, length:4096); close(soc); display ("Result:",r,"\n"); if(!r) { display("Security Hole in MSSQL\n"); security_hole(port:port, data:report); } } 其中pkt_hdr是根据TDS协议构造的包,中间加了560个字符X,pkt_tail是构造的TDS包尾。 从这里我们可以看到,可怜的NFR居然不负责任地把MS SQL Server Hello Overflow NASL script中的pkt_hdr取出11个字符,毅然决然地把它们作为其签名。更为可笑的是居然还写着“False positives are unlikely due to the nature of the attack ”。 这就是在许多评测中遥遥领先的NFR?后来和stardust聊起这个事情的时候,认为这个现象和很多评测机构在评测IDS产品的时候,重视对产品漏报的检测而忽视对误报的评测有关。因为在评测产品时,基本上都是大部分都是黑箱评测,要检测漏报只要收集几个Exploits就可以进行,但要检测漏报却要产生正常的包,有些系统比如这里的Sql Server,如果不了解它的协议包格式,是很难产生的。因此一些IDS产生便钻了这样的空子,只要收集一些Exploits,把其中的攻击代码作为攻击签名直接发布,而不去分析漏洞产生的真正原因。 下面我们来分析一下这个漏洞产生的原因,然后我们就可以根据这个分析,写出比较完善的攻击签名。 6. 漏洞分析 用IDA对SSlibnet.dll反汇编,我们可以看到: .text:42CF6F49 loc_42CF6F49: ; CODE XREF: sub_42CF6E4F+EA j
复制本页网址和标题,发送给你QQ/Msn的好友一起分享
上一篇:论坛签名最流行的三种样式
下一篇:Windows在设计上存在致命缺陷