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

Sun Jul 25 08:51:21 GMT 2004

Network Detect 1

By Ian Marks

DNS Named Version Bind Attempt

1) Source of trace:

http://isc.sans.org/logs/Raw/2002.5.10

Time frame

To determine the time frame of the dump I took the first and last lines 
of output from:

tcpdump -nqnr 2002.5.10 -tttt |gawk '{print $1 " " $2}'

Start = 06/10/2002 00:18:48.944488

Stop = 06/10/2002 23:52:36.854488

2) Detect was generated by:

The tools used to analyze the detect were:

Fedora Core2 2.6 with:

Snort Version 2.1.3 (Build 27) with libpcap version 0.8.3

RedHat 9 2.4 with:

tcpdump version 3.7.2 with libpcap version 0.7.2

This detected was by a fully enabled default rule set on snort with the 
exception of defining the home network variable to 46.5.0.0/16.

snort -c /etc/snort/sort.conf -vdek none -r 2002.5.10 -l snort-logs/

Rule that triggered alert was:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS named version 
attempt"; content:"|07|version"; offset:12; nocase; content:"|04|bind"; 
offset:12; nocase; reference:arachnids,278; reference:nessus,10028; 
classtype:attempted-recon; sid:1616; rev:6;)

Alerts:

This is a just a sample of the 58 alerts triggered on this rule.

[**] DNS named version attempt [**]

06/10-05:33:34.284488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 len:0x48

203.107.136.133:1169 -> 46.5.29.29:53 UDP TTL:45 TOS:0x0 ID:45068 
IpLen:20 DgmLen:58

Len: 30

12 34 00 80 00 01 00 00 00 00 00 00 07 76 65 72 .4...........ver

73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03 sion.bind.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

[**] DNS named version attempt [**]

06/10-10:06:51.474488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 len:0x48

203.197.102.110:4019 -> 46.5.20.184:53 UDP TTL:44 TOS:0x0 ID:55389 
IpLen:20 DgmLen:58

Len: 30

12 34 00 80 00 01 00 00 00 00 00 00 07 76 65 72 .4...........ver

73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03 sion.bind.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Here is a small sample of the tcpdump output for all UDP DNS traffic 
from the logs.

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.

4) Description of attack:

This isn't so much of an attack as it is of a precursor to an attack. 
The attackers are in their reconnaissance phase and trying to find out 
what versions of bind are running on particular DNS servers. This is 
likely done by issuing the Unix command dig (ipaddress) TXT CHAOS 
version.bind or by using Nessus and issuing the command nasl -t 
(ipaddress) bind.version.nasl. Once the attacker found what version of 
bind was running, he could then search for an exploit for that specific 
version of bind.

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.

6) Correlations

Nessus has the following plug-in to query the version of bind on a DNS 
server.

#

# This script was written by Noam Rathaus <noamr at securiteam.com>

#

# See the Nessus Scripts License for details

#

if(description)

{

script_id(10028);

script_version ("$Revision: 1.21 $");

name["english"] = "Determine which version of BIND name daemon is running";

script_name(english:name["english"]);

desc["english"] = "

BIND 'NAMED' is an open-source DNS server from ISC.org. Many proprietary

DNS servers are based on BIND source code.

The BIND based NAMED servers (or DNS servers) allow remote users

to query for version and type information. The query of the CHAOS

TXT record 'version.bind', will typically prompt the server to send

the information back to the querying source.

Solution:

Using the 'version' directive in the 'options' section will block

the 'version.bind' query, but it will not log such attempts.

Risk factor : Medium";

script_description(english:desc["english"]);

summary["english"] = "Determine which version of BIND name daemon is 
running";

script_summary(english:summary["english"]);

script_category(ACT_GATHER_INFO);

script_copyright(english:"This script is Copyright (C) 1999 SecuriTeam");

family["english"] = "General";

script_family(english:family["english"]);

Details on the snort alert can be found at 
http://www.snort.org/snort-db/sid.html?sid=1616

CVE entry http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0009 
deals with one of the vulnerabilities associated with bind.

7) Evidence of active targeting;

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.

tcpdump -nnqr 2002.5.10 udp port 53 and host 203.107.136.133

04:23:09.434488 203.107.136.133.4302 > 46.5.139.47.53: udp 30

05:05:22.174488 203.107.136.133.3561 > 46.5.22.96.53: udp 30

05:33:34.284488 203.107.136.133.1169 > 46.5.29.29.53: udp 30

05:52:14.404488 203.107.136.133.4315 > 46.5.216.88.53: udp 30

05:53:04.084488 203.107.136.133.2252 > 46.5.246.131.53: udp 30

06:00:29.374488 203.107.136.133.3463 > 46.5.215.240.53: udp 30

This was captured over a period of 2 hours. Notice the targeted 
addresses are not in any order and that they don't match up with the 
attacker’s source port. Typically, the source port should increment by 
one with each new connection attempt until it is reset after it reaches 
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.

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, 
and was know for targeting vulnerable versions of bind. The worm scanned 
class B networks and then checked to see what versions of bind the 
servers were running. This could explain the large gaps in the source 
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.

8) Severity:

The severity is calculated in the following way: severity = 
(criticality+lethality) (system countermeasures + network countermeasures)

Criticality 3

DNS Servers are critical to network operations but will not contain 
company proprietary/financial information.

Lethality 1

This is just reconnaissance, so there is no way that that this query 
should effect network operations.

System countermeasures 3

It is unclear if the system is patched or if it is even running bind.

Network countermeasures 1

If these hosts are legitimate DNS servers this traffic will have to be 
allowed to pass. The queries are occurring on UDP/53, the same way a 
standard DNS lookup of less then 512 bytes happens.

Severity 8

9) Defensive recommendation:

DNS servers that are facing the Internet are usually big targets. It is 
extremely important that they stay current with the latest OS and 
software patches. Also just as important, make sure to remove any 
services that are not specifically needed. Configuration should be set 
to allow zone transfers to and from only trusted sources. It would also 
be a good idea to run a host based IDS/Firewall that could protect 
against services getting started up from a worm or other type of new 
exploit. Patches only help against known attacks, if a new worm infected 
a system, a host-based firewall could prevent it from propagating or 
starting additional services.

10) Multiple choice questions:

Which port will a DNS zone transfer take place on?

A) UDP/53

B) UDP/1024

C) TCP/53

D) TCP/1024

Answer: C