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 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
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
NOTE: Older (EOL) Cisco ASA 5500 series are NOT affected (due to older code). Also the Virtual ASA (ASA 1000V) is not affected
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
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
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
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.