> 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
This archive was generated by hypermail 2b30 : Wed May 07 2003 - 22:34:47 PDT