TROOPERS12 came to an end last week on Friday; needless to say it was an awesome event. 😉
The first two days offered workshops on various topics. On Monday Enno, Marc “Van Hauser” Heuse and I gave a one day workshop on “Advanced IPv6 Security”. I think attendees as well as trainers had a real good time during and after the workshop fiddling around with IPv6. Especially Marc had quite some fun as he discovered that we provided “global” IPv6 Connectivity for the conference network, and according to one of his tweets, TROOPERS12 was the first security conference he visited, offering this kind of connectivity.
So back to the topic
In the last post of the series Enno discussed how RA-Guard can be circumvented with clever use of extension headers. As a short reminder, the packet dump looks like this.
As we found out on the Heise IPv6 Kongress last year, this issue can be mitigated with the following parameter in an IPv6 ACL.
deny ipv6 any any undetermined-transport
As a reminder, this parameter drops all IPv6 packets where the upper-layer protocol information cannot be determined.
After the workshop was officially over, Marc and I played a little bit with this ACL Parameter to see if it is working as intended. So I configured the following IPv6 ACL on our beautiful Cisco 4948E:
4948E(config)#ipv6 access-list IPv6
4948E(config-ipv6-acl)#deny ipv6 any any undetermined-transport
4948E(config-ipv6-acl)#permit ipv6 any any
4948E(config-if)#ipv6 traffic-filter IPv6 in
We started the attack again with the following parameter:
Apparently nothing happened with my (IPv6 enabled) laptop (which is a good thing ;))
The corresponding packet dump looked quite unspectacular:
Only the STP packets could be seen, and the flooded router advertisements were dropped by the Switch.
So could this parameter solve the issue with the whole RA mess?
Unfortunately the answer is no. The ACL parameter does mitigate the issue with the fragmented router advertisement. However, the ACL parameter can be circumvented by using overlapping fragments. Unfortunately we couldn’t test this scenario because this wasn’t yet implemented in the THC Tool Suite, but this is just a matter of time…
The IPv6 Packet basically looks like this:
Destination Header (8 bytes)
ICMPv6 with Echo Request
Fragmentation Header with offset == 1 (equals position of 8th byte ==
start of Echo Request in first fragment)
ICMPv6 with RA
In this case it depends on the operating system whether or not the packet is discarded when overlapping fragments are detected. RFC 5722 is very specific on how these should be handled:
“When reassembling an IPv6 datagram, if one or more its constituent fragments is determined to be an overlapping fragment,the entire datagram (and any constituent fragments, including those not yet received) MUST be silently discarded.”
So it is up to the operating system to implement this behavior. We’ll see how things work out 😉
If you’re interested in more IPv6 issues, or simply wanna chat about this topic, meet Enno and me again at the Heise IPv6 Kongress this year in Frankfurt, where we will give a talk on IPv6 as well.
Have great day,