On February 10, 2016, Cisco publicly acknowledged CVE-2016-1287 – a CVSS 10.0 rated vulnerability in their ASA line of products. ASA devices are often generically referred to as firewalls, but they are also often used for terminating Virtual Private Network (VPN) connections (the important part of this disclosure), and less often utilized for network anti-virus and intrusion prevention. The topic of this post highlights an issue that exists in Cisco’s implementation of the Internet Key Exchange (IKE) protocol (versions 1 and 2), which is used to negotiate the security settings of the IPSec protocol stack, and most importantly, IPSec VPN connections. While this vulnerability doesn’t exactly fit the criteria that many would consider “high profile” in the same way that the vendor agnostic Heartbleed and Shellshock disclosures were, it is still worthy of significant attention. According to this Shodan report, there are currently over 5.8 million devices on the Internet with the IKE protocol available. Granted, not all 5.8 million of those devices are ASA devices, but given Cisco’s popularity in the market, even a conservative 20%+ market share would be north of a million affected devices. Combine that with the general latency associated with patching infrastructure equipment, and odds are unfortunately in favor of the nefarious.


There are two functions within the algorithm that ASA devices use to reassemble fragmented IKE payloads that chiefly contribute to this vulnerability. One is responsible for parsing the fragment and maintaining the fragment reassembly queues, and the other monitors the reassembly queues and handles the actual reassembly of the fragments once all of the fragments have arrived. The problem begins with the function that is responsible for maintaining the fragment reassembly queues. There are three primary logical issues that make this code vulnerable:

  1. The calculation that is performed to make sure that the size of an incoming fragment is acceptable checks for a maximum value, but not a minimum value;
  2. The code assumes that the fragment is at least as large as the header (8 bytes); and
  3. The length of the header is subtracted from the length of the fragment before the queue size is updated.

With no minimum value and the assumption that all fragments are at least as large as the header, an attacker can use a tool like Scapy to craft a packet with a fragment that is smaller than 8 bytes (the size of the header). When we move to step three where the length of the header (8) is subtracted from the size of the fragment (< 8), we end up in negative memory space, causing a Denial-of-Service (DoS) condition.

David Barksdale, Jordan Gruskovnjak, and Alex Wheeler of Exodus Intelligence discovered this vulnerability and are credited with disclosing it to Cisco. In addition to this, they have also posted an excellent technical explanation of their research as well as a proof-of-concept explanation of the methodology they used to achieve remote code execution.


Ultimately, exploitation will either result in remote control of the affected system or Denial-of-Service. Depending on how authentication is handled (local versus RADIUS/TACACS, etc.), credential reuse, network segmentation, and many other potential factors, a skilled attacker could eventually leverage control over the device into control over the environment in a worst-case scenario. If cryptographic key information can be discovered, capturing and decrypting traffic flowing through these devices is also a possible risk.


According to Cisco’s advisory, ASA administrators can run the following command on their devices to test their configuration for the vulnerability:

# show running-config crypto map | include interface

Should the device be configured to terminate IKE VPN connections (i.e. vulnerable), a crypto map will be present for at least one interface.

Monitoring for and detection of attempted exploits will likely require very flexible monitoring tools or a subscription service with aggressive signature SLA’s. Packet inspection needs be configured on a device that captures inbound traffic to the ASA device and flags any inbound packets in the IKE protocol that have a value of less than eight (8) in the length field of a fragmented (type 132) packet. Detection is further complicated by the need to consider that multiple fragmented payloads could potentially be linked inside of a single IKEv2 packet and therefore also that the payload may not be the only, or even the first, payload in the packet.


Currently, there are no workarounds for this issue. Cisco has issued a patch and an advisory with information on what versions of the ASA software are affected. Additional information and a link to the relevant patch can be found in Cisco’s advisory.

Summary Opinion

Shortly after this vulnerability was announced, HD Moore (perhaps jokingly) tweeted that he was ordering an ASA. Rest assured, despite the current lack of a publicly available exploit at the time of this writing, it is likely coming in the near future. The Internet Storm Center detected a significant spike in scanning for the IKE protocol across the Internet following the announcement. If you have ASA devices exposed to the Internet, and they are being used to facilitate VPN connections with the IKE protocol, you need to deploy this patch yesterday. VPN and firewall devices are the entryway to protected environments, and the risks associated with this vulnerability extend far beyond the device itself.

As a penetration-testing consultant, I’ve seen many different environments in a variety of sizes and configurations. I’ve seen large companies with seemingly limitless budgets continue to maintain end-of-life systems in a flat network with vulnerabilities that are nearly a decade old. Conversely, I’ve seen smaller organizations without dedicated security personnel lock down a network to the point that all systems are patched within 48 hours of release. However, one thing that is still unfortunately very common, despite the current landscape of the industry, is that many organizations still do not regularly check for and apply security patches for applications and devices, such as web platforms, virtualization tools, networking infrastructure, and storage solutions. These, and any other third-party applications in use, whether on a server or an endpoint, should be included in any vulnerability and/or patch management program that aspires to be truly effective. Furthermore, evaluating the environment for missing patches and vulnerabilities should not be an activity that only occurs when a significant vulnerability disclosure (such as this one) triggers widespread panic. Regular vulnerability scanning and metric reporting should be a minimum requirement for any organization that claims to take security seriously.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, and with offices in Georgia, Massachusetts, Michigan, Minnesota, Missouri, Florida, Texas, and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: