[ipv6hackers] Windows 7/2008 R2 Improved Resilliency to IPv6 Floods
jim.small at cdw.com
Sun Apr 14 03:29:41 CEST 2013
> On 12.04.2013 08:45, Jim Small wrote:
> > Your tools are better than you think! With some advice from Sam Bowne I
> can consistently crash Windows 8 using fake_router6 and flood_router26 -
> takes less than a minute. However, I can't crash Windows 7 with KB2750841.
> So it would seem there is some missing functionality on Windows 8/2012 as
> compared to 7/2008 R2 with KB2750841.
> > RA Guard on some switches does seem to protect against this - even with
> using fragmentation and/or HBH tricks. However, with Fernando's ra6 tool I
> can create wicked packets that still crash Windows 8 with RA Guard.
> However, with a switch that can block fragments and/or undetermined
> transport packets (ULP not in first fragment) I can defend against these
> attacks. It is some work though and there could be unintended side effects.
> Hopefully the drafts Fernando is pushing will eventually make it through the
> IETF and close the loopholes.
> I think everybody - including me - is interested what you are doing
> exactly :-)
> how do you crash windows 8 with fake_router6 and flood_router26?
At first I was using a VM, but that proved problematic so I started using a laptop (bare metal/no hypervisor). I can run flood_router26 by itself and:
* With a new laptop (fast quad core i7) running Ubuntu 12.10 it can push up to 120,000 RA packets/second on a Gigabit interface - one thing I have noticed using this compared with a VM, a faster more powerful attacking device is far more effective
* Typically crash a new Windows 8 laptop in 10-30 seconds
* Windows 7 is unusable while flood_router26 is running but quickly recovers after (with KB2750841)
* Windows Vista bogs down and then forever runs at 100% CPU until you reboot it. It's unusable during the flood and usually becomes partially usable sometime after it ends. However, it remains bogged down and somewhat unresponsive. Sometimes it appears to crash too but not consistently.
If I use a Cisco 3k switch (E/X/C-series) running 15.0(2)SE with RA Guard and run flood_router26 again (no options):
* No effect on any of the laptops - RA Guard protects them
Repeat test, this time with flood_router26 -H eth0:
* Again, no effect, RA Guard works (but this trick does work on some platforms so good to test)
Repeat test, this time with flood_router26 -D eth0:
* This is a good example of where I run into problems with Wireshark. When I SPAN the switchport to see what’s coming in, here’s how it’s parsed in Wireshark (showing in text):
Frame 4: 1302 bytes on wire (10416 bits), 1302 bytes captured (10416 bits)
Internet Protocol Version 6, Src: fe80::76:a3c6:7636:3901 (fe80::76:a3c6:7636:3901), Dst: ff02::1 (ff02::1)
0110 .... = Version: 6
[0110 .... = This field makes the filter "ip.version == 6" possible: 6]
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
.... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
.... .... ...0 .... .... .... .... .... = ECN-CE: Not set
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 1248
Next header: IPv6 fragment (44)
Hop limit: 255
Source: fe80::76:a3c6:7636:3901 (fe80::76:a3c6:7636:3901)
Destination: ff02::1 (ff02::1)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Next header: IPv6 destination option (60)
Reserved octet: 0x0000
0000 0000 0000 0... = Offset: 0 (0x0000)
.... .... .... .00. = Reserved bits: 0 (0x0000)
.... .... .... ...1 = More Fragment: Yes
Next header: ICMPv6 (58)
Length: 188 (1512 bytes)
IPv6 Option (Pad1)
Type: Pad1 (0)
IPv6 Option (Pad1)
Type: Pad1 (0)
(Followed by insane amount of IPv6 Option (Pad1)s...)
[Malformed Packet: IPv6]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Message: Malformed Packet (Exception occurred)]
[Severity level: Error]
So perhaps too many options for the Wireshark parser and it chokes? I can look at the frame hex dump or use tcpdump and that works fine.
* In any case, back to the main story - with -D option it:
* With this option, some of the traffic gets by RA Guard, however, it's not enough to cause serious harm to any of the hosts:
* Windows 7 has a modest CPU hit (15% on my test laptop) but you can't really tell the difference
* Windows 8 shows some CPU hit (25% on my test laptop) but is still very usable
* Windows Vista does worse with the CPU pegged but is still usable, and when the attack stops it sometimes recovers
Repeat test, this time with flood_router26 -FFFDDH eth0:
* Similar results
* I know on my VM for some of the tests I had to "prime" the system with fake_router6. I can't tell you why - I got this advice from Sam Bowne (samsclass.info) and it did seem to help.
On another side note - I believe the RFC 2460 limits the HBH EH to one, the DO to two, but even this is a should - seems like it's a practical limit too though. However, is there any limit to the number of other EH headers like fragmentation you can stuff into an IPv6 packet?
So with RA Guard still enabled and with Fernando's ra6 I can make more wicked packets but today I couldn't replicate what I did a few days ago - I even saved the history but this time it didn't work. So I could torture the machines but they didn't crash. Maybe there's a sequence or certain conditions to crash the systems?
* However, it still completely breaks IPv6 configuration so that's obviously bad.
* That sucks I can't figure out how to replicate what I did a few days ago. :-(
All the above attacks can be blocked though by either:
* Block IPv6 fragments (if supported by the hardware)
* Block fragments with an unknown Upper Layer Protocol (if supported by the hardware)
See Enno's blog for a good discussion of this here:
> And how do you use Fernando's ra6 tool to bypass RA guard on some
> switches and crash windows 8 with it?
I couldn't get it to work again today. If I figure out a reliable way to do this with RA Guard on I'll post it.
> btw. at my IPv6 hacking training a few days at hack in the box
> amsterdam, we were able crash the whole conference network (not just the
> part we were in) four times - with different issues each time.
> I do not know what it were each time, once it triggered a kernel bug in
> linux in point to point links, another time it was crashing Arbor' over
> its intrusion detection engine as the neighbor table grew and grew.
> everything is oh so IPv6 ready ...
LOL - took out the network eh! I will say it's gotten much better over the past couple of years. At the current rate of adoption and improvement things should be pretty bulletproof in another year or two...I hope!
More information about the Ipv6hackers