Re: DNS Injection Problem

["Stephen P. Berry" <spb () meshuggeneh net>]

> 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

Attachment: _bin
Description: