Hello to the list and RA guard evasion technique

[Eric Vyncke (evyncke)]

Hello Marc,

It was nice to meet you a couple of weeks ago and indeed the 'undetermined-transport' should block the first iteration of your attack (as this keyword blocks all packets which are 1st fragment and where there is no layer-4 header). So, I was happy to have a workaround for you :-)

But, you obviously have found a work-around around the work-around: overlapping fragments. Especially if hosts accept it... (which is weird BTW but what can we do?). The theoretical mitigation would force re-assembly in the switch which could lead to a DoS which could be worse as it breaks other layer-2 broadcast domains. The standard mitigation is SEND of course in all hosts which is not possible right now (BTW, I keep hearing rumors that MSFT could do it eventually!). The only practical one is very short layer-2 broadcast domains such as private VLAN or no client-client communication via AP (which of course has its own challenges).

Have a nice Sunday

-éric


> -----Original Message-----
> From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops-
> bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Marc Heuse
> Sent: dimanche 29 mai 2011 11:40
> To: ipv6-ops at lists.cluenet.de
> Subject: Hello to the list and RA guard evasion technique
> 
> Hi guys,
> 
> as Fernando Gont, Eric Vyncke and quite some more clever IPv6 heads are
> on this list, I subscribed and will join the (security) discussions.
> 
> I am the author of the thc-ipv6 toolkit and have so far done quite some
> ipv6 security/vulnerability research. The newest issue I published is
> bypassing the RA Guard security features on Cisco switches.
> 
> Note that this technique also bypasses the following configuration Eric
> recommended for switches that have layer 3 ACL capabilities but do not
> support RA guard:
>     deny icmp any any router-advertisement
>     permit any any
> 
> And it also bypasses NDPmon/RAfixd/RAmond.
> 
> 
> Attack:
> =======
> Make the evil Router Advertisement fragmented and put the ICMPv6 into
> the second fragment, eg. by putting a very large Destination extension
> header before the ICMPv6 part.
> 
> So the packets look like:
> 
> Fragment 1:
>  IPv6 Header
>  Fragmentation Header
>  Destination Header (~1400 bytes)
> 
> Fragment 2:
>  IPv6 Header
>  Fragmentation Header
>  Destination Header (continued with some bytes)
>  ICMPv6 with RA
> 
> 
> Workaround:
> ===========
> To prevent this attack, put the following IPv6 ACL on all ports:
> 
>     deny ip any any undetermined-transport
> 
> This will drop all packets where the switch is not able to identify the
> IPv6 transport type like in this attack. Note that this might drop some
> unusual valid traffic too.
> 
> 
> Workaround Bypass:
> ==================
> Craft the packets in a way so that the first fragment has an ICMPv6 echo
> request and the second fragment overwrites the first fragment with the
> ICMPv6 router advertisement.
> 
> Fragment 1:
>  IPv6 Header
>  Fragmentation Header
>  Destination Header (8 bytes)
>  ICMPv6 with Echo Request
> 
> Fragment 2:
>  IPv6 Header
>  Fragmentation Header with offset == 1 (equals position of 8th byte ==
> start of Echo Request in first fragment)
>  ICMPv6 with RA
> 
> Note that the handling of overlapping fragments differs between
> platforms, some take the first fragment received, others the latest, so
> send the packets accordingly to your target.
> 
> 
> Other implementations
> =====================
> Works on all implementations so far I tested, on some e.g. NDPmon it is
> way simpler, you have have to add an empty hop-by-hop header and it goes
> blind for NDP and RA attacks.
> 
> 
> Basically, if just want to prevent accidental RA's on the network, then
> all the tools and mechanisms are fine.
> But if you want to prevent attacks, the only secure way is packet
> reassembling/verification in the switches - and that is not a good idea
> for performance and availability reasons (RAM, CPU, ...).
> 
> Greets,
> Marc
> 
> --
> Marc Heuse
> Mobile: +49 177 9611560
> Fax: +49 30 37309726
> www.mh-sec.de
> 
> Marc Heuse - IT-Security Consulting
> 
> Ust.-Ident.-Nr.: DE244222388
> PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A