Evasion of Cisco ACLs by (Ab)Using IPv6 – Part 2

When we wrote our initial blogpost regarding the evasion of Cisco ACLs by (Ab)Using IPv6, where we described (known to Cisco) cases of Access Control Lists (ACL) circumvention, we also suggested some mitigation techniques including the blocking of some (if not all) IPv6 Extension Headers.
Almost a month later, we got a comment from Matej Gregr that, even if the ACLs of certain Cisco Switches are configured to block IPv6 Extension headers like Hop-by-Hop or Destination Options headers, this does not actually happen/work as expected. Of course this made us re-visit the lab in the interim ;-).

To have a real-world setup, we decided to perform the tests against a high-end switch, the Cisco 4948E, using a fairly recent image, that is Cisco IOS Version 15.2(3)E, RELEASE SOFTWARE (fc4). We applied the ACL configuration to the VLAN, to physical ports, as well as their combination.

We tested this ACL:

   deny hbh any any sequence 10
   deny 60 any any sequence 20
   deny 43 any any sequence 21
   deny 44 any any sequence 22
   deny tcp any any eq 22 sequence 28
   permit ipv6 any any sequence 30

As you can see, in the above ACL we configure to block the Hop-by-Hop header, the Destination Options header, the Routing header, the Fragment header, as well as TCP port 22 (usually used for SSH…).

For all tests we used Chiron, a tool that allows (among else) the construction of completely arbitrary IPv6 header chains.

In a nutshell, the results for all cases are the following:

• Hop-by-Hop Headers are blocked in any case, as they should be (the device responds with an ‘ ICMPv6 Destination unreachable, Communication with destination administratively prohibited‘ message).
• All the other IPv6 Extension headers which should be blocked according to the above ACL, including the Type-0 Routing header (which should be deprecated as of RFC 5095 anyway), are NOT blocked as long as:
  • the corresponding packet is not fragmented,
  • or if it is fragmented, the tested Extension header is included in the unfragmentable part of the fragment. When it is in the fragmentable part, the fragment is blocked.

Still, despite the above issues, we were not able to reach a prohibited port (SSH in our example) exactly because the IPv6 Extension headers cannot be in the fragmentable part of the packets.

Evidently, once we remove one of the Extension headers from the ACL (e.g. the Destination Options one), we can reach the otherwise blocked port (SSH in our example) by adding this allowed IPv6 Extension header to the chain and fragmenting the packet (so as the layer-4 header is moved to the second fragment). But, again, this is a known issue, isn’t it? For instance, let’s use the following ACL:

   deny hbh any any sequence 10
   deny 43 any any sequence 21
   deny 44 any any sequence 22
   deny tcp any any eq 22 sequence 28
   permit ipv6 any any sequence 30

In such a case, we can evade the ACL by “exploiting” the Destination Options header in order to reach TCP port 22. To do so, in our tests we used the Chiron proxy running the following command:

./chiron_proxy.py enp7s0 127.0.0.1 127.0.0.3 -d 2001:db8:c001:cafe::4 -luE 60  -lfE 60 -nf 2

where 2001:db8:c001:cafe::4 was our target.

Detailed explanation about the above Chiron command and how it works can be found at the accompanied to Chiron documentation. Briefly, in our example Chiron accepts IPv4 connections to 127.0.0.3 (localhost address), extracts the IPv4 header, adds an IPv6 one (adding also two Extension Headers and fragmenting it) and sends the packet(s) to the IPv6 target, and vice versa.

Then, we performed an SSH connection to the target simply by:

ssh root@127.0.0.3.

We also tested another, earlier release (Cisco IOS Software Version 15.2(1)E1, RELEASE SOFTWARE (fc2)). In this case the situation was even worse, that means:

1. The Hop-by-Hop header was not blocked.
2. Prohibited (by ACL) Extension headers could also be included in the fragmentable part of the packets.

Now, as it was mentioned, the ACL evasion (as well as the RA Guard and the DHCPv6 evasions) by adding an IPv6 Extension header and fragmenting the packet so as the layer-4 header is not in the first fragment is a known issue. To address it Cisco has introduced the “undetermined-transport” keyword to block traffic in case the layer-4 header is not in the first fragment and hence cannot be determined. However, this feature is not available on all devices/images. Still, since it is supported on the device used here, we also applied it to our ACL:

   deny hbh any any sequence 10
   deny 43 any any sequence 21
   deny 44 any any sequence 22
   deny tcp any any eq 22 sequence 28
   deny ipv6 any any log-input undetermined-transport sequence 29
   permit ipv6 any any sequence 30

The result? Not only the denied traffic was blocked, but actually ALL the traffic, including the legitimate one, was also blocked (similar to what we had observed here). We could not even ping the switch itself (which, before, was reachable of course). Is this a bug or did we miss something during the configuration? Well, even if it is the second case, we wonder what tricks a network admin should do in order to protect her network from IPv6 Extension Header based evasion tricks.

Summary

Using fairly recent Cisco IOS releases on an enterprise device, only Hop-by-Hop Extension headers are blocked effectively by the ACLs. Other Extension headers are blocked only when they are included in the fragmentable part of fragments; otherwise they pass unaffected despite “contradictory” ACLs. Still, this apparent malfunction (?) cannot be exploited easily for reaching e.g. TCP ports blocked by the ACL.

Moreover, using “undetermined-transport”  as recommended by Cisco for defending the network from such attacks does not always work as expected; it may block legitimate traffic. So things can even get worse, from an operational perspective.

We have some more results from the Cisco lab and we’ve started to perform similar tests against HP devices. Stay tuned…

Best

Enno