[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Kyle Maxwell (Detect 1)
Kyle Maxwell
krmaxwell at gmail.com
Sun Jul 25 20:49:04 GMT 2004
Following is the first detect and analysis for my GCIA practical;
comments and suggestions are welcomed and requested. Referenced URLs
are at the end of the analysis.
Detect 1: DNS named version attempt
(1) Source of trace:
This trace was taken from http://isc.sans.org/logs/Raw/2002.6.16.
Snort 2.1.3 was run as "snort -c snort.conf -r 2002.6.16 -l june/ -A
full -k none -d -h 46.5.0.0/16". The home network parameter was chosen
based on running "tcpdump -n -r 2002.6.16" and noticing that all
packets had at least one endpoint in 46.5.0.0/16, though at varying
subnets within the network. The relevant alert found within june/alert
was:
[**] [1:1616:6] DNS named version attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
07/15-19:06:52.934488 203.107.136.44:1723 -> 46.5.142.31:53
UDP TTL:45 TOS:0x0 ID:25994 IpLen:20 DgmLen:58
Len: 30
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=10028][Xref =>
http://www.whitehats.com/info/IDS278]
Examining june/203.107.136.44/UDP:1723-53, we find:
[**] DNS named version attempt [**]
07/15-19:06:52.934488 203.107.136.44:1723 -> 46.5.142.31:53
UDP TTL:45 TOS:0x0 ID:25994 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.....
Further, there are 8 other alerts in this log file from the same
source attempting the same request to other systems on the 46.5.0.0/16
network.
[**] DNS named version attempt [**]
07/15-21:37:58.814488 203.107.136.44:1848 -> 46.5.92.193:53
UDP TTL:45 TOS:0x0 ID:8149 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 [**]
07/15-23:06:42.464488 203.107.136.44:2392 -> 46.5.41.81:53
UDP TTL:45 TOS:0x0 ID:62216 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 [**]
07/15-20:23:52.704488 203.107.136.44:2794 -> 46.5.193.183:53
UDP TTL:45 TOS:0x0 ID:48852 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 [**]
07/16-02:44:33.284488 203.107.136.44:3938 -> 46.5.102.170:53
UDP TTL:45 TOS:0x0 ID:3545 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 [**]
07/15-20:38:38.254488 203.107.136.44:4011 -> 46.5.135.4:53
UDP TTL:45 TOS:0x0 ID:65067 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 [**]
07/15-20:25:06.454488 203.107.136.44:4220 -> 46.5.162.91:53
UDP TTL:45 TOS:0x0 ID:50446 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 [**]
07/16-00:54:51.794488 203.107.136.44:4261 -> 46.5.47.69:53
UDP TTL:45 TOS:0x0 ID:19627 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 [**]
07/15-22:07:33.724488 203.107.136.44:4728 -> 46.5.174.56:53
UDP TTL:45 TOS:0x0 ID:47083 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.....
Based on other alerts seen in analyzing the original log file (e.g.
inbound connections to TCP ports 515 and 6346), it is conjectured that
there is no firewall in place protecting the 46.5.0.0/16 network, or
at least such a firewall has an extremely permissive rule set.
Further, all packets in the file the same MAC addresses 0:0:c:4:b2:33
and 0:3:e3:d9:26:c0 (no results were returned from "/usr/sbin/tcpdump
-ner 2002.6.16 |awk '{print $2"\n"$3}'|grep -v "0:0:c:4:b2:33" | grep
-v 0:3:e3:d9:26:c0"). Both MAC addresses belong to Cisco Systems,
Inc., suggesting that the IDS sensor was monitoring a link between two
Cisco routers, though one or both may also have been a PIX firewall or
similar.
(2) Detect was generated by:
Snort 2.1.3 (build from dag repository) running on Fedora Core 2. The
rule that triggered this 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;)
In particular, the rule triggers based on the presence of <07>
followed by "version" beginning at the 13th byte in the packet.
(3) Probability the source was spoofed:
It is unlikely (though possible) that the source was spoofed; although
the packet was a UDP datagram (thus making it a connectionless
attempt), the activity is apparently a reconaissance attempt (see part
4 of this detect analysis below) and thus the attacker would need to
see the result for the activity to be of any use to him. It's
possible, however, that this is not the actual address of the source;
the true source could potentially be anywhere along the route to
203.107.136.44 or on the same subnet, in which case the attacker could
generate a packet with the spoofed address and observe the reply in
transit.
(4) Description of attack:
The activity is intended to discover the version of BIND[1] running on
the server; older versions of BIND have many vulnerabilities[2]. BIND
is a widely-used server application used for DNS (Domain Name
Service), translating human-convenient names (such as www.example.com)
to IP addresses with which systems can communicate (such as
172.16.1.1). DNS servers contain information about many (sometimes
all) hosts on a network, and in some cases may contain OS, version, or
administrative information on systems in a network. In this case, if
the version attempt is successful, the attacker will be able to tailor
further attacks to the version of BIND in use without noisily
attempting exploits for other versions that may be detected by server
administrators or network security staff. An attacker able to find
older or misconfigured servers is well on his way to compromising that
machine or finding information that will assist him in his efforts to
compromise other systems on the target network.
The Common Vulnerabilities and Exposures project has assigned ID
CVE-1999-0009 to this vulnerability with the description[3] "Inverse
query buffer overflow in BIND 4.9 and BIND 8 Releases." Referring to
the related SecurityFocus Bug ID listing[4], we also see that in some
cases this type of query can lead to a buffer overflow attempt that
would allow "arbitrary commands [to be] run on the affected host." The
trace in this case does not appear to indicate that this attack was
performed.
(5) Attack mechanism:
DNS requests are typically sent via UDP datagrams (exceptions include
zone transfers and requests too large to fit in a single datagram).
This request in particular asks for a TXT record of class CHAOS,
querying specifically "version.bind". This then returns the value
assigned to "version" in the options section of named.conf[5].
Analyzing the various alerts seen, in particular their timestamps and
order in the file, it becomes questionable whether the timestamps are
correct or if they were somehow written in the incorrect order.
Assuming that the source port increases monotonically (each successive
UDP packet uses a higher ethereal source port than previous packets
until the maximum is reached), the most likely explanation is that the
order is correct but timestamps are corrupted. This is further
supported by the fact that all timestamps appear to indicate that the
traffic was generated on July 15th or 16th but the file was allegedly
generated on June 16th. In either case, I was unable to determine a
pattern in either the source ports or the IP IDs. The differences in
source port numbers between successive packets would seem to indicate
that the source system is relatively active; one gap between two
packets (the 4th and 5th in sequence) is 1144, indicating that over a
thousand other UDP packets were sent in between the requests. No
pattern was discernible in the destination addresses, either.
(6) Correlations:
This activity is commonly considered to be part of an initial
reconnaissance of a network prior to actual exploitation attempts[6].
Other GCIA practicals have examined similar behavior, including
Shakeel Akhter[7], Pedro Bueno[8], and a posted attempt by Sanjay
Menon[9]. A GCIH practical by Chris Talianek[10] also uses this
technique in his examination of buffer overflows in BIND v8.2,
querying the version first to see if the server might be vulnerable. A
similar (though not identical) detect is examined in somewhat less
detail in Intrusion Signatures and Analysis, pp. 42-46.
References to this source are also found on what appears to be a list
of web servers in Thailand[11] in AS (Autonomous System) 7693; the
source web server has the version string "Apache/1.3.29 (Unix)
PHP/4.3.2" according to that list. A posting was made to what appears
to be a "Hot or Not" style website[12] (mthai.com), also in Thai. It
is surmised that this is a Unix desktop or shared system. According to
APNIC, the address is assigned to KSC Commercial Internet, an ISP in
Bangkok, Thailand, which also owns the AS referenced above according
to a lookup performed via Eye-Net Consulting[13] which used data from
APNIC.
inetnum: 203.107.128.0 - 203.107.255.255
netname: COMNET-TH
descr: KSC Commercial Internet Co. Ltd.
descr: 2/4 Samaggi Insurance Tower 10th Fl.,
descr: Viphavadee-Rangsit RD
descr: Thungsonghong, Laksi
descr: Bangkok 10210
country: TH
admin-c: JT183-AP
tech-c: TOC1-AP
remarks: service provider
remarks: Delegate four /19 to /17
mnt-by: APNIC-HM
mnt-lower: KSC-ADMIN
changed: hostmaster at apnic.net 20000301
changed: hostmaster at apnic.net 20011016
changed: hm-changed at apnic.net 20020830
status: ALLOCATED PORTABLE
source: APNIC
person: Joost Th.A Doevelaar
nic-hdl: JT183-AP
e-mail: jdoevelaar at ksc.net
address: KSC Commercial Internet Co.,Ltd.
address: 2/4 Samaggi Insurance Tower 10th Fl., Viphavadee-Rangsit Rd.,
address: Thungsonghong, Laksi
address: Bangkok 10210
phone: +66-2-9797777
fax-no: +66-2-5885665
country: TH
changed: netadmin at ns.ksc.co.th 20030115
mnt-by: KSC-ADMIN
source: APNIC
person: Technical Operation Center
address: KSC Commercial Internet Co.,Ltd.
address: Operation Department
address: 2/4 Samaggi Insurance Tower 10th Fl., Viphavadee-Rangsit Rd.,
address: Thungsonghong, Laksi
address: Bangkok 10210
country: TH
phone: +66-2-9797777 ext. 8428
e-mail: netadmin at ns.ksc.co.th
nic-hdl: TOC1-AP
mnt-by: KSC-ADMIN
changed: admin at ns.ksc.co.th 20011012
changed: hm-changed at apnic.net 20030718
source: APNIC
(7) Evidence of active targeting:
There is insufficient evidence in the traces gathered to determine
whether the destination systems were actively targeted. Multiple hosts
were attempted in seemingly random fashion; it is possible that the
attacker was simply scanning large swaths of address space looking for
BIND servers that would respond to his query. It is also possible,
however, that by spacing out such requests over multiple servers at
different times, the attacker was hoping to evade detection and "stay
beneath the radar", actively targeting the network in question.
(8) Severity:
Criticality: 4
DNS servers are repositories for great amounts of information about a
network, and their integrity is key, as many applications trust their
results.
Lethality: 2
The observed activity is only a reconnaissance attempt, not an active
exploit. It is, however, frequently a precursor to more serious
attacks.
System countermeasures: 3
No traffic originating from these systems was in the original log
file, nor was any other traffic to these systems observed, but the
rule set is unknown and replies may not have been logged. This value
is just chosen as a middle value.
Network countermeasures: 2
Minimal, if any, firewalling of the network is apparent. UDP packets
on port 53 are allowed in, and it is possible that the systems in
question are not even DNS servers as no other traffic was seen to them
in the alerts and log file.
Severity
= (Criticality + Lethality) – (System + network countermeasures)
= (4+2) – (3+2)
= 1
(9) Defensive recommendations:
Ports not needed for operations should be denied at the firewall
rather than passed or forwarded to internal systems. For example,
traffic to UDP port 53 should only be allowed to DNS servers that need
to interface with the Internet in general.
Further, servers that do require inbound connections to be permitted
typically do not require outbound connections, and these should be
denied in the firewall as well. Appropriate exceptions may be made for
defined uses. This will restrict the spreading of worms and other
malicious software, as well as not allow compromised systems to be
used as attack vectors or "launching pads".
All systems should have all appropriate patches applied; in
particular, BIND should be running at the latest version in the
appropriate series (8.4.4[14] or 9.2.3[15] at the time of this
writing).
Appropriate steps should be taken to harden the BIND configuration.
Many freely available documents have recommendations on this
hardening; O'Reilly has even made the Security chapter of the seminal
text "DNS & BIND" available on the Internet[16]. In particular, ACLs
may be created to define who is allowed to query the version number or
the version number itself may be spoofed, replaced, or simply not
available[17]. A "Secure BIND Template" is available to assist with
this hardening process[18].
(10) Multiple choice test question:
What is the key defensive action to prevent version number queries
from succeeding?
(A) Firewall UDP port 53 on all machines.
(B) Upgrade to a newer version of BIND.
(C) Replace the reported version number or prevent it from being
reported altogether.
(D) Nothing; there is little or no reason to prevent such queries.
Answer: C
References:
[1] http://www.isc.org/products/BIND/
[2] http://www.isc.org/index.pl?/sw/bind/bind-security.php
[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0009
[4] http://www.securityfocus.com/bid/134/discussion/
[5] http://www.freebsddiary.org/bind-version.php
[6] http://www.iss.net/security_center/advice/Intrusions/2000411/
[7] http://www.giac.org/practical/GCIA/Shakeel_Akhter_GCIA.pdf
[8] http://www.giac.org/practical/Pedro_Bueno_GCIA.doc
[9] http://cert.uni-stuttgart.de/archive/intrusions/2002/09/msg00121.html
[10] http://www.giac.org/practical/chris_talianek.doc
[11] http://zenith.gits.net.th/iir/zone/AS7693/domainwww/
[12] http://www.mthai.com/sticker/oo/others/173331.shtml
[13] http://www.enc.com.au/itools/aut-num.php
[14] http://www.isc.org/sw/bind/bind8.php
[15] http://www.isc.org/sw/bind/bind9.php
[16] http://www.oreilly.com/catalog/dns4/chapter/ch11.html
[17] http://www.freebsddiary.org/bind-version.php
[18] http://www.cymru.com/Documents/secure-bind-template.html
--
Kyle Maxwell
krmaxwell at gmail.com
More information about the Intrusions
mailing list