Full Disclosure mailing list archives

Re: FW: Question for DNS pros


From: Paul Schmehl <pauls () utdallas edu>
Date: Tue, 03 Aug 2004 10:21:42 -0500

--On Tuesday, August 03, 2004 09:48:59 AM -0500 Frank Knobbe <frank () knobbe us> wrote:

I'm seeing the same thing now. It caught my eye because of another
oddity that occurs from those IP's and I wanted to check with you if you
see that as well. These addresses (about a dozen IP's from China in my
case) also send a TCP SYN packet with 24 '0x00' bytes payload to port
53. Seq # and Ack # are set, windows size is 2048 (although I haven't
confirmed that with all past scans).

Below is a tcpdump. See if that looks familiar :)

Very familiar.

So it doesn't appear to be targeted just at UT Dallas. I start to wonder
if other sites get hit too, but if that flies under the radar.

I have no doubt that would be true. This now appears to be very deliberate and well planned.

Also, there is no name server at that address, never has been. The IP
being targeted is the global NAT IP of a firewall. All outbound
connections come from that IP. No other IP (in a two class C range) is
being hit.

That's interesting. The address being targeted here was *also* a firewall PAT address. I'm starting to wonder if this is some sort of a recon tool to get past firewalls. That would explain why they're using port 53 (normally open) and udp (stateless). If they get any kind of response at all, they've identified a live host.

This has started on a regular basis last week and seems steady:

Ours has stopped.

There are about 18 sources involved, but the majority of the packets are
coming from 218.75.110.194 (601),

Ditto

61.135.158.28 (589), and 61.135.158.29

I don't have those two in my dumps, but I only identified 8 unique addresses before the probes ceased.

(451), all three from China. All unsolicited incoming packets. Nothing
is part of any kind of communication (i.e. response to web browsing,
triggering web bugs, p2p, IM, etc).

Ditto

Paul, were you able to find anything out about this? Do those IP's
correlate with your captured IP's? Do you see the TCP SYN too?

Unfortunately, I wasn't capturing *all* traffic to that IP, just udp/53, so I can't tell you if there was any tcp traffic to it.

21:16:15.434753 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51621
NS? . (17) (ttl 44, id 51622, len 45)
21:16:16.194129 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51622
NS? . (17) (ttl 44, id 51623, len 45)
21:16:16.932505 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51623
NS? . (17) (ttl 44, id 51624, len 45)

21:16:18.431546 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9949
PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9950, len 73)
21:16:19.186279 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9950
PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9951, len 73)
21:16:19.939409 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9951
PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9952, len 73)

Mine are identical to yours. Same host, same src port, same types of packets, same ttl, same len) Whatever this is is obviously crafted from some sort of script. The only thing I can think of is recon. If someone has any bright ideas, speak up.

14:07:51.507129 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]
23237 NS? . (17) (ttl 48, id 23238, len 45)
14:07:52.256946 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok] 23238 NS? . (17) (ttl 48, id 23239, len 45) 14:07:53.573977 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok] 23619 NS? . (17) (ttl 48, id 23620, len 45) 14:07:53.752289 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok] 23703 PTR? x.x.x.x.in-addr.arpa. (44) (ttl 48, id 23704, len
72)
14:07:54.336206 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok] 23620 NS? . (17) (ttl 48, id 23621, len 45) 14:07:54.516745 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok] 23704 PTR? x.x.x.x.in-addr.arpa. (44) (ttl 48, id 23705, len
72)
14:07:55.087551 218.75.110.194.3847 > x.x.x.x..domain: [udp sum ok] 23621 NS? . (17) (ttl 48, id 23622, len 45) 14:07:55.275934 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok] 23705 PTR? x.x.x.x.in-addr.arpa. (44) (ttl 48, id 23706, len
72)

Paul Schmehl (pauls () utdallas edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


Current thread: