[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect Bre tt Hutley
Adams, Samuel (contractor)
AdamsS at eur.disa.mil
Thu Sep 2 15:34:08 GMT 2004
Some questions/comments below....
I first started examining the libpcap formatted files using my own
tool, TrackAttack ( <http://www.trackattack.org/>
http://www.trackattack.org/). I was examining the
log files looking for interesting traffic, and started off generating
a histogram of the various packet types. That was when I noticed the
IGMP packets, and started to look into them. The trace I have given is
the output from 'tcpdump -n -r 2002-10-08_raw.log igmp'. I
concatenated the output from all the log files to a single file, and
then used perl scripts to do more detailed analysis.
Is there any documentation on your tool? I looked at this site and at
sourceforge and couldn't find any. It seems pretty self-explanatory but if
you're going to include output from the tool in your paper, you should
probably have some documentation for the tool in case folks have questions.
3. Probability source address was spoofed
Other evidence is that the source and destination mac addresses are
different, indicating this packet is being routed. (00:03:e3:d9:26:c0
> 00:00:0c:04:b2:33).
You might consider doing some research on the MAC addresses. Who owns these?
Sometimes with Cisco devices you can make an educated guess about the
name/model of the device via the MAC address. Any chance of that here?
4. Description of attack
IGMP is like ICMP for multicast IP traffic, in that it acts as a
management protocol. It allows network devices to notify routers when
they are interested in multicast traffic, so that traffic of interest
can be routed to them. It also allows routers to determine if any
network device on the local network is interested in multicast
traffic. As of IGMP version 2, a network device is able to inform a
router that it is no longer interested in a particular multicast
group. This "Leave" report will often generate a "Membership Query" by
the router to determine whether any devices are still interested in
the multicast address. A router will also generate IGMP "Membership
Query" packets periodically if a device has previously registered
interest in a multicast group. The allows the router to determine when
it should stop routing the multicast traffic of interest to the
network.
Given that I believe that the packets are crafted, they must have been
crafted for a reason. Unfortunately it's not an obvious attack.
There are numerous possibilities about what this traffic could be:
Possibilities
=============
a. Valid traffic (response to some kind of membership report, or
leave request)
b. Broken router traffic
c. Broken application traffic
d. DoS attempt
I. Windows large IGMP vulnerability. Many tools available to
attack this vulnerability.
II. SGI/FreeBSD DoS attack.
III. La Tierra Land Attack
e. Scanning attempt
I. SynScan - upscan.c
II. nmap protocol scan
III. IRPAS
f. Covert channel
Packet characteristics
======================
Over the course of at least 10 days (when we run out of log files) -
from the 8th-18th Oct 2002, the sensors pick up IGMP traffic destined
for a range on internal hosts on the network.
Here are the packet characteristics:
IP Layer
--------
Protocol Type is 2 = IGMP
The source address and destination address are the same.
There are no IP options specified
The Type of Service flags are zero (no flags set).
The IP ID is zero
The packets are not fragmented
The TTL of all the packets is 47, except for the last 35 packets
which have a TTL of 46
IGMP Layer
----------
The message type field is 0x11, indicating this is a IGMP
Membership Query
The max response time is 10 seconds (indicating that this is a
version 2 IGMP packet). Interestingly enough, this is the default
response time for a version 1 IGMP packet which would have this
field set to zero.
The IGMP checksum seems valid given the multicast address.
The multicast address is NOT in fact a valid multicast address, but
is instead an address in the range 240.0.0.58 - 240.0.3.199. A
valid multicast address is in the range 224.0.0.1 -
239.255.255.255
Note that the size of the packet is exactly right for IGMP - 28
bytes (20 bytes for IP header and 8 bytes for IGMP)
The Case for each Possibility
=============================
At the IP/IGMP layer there is the following evidence to show the
packet is crafted:
a. The IP ID is zero.
b. Source IP is equal to destination IP.
c. The TTL is greater than 1.
d. An invalid multicast address is specified
e. TOS field is zero.
Also there is the fact that a lot of packets are hitting our sensors
at the same time. This is more in line with scanning behavior than
IGMP traffic!
Note that the IGMP checksum appears to be valid. This is something
that many packet crafting attack tools or scanning code does not
bother getting right. Also the IGMP maximum response time field is set
to 100. This indicates that the router is prepared to wait 100 * 1/10
of a second (or 10 seconds) for a response. By being non-zero this
indicates that this packet is an IGMP version 2 packet, and 10 seconds
is also the default response time for an IGMP version 1 packet which
has zero byte in this field.
The last sentence is confusing. Is a 10 second response timeout represented
by a 0 byte value in the maximum response field? That seems a little
strange. I'm certainly not an IGMP expert but that seems like a funky way to
do things.
Because of the evidence above, I would completely rule out the
possibility of this being valid traffic, and tend to rule out the
broken router traffic possibilities, and broken application traffic
possibilities.
Given the evidence you've presented so far, the only thing that really
suggests this is malicious is the IP ID of 0.
A tos field of 0 and a ttl greater than 1 are certainly not unusual in
traffic other than IGMP. Having the same source and dest along with an
invalid multicast address only goes further to suggest this is a
misconfiguration.
What could a hacker possibly hope to achieve with this attack? A source IP
equal to the destination IP precludes a response. Unless the intended victim
is set up with some sort of trigger to open a back door upon receiving a
certain type of IGMP traffic, it seems unlikely that this will lead to a
compromise of the victim system. Perhaps since there are few, if any
vulnerabilities associated with IGMP and most IDSs ignore it, the attacker
hopes to slip in under the radar. This traffic seems a bit visible and
clumsy for a slick, well thought out attack. It seems like the only thing
this attack could plausibly accomplish is a denial of service. I would think
this would either require an extremely high level of traffic or just 1
packet per host. The trojan scenario also suggests just 1 packet per host.
Looking at your histogram below, none of these scenarios seems likely.
Consider the timing of the packets:
Here is a histogram of the detect time for each packet:
Detect timestamp Number of detects
2002-10-08 01:52:39.026507 3
2002-10-08 01:52:39.036507 8
2002-10-08 09:54:06.296507 3
2002-10-08 09:54:06.306507 8
2002-10-08 09:54:06.326507 1
2002-10-08 09:54:06.346507 11
2002-10-09 09:58:29.346507 11
2002-10-09 17:55:34.036507 11
2002-10-11 10:02:51.796507 11
2002-10-13 01:23:45.976507 11
2002-10-13 09:25:13.706507 1
2002-10-13 09:25:13.716507 10
2002-10-13 17:22:18.726507 11
2002-10-15 13:36:45.306507 11
2002-10-16 02:33:01.856507 11
2002-10-16 18:26:16.456507 12
2002-10-18 11:00:02.646507 1
2002-10-18 11:00:02.666507 11
Notice we are getting a lot of packets hitting our interface at the
same time with a resolution of about a 100th of a second. Consider how
it looks if we drop the resolution to one second:
Detect timestamp Number of detects
2002-10-08 01:52:39 11
2002-10-08 09:54:06 23
2002-10-09 09:58:29 11
2002-10-09 17:55:34 11
2002-10-11 10:02:51 11
2002-10-13 01:23:45 11
2002-10-13 09:25:13 11
2002-10-13 17:22:18 11
2002-10-15 13:36:45 11
2002-10-16 02:33:01 11
2002-10-16 18:26:16 12
2002-10-18 11:00:02 12
The output from 'cal 10 2002', tells us that these attacks occurred on
Tuesday 8th, Wednesday 9th, Friday 11th, Sunday 13th, Tuesday 15th,
Wednesday 16th and Friday 18th, with most of the attacks occurring
around 2am, 10am or 6pm. The log files end on the 18th October, so
unfortunately we can't tell if the attack continues after this period.
(I've modified the output of 'cal 10 2002' below to highlight the days
this attack occurred).
October 2002
S M Tu W Th F S
1 2 3 4 5
6 7 [ 8][ 9] 10 [11] 12
[13] 14 [15][16] 17 [18] 19
20 21 22 23 24 25 26
27 28 29 30 31
Here are the range of IP addresses being targeted, broken down by
network: (The first 3 octets of every IP address are in the first
column, the list of forth octets follow).
170.129.15: 162
170.129.21: 101 111 117 122 128 133 138 144 149 154 160
170.129.71: 7 20 26 31 37 42 47 53 58 63 69 74
170.129.163: 252
170.129.164: 3 9 14 20 25 30 36 41 46 52
170.129.215: 85 93 99 104 110 115 120 126 131 137 142
207.166.14: 37 44 50 56 61 66 72 77 83 88 94
207.166.38: 167 172 177 182 188 193 199 204 209 214 220
207.166.46: 3 9 14 19 25 30 36 233 241 247 252
207.166.71: 192 199 205 211 216 221 227 232 238 243 249
207.166.84: 64 69 74 80 85 91 96 101 107 112 122
207.166.97: 115 120 125 131 136 141 147 152 158 163 168
207.166.102: 247
207.166.108: 3 8 203 214 220 225 231 236 241 246 252
207.166.199: 25 32 38
207.166.200: 42 47 52 58 63 69 74 80
207.166.206: 26 31 37
207.166.207: 40 45 51 56 62 67 73 78
Unfortunately this analysis may be corrupted by the IP obfuscating
process, as I am not sure that the same obfuscated IP addresses are
generated across the different log files.
This table shows the date and hour of every network scan:
Date Hour Networks
2002-10-08 01 207.166.206 207.166.207
2002-10-08 09 207.166.102 207.166.108 207.166.84
2002-10-09 09 207.166.14
2002-10-09 17 207.166.199 207.166.200
2002-10-11 10 207.166.71
2002-10-13 01 207.166.46
2002-10-13 09 207.166.97
2002-10-13 17 207.166.38
2002-10-15 13 170.129.215
2002-10-16 02 170.129.163 170.129.164
2002-10-16 18 170.129.71
2002-10-18 11 170.129.15 170.129.21
The multicast group address also varies seemingly randomly from the
range 240.0.0.58 to 240.0.3.199. Note that this is just outside the
valid range of 224.0.0.1 to 239.255.255.255. Could the program
generating these values be overflowing?
5. Attack Mechanism
I believe this is either a misguided attempt to scan a large number of
hosts using IGMP packets, or a misguided attempt to perform a
large-scale denial of service attack using a modification to an attack
tool such as sXe.c or stresser.
A network device that is interested in a multicast group will respond
to a membership query request. An attacker could use an IGMP
membership query request to gather information about hosts, but it
would be very limited information. Usually this request is broadcast
to all devices on the local network. A device will then wait for a
short while to see if another device broadcasts a membership report,
indicating that they are interested in that multicast group. If
another host broadcasts the membership report for that group, then the
network device doesn't have to respond with a membership report of its
own. An attacker could send a membership query directly to a host to
guarantee that another host won't generate a membership report. Rather
than putting a specific multicast group in the IGMP packet, an
attacker would be better off specifying a multicast group field of
0.0.0.0, which tells the network device to report on ANY multicast
group it is interested in. Unfortunately, any reply to a Membership
Query will have a TTL of 1, so this type of scan is only useful for
detecting hosts on the local network! RFC 792 states that ICMP error
messages are never sent in response to an IGMP message of any
kind. This limits using broken IGMP packets as a scanning tool.
The sXe IGMP flood attack tool is used to generate a large number of
IGMP membership query (by default) packets spoofed to come from the
victim IP address. A file containing a list of broadcast addresses is
specified in the command line. The idea being that the victim would be
flooded with IGMP membership report responses. This tool is not very
well documented in the code. If it were modified so as to set the
source IP equal to the destination address (which is supposed to be
the broadcast address read from the file), and then the tool was run
with a list of hosts in the file instead of broadcast addresses, we
would get packets almost identical to those observed in the log
files. The only difference being that the version of sXe I have sets
the multicast group address to be 224.0.0.1, so the attacker would
have had made a change to this code as well. The attacker could have
modified the original code, not realizing the mechanism behind how it
worked. The only comment in the code other than the author's name
(l-n1nja), is; "If you can figure out how to use this, you can create
quite an effective attack from even a 14kbs modem.". In the version of
the code I have, the author has commented out the assignment of the
source IP address to the victim's address, and instead it gets
assigned to the address of the attacker's machine meaning that if they
achieve a IGMP flood, it will be directed at themselves.
Another alternative is the network stress-testing tool; stresser. This
tool also will generate a flood of IGMP membership queries, but they
are type 1 queries with the multicast group ID set to 0.0.0.0. This
tool does not seem to be intended to be a IGMP smurf-style
amplification tool in itself, although the user has the option of
specifying both the source IP address and the destination IP address,
or making one or the other, or both, randomly generated. Interestingly
enough, the code in the IGMP generation sets the IP ID to the user ID,
which would normally have the effect of setting the IP ID to be 0
since root is usually required to generate raw packets. Again, a
modification of the code would be required in order for the packets
generated by this tool to resemble those observed in the log files.
Your analysis is unquestionably thorough and excellent. Are you familiar
with Ockham's Razor? Generally the simplest solution is the correct one. You
have a number of complex scenarios here but don't you think it would take
quite a bit of work to make one of them happen? Wouldn't there be an easier
way for an attacker to achieve his goals?
6. Correlations
Other than previous analysts examining this traffic, I have found no
other record of traffic of this kind, and have not seen this kind of
traffic in the wild. I was able to create a program that replicates
this type of traffic using the libnet library, but was not able to
elicit any kind of response from the machines in my test lab. The code
in the various tools I have examined would have to be modified quite a
bit in order to create these kind of packets. The sXe program is
probably the closest "out-of-the-box" tool I could find that could
generate packets close to what we have observed.
A Land attack tool I found on <http://insecure.org> http://insecure.org
called "La Tierra"
has the option to specify the protocol when creating the packets. This
tool could create packets with the same source IP and destination IP
address and with the IGMP protocol, but would not create a valid IGMP
body.
Nmap and IRPAS will attempt to identify active protocols by sending
IP headers with no body and with differing IP protocol
identifiers. This is not what we are seeing however.
The following DoS tools were tested to see if they would generate
packets similar to those we see in the log files. All of these tools
generated packets with different characteristics, with sXe.c and
stresser coming the closest to a match. Except where I have noted, the
malware code generates fragmented or oversized IGMP packets.
- Electronic Souls 0x4453 droid is an IRC bot which has the capability
to do an IGMP flood.
- 7plagues.pl - DoS perl script
- fawx.c - DoS program
- IGMP - Delphi DoS program
- igmpsyn.c - DoS program
- krush.c - DoS program (This one uses random IGMP types, codes and
multicast group addresses, but does specify the correct packet size
and does not use fragmented packets).
- trash2.c - DoS program
- winkod.pl - DoS program
- bomba - Pascal DoS program
- igmpofdeath.c - DoS program
- sXe.c - this code produces a flood of packets that look very similar
to those seen in the log file (if you specify an IGMP code of
100). It is possible that someone has taken the code from this
program and modified it to set the source IP to be equal to the
destination IP and to generate a random multicast group address.
- stresser-0.7.c - this code generates a flood of packets, and will
generate IGMP membership query packets by default.
Again, very thorough, excellent analysis. You've certainly covered all the
bases. If, despite my efforts - you continue to believe that this is an
attack and not a misconfiguration, you might devote some time to explaining
why you believe an attack is more likely.
7. Evidence of Active Targeting
Because we don't see any of the target IP addresses repeated in our
logs, and the way the IP addresses are distributed, this has more of
the smell of a scan rather than a denial of service attack. I am not
sure if the obfuscation of IP addresses is consistent across the log
files, but if it is then this looks like a large scan across multiple
IP blocks, and not a particular attack against our network.
8. Severity
Criticality: 3
It is impossible to assess the criticality of the machines that would
see these packets. Because a large part of the network is being
scanned however, I would have to assume that SOME critical machines
would be hit by these packets. Not to mention the routers, switches,
and other network infrastructure in between the internal network and
the critical machines.
Lethality: 1
There are only a few reports of IGMP packets being harmful to machines
- the most obvious being the large, fragmented IGMP packet attack
against unpatched Windows machines. The packets are neither large or
unfragmented. The DoS against SGI and FreeBSD machines required IGMP
packets but with a very small response delay specified. The DoS attack
described at <http://www.cs.ucsb.edu/~krishna/igmp_dos/>
http://www.cs.ucsb.edu/~krishna/igmp_dos/ could not be
achieved using IGMP membership query packets. Finally the packets do
not have the characteristics of an IGMP flood attack.
System Countermeasures: 5
There are no reports of machines failing when being hit by packets
such as these. Unless the machine is subscribed to the multicast group
being targeted by the packet, it will ignore the packet - and seeing
as how the multicast groups that are passing through our network
perimeter are invalid, the hosts should ignore these packets. In my
testing I could not elecit a response from machines in my test lab
when throwing these packets at them.
Network Countermeasures: 2
In all the log traffic I analyzed from this site I could not find
either fragmented packets or ICMP packets, leading me to believe that
these packets are being blocked. This should stop the Denial of
Service attacks against unpatched Windows machines. It seems to be
possible to be able to DoS older unpatched SGI or FreeBSD machines
using the small response delay attack. It may also be possible to
launch a denial of service attack by submitting a flood of IGMP
packets with the destination address being an internal broadcast
address, and with a spoofed source address of the victim.
Also the fact that IGMP packets are allowed to slide through the
firewall makes them suitable as a covert channel.
Attack Severity = (Criticality + Lethality) -
(System Countermeasures + Network Countermeasures)
= (3 + 1) - (5 + 2)
= -3
10. Multiple Choice Question
Question: The TTL (Time to Live) on an IGMP packet should be initially
set to what number?
A - 255
B - 2
C - 1
D - 0
Answer: C
Wouldn't it be better to know why the TTL is 1 as opposed to making sure
someone memorized a number?
Your analysis is unquestionably impressive. Hopefully you find the criticism
helpful or at least vaguely constructive. Cheers,
Sam Adams
More information about the Intrusions
mailing list