This weekend Cisco released a high severity Security Advisory confirming a vulnerability in its implementation of the IKEv1 protocol in products running Cisco’s IOS, IOS-XE and IOS-XR software.
Read Cisco’s Security Advisory Here
The above vulnerability allows a remote attacker to craft a IKEv1 packet to an affected device configured to accept IKEv1 security negotiation requests. A successful exploit could allow the attacker to retrieve memory contents, which could lead to the disclosure of confidential information.
Does this advisory affect me?
IKEv1 is part of the IPsec security suite and is used to negotiate cryptographic algorithm, mode, and shared keys between two IPsec devices. The end result of IKE is a shared session secret that will be used to derive cryptographic keys.
A number of features use IKEv1, including different Virtual Private Networks (VPN) such as:
- LAN-to-LAN VPN
- Remote access VPN (excluding SSLVPN)
- Dynamic Multipoint VPN (DMVPN)
- Group Domain of Interpretation (GDOI)
If you currently have IPsec VPN tunnels terminating on Cisco ISR (Integrated Services Routers) Generation 1, 2 or 3 routers (reference table below) then you should read on. It should be noted that the Cisco ASA Firewall product line is NOT affected by this vulnerability.
How do I confirm that my Routers are affected?
First we need to confirm that your router is configured to use IKE. We can determine this by looking at what ports your router is listening on.
IKE uses UDP ports 500 and 4500, and we can see this by pasting the below command into the router cli:
show udp | include 500|4500
The screenshot below shows a router which is indeed configured for IKE and thus has udp ports 500 and 4500 open for both IPv4 and IPv6 traffic.
Display IKEv1/2 Listening ports: (No output from the below command confirms that this device is NOT vulnerable) 
Next we need to confirm which version of IKE we have configured. IKEv1 is the predecessor to IKEv2 which was standardized in RFC 5996 back in September 2010. It should be noted that although IKEv2 is NOT susceptible to this vulnerability, Cisco devices configured for IKEv2 will still process IKEv1 packets and are thus still affected by this vulnerability.
To determine if our VPN is using IKEv1 we can paste the below command into the router cli:
show crypto isakmp sa
The screenshot below confirms that this router has a single IKEv1 SA (security association) and will need to be remediated.
Display IKEv1 Sessions: (No output from the below command confirms that no IKEv1 sessions are currently active) 
We can also check for active IKEv2 security associations using the below command:
show crypto ikev2 sa
The below output shows a router with a single IKEv2 SA. Routers that have IKEv2 SA’s still require remediation.
Display IKEv2 Sessions: (No output from the below command confirms that no IKEv2 sessions are currently active) 
My Routers configured for IKE, what should I do?
As of the writing of this blog post there have been no Cisco provided workaround’s for this issue, although they are currently working on releasing a software patch. You Should check the Security Advisory webpage regularly for updates.
Check Cisco’s Security Advisory Webpage Here
Here at LookingPoint we are recommending customers affected by this threat to limit their exposer by allowing only trusted IP addresses to negotiate IKE with their routers (see mitigation steps below), while working toward the ultimate resolution of patching their affected software as and when Cisco makes them it available.
Mitigation Steps.
Exposure to this threat can be limited by only allowing trusted public IP address to negotiate IKE with your routers.
To achieve this, you can create an access list similar to the one below and applying it to the interface that terminates your IPsec sessions.
As mentioned above the long term solution to this threat is to patch your routers. We also recommend taking this opportunity to migrate your VPN configurations to the newer IKEv2 protocol which offers increased security and performance.
Contact Us For More Information
Written By: Chris Marshall, Senior Solutions Architect for LookingPoint, Inc.