.text:42CF6F49 mov eax, [ebp+0xc]
.text:42CF6F4C add eax, [ebp-0x218]
.text:42CF6F52 push eax
.text:42CF6F53 lea ecx, [ebp-0x214]
.text:42CF6F59 push ecx
.text:42CF6F5A call strcpy
.text:42CF6F5F add esp, 8
.text:42CF6F62 push offset unk_42D01104
.text:42CF6F67 lea edx, [ebp-0x214]
.text:42CF6F6D push edx
.text:42CF6F6E call strcmp
.text:42CF6F73 add esp, 8
这个漏洞的原因就在这里，当程序用strcpy拷贝的时候，如果源字符串超出0x214（也就是532）后，目标地址后的环境变量就会被覆盖导致溢出。由于这个漏洞很早，经历了“Slammer”蠕虫后，基本上所有的系统都补掉了这个漏洞，因此这里就不在提供攻击代码了，有兴趣的朋友可以自己分析和编写一下。
另外需要在这里说明的是，如果分析了TDS协议和这个漏洞的成因，完善的攻击程序中的TDS包的长度是根据计算生成的，明显不会是”\x00\x34”,以避过SQL Server中针对TDS包长度的校验（当然在这个版本的SQL Server中还不包含这个校验），或者攻击程序把这攻击代码分成多个包，因此TDS格式中的status就不会是0x01,因此NFR是检测不出完善的攻击程序的的，也就是说针对这个漏洞，NFR 同时存在误报和漏洞的情况。
在分析了这个漏洞的成因后，我们就可以针对这个问题写出自己的NFR检测代码：
sqlserv_schema = library_schema:new(1, ["time","ip","int","ip","int", "str"],
scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema");
HELLO_SIG = "\x12 ";
#考虑了分包和长度不固定的因素，去除了后面不可靠的特征串
MIN_LEN =29;
#包括TDS包头和字段指示头的总长度
…….
<snip>
filter hello tcp (client, dport: 1433) {
declare $Blob inside tcp.connsym;
if ($Blob == NULL) {
$Blob = tcp.blob;
} else {
$Blob = cat($Blob, tcp.blob);
}
if (strlen($Blob) < MIN_LEN)
return;
if (prefix($Blob, HELLO_SIG) && strlen($Blob) > 295) {
#考虑到实例名不可能超过255，因此这里长度选择了40（包头）+255=295
#也可以增加一个Value，以便用户自己根据事件情况进行调节
#报警
….
}
7. 小结
通过对NFR这个攻击签名的分析可以看出，发布完善的IDS攻击签名不是一个简单的事情，它需要了解应用的协议格式和漏洞的成因。而不是简单地收集网络上存在地exploits，然后截取其中的特征码。
上一篇:论坛签名最流行的三种样式
下一篇:Windows在设计上存在致命缺陷
|
精品推荐