Cisco CVE-2016-1287 Network Vulnerability and our Mitigation Solution

CISCO CVE-2016-1287 VULNERABILITY PROBLEM

Yesterday Cisco released an out of band patch for an ASA vulnerability (CVE-2016-1287) that permits remote code execution for any ASA device enabled for IKE / IPSec.
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike

You can validate if your configuration is affected using the following command:

show run crypto map | include interface

The Cisco advisory indicates that there is no way to mitigate this threat. There are a large number of vulnerable ASA firmware versions that have not and will not receive fixes. Customers should be aware of the difficulty in migrating from 8.2 to newer versions because of the complete restructuring of NAT rules.

The ISC has noticed a substantial increase in scans for the devices running IKE.
https://isc.sans.edu/forums/diary/Critical+Cisco+ASA+IKEv2v2+Vulnerability+Active+Scanning+Detected/20719/

The discoverer of this vulnerability has published an extensive write-up that includes detailed information on memory offsets and what appears to be almost all the details required to develop a complete attack.
https://blog.exodusintel.com/2016/01/26/firewall-hacking/

Based on the gravity of this situation we recommend that customers immediately upgrade affected Internet facing ASAs that are vulnerable to this issue.

OUR CISCO CVE-2016-1287 VULNERABILITY MITIGATION SOLUTION

We have developed a workaround that will help address this issue while you work on upgrading your devices. You can only use this approach if you are not using dynamic crypto maps (typically used for remote access VPN using the legacy Cisco VPN Client).

The mitigation uses control-plane ACLs to limit permitted IKE peers. We have tested the ACL and confirm that it blocks IKE traffic for non-permitted peers.

STEP 1

First you create an object group defining your know and permitted IKE peers. These are the IP addresses defined in your crypto maps.

object-group network permitted-ike-peers
network-object host 1.1.1.1

STEP 2

Then you create an access list that permits these peers to perform IKE, denies all other IKE connections and finally permits all other traffic.

access-list ike-filter extended permit udp object-group permitted-ike-peers any eq isakmp
access-list ike-filter extended permit udp object-group permitted-ike-peers any eq 4500
access-list ike-filter extended deny udp any any eq isakmp
access-list ike-filter extended deny udp any any eq 4500
access-list ike-filter extended permit ip any any

STEP 3 

Finally, you apply this ACL to the control plane on your outside or other exposed interfaces. This should be all the untrusted interfaces referenced in the show run crypto map | include interface command.

access-group ike-filter in interface outside control-plane

While this example ACL only limits IKE it would be an excellent idea to more completely secure non-required protocols on the ASAs exposed interfaces. This is a more complex change however and the goal of this approach is immediate mitigation.

An adversary who knows a permitted IKE peer IP address can probably spoof a packet and exploit the vulnerability. Cisco TAC has confirmed that this approach should work in theory however there may be other elements of the vulnerability that we are not privy too. Until there is public exploit code available (which may not take that long) we cannot completely test this. We believe that it should substantially increase the difficulty of exploiting the vulnerability.

If you’re interested in this solution or our managed firewall services we’d be please to help you, please contact our sales team.

Special thanks to Codey Oxley for suggesting ASA Control Plane ACLs as a potential method of remediating this vulnerability.