Re: DNS Injection Problem

From: Stephen P. Berry (spb_at_meshuggeneh.net)
Date: 05/06/03

  • Next message: Christopher X. Candreva: "Re: [Full-Disclosure] Hotmail & Passport (.NET Accounts) Vulnerability (fwd)"
    To: "Blade Runner" <blade@seven.com.br>
    Date: Tue, 06 May 2003 14:39:54 -0700
    
    
    

    > My client works as an ISP and
    > somebody is injecting parameters in their DNS tables/files. Eventually
    > dial-up costumers are accessing faked home pages ( usually banks ). These
    > attacks were reported to the FPD ( Federal Police Dep ), but they didn't
    > find anything yet.
    > I am looking for a vulnerability in my server but it is a hard thing to do.

    If you have access to traffic logs or raw dumps from the time window in
    which the posited exploit(s) occured, check the traffic for:

            -A large volume of queries for the A record of one of the subsequently-
             spoofed hostnames (occuring all in a lump)
            -A large volume of A records in response (apparently) from the NS
             for the zone of which the spoofed hostname is a member. These responses
             will all have the same destination port.

    If you see something like this, then you're probably looking at someone using
    an DNS spoofing method recently posted to Bugtraq ("An Implementation of
    a Birthday Attack in a DNS Spoofing", Ramon Izaguirre, Bugtraq, 24 April 2003).

    Some suggestions for tracking this back to the source:

            -The distributed exploit script relies on the underlying OS (via
             the perl Net::RawIP module) to set many packet variables. Group
             DNS traffic to the exploited server by TTL. Locate the attack.
             If the blackhat was using the bugtraq posting as a cookbook, there
             should be a query for a record in a zone he controls immediately
             before the attack begins. Mod some funny routing issues, the TTLs
             should be the same.
             Note that most of the queries will be coming from (pseudo)random
             addresses, all spoofed.
            -A number of variables are set to random values in the script using
             perl's rand, unseeded. This should allow an analyst to evaluate
             the behaviour of the OS's facilities for pseudorandom number
             generation, which could provide information about what the underlying
             OS is.
            -Check for a query for the affected zone from an external address
             immediately after the attack. This would be the blackhat checking
             to see if it worked. Since he needs to see the response to know
             if the attack worked, he's got to have access to the source (or
             some point along the route path back to it) of the query. Chances
             are this is the blackhat's machine (or one he's compromised).
            -Use passive fingerprinting on the attack packets. Since the published
             exploit code doesn't attempt to evade fingerprinting, if the underlying
             is susceptible to printing then the attack packets will be identifiable.

    Here's some sample packets to give you an idea what the attack looks like. In this
    case: the hostname to be spoofed is www.fake.com; it will be set to 127.0.0.1;
    the NS for fake.com is 1.1.1.1; and 2.2.2.2 is your DNS server. First, there is
    a slew of spoofed queries for the hostname to be affected:
            
            1052253581.794960 194.222.3.230.25665 > 2.2.2.2.53: 17734+ A?
                    www.fake.com. (30) (DF) [tos 0x10]
            1052253581.795987 90.92.255.41.40836 > 2.2.2.2.53: 50346+ A?
                    www.fake.com. (30) (DF) [tos 0x10]
            1052253581.797033 113.101.139.69.39901 > 2.2.2.2.53: 25566+ A?
                    www.fake.com. (30) (DF) [tos 0x10]
            1052253581.798086 149.62.108.8.41073 > 2.2.2.2.53: 49728+ A?
                    www.fake.com. (30) (DF) [tos 0x10]

    ...where all the source addresses are in fact spoofed. Following a bunch of
    these packets (by default 1140), a bunch of A record responses arrive, apparently
    from the NS for fake.com:

            1052253583.051551 1.1.1.1.53 > 2.2.2.2.12345: 4674- 1/0/0 A
                    127.0.0.1 (46) (DF) [tos 0x10]
            1052253583.052493 1.1.1.1.53 > 2.2.2.2.12345: 11575- 1/0/0 A
                    127.0.0.1 (46) (DF) [tos 0x10]
            1052253583.053501 1.1.1.1.53 > 2.2.2.2.12345: 59146- 1/0/0 A
                    127.0.0.1 (46) (DF) [tos 0x10]
            1052253583.054500 1.1.1.1.53 > 2.2.2.2.12345: 15076- 1/0/0 A
                    127.0.0.1 (46) (DF) [tos 0x10]

    So, in this example, you would look at your data immediately before the first
    query packet (which arrived at 1052253581.794960 in the above example) for
    traffic from port 53 on some host to port 12345 on your DNS server. The
    source of these packets is controled by the blackhat, and it's fairly likely
    that it's the actual source of the subsquent traffic.

    You would also look for a query for www.fake.com after the last of the A record
    responses (apparently) from 1.1.1.1. Chances are this is your blackhat
    checking to see if the exploit worked, and if he's expecting to get a response
    back it has to be a host that he controls (possibly the same as the IP address
    you just found above).

    Hope this helps. If you don't have access to the traffic logs/raw data or
    if you do have access to the data and they don't look like this: nevermind.

    -spb

    
    



  • Next message: Christopher X. Candreva: "Re: [Full-Disclosure] Hotmail & Passport (.NET Accounts) Vulnerability (fwd)"

    Relevant Pages

    • RE: Firewall Rule Set not allowing access to DNS servers?
      ... I changed the DNS rules as you suggested, and the firewall works perfectly - ... > # Allow out access to my ISP's Domain name server. ... > so your udp packets never match this rule and default to ...
      (freebsd-questions)
    • Windows 9X clients can change password in Windows 2003 PDC Emulator
      ... I've desinstalled the WINS Server of the Windows 2000 and now, ... The DNS, WINS and AD replication are OK (Windows 2003 is Primary DNS+WINS ... Gathering NetBT configuration information. ... Packets Received: 36169 ...
      (microsoft.public.windows.server.migration)
    • Re: Slow telnet/pop3 connection
      ... Just the initial presentation of the login prompt. ... If your DNS can not resolve the ... clients in the/etc/hosts file on the server. ... slow boxto REJECT packets to tcp/114. ...
      (comp.os.linux.networking)
    • Re: DNS-Urgent-Help-Please
      ... but the responses are only seen attached to the message (unless ... | i am going to install KTC.COM as the Forest Root Domain, & Install DNS ... Bring New Server. ...
      (microsoft.public.win2000.general)
    • Re: DNS Help- Urgent
      ... but the responses are only seen attached to the message (unless ... | i am going to install KTC.COM as the Forest Root Domain, & Install DNS ... Bring New Server. ...
      (microsoft.public.win2000.cmdprompt.admin)