[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect Ian Marks

[Daniel Wesemann]

On Sun, 25 Jul 2004, Ian wrote:

> DNS Named Version Bind Attempt
Ian, please find my comments in-line below.

> tcpdump -nnr 2002.5.10 udp and port 53
> 20:24:07.524488 203.107.136.88.3781 > 46.5.12.133.53: 4660 [b2&3=0x80]
> TXT CHAOS? version.bind. (30)
> 01:35:52.244488 203.122.47.137.13605 > 46.5.37.204.53: 4660 [b2&3=0x80]
> TXT CHAOS? version.bind. (30)
> 03:16:22.074488 203.107.136.88.3213 > 46.5.164.19.53: 4660 [b2&3=0x80]
> TXT CHAOS? version.bind. (30)
> 19:49:20.654488 210.195.43.28.4040 > 46.5.150.2.53: 4660 [b2&3=0x80] TXT
> CHAOS? version.bind. (30)

> 3) Probability the source address was spoofed:
>
> The traffic is probably not spoofed because the attackers are looking
> for an answer to a query. In this instance it wouldn't make sense for
> the attacker to spoof an address, because he wouldn't get his answer
> back. All the queries were made from Asia, which could lead to the
> presumption that a group of organized attackers did this. The reason I'm
> assuming organized, is that none of the queries targeted the same address.

Hmmmm. If I want to get an answer to the query, I could still spoof all
but one of the addresses, couldn't I ?  Also, what (if anything) could it
suggest that one of them (.88) came back onto your turf hours later, going
after a different address ?

> 5) Attack mechanism
>
> The attack was unsuccessful. There are no recorded replies back from any
> of the DNS servers. This would prevent the attacker from gaining any
> information about the DNS servers.

How can you tell? Do you have a rule that triggers on the reply, or
do you record all your traffic anyway? :-)

> The time frame of each query is rather slow which would lead me to
> believe these are not automated. Typically if a scan were automated you
> would see the attacker hitting hosts in a pattern, say climbing up a
> class B network from the lowest IP to the highest IP in a short period
> of time. The queries are suspiciously out of place. Here is an example
> from one host. port 65535. Either the host is extremely busy or some is
> crafting the packets to randomly change the source ports. The 4th and
> 5th attempts are a lapse of 50 seconds and go through over 63,472 ports.

Good reasoning. Though, how would the pattern look if the scan were fully
automated, but going randomly after a much bigger network range than
just yours ?

> Once possible but not likely answer, could be that this is traffic from
> hosts infected with the li0n worm. The li0n worm was seen in early 2001,
[...]
> ports. There is one major problem with this theory. The infected hosts
> scan the class B networks for TCP/53 first to find out which servers to
> attack. These TCP scans do not show up in the logs.

grin, a major problem indeed :-).  a good write-up on lion is available on
http://www.whitehats.com/library/worms/lion/ and there's two snort sigs
(sid 303 314) that should fire on a real li0n.  I'd say you can get away
with claiming that version.bind is a precursor to a real attack, but a
link to li0n strikes me as a bit farfetched...

> 9) Defensive recommendation:
these are very good.

> 10) Multiple choice questions:
> Which port will a DNS zone transfer take place on?
ahem. isn't this question somewhat unrelated to the rest of your detect?


take care && good luck,
-daniel, gcia