Reply Re: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect Roch Decoste
Roch Decoste
roch_gcia_cert at rogers.com
Fri Sep 3 05:18:46 GMT 2004
The following are answers to questions brought up by Dana Webber in reference to my 'DNS Named Version Attempt' detect posted August 30th, 2004 (quoted bellow).
1) What was the attacker’s OS?
Because the only 2 packets available from the logs for IP address 203.197.102.29 are UDP based, passive fingerprinting analysis is greatly restricted. In this case the only information available from the IP header is the TTL, which is set to 44. This would lead me to guess that we are dealing with an older Linux kernel (who’s TTL typically starts at 64).
IP option flags have also been known to help fingerprint an OS (in the absence of a TCP header), but unfortunately none of these are set in any of the packets sent by the offending IP.
2) How do you know that the attacker is not trying to "set up" an innocent person to get them in trouble?
There is always the possibility that our attacker has spoofed the packets’ source IP address, however this would prove to be useless as a reconnaissance attempt, and I highly doubt that two simple ‘BIND version’ requests would get anybody in any kind of trouble.
3) What about hping2?
You bring up a good point, because hping2 allows you to specify your packet’s payload, it would be possible to create UDP packets with payloads containing DNS requests with the same DNSid.
During my research I’d noticed this anomaly being generated by many other IP addresses in multiple log files on the Incident.org website. Therefore I focused my energy on finding a pre-existing vulnerability assessment tool which possibly left this anomaly as a fingerprint, unfortunately I came up empty handed.
Thanks for the comments & questions Dana,
Roch
Dana Webber <dana at dunrobin.dyn.dhs.org> wrote:
What was the attackers OS?
On Monday 30 August 2004 09:44, you wrote:
> msg:"DNS named ver..." - Title of the alert.
> 3) Probability the source address was spoofed
> ---------------------------------------------
> Very low. This is a reconnaissance type probe generated using a UDP
> packet. UDP packets can very easily be spoofed, however should the
> attacker have spoofed the source IP address any responses generated by the
> victim would never be seen by the attacker. Unless, both the recipient and
> the attacker are on the same collision domain.
How do you know that the attacker is not trying to "set up" an innocent person to
get them in trouble.?
> 4) Description of the attack
> ----------------------------
> The attack consisted of a single UDP packet which queried a DNS server for
> its BIND version. The same request was sent to two distinct hosts
> approximately 4 minutes apart (refer to section 1B for a detailed view of
> the two packets). An analysis of the packets did not reveal any
> abnormalities from the IP and UDP headers. The source IP id and port
> numbers are different in both cases and the absolute time at which the
> packets were sent also appear to be random. Up to this point there is no
> evidence of scripting involved to conduct these reconnaissance attacks.
>
> The only discrepancy identified in the analysis of these two packets is
> that they both have the same DNSid of 4660. Both nslookup and dig
> utilities were thoroughly tested in a lab network in an effort to recreate
> these packet anomalies, however none of these had the functionality to
> allow a user to specify a DNSid number.
>
> A very interesting tool was uncovered during the research phase of this
> detect. NETWOX, authored by Laurent Constantin, is a toolset providing
> over 150 amalgamated utilities to help resolve network problems. One of
> the tools enabled users to obtain a BIND DNS server's version number. It
> allowed the user to specify values for a multitude of fields in the DNS
> query packet, however it did not provide the ability to specify a DNSid.
>
> When tested in a lab environment NETWOX behaved in the same fashion as dig
> and nslookup. It did not leave any distinguishable fingerprints The DNSid
> value (4660) has also been identified in many other binary log files made
> available on the SANS website. I spent quite a bit of time researching
> this oddity, unfortunately the only information which could be found where
> past GCIA detects posing the same question. The following links point to
> GCIA detects produced by Kahleong Fong and Steve Gamble, both of which
> encountered the same question, 'why is the DNSid set to 4660 for multiple
> BIND version queries?':
> http://www.dshield.org/pipermail/intrusions/2003-March/007104.php
> http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00273.html
What about hping2 ?
--
Dana Webber
dana at dunrobin.dyn.dhs.org
http://dunrobin.dyn.dhs.org
__________________________________________________________________
Roch Decoste <roch_gcia_cert at rogers.com> wrote:
DETECT #1: DNS Named Version Attempt
_____________________________________
-------------------------------------
1) Source of Trace
------------------
The binary log file used for this trace was 2005.05.16 which originated from
the INCIDENTS.ORG website at http://isc.sans.org/logs/raw/2002.05.16. As
indicated by the readme file located in the same directory as the capture file 'this
log file is the result of a Snort instance running in binary logging mode, all
content has been sanitized'. Because of this sanitization, the only network
infrastructure details available from this raw dump are the MAC addresses &
manufactures of the devices located on either side of the IDS node.
The MAC addresses can be obtained by extracting the link level header
information of each packet (using tcpdump -e). A quick online search will indicate to
which manufacture the MAC address was assigned to. The following commands will
extract from the tcpdump output all unique source MAC and unique destination
MAC addresses recorded by the IDS node:
tcpdump -ner 2002.5.16 | awk '{print $2}' | sort -u
tcpdump -ner 2002.5.16 | awk '{print $3}' | sort -u
The results of both queries generated MAC addresses 00:00:0C:04:B2:33 and
00:03:E3:D9:26:C0. This indicates that the IDS sensor can only see traffic being
passed between two machines (possibly a firewall & a gateway). The following
manufacture's MAC address assignments were found at
http://standards.ieee.org/regauth/oui/index.shtml.
00:00:0C:04:B2:33 CISCO SYSTEMS, INC.
170 WEST TASMAN DRIVE
SAN JOSE CA 95134-1706
00:03:E3:D9:26:C0 Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA 95134
United States
2) Detect Generation Method
---------------------------
The SNORT alerts were generated by Snort Ver. 2.1.2(build 25) using a default
configuration with ruleset Ver. 2.1.0. This detect will concentrate on the 'DNS
Named Version Attempt' alerts generated by SNORT for this binary log file.
a) Snort alert logs for to the 'DNS Named Version Attempt'
----------------------------------------------------------
[**] [1:1616:4] DNS named version attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
06/16-07:46:17.214488 203.197.102.29:3566 -> 46.5.237.85:53
UDP TTL:44 TOS:0x0 ID:6052 IpLen:20 DgmLen:58
Len: 30
[Xref => http://www.whitehats.com/info/IDS278][Xref =>
http://cgi.nessus.org/plugins/dump.php3?id=10028]
[**] [1:1616:4] DNS named version attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
06/16-07:50:08.514488 203.197.102.29:3682 -> 46.5.187.139:53
UDP TTL:44 TOS:0x0 ID:9964 IpLen:20 DgmLen:58
Len: 30
[Xref => http://www.whitehats.com/info/IDS278][Xref =>
http://cgi.nessus.org/plugins/dump.php3?id=10028]
The above alerts indicate requests from IP 203.197.102.29 were sent to two IPs
within the 46.5.0.0 network in an attempt to determine their Bind DNS version.
These requests were both made June 16th [year not indicated], at
07:46:17.214488 hrs and 07:50:08.514488 respectively. Snort classified these requests as an
'attempted information leak' priority two alert.
b) Snort rule responsible for this alert
----------------------------------------
alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS named version attempt";
content:"|07|version"; nocase; offset:12; content:"|04|bind"; nocase; offset:
12; reference:nessus,10028; reference:arachnids,278; classtype:attempted-recon;
sid:1616; rev:4;)
The following is a break down and explanation of the above noted rule:
alert - Alert & log the information.
udp - Only trigger on UDP traffic.
$External_Net - Originating from any external address (defined
by $External_net variable).
any - Originating from any port.
-> - Traffic direction.
$Home_Net - Destined to any internal address (defined by
$Home_Net variable).
53 - Destined to port (DNS).
msg:"DNS named ver..." - Title of the alert.
content:"|07|version"... - Only trigger if words 'version' &
'bind'(case insensitive) are found
starting from byte 12 in the payload.
reference:nessus,10028... - External attack reference Ids.
classtype:attempted-recon - Snort's alert classification.
sid:1616 - Snort's signature ID.
rev:4 - Rule revision number.
c) TCPDUMP syntax used to extract responsible packets
-----------------------------------------------------
tcpdump -nXvr 2002.5.16 'src host 203.197.102.29 and dst port 53'
The following is an explanation of the flags used to read & interpret the
binary log file:
n - Don't convert addresses (host addresses, port numbers,
etc) to names.
X - Print results in hex and ascii format.
v - Be more verbose in output. Include TTL, identification,
total length, options & do header checksum verification.
r - Read packets from specified file.
The following is an explanation of the filter syntax used to isolate the
desired packets:
SRC HOST 203.197.102.29
Indicates that only packets with a source IP address 203.197.102.29 are to be
dumped.
AND DST PORT 53
In addition to the above filter, only dump packets with a destination port of
53 (DNS).
d) Corresponding TCPdump data
-----------------------------
07:46:17.214488 203.197.102.29.3566 > 46.5.237.85.53: [bad udp cksum f7fa!]
4660 [b2&3=0x80] TXT CHAOS? version.bind. (30)
(ttl 44, id 6052, length: 58, bad cksum 2eda!)
0x0000: 4500 003a 17a4 0000 2c11 2eda cbc5 661d E..:....,.....f.
0x0010: 2e05 ed55 0dee 0035 0026 74f0 1234 0080 ...U...5.&t..4..
0x0020: 0001 0000 0000 0000 0776 6572 7369 6f6e .........version
0x0030: 0462 696e 6400 0010 0003 .bind.....
07:50:08.514488 203.197.102.29.3682 > 46.5.187.139.53: [bad udp cksum f9f9!]
4660 [b2&3=0x80] TXT CHAOS? version.bind. (30)
(ttl 44, id 9964, length: 58, bad cksum 525a!)
0x0000: 4500 003a 26ec 0000 2c11 525a cbc5 661d E..:&...,.RZ..f.
0x0010: 2e05 bb8b 0e62 0035 0026 a744 1234 0080 .....b.5.&.D.4..
0x0020: 0001 0000 0000 0000 0776 6572 7369 6f6e .........version
0x0030: 0462 696e 6400 0010 0003 .bind.....
3) Probability the source address was spoofed
---------------------------------------------
Very low. This is a reconnaissance type probe generated using a UDP packet.
UDP packets can very easily be spoofed, however should the attacker have spoofed
the source IP address any responses generated by the victim would never be seen
by the attacker. Unless, both the recipient and the attacker are on the same
collision domain.
4) Description of the attack
----------------------------
The attack consisted of a single UDP packet which queried a DNS server for its
BIND version. The same request was sent to two distinct hosts approximately 4
minutes apart (refer to section 1B for a detailed view of the two packets). An
analysis of the packets did not reveal any abnormalities from the IP and UDP
headers. The source IP id and port numbers are different in both cases and the
absolute time at which the packets were sent also appear to be random. Up to
this point there is no evidence of scripting involved to conduct these
reconnaissance attacks.
The only discrepancy identified in the analysis of these two packets is that
they both have the same DNSid of 4660. Both nslookup and dig utilities were
thoroughly tested in a lab network in an effort to recreate these packet anomalies,
however none of these had the functionality to allow a user to specify a DNSid
number.
A very interesting tool was uncovered during the research phase of this detect.
NETWOX, authored by Laurent Constantin, is a toolset providing over 150
amalgamated utilities to help resolve network problems. One of the tools enabled
users to obtain a BIND DNS server's version number. It allowed the user to specify
values for a multitude of fields in the DNS query packet, however it did not
provide the ability to specify a DNSid.
When tested in a lab environment NETWOX behaved in the same fashion as dig and
nslookup. It did not leave any distinguishable fingerprints
The DNSid value (4660) has also been identified in many other binary log files
made available on the SANS website. I spent quite a bit of time researching
this oddity, unfortunately the only information which could be found where past
GCIA detects posing the same question. The following links point to GCIA
detects produced by Kahleong Fong and Steve Gamble, both of which encountered the
same question, 'why is the DNSid set to 4660 for multiple BIND version queries?':
http://www.dshield.org/pipermail/intrusions/2003-March/007104.php
http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00273.html
5) Attack mechanism
--------------------
A single UDP packet was sent to port 53 of the target machines. If a response
was generated by the target machines the attacker would have learnt two
valuable pieces of information:
a) Whether or not the target is running a DNS server.
b) If the target is running a BIND DNS server, the attacker will receive a
reply containing its version and type information (if this option was not
explicitly disabled by the target machine's administrator).
A background check on the attacker's IP address, 203.197.102.29, revealed that
he/she was utilizing dial-up access provided by VSNL Technologies, a company
based out of Maharashtra, India. Depending on the payment methods and locations
from where the Internet connection was established it may be next to impossible
to locate & identify an attacker utilizing this method of internet access.
6) Correlations
---------------
http://www.dshield.org/pipermail/intrusions/2003-March/007104.php
http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00273.html
http://cert.uni-stuttgart.de/archive/intrusions/2003/02/msg00191.html
7) Evidence of active targeting
-------------------------------
Addresses 46.5.237.85 and 46.5.187.139 were actively targeted. The attacker's
IP address (203.197.102.29) was only reported twice in the Snort binary dump
that day, and both entries were for 'DNS Named Version' attempts. The attacker
was not scanning a range of IPs for DNS servers, but rather actively targeting
two IPs for additional information. This kind of behaviour would indicate that:
a) The attacker may have in his/her possession a tool/utility to compromise
certain BIND DNS servers.
b) The attacker is already aware of this network's basic layout, and knows that
IP addresses 46.5.237.85 and 46.5.187.139 are DNS servers.
c) The attacker is verifying what version & type of DNS server is running on
these machines in hopes that they are vulnerable versions of BIND.
8) Severity
-----------
SEVERITY = (Criticality + Lethality) - (System Countermeasures + Network
Countermeasures)
*** Criticality = 5 ***
DNS servers are often at the heart of large networks. Without domain name
services, users and applications alike are unable to utilize domain name resolution
to access other servers (web, ftp smtp, etc). This can in effect bring the
entire network to a halt.
*** Lethality = 1 ***
At this point no attack has taken place. The request was only part of a
reconnaissance attempt.
*** System Counter = 1 ***
With only the IDS logs available for this analysis it is impossible to
determine any of system configurations or countermeasures. Thus we must default to a
worst case scenario.
*** Network Counter = 3 ***
As stated previously, no network layouts are available for this analysis. We
will assume typical placement of the DNS server within a DMZ. A firewall and
IDS should be part of a standard DMZ implementation thus reducing an attacker's
opportunities, while identifying any attempts made to compromise the system.
*** Total = (5 + 1) - (1 + 3) = 2 ***
The immediate severity of this attack is low, however it should serve as a
warning to system administrators that an attacker is lurking and to ensure their
DNS server is well maintained.
9) Defensive Recommendations
----------------------------
Should the information provided to the attacker correspond to a BIND version
for which a compromise is readily available an attack could soon follow.
Disabling the BIND software from returning the version number, or modifying the
returned value to be the latest BIND release will temporarily slow down an attack,
but should certainly not be considered an adequate countermeasure.
In addition to a network firewall and IDS system implemented in a properly
configured DMZ where the DNS server should reside, an application layer firewall
could be configured on the DNS server in order to mitigate specific attacks made
to the named service.
Proper system maintenance and timely software updates are the key,
understandably this solution is not always a viable one in large corporations or government
agencies were patches and software updates must be thoroughly tested before
being brought in an operational environment to ensure they do not affect any other
systems on the network.
10) Multiple Choice Test Question
---------------------------------
07:46:17.214488 203.197.102.29.3566 > 46.5.237.85.53: [bad udp cksum f7fa!]
4660 [b2&3=0x80] TXT CHAOS? version.bind. (30) (ttl 44, id 6052, length: 58)
In the wild, what would happen to the above packet?
A) It would have reached its destination on the next hop.
B) It would have been dropped by the next router it encountered.
C) The destination machine would have discarded it as it made
its way up the stack. (** correct answer **)
D) It would have been successfully processed by the destination
machine.
11) References
--------------
http://standards.ieee.org/regauth/oui/index.shtml.
http://www.whitehats.com/info/IDS278
http://www.sans.org/top20/#u1
http://www.dshield.org/pipermail/intrusions/2003-March/007104.php
http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00273.html
http://www.snort.org/docs/writing_rules/chap2.html
http://cert.uni-stuttgart.de/archive/intrusions/2003/02/msg00191.html
More information about the Intrusions
mailing list