1.  前言  3
2.  報(bào)警信息  3
3.  NFR的檢測(cè)  4
4.  協(xié)議分析  8
5.  漏洞說(shuō)明  15
6.  漏洞分析  18
7.  小結(jié)  20


1.  前言
NFR（Network Flight Recorder）是一個(gè)老牌的商業(yè)網(wǎng)絡(luò)IDS產(chǎn)品，最初由Firewall的牛人Marcus J. Ranum創(chuàng)建，是作為一個(gè)通用的網(wǎng)絡(luò)流量分析和記錄軟件來(lái)實(shí)現(xiàn)的，為了最大限度地發(fā)揮分析工具的靈活性，NFR提供了完善強(qiáng)大的N-Code腳本語(yǔ)言，在很多的評(píng)測(cè)中表現(xiàn)出色。雖然L0pht為NFR提供過(guò)數(shù)百個(gè)簽名庫(kù)，但是缺乏一個(gè)可靠的簽名集一直是他的軟肋。

使用NFR有一段時(shí)間后，發(fā)現(xiàn)NFR存在著不少問(wèn)題。且不說(shuō)AI對(duì)中文的兼容性差而經(jīng)常退出，也不說(shuō)NFR版本升級(jí)而攻擊事件說(shuō)明卻一直用舊版本的說(shuō)明，單是IDS中最關(guān)鍵的攻擊簽名庫(kù)，卻讓我大跌眼鏡。除了升級(jí)緩慢以外，甚至還存在不少錯(cuò)誤的簽名。本系列文章針對(duì)其中我發(fā)現(xiàn)的部分問(wèn)題進(jìn)行分析和闡述，以便各位更好地利用NFR產(chǎn)品，同時(shí)也想和各位同仁討論IDS中攻擊簽名庫(kù)的編寫(xiě)。由于知識(shí)和時(shí)間的限制，錯(cuò)誤之處在所難免，還希望得到各位的指教，任何意見(jiàn)或建議請(qǐng)發(fā)至:benjurry@xfocus.org

SQL Server是微軟為對(duì)抗Oracle推出的數(shù)據(jù)庫(kù), 占領(lǐng)的市場(chǎng)份額已經(jīng)僅次于Oracle，居世界第二，但是其安全性也一直受到用戶(hù)的置疑。從1996年，Microsoft公司推出的SQL Server 6.5版本到1998年推出的SQL Server 7.0，以及到2000年8月推出了SQL Server 2000，在版本和功能不斷升級(jí)的情況下，安全問(wèn)題卻沒(méi)有得到很好地改善，不斷發(fā)布針對(duì)SQL Server的安全公告和補(bǔ)丁。在2003年1月24日，針對(duì)SQL Server的“Slammer”蠕蟲(chóng)在Internet上肆虐，導(dǎo)致網(wǎng)絡(luò)流量激增，嚴(yán)重影響了世界范圍內(nèi)的計(jì)算機(jī)和網(wǎng)絡(luò)系統(tǒng)。SQL Server的漏洞引起了各大安全公司和廠商的重視，因此NFR也立即發(fā)布了多個(gè)針對(duì)SQL Server的攻擊簽名，其中包括了2002年8月7日Immunity公司Dave Aitel發(fā)現(xiàn)的Hello Buffer Overflow漏洞。但是在使用過(guò)程中，我發(fā)現(xiàn)NFR針對(duì)該漏洞的報(bào)警非常多，于是我對(duì)此進(jìn)行了分析，于是寫(xiě)成了這個(gè)文章，以做記錄。


2.  報(bào)警信息
下面是NFR針對(duì)MS SQL Hello Buffer Overflow的報(bào)警信息：

Severity:      Attack
Time:        13:54:21 15-Jul-2003
Source File:    packages/mssql/sql2k.nfr
Line:        226
Host:        benjurry-xfocus
Alert ID:      mssql_sql2k:buffered_hello
Source ID:     mssql_sql2k:source_me
Source:       mssql_sql2k:source_me
Source Description: Sqlserver 2k overflow detector
Source PID:     36531
Alert Message:   Saw 8 Mssql HELLO overflows from 192.168
          0.110 in 900 seconds
:          3
Source IP:     192.168.0.110
Destination IP:       --

其中包括了事件的嚴(yán)重等級(jí)、時(shí)間、NFR Sensor名字、攻擊源IP、目的IP和一些其他報(bào)警信息。
在實(shí)際的使用中，一天產(chǎn)生了幾百條這種報(bào)警，看來(lái)這是個(gè)誤報(bào)，我們可以好好的分析一下了。


3.  NFR的檢測(cè)
我們首先打開(kāi)NFR發(fā)布的簽名庫(kù) MSSQL.fp(或者也可以在AI的package中查看) 看一下NFR的針對(duì)這個(gè)漏洞的攻擊簽名：

<snip>
…..

變量定義等…

…
<snip>
sqlserv_schema = library_schema:new(1, ["time","ip","int","ip","int", "str"],
  scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema");

HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
MIN_LEN = strlen(HELLO_SIG);


…….
<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)) {
    if (COUNTHELLO[tcp.connsrc]) {
      COUNTHELLO[tcp.connsrc] = COUNTHELLO[tcp.connsrc] + 1;
    } else {
      COUNTHELLO[tcp.connsrc] = 1;
    }
    if (do_alert(hello_overflow_alert, tcp.connsrc)) {
      alert(source_me, hello_overflow_alert, tcp.connsrc,
        tcp.connsport, tcp.conndst, tcp.conndport,
        "--AlertDetails",
        "ALERT_ID", "40-8",
        "ALERT_CONFIDENCE", 60,
        "ALERT_SEVERITY", "medium",
        "ALERT_IMPACT", "unknown",
        "ALERT_EVENT_TYPE", "attack",
        "ALERT_ASSESSMENT", "unknown",
        "IP_ADDR_SRC", tcp.connsrc,
        "PORT_SRC", tcp.connsport,
        "IP_ADDR_DST", tcp.conndst,
        "PORT_DST", tcp.conndport,
        "IP_PROTO_NUM", 6);
    }
    record packet.sec, tcp.conndst, tcp.conndport, tcp.connsrc,
      tcp.connsport, $Blob to sqlserv_rec;
    misc_attacks:rec(packet.sec, scope(),
            "Mssql HELLO overflow!", tcp.connsrc, tcp.conndst);
  }
}

從上面的N-CODE中我們可以看到,NFR在做這個(gè)檢測(cè)的時(shí)候步驟如下:

1、定義了一個(gè)攻擊特征碼:
HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
和攻擊特征碼的長(zhǎng)度:
MIN_LEN = strlen(HELLO_SIG);

2、從TCP的載荷數(shù)據(jù)中取出數(shù)據(jù),把這個(gè)數(shù)據(jù)的長(zhǎng)度和特征碼長(zhǎng)度比較，如果這個(gè)數(shù)據(jù)長(zhǎng)度小于攻擊特征碼的長(zhǎng)度，那么就不再進(jìn)行下一步的檢測(cè)；

3、否則，把這個(gè)數(shù)據(jù)和特征碼進(jìn)行字符串匹配，如果一致則認(rèn)為是攻擊行為，然后進(jìn)行阻止或者報(bào)警。
接下來(lái)我們分析一下NFR IDS Record的數(shù)據(jù)，在AI中選擇package->Query->MSSQL->MSSQL Server 200,定好條件，按Table查到數(shù)據(jù)，隨便選取一條，copy出來(lái)得到如下內(nèi)容：

Time:        15-Jul-2003 13:54:21
NFR:        benjurry-xfocus
Destination Address:192.168.0.135
Destination Port:  1433
Source Address:   192.168.0.110
Source Port:    1391
Payload:      
          \x12\x01\x004\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b\x00
          \x01\x02\x00\x1c\x00\x0c\x03\x00(\x00\x04\xff\x08\x00\x00\xc2\x00
          \x00\x00MSSQLServer\x00x\x03\x00\x00

上面這條記錄包含了攻擊的時(shí)間,報(bào)告攻擊行為的NIDS sessor名字,目的IP、目的端口、源ip和源端口，而我們關(guān)心的是有效載荷Payload，因?yàn)樗�是NIDS用來(lái)和攻擊簽名庫(kù)比較的數(shù)據(jù)。但是NFR在這里有幾個(gè)小問(wèn)題：

1.  會(huì)把payload中的能轉(zhuǎn)換成ASCII字符的16進(jìn)制數(shù)轉(zhuǎn)換成ASCII碼；

2.  不能處理Unicode的字符，這個(gè)將在以后的分析中可以看到。

在這個(gè)例子中為了分析方便，我們把上面的payload中的字符特征碼部分轉(zhuǎn)換成16進(jìn)制數(shù)：
\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00MSSQLServer\x00x\x03\x00\x00


NFR抓到數(shù)據(jù)組包后，發(fā)現(xiàn)是SQL Server包，便把里面的內(nèi)容和SQL Server的攻擊庫(kù)進(jìn)行比較，很明顯，上面所列的數(shù)據(jù)和攻擊庫(kù)是相符合的，因此一個(gè)報(bào)警便產(chǎn)生了，但是這真是一個(gè)攻擊行為嗎？我們繼續(xù)看下面的分析。


4.  協(xié)議分析

根據(jù)Xfocus的協(xié)議分析項(xiàng)目（將會(huì)在近期公布項(xiàng)目成果），MS SQL 2000用的是TDS8.0，它的格式如下：
-------------------------------------------------
TDS包頭（8字節(jié)）    TDS負(fù)載數(shù)據(jù)       
-------------------------------------------------
其中MS SQL SERVER 2000 TDS的包頭結(jié)構(gòu)如下：
-------------------------------------------------------------------
TOKEN STATUS LENGTH SIGNED NUM PACKET NUM WINDOW SIZE
-------------------------------------------------------------------
其中TOKEN字段域1個(gè)字節(jié)，用來(lái)表示TDS操作請(qǐng)求種類(lèi)。在這個(gè)漏洞中是0x12，也就是NFR記錄中的有效負(fù)載中的第一個(gè)字節(jié)0x12, 0x12是預(yù)登錄驗(yàn)證命令請(qǐng)求。其目的是獲得當(dāng)前MS SQL SERVER2000的一些設(shè)置值，比如SQL SERVER版本，是否支持加密等信息，作為客戶(hù)端在構(gòu)造TDS包的一個(gè)依據(jù)。SQL Server在接受到該類(lèi)型的包的時(shí)候，將會(huì)由SSlibnet.dll中的相應(yīng)函數(shù)做處理，在我的系統(tǒng)SQL Server 2000（沒(méi)有SP）的情況下，相應(yīng)函數(shù)如下：


.text:42CF6DDD ; Attributes: bp-based frame
.text:42CF6DDD
.text:42CF6DDD         public ConnectionPreLogin
.text:42CF6DDD ConnectionPreLogin proc near
.text:42CF6DDD
.text:42CF6DDD var_4      = dword ptr -4
.text:42CF6DDD arg_0      = dword ptr 8
.text:42CF6DDD arg_4      = dword ptr 0Ch
.text:42CF6DDD arg_8      = dword ptr 10h
.text:42CF6DDD arg_C      = dword ptr 14h
.text:42CF6DDD arg_10     = dword ptr 18h
.text:42CF6DDD
.text:42CF6DDD         push  ebp
.text:42CF6DDE         mov   ebp, esp
.text:42CF6DE0         push  ecx
.text:42CF6DE1         mov   eax, [ebp+arg_0]
.text:42CF6DE4         mov   ecx, [eax+94h]
.text:42CF6DEA         mov   [ebp+var_4], ecx
.text:42CF6DED         cmp   [ebp+var_4], 1
.text:42CF6DF1         jz   short loc_42CF6E01
.text:42CF6DF3         cmp   [ebp+var_4], 1
.text:42CF6DF7         jle   short loc_42CF6E3D
.text:42CF6DF9         cmp   [ebp+var_4], 3
……


STATUS字段域1個(gè)字節(jié)，當(dāng)它為0x01的時(shí)候表示此包為當(dāng)前TDS會(huì)話中的最后一個(gè)TDS包。
LENGTH字段域2個(gè)字節(jié)，表示TDS包的總長(zhǎng)度，包括TDS包頭的長(zhǎng)度。
SIGNED NUM字段域2個(gè)字節(jié)，目前保留未用。
PACKET NUM字段域1個(gè)字節(jié)，表示此TDS包在當(dāng)前TDS操作請(qǐng)求中的序號(hào)
WINDOW SIZE字段域1個(gè)字節(jié)，目前保留未用。
MS SQL SERVER 0X12 TDS的包主要包格式如下：
------------------------------------------------------
TDS包頭（8字節(jié)） 字段指示頭     信息     
------------------------------------------------------
其中字段指示頭是一個(gè)可以變長(zhǎng)的表，表的每一項(xiàng)代表了在一個(gè)字段在信息中的偏移地址和長(zhǎng)度信息，在SQL2000中主要是4個(gè)字段，其對(duì)應(yīng)的字段指示頭的結(jié)構(gòu)如下：
{
  BYTE CNETLIBVERNO；
  WORD CNETLIBVEROFFSET；
  WORD CNETLIBVERLEN；
  BYTE CENYFLAGNO；
  WORD CENYFLAGOFFSET；
  WORD CENYFLAGLEN；
  BYTE SINSTNAMENO；
  WORD SINSTNAMEOFFSET；
  WORD SINSTNAMELEN；
  BYTE CTHREADIDNO；
  WORD CTHREADIDOFFSET；
  WORD CTHREADIDLEN；
  BYTE FILEDEND；
}
信息內(nèi)容的結(jié)構(gòu)如下：
{
  BYTE CNETLIBVER[CNETLIBVERLEN]
  BYTE CENYFLAG[CENYFLAGLEN]；
  BYTE SINSTNAME[SINSTNAMELEN]
  DWORD CTHREADID[CTHREADIDLEN]；
}
其中：
CNETLIBVERNO字段域
偏移：0
長(zhǎng)度：1
含義：客戶(hù)端使用的網(wǎng)絡(luò)連接庫(kù)（NETLIB）的版本號(hào)信息的字段編號(hào)。
說(shuō)明：
備注：該值固定為0

CNETLIBVEROFFSET字段域
偏移：1
長(zhǎng)度：2
含義：客戶(hù)端使用的網(wǎng)絡(luò)連接庫(kù)（NETLIB）的版本號(hào)信息的字段偏移。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：

CNETLIBVERLEN字段域
偏移：3
長(zhǎng)度：2
含義：客戶(hù)端使用的網(wǎng)絡(luò)連接庫(kù)（NETLIB）的版本號(hào)信息的字段長(zhǎng)度。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：該值固定為6

CENYFLAGNO字段域
偏移：5
長(zhǎng)度：1
含義：客戶(hù)端使用強(qiáng)制加密標(biāo)記字段的字段號(hào)。
說(shuō)明：
備注：該值固定為1

CENYFLAGOFFSET字段域
偏移：6
長(zhǎng)度：2
含義：客戶(hù)端使用強(qiáng)制加密標(biāo)記字段的偏移。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：

CENYFLAGLEN字段域
偏移：8
長(zhǎng)度：2
含義：客戶(hù)端使用強(qiáng)制加密標(biāo)記字段的長(zhǎng)度。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：該值固定為1

SINSTNAMENO字段域
偏移：0XA
長(zhǎng)度：1
含義：客戶(hù)端要求使用服務(wù)器的實(shí)例名字段的字段號(hào)。
說(shuō)明：
備注：該值固定為2

SINSTNAMEOFFSET字段域
偏移：0XB
長(zhǎng)度：2
含義：客戶(hù)端要求使用服務(wù)器的實(shí)例名字段的偏移。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：

SINSTNAMELEN字段域
偏移：0XD
長(zhǎng)度：2
含義：客戶(hù)端要求使用服務(wù)器的實(shí)例名字段的長(zhǎng)度。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：

CTHREADIDNO字段域
偏移：0XF
長(zhǎng)度：1
含義：客戶(hù)端進(jìn)程的線程ID字段的字段號(hào)。
說(shuō)明：
備注：該值固定為3

CTHREADIDOFFSET字段域
偏移：0X10
長(zhǎng)度：2
含義：客戶(hù)端進(jìn)程的線程ID字段的的偏移。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：

CTHREADIDLEN字段域
偏移：0X12
長(zhǎng)度：2
含義：客戶(hù)端進(jìn)程的線程ID字段的長(zhǎng)度。
說(shuō)明：字段格式是網(wǎng)絡(luò)字節(jié)順序
備注：該值固定為4

FILEDEND字段域
偏移：0X14
長(zhǎng)度：1
含義：此字段標(biāo)記字段指示頭已經(jīng)結(jié)實(shí)，下面的就是字段的信息。
說(shuō)明：結(jié)束標(biāo)記是0XFF
備注：

CNETLIBVER字段域
偏移：0X15
長(zhǎng)度：6
含義：客戶(hù)端使用的網(wǎng)絡(luò)連接庫(kù)（NETLIB）的版本號(hào)。
說(shuō)明：其版本號(hào)取的是DBNETLIB.DLL的版本
備注：其格式是網(wǎng)絡(luò)字節(jié)格式，如版本號(hào)為80.528.00，則為
  08 00 02 10 00 00

CENYFLAG字段域
偏移：0X1B
長(zhǎng)度：1
含義：客戶(hù)端強(qiáng)制加密標(biāo)志。
說(shuō)明：0代表客戶(hù)端不強(qiáng)制加密，1代表客戶(hù)端使用強(qiáng)制加密
備注：

SINSTNAME字段域
偏移：0X1C
長(zhǎng)度：SINSTNAMELEN
含義：客戶(hù)端要求使用的實(shí)例名。
說(shuō)明：?jiǎn)巫止?jié)格式
備注：默認(rèn)實(shí)例使用MSSQLserver這個(gè)名字

CTHREADID字段域
偏移：0X1C+SINSTNAMELEN
長(zhǎng)度：4
含義：客戶(hù)端進(jìn)程的線程ID。
說(shuō)明：字段格式是主機(jī)字節(jié)順序
備注：

由上面的格式可以看出，一個(gè)用默認(rèn)實(shí)例名MSSQLserver連接的SQL TDS包格式將是如下的格式：
\x12\x01\x00\x34\x00\x00\x00\x00
\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03
\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00MSSQ
LServer\x00
\x78\x03\x00\x00

而NFR的攻擊簽名庫(kù)卻是
HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
明顯是正常TDS 0x12預(yù)登陸包的一部分，這就難怪會(huì)有這么多報(bào)警了，那NFR的這個(gè)攻擊簽名是如何得到的呢？
我們還是從它的漏洞說(shuō)明入手吧！


5.  漏洞說(shuō)明
下面是NFR N-CODE中對(duì)這個(gè)漏洞的說(shuō)明：
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
我們可以看到這個(gè)漏洞來(lái)自于http://www.immunitysec.com/ 的Dave Aitel，而從http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html所列的MS SQL Server Hello Overflow NASL script中我們可以看到這個(gè)漏洞的關(guān)鍵就在于以下幾個(gè)語(yǔ)句：

<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是根據(jù)TDS協(xié)議構(gòu)造的包，中間加了560個(gè)字符X，pkt_tail是構(gòu)造的TDS包尾。

從這里我們可以看到，可憐的NFR居然不負(fù)責(zé)任地把MS SQL Server Hello Overflow NASL script中的pkt_hdr取出11個(gè)字符，毅然決然地把它們作為其簽名。更為可笑的是居然還寫(xiě)著“False positives are unlikely due to the nature of the attack ”。
這就是在許多評(píng)測(cè)中遙遙領(lǐng)先的NFR？后來(lái)和stardust聊起這個(gè)事情的時(shí)候，認(rèn)為這個(gè)現(xiàn)象和很多評(píng)測(cè)機(jī)構(gòu)在評(píng)測(cè)IDS產(chǎn)品的時(shí)候，重視對(duì)產(chǎn)品漏報(bào)的檢測(cè)而忽視對(duì)誤報(bào)的評(píng)測(cè)有關(guān)。因?yàn)樵谠u(píng)測(cè)產(chǎn)品時(shí)，基本上都是大部分都是黑箱評(píng)測(cè)，要檢測(cè)漏報(bào)只要收集幾個(gè)Exploits就可以進(jìn)行，但要檢測(cè)漏報(bào)卻要產(chǎn)生正常的包，有些系統(tǒng)比如這里的Sql Server，如果不了解它的協(xié)議包格式，是很難產(chǎn)生的。因此一些IDS產(chǎn)生便鉆了這樣的空子，只要收集一些Exploits，把其中的攻擊代碼作為攻擊簽名直接發(fā)布，而不去分析漏洞產(chǎn)生的真正原因。

下面我們來(lái)分析一下這個(gè)漏洞產(chǎn)生的原因，然后我們就可以根據(jù)這個(gè)分析，寫(xiě)出比較完善的攻擊簽名。


6.  漏洞分析
用IDA對(duì)SSlibnet.dll反匯編，我們可以看到：


.text:42CF6F49 loc_42CF6F49:     ; CODE XREF: sub_42CF6E4F+EA j
.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


這個(gè)漏洞的原因就在這里，當(dāng)程序用strcpy拷貝的時(shí)候，如果源字符串超出0x214（也就是532）后，目標(biāo)地址后的環(huán)境變量就會(huì)被覆蓋導(dǎo)致溢出。由于這個(gè)漏洞很早，經(jīng)歷了“Slammer”蠕蟲(chóng)后，基本上所有的系統(tǒng)都補(bǔ)掉了這個(gè)漏洞，因此這里就不在提供攻擊代碼了，有興趣的朋友可以自己分析和編寫(xiě)一下。


另外需要在這里說(shuō)明的是，如果分析了TDS協(xié)議和這個(gè)漏洞的成因，完善的攻擊程序中的TDS包的長(zhǎng)度是根據(jù)計(jì)算生成的，明顯不會(huì)是”\x00\x34”,以避過(guò)SQL Server中針對(duì)TDS包長(zhǎng)度的校驗(yàn)（當(dāng)然在這個(gè)版本的SQL Server中還不包含這個(gè)校驗(yàn)），或者攻擊程序把這攻擊代碼分成多個(gè)包，因此TDS格式中的status就不會(huì)是0x01,因此NFR是檢測(cè)不出完善的攻擊程序的的，也就是說(shuō)針對(duì)這個(gè)漏洞，NFR 同時(shí)存在誤報(bào)和漏洞的情況。

在分析了這個(gè)漏洞的成因后，我們就可以針對(duì)這個(gè)問(wèn)題寫(xiě)出自己的NFR檢測(cè)代碼：


sqlserv_schema = library_schema:new(1, ["time","ip","int","ip","int", "str"],
  scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema");

HELLO_SIG = "\x12 ";
#考慮了分包和長(zhǎng)度不固定的因素，去除了后面不可靠的特征串
MIN_LEN =29;
#包括TDS包頭和字段指示頭的總長(zhǎng)度

…….
<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) {
    #考慮到實(shí)例名不可能超過(guò)255，因此這里長(zhǎng)度選擇了40（包頭）+255=295
#也可以增加一個(gè)Value，以便用戶(hù)自己根據(jù)事件情況進(jìn)行調(diào)節(jié)
#報(bào)警
….

}


7.  小結(jié)
通過(guò)對(duì)NFR這個(gè)攻擊簽名的分析可以看出，發(fā)布完善的IDS攻擊簽名不是一個(gè)簡(jiǎn)單的事情，它需要了解應(yīng)用的協(xié)議格式和漏洞的成因。而不是簡(jiǎn)單地收集網(wǎng)絡(luò)上存在地exploits，然后截取其中的特征碼。
目前很多人包括IDS開(kāi)發(fā)人月都在討論IDS有沒(méi)有前途，需不需要。我想與其在那里討論，不如靜下來(lái)好好分析漏洞，完善攻擊簽名，使IDS做的更準(zhǔn)確。
與其坐而論不如起而行！�。ǔ鎏帲簑ww.xfocus.net）