Tuesday 5 April 2016

Considerations For Patching The Cisco ASA Vulnerability


A critical vulnerability in the Internet Key Exchange (IKE) code used in Cisco Adaptive Security Appliances (ASA) that could allow an attacker to remotely execute code was discovered earlier this year. There are no workarounds to this vulnerability, but Cisco has released a patch. Here are a few points to consider when applying this important patch.

About the Cisco ASA Vulnerability


The Cisco ASA IKE buffer overflow is a critical vulnerability that requires a proactive response. Since this vulnerability affects network perimeter defense mechanisms and could allow an intruder to execute arbitrary code and obtain full control of an affected system, I urge professionals to take a close look at possible Cisco ASA remediation actions.

In general, most people think of installing the vendor’s patch as a first resort. While this is advisable, it may not always be feasible. Sometimes the patch is not yet available; in some cases, it can take a vendor days or weeks to issue a patch. Even when the patch is available, some systems might not be able to accommodate it due to limited resources (e.g., memory, processing or HDD space) or other constraints. For example, Cisco ASA appliances may require memory upgrades before installing the patch.

In instances where a patch is not available or cannot be installed, there are other approaches to remediation — such as secondary control patching or configuration setting modification — that organizations may consider.

Let’s take a look at the most common mitigation approaches, starting with the vendor patch.

Installing the Vendor Patch


When possible, a vendor’s patch should be installed on the affected systems to mitigate the vulnerability. But this requires some due diligence before applying the patch; carefully review the requirements and prerequisites for successful patching below.

   
  • Patch Analysis: Have you reviewed the requirements and prerequisites for the patch? (For example, does the device have enough memory to support the patch?)
  • Change Management: Do you have a change record? It is useful to review the recent configuration settings on the firewall before installing patches.
  • Patch Testing: Have you tested the patch before deploying it to production servers? In a testing environment, perform the following activities:
Use a vulnerability scanner or Nessus Scanner (Plugin ID: 88713) to identify whether the system is vulnerable. 
Validate that patches were installed properly by reviewing patch logs.
Use a testing kit such as Core Impact to confirm whether the patch effectively mitigated the vulnerability.
Disaster Recovery and Business Continuity: What if the device fails during the patch installation? Is there a firewall backup in case a rollback is required? Are the ASAs deployed in a high-availability design to keep the network and business running during the patching?

Deployment Time Frame


If you are patching many ASA firewalls, it might take some time. If you are unable to patch all your firewalls at once, or if a vendor patch is not yet available, consider one of the below options to help protect your network while the process is completed.

Even before a vendor’s patch is available, many intrusion prevention system (IPS) vendors update their IPS signatures to detect and block zero-day exploits and particular vulnerabilities. This mechanism has been used in IBM for more than a decade and is known as virtual patch technology.

Virtual patching can provide an additional layer of protection in front of affected Cisco ASA firewalls and help ensure exploits targeting firewalls are detected and blocked before impact. Many vendors released IPS definitions for the ASA IKE vulnerability:

  • IBM X-Force has published XPU 36.021 for the Cisco ASA Software IKEv1 and IKEv2 buffer overflow vulnerability. The signature is: ISAKMP_CiscoASA_Fragmentation_Overflow.
  • Cisco has an IPS signature 7169-0 and Snort ID: 36903 for this vulnerability.

Configuration Settings Modifications


When a vendor’s patch is not available, configuration changes can be useful and effective — if used properly. For example, disabling the affected service (e.g., IKE),will result in losing the virtual private network (VPN) capability from this firewall. But in return, you have reduced the likelihood of someone exploiting the vulnerability.

Disabling IKEv1 and IKEv2 will limit the exposure until the patch is deployed. Disable them using the following commands:
  •     no crypto ikev1 enable; and
  •     no crypto ikev2 enable.
If the VPN service is mandatory, you could add an access control list on the Internet-facing interfaces to block UDP 4500/500 from all except selected trusted ASA peers. This will ensure that incoming IKE transactions are only accepted from trusted sources.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.