Cisco SIP inspection based DoS attack

Foreword:


At the end of Oct, Cisco announced a vulnerability in its ASA OS and Firepower FTP running products.

The vulnerability is based on the SIP inspection code that handles SIP signaling packets.

The vulnerability:


The FW do inspection on protocols for various reasons, NAT fixup, added security, discovery of dynamic port connections and allowing traffic to pass via the firewall etc. The SIP inspection is part of the default Global Inspection Policy that is enabled on the device, meaning all firewalls with default configuration for inspection are affected.

A bombardment of a high-rate specifically crafted SIP requests can impact the firewall (high CPU load) and cause legitimate traffic to cease hence causing a Denial of Service.

There is currently no software updates from Cisco to address this vulnerability. All mitigation options are based on additional configuration and listed below

Affected Products:


  • Vulnerable Products

This vulnerability affects Cisco ASA Software Release 9.4 and later and Cisco FTD Software Release 6.0 and later on both physical and virtual appliances if SIP inspection is enabled and the software is running on any of the following Cisco products. Worth noticing is that SIP inspection is enabled by default


  • 3000 Series Industrial Security Appliance (ISA)
  • ASA 5500-X Series Next-Generation Firewalls
  • ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • Adaptive Security Virtual Appliance (ASAv)
  • Firepower 2100 Series Security Appliance
  • Firepower 4100 Series Security Appliance
  • Firepower 9300 ASA Security Module
  • FTD Virtual (FTDv)

NOTE: Older (EOL) Cisco ASA 5500 series are NOT affected (due to older code). Also the Virtual ASA (ASA 1000V) is not affected

Determining if your product is vulnerable:


Check your current running software versions

For ASA:

ciscoasa# show version | include Version

If version is above 8.4 then it is vulnerable

For Firepower FTD:

> show version

If version is above 6.0 then it is vulnerable

Is my firewall under attack?


During an active attack you will be able to see large number of connections coming to your firewall on port 5060 (traditional SIP port and the one the Cisco devices are listening to in order to perform the inspection).

The following command will show the current SIP connections, they will be listed as incomplete as the source of the DoS only actively bombards the firewall without closing the SIP connection.

show conn port 5060

Another useful command is:

show processes cpu-usage non-zero sorted

This will show you the current cpu usage per process. Typical high CPU values will be observed during the attack. A continuous exploit of this vulnerability will cause continues high-CPU and could cause the device to crash and reload itself

Another indicator of compromise for this attack is a sudden reload after a network slowdown and the presence of a crashfile

show crashinfo

After the device boots up again, the output of show crashinfo will show an unknown abort of the DATAPATH thread

Workaround (Mitigation):


There are several options, all limiting the allowance of these SIP packets to reach or overwhelm the device

1. Disable SIP inspection

Have SIP inspection only if you are actively using it. Our experience with SIP inspection is that usually it is not required (not all customers are doing SIP trunks from inside the organization to a IP Telephony provider in the cloud). Even if SIP is in use, most SIP providers would actively ask you to disable the SIP inspection as Cisco is slow on updating it comparing to how fast SIP protocol changes. SIP providers would ask you just to open specific port ranges and not rely on this inspection due to multiple reasons.

To disable SIP inspection, configure the following:

For Cisco ASA Software 
policy-map global_policy
 class inspection_default
  no inspect sip

For Cisco FTD Software Releases
configure inspection sip disable

Note: This command is issued from the FTD CLI.

2. Actively block IP address(es) of the attackers

You can always actively block (by ACL) the offending IP address that you are seeing via the show conn port 5060. You need also to clear the existing connection issuing clear conn address

Other option is the old shun command that blocks all traffic from certain source IP

shun

This does not survice a reload

3. Filter out based on the SIP attributes

Most observed attacks use an SIP attribute of Sent-by Address that is set to 0.0.0.0. That is not typical behavior for a valid SIP communication, the attack can also be confirmed by doing a packet capture and noticing the amount of packets arriving from a SIP address you are not expecting. You can read the packet captures, check for the Sent-by address and if values are set to 0.0.0.0 and previous methods of mitigation are not valid for your environment then you can proceed and implement this change

regex VIAHEADER “0.0.0.0”

policy-map type inspect sip P1
parameters
match message-path regex VIAHEADER
drop

policy-map global_policy
class inspection_default
no inspect sip
inspect sip P1

4. Rate limit all SIP traffic

Not a great option as that could also influence legitimate traffic, however SIP is the signaling protocol for setting up voip connections, so in nature it should not be very chatty.

You can use the Cisco MPF (Modular Policy Framework) to create a policy and match the SIP traffic and then set a rate limit on this traffic so it would not cause the high cpu spike. Configuration can vary here, so it needs to be done by an expert on product or an external capable consultant.

Nyatya Wiper Malware

Cisco ASA 5500 Series and Cisco IOS XE – IPSec related DoS vulnerability

Nyatya Wiper Malware

Foreword

Today Cisco published its regular semiannual security advisory publication and there is one vulnerability (CVE-2018-0472) that catches the eye. A Cisco ASA and Cisco IOS / XE IPSec related DoS vulnerability that has been marked as HIGH.

Overview

The vulnerability stems from improper handling of IPSec AH (Authentication Header) or ESP (Encapsulating Security Payload) packets. A potential bad player can send specifically crafted IPSec packets that would cause the IPSec device to reload hence causing the Denial of Service attack. No workarounds are available to mitigate this threat. Customers are urge to upgrade their running OS (either ASA OS or IOS XE).

Which products are affected

Cisco IOS XE Software products affected by this vulnerability:

Cisco ASR 1000 Series Aggregation Services Routers:

  • ASR 1001-X
  • ASR 1001-HX
  • ASR 1002-X
  • ASR 1002-HX
  • Cisco ASR 1000 Series 100-Gbps Embedded Service Processor (ASR1000-ESP100)
  • Cisco ASR 1000 Series 200-Gbps Embedded Service Processor (ASR1000-ESP200)

Cisco 4000 Series Integrated Services Routers:

  • ISR 4431
  • ISR 4451-X

The routers must be running an IPSec related technology.

List of vulnerable technologies on IOS XE

  • LAN-to-LAN VPN
  • Remote-access VPN, excluding SSL VPN
  • Dynamic Multipoint VPN (DMVPN)
  • FlexVPN
  • Group Encrypted Transport VPN (GET VPN)
  • IPsec virtual tunnel interfaces (VTIs)
  • Open Shortest Path First Version 3 (OSPFv3) Authentication Support with IPsec

Cisco ASA products affected by this vulnerability:

Cisco ASA 5500-X Series Adaptive Security Appliances:

  • ASA 5506-X Series
  • ASA 5508-X Series
  • ASA 5516-X Series

No other models are affected!

List of vulnerable technologies on ASA XE and FTD

  • LAN-to-LAN IPsec VPN
  • Remote-access VPN using the IPsec VPN client
  • Layer 2 Tunnelling Protocol (L2TP)-over-IPsec VPN connections (not supported on FTD)

How to fix this:


As we mentioned there is not workaround for that vulnerability, an update is needed.

Cisco has released today the necessary upgrades to all vulnerable software


Cisco ASA table with vulnerable OS and which is the update to fix it

Cisco ASA Major Release First Fixed Release for This Vulnerability
9.3Affected; migrate to Release 9.4
9.49.4.4.18
9.5Affected; migrate to Release 9.6
9.69.6.4.8
9.7Affected; migrate to Release 9.8
9.89.8.2.26
9.99.9.2.2

Cisco FTD table with vulnerable OS and which is the update to fix it

Cisco FTD Software ReleaseFirst Fixed Release for This Vulnerability
6.0Migrate to 6.1.0 HotFix or later
6.0.1Migrate to 6.1.0 HotFix or later
6.1.0Cisco_FTD_Hotfix_EI-6.1.0.7-2.sh (all FTD hardware platforms except 41xx and 9300)
Cisco_FTD_SSP_Hotfix_EI-6.1.0.7-2.sh (41xx and 9300 FTD hardware platforms)
6.2.0Not vulnerable
6.2.1Migrate to 6.2.2.3
6.2.26.2.2.3
6.2.36.2.3.1
6.2.3-851
6.2.3-85.02

For Cisco IOS XE Cisco recommend a manual check with their online Cisco IOS Software Checker at:

https://tools.cisco.com/security/center/softwarechecker.x

What is Cisco Unified Threat Defense (FTD)?

Cisco has finally decided to merge its two major network security products – the ASA and FirePOWER. These two have been living on the same hardware (5500X) model for years now but they required separate management which increased the deployment and operational costs for a Cisco FirePOWER implementation. Now Cisco has decided to merge these two platforms by removing the logical separation in hardware and the full separation in software by creating a merged OS that combines the features of both worlds, hence lowering the time/costs for deployment and running.

A bit of History

Cisco is a major player in the Firewall Market since the PIX. With the introduction of the first gen ASA, the PIX was given a polish, new features (such as dynamic routing, QoS, new RFC based protocol inspections/fixup and a few more), but ASA’s were and still are a traditional stateful packet firewall positioned at the Internet Edge. The demands to introduce firewalls also in the DC drove the change from IP based object to Name based object and totally different way of doing NAT (including the introduction of the Any as interface) in versions 8.3+. Still the ASA was purely a stateful firewall and the IDS/IPS module that Cisco was offering was quite outdated in technology and had a less than excellent catch-rate. Cisco knew that and purchased the best IPS/IDS vendor out there – SourceFire.

Now Cisco had two flagmen in the network security and naturally decided to offer them as one box – hence the NX 5500X Firewalls were created, no modules needed, all you need to run both ASA and FirePOWER was an upgrade to SSD drives. However, the management, logging, operation of the ASA and FirePOWER was still independent – ASA was managed and monitored by either ASDM or CSM, where FirePOWER was using – FireSight (pre-version 6) and now FMC (Firepower Management Center). Most competitors (Palo Alto and Check Point) did not need nor have separate management platforms to configure their advanced Next-Gen capabilities and frankly speaking users/admins were not happy with having to do double amount of work to enable a Cisco Next Gen Firewall – interfaces, licensing, configuration, policies, monitoring etc.

In 2015 Cisco hinted about the concept of having one unified management OS that would combine the features of both FirePOWER and ASA. The FirePOWER was chosen as a base for that new image, so from day one the FTD image had almost a 100% of the FirePOWER functionality but a very small percentage of the ASA functionality. The first release (6.0) for testing and Cisco partners was in 2016 and then the FTP had about 20% of the features of the ASA – basic features of course were migrated first, but shockingly there was lack of some major features such as – HA, VPNs (both site-to-site and Anyconnect), dynamic routing protocols, virtualization/contexts, QoS.  A quick introduction of 6.0.1 and 6.1 introduced HA failover so the FTD was now ready to go public.

The Situation today

Latest version release early 2017 is 6.2.0

Cisco continued its work to close the gap between the current ASA and FTD functionality. New major functionality added: Clustering for ASA, Site-To-Site IPSec VPN with certificates (6.1 supported Site-to-Site VPN but only with Pre-Shared-Key), PKI support, SGT without Realm, Migration tool (from traditional ASA to FTD), REST API, Packet Tracer and Capture functionality.

On top of the migrated in 6.1 functionalities such as integrations with Cisco ISE, Threat Grip, on-box management for some model, the 6.2 is looking more and more enterprise ready (not only SOHO as the 6.0 and 6.1). Also, adding the tools for automated migration, the FTD becomes more easily available when doing migration. The user base is also enlarging quite quickly (good for discovering of bugs and security/stability issues).  Version 6.2.1 is just around the corner and will close the gap even further introducing the Anyconnect Remote Access functionality and many improvements/new features in NAT, Dynamic Routing, Multicast and QoS, HA, Site-To-Site VPN and interestingly an option for conversion back to ASA image.

This all points that soon there will be a major swift in the Cisco Security community and more and more clients will start using FTD. Naturally after break-point Cisco will start the phase out of the traditional ASA image (functionality gap will be in favor of the FTD) and clients will be forced to switch. Of course, that process will take time but why not be ahead of the curve?

Resources:

http://www.cisco.com/c/en/us/td/docs/security/firepower/620/relnotes/Firepower_System_Release_Notes_Version_620/new_features_and_functionality.html

Network Security

The Importance of Retrospective Network Security

Network Security

We are experiencing a new phase in our vision of network security. There is currently no quick fix solution, no 100% proof network security protection/prevention tool or product. There is always zero-day or purposely built (very focused, low spread) APT malware that current vendors are unable to detect at the time of the breach.

Hence total prevention is a myth.

Most of the current network security solutions offer only Point-In-Time detection/prevention. Namely they inspect the traffic when the traffic goes via the firewall and if they deem the traffic is clean  or unknown, at that exact time, they will allow it and forget about it. That could lead to malware passing through and being undetected for long periods of time. All vendors rely on intercepting the C&C communication to the botnet servers but not all malware uses such a centralized operation method so that cannot be considered a proven method of detection. That is why most of the vendors will apply their own sandboxing solution, namely send all files of unknown malware type to the cloud where they will be detonated in a controlled environment and the result of their execution will be deemed malicious or not by machines or sometimes humans. Upon discovery of malicious actions, the file is marked as malware and an update is shot out to all vendor appliances out there so they can intercept and drop such files. That process however takes time (typically more than 8 hours) and usually stops more than 96% of the malware spread (it depends on how quickly the different vendors discover that the file is malicious and how quickly the update is sent out) and that percentage was deemed high-enough for most companies.

What about that 4% though? I am sure any business owner would not like to be in this position and would like greater protection and value for their money. When a mere 4% can cause 100% of your security problems, you’re not protected.

Cisco is the only vendor in the NGFW market that currently has its vision also set on the retrospective side of the network security, the so-called After-The-Attack phase. Cisco uses the combination between Firepower and AMP for both network and endpoint to be able to provide threat context and to pinpoint the progress and spread of the malware in historical time so you will know exactly when and how the malware moved in your network, which hosts were infected so that you can immediately deploy mitigation techniques. First restrict the malware, block the effect of the malware and finally remove the malware that has already breached your network. Without this continuous analysis, the attack can run rampant on the network and it will be extremely difficult to determine the scope of the outbreak and the root cause or provide on-time/adequate response. Here is an example of such an event and how Firepower and AMP deal with it.

The following 4 simple steps represent how Firepower and Amp works with zero-day malware files:

  1. Unknown file gets downloaded to a client ip (1.2.3.4 for example) via http application with Firefox, the file is then allowed to reach the endpoint. The unknown file is sent to the cloud to be detonated and given a verdict.
  2. The Firepower tracks the movement/copying of the file within the network so it sees the file being propagated via any protocol at any time. For example, the file gets copied to another host 1.2.3.5 via SMB at 12:41 AM on the 1st of Dec 2016.
  3. Within 30min the same file gets replicated to 5 more devices within the internal range, all via SMB. The Firepower has a map of the file trajectory with hosts and timing of the movements.
  4. Two hours since the file was first seen, Cisco Security Intelligence Cloud had reached a verdict that the file in question is in fact malicious. From now on all Cisco AMP and Firepower enabled devices will drop that file upon encounter and alarm/log, but here comes the difference between Cisco and other vendors, namely the retrospective part. In our example, all future transfer of the files will be blocked and the file itself will be quarantined on all endpoints that have this file (requires AMP for endpoint), even more the administrators can leverage the trajectory map and verify the malicious file has been quarantined/removed and hosts have been remediated.

Abbreviations:

APT – Advanced Persistent Threats

C&C – Command and Control

NGFW – Next-Generation Firewall

Cisco Security

Why do legacy ASAs need Migration to ASA X Generation?

Cisco Security

The traditional legacy ASA Firewalls (5505, 5510, 5520, 5540, 5580) are End of Life (EOL) and soon will be End of Support (EOS). There are still a vast number of ASA’s in the public realm used as a security device/internet edge firewalls where many companies think they are providing the necessary security, the reality cannot be further from the truth.

These older model ASA’s have the following problems

  1. Hardware Problems

Cisco ASA Firewalls have a Meantime-Between-Failure (MTBF) which is simply the predicted elapsed time between inherent failures of such devices. When legacy ASA’s are out of support it is not possible to renew support contracts as Firmware updates are no longer available, effectively making the devices EOL. Meaning they are a ticking bomb and without support any network can suffer significant downtime when the device gives up.

  1. Code Vulnerabilities

ASA updates are uncommon, occurring every 6 months or so, meaning security holes can appear with such a time gap between security patch updates. Effectively your device is vulnerable and unsecured whilst it awaits the next patch update. Currently legacy ASA Firewalls only run to version 9.1 updates. These vulnerability problems wouldn’t be a threat if default and most deployed scenario is an Internet Edge Firewall.

  1. Lack of new features

Cisco is not deploying any new features to the legacy ASA’s and the major version will probably not move away from 9.1 (when the newest is 9.6 for next generation Firewalls)

  1. Lack of real security

Any working firewall cannot only rely on the Stateful Firewall technology for protecting the assets of an organization. Legacy ASA’s can only run the legacy Cisco IPS with a separate module which cannot measure to the modern IPS technology. The new generation of firewalls have the Firepower functionality which is the industry leading IPS technology.

Challenges for migrating Legacy ASA to ASA X?

  1. Configuration migration
  • Manual migration – Configuration between Legacy ASA’s and the new ASA X usually differs and cannot be simply copied and pasted into the new device. Different naming for interfaces and different features and functionalities means different syntax for the CLI.

Very often the legacy ASA’s run a pre-8.3 code due to RAM restrictions (RAM needs to be upgraded for post 8.3+ code). The pre-8.3 code is very different from today’s code in terms of syntax. It does mandate the obligatory use of objects, the NATs are the old PIX like fashion and any policies use the global ip addresses (the so called real ip addresses seen on the interface) than the original one (the ip addresses on the hosts). That means that large portions of the config need to be redone (in most cases manually) when you do the switch over.

The sections that needs manual work are: Objects, NATs, Policies and ACLs. That is the recommended approach and usually an experienced Cisco Security Consultant is needed to perform the job.

  • Automatic migration is possible if the legacy ASA has its RAM upgraded (512MB for 5505 and more than 1GB for the other models is mandatory). Depending on the starting OS Image version several upgrades are done to ensure the device runs the latest 8.2.x code and then jump to 8.4.1. During that jump the device will automatically redo the configuration to its best (will shout out errors on console while booting if it cannot migrate certain areas of the config), it will create objects (with automatic names) and will deploy them.

During automatic migrations, there is always a chance that something will not work so the migration again needs to be performed by someone who understands the migration process, can track down and manually intervene to correct errors or add configuration after the migration. Also, the configuration after an automatic migration is not easily readable due to the creation of objects with automatic naming convention.

  • Raising the security level – if you migrated from a legacy ASA to a new generation ASA X that supports other security technologies and Firepower then it makes sense to leverage new technologies and enable/configure/tune them. A blind one-to-one migration might give you more in the world of availability (new hardware, newer code, less code vulnerabilities and frequent code updates), but will not give you ultimately better protection for your assets. A deep packet inspection with content analysis is a must in the modern threat landscape. Implementing the Firepower technology is necessary but a complex step that needs to be done by people with the right skillset and experience.

References:

  1. EOS / EOL announcement

http://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/eol_C51-727283.html