[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect Bre tt Hutley

[Brett Hutley]

Hi Sam,
Thanks for the response.

(I've edited the response a bit to make it easier to read).

On Thu, Sep 02, 2004 at 03:34:08PM -0000, Adams, Samuel (contractor) wrote:
> Some questions/comments below....
> 
>> I first started examining the libpcap formatted files using my own
>> tool, TrackAttack (  <http://www.trackattack.org/>

*snip*

> 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.

It's still pretty much a work in progress. I'm hoping to get better
documentation up over the next 2 weeks or so, but it's still evolving
quite quickly because I'm using it to complete the practical.

> 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?

Yes, good point. I omitted it here because the other people who
have analyzed this traffic did an excellent job on researching the
Mac address layer. We can identify these mac addresses as having
been added by Cisco devices by looking up the vendor code at the
ieee: http://standards.ieee.org/regauth/oui/oui.txt. If we do a 

'( for f in *.log; do tcpdump -n -e -r $f; done ) | \
  cut -d ' ' -f 2,4 | sort | uniq' 

this is the output we get:

00:00:0c:04:b2:33 00:03:e3:d9:26:c0,
00:03:e3:d9:26:c0 00:00:0c:04:b2:33,
00:03:e3:d9:26:c0 00:00:c0:6b:e9:c6,
  
This indicates there is bidirectional flow from the devices
in question:

00:00:0c:04:b2:33 > 00:03:e3:d9:26:c0
00:03:e3:d9:26:c0 > 00:00:c0:6b:e9:c6,

So it would appear our sensor lies between these two devices,
probably Cisco routers. 

*snip*
>> 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. 

Yes, it probably should be clearer. In IGMP version 1, the second
byte along in the IGMP packet was unused and the specification
required this to be zero in IGMP query messages. In IGMP version 2
it became the maximum response timeout field.
The specification also says that IGMPv2 hosts should treat any
IGMPv1 query they get (ie the 2nd byte is zero) as having a maximum
response time of 10 seconds (ie assume the byte is 100).

>> 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. 

Yes, I complete agree! This is what made the traffic so difficult
to interpret. It seemed to me to be a mistake, either by some network
device misfiring and spewing black IGMP packets over the place, or
by a coder getting a bit of code wrong. To me, an IGMP-enabled
device that could go so disasterously wrong in so many ways (IP ID
of zero, src ip = dst ip, TTL > 1, invalid multicast group, and the
sheer ip address range, timing, and duration of the packets) seemed
more unlikely than someone making a mistake with a piece of malware.
I could however be completely wrong :)

*snip*
> 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? 

Yes, undoubtedly. I don't think that an attacker would have achieved
anything by this other than confusing the hell out of analysts!
Actually, my suspicion is that this traffic was generated by one
of the SANS examiners who is rolling around laughing at this very
moment :)

*more analysis snipped*
>> - 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.

I'm not really a router expert and am perfectly happy to conceed
to wiser heads on this. However I would imagine that there is not
much configuration you can do to a router at the IGMP level? The
specification seems to define how the packets look and behave and
so the main configuration options seem to me to be whether the
router should route them or not. That's why I don't think this is
caused by a human misconfiguring a router. As far as a router itself
going haywire and corrupting it's own packets - I wouldn't think
it would happen in such a way as to affect the packet so precisely!
The fact that 4 fields in the packet are out-of-spec, combined with
direction, frequency and duration of the packets would indicate to
me that some evil agency is at work - probably stroking a white cat
:)

> 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,

Thanks agin for the response! It's great to get some feedback.
Cheers, Brett
-- 
Brett Hutley [MAppFin,CISSP,SANS GCIH]
mailto:brett at hutley.net
http://hutley.net/brett