In the recent post on the IPv6 properties of the latest MS Windows versions I announced another one providing details on the RFC 6980 related testing I had performed. So here we go.
When doing IPv6 security testing there’s mainly four toolkits which can be used:
- Antonios Atlasis‘ Chiron
- Marc Heuse’s THC-IPV6
- Fernando Gont‘s IPv6 Toolkit
- Scapy (whose IPv6 capabilities are, afaik, mainly maintained by Guillaume Valadon. some tutorial on IPv6 packet crafting with scapy can be found here).
Each of them has specific strenghts & limits, which will not be discussed here. For the testing I performed I chose Chiron as it has the most powerful options when it comes to IPv6 extension headers and fragmentation.
The lab setup was quite simple:
- the Windows (Server 2016) system (looked at in the other post) is the victim.
- the attacking system is Linux-based, equipped with Chiron.
- both are connected by a simple Cisco 2960 L2 switch (initially running “C2960S Software (C2960S-UNIVERSALK9-M), Version 15.0(2)SE2, RELEASE SOFTWARE (fc1))“; for a second round of testing I used “(C2960S-UNIVERSALK9-M), Version 15.0(2)SE10a, RELEASE SOFTWARE (fc3)” which is from October 2016).
- there is a “legitimate” router sending periodic (every ~10 sec) IPv6 router advertisements with a PIO option incl. A-flag.
Now the main question of the exercise was: can the attacker manage to influence the IPv6 configuration of the victim (read: ideally inject a new/additional default route and/or trigger the generation of an IPv6 address from the attacker-chosen prefix).
The testing was split into two main phases:
- without RA Guard being enabled on the switch to check which variants are processed at all by the Windows system.
- after that I enabled RA Guard and repeated (only) the “successful“ variants from the first phase to see if any of those still made it through. In addition I used “debug ipv6 snooping raguard” on the device to monitor the detection/blocking capabilities.
The following Chiron command constitutes the “baseline” attack (a full tutorial of Chiron can be found here):
chiron_local_link.py eth0 -ra -pr 2001 1:db8:10:50:: -pr-length 64 -mtu 1400 -s fe80::3aea:a7ff:fe85:c926
The following table lists the results. A quick comment as for the “Wireshark“ column: I did not further investigate at which point the “missing” packets were actually dropped (e.g. by means of a monitor session on outbound packets on specific switch ports). Further it should be noted I performed many more tests than the ones shown here. The table only lists those variants which were, from my perspective, the most relevant/interesting ones.
We can summarize:
- As long as no fragmentation is involved the target OS processes the RAs (but those are blocked by the switch when RA Guard is enabled on the attacker’s port).
- Once the RAs get fragmented, most variants are no longer processed by the target OS.
- Specific combinations of EHs still make the attack successful, when put into the fragmentable part (=> 2nd fragment).
- This even works when somewhat dubious EH combinations (like two RoutingHdrs) are in the fragmentable part.
- RA Guard blocks most of attack variants which were successful against the target OS, but some specific variants are still able to circumvent it.
- It seems the fragmentable part is the (from the attacker’s point of view) most promising place to carry the ICMPv6 payload (probably as most RFC 6980 or RA Guard implementations “do not expect” any extension headers [except for the frag hdr, of course] in the 2nd or later fragments and hence fail to properly recognize the subsequent ICMPv6 part).
- Different RA Guard implementations might differ when it comes to their capabilities and effectiveness.
- From an attacker’s perspective – as always – tenacity and creativity might be helpful…
I hope this post sheds some light onto the specific protection capabilities of MS Server 2016/Windows 10 against RA-related attacks and shows how to test these aspects in general. I will include some of the results & conclusions in my upcoming talk at Troopers NGI.
Everybody have a great weekend
Enno