ICMP Unreachable DoS Attacks (aka "Black Nurse")
Thanks to our reader Mikael for pointing out a new branded vulnerability with domain name, logo and catchy name: "BlackNurse". (no jingle though). [1]
The problem pointed out by this announcement is that firewalls can spend significant resources on processing these relatively common ICMP error messages. Type 3 error messages are used for various "Unreachable" messages. For example, Type 3 Code 3 is used for port unreachable. For a complete list, see the official IANA list [2] .
The announcement doesn't make any statements as to why these packets take up so much CPU time. In my opinion, this is likely due to the firewall attempting to perform stateful analysis of these packets. ICMP unreachable packets include as payload the first few bytes of the packet that caused the error. A firewall can use this payload to determine if the error is caused by a legit packet that left the network in the past. This analysis can take significant resources.
According to the description of the attack, firewalls will suffer performance issues if hit by a few 10s of MBits of ICMP traffic, even for firewalls that are supposed to be able to dell with Gigabit networks. The "fix" is to block or rate limit the traffic.
It is not recommended to block all Type 3 ICMP messages. In particular Type 3 Code 4 (Fragmentation Needed and Don't Fragment was Set) messages are requied for path MTU discovery, which many modern operating systems use. Port unreachable messages (Type 3 Code 3), which were used in most of the tests performed by the group releasing this vulnerability, can usually be blocked but you may see some performance issue if for example a DNS resolver is attempting to connect to a non-existing DNS server, and then delays trying a secondary server because it never receives the port unreachable message.
So what should you do?
- Don't panic. This is not a big deal. Test your firewall if you can, or check if is on the vulnerable list
- You are vulnerable if you use a smaller Cisco ASA firewall. Newer/Larger multi-core versions appear to be fine. SonicWall and "some" Palo Alto firewalls appear to be vulnerable too.
- iptables based firewalls are not affected
- Monitor incoming ICMP unreachables. The advisory includes some snort rules to do so, but anything monitoring ICMP should work (netflow?) as no payload inspection is necessary
- Cisco does not consider this a security issue. There is no CVE.
[1] http://www.netresec.com/?page=Blog&month=2016-11&post=BlackNurse-Denial-of-Service-Attack
[2] http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes-3
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
Anonymous
Nov 10th 2016
8 years ago
I am testing this on some other firewalls so far I am seeing the same results a higher cpu load with icmp code 3 versus echo
Anonymous
Nov 11th 2016
8 years ago
Anonymous
Nov 11th 2016
8 years ago
Anonymous
Nov 15th 2016
8 years ago
"iptables based firewalls are not affected"
Anonymous
Nov 15th 2016
8 years ago
In the case of ASA, the CPU spike seems to be related to two factors
1. Packet processing (like you mentioned)
2. Logging sub-system (seems to be default on ASA's to log this in "error" facility)
in that order. If you disable logging and tweak a few icmp unrechable parameters you can get some performance like Danish TDC company has pointed out. However overall the CPU spike shows some struggle the firewall is having in parsing/verifying the ICMP unreachable payload which contains IP headers and payload from the purported unreachable session.
The attack is interesting as it provides another asymmetric way to exhaust resources on firewalls. The only right mitigation seems to be upstream throttling or dropping (before the firewall) of ICMP unreachables code 3. Not all codes under ICMP unreachable (type 3) are as effective in CPU.
Vjay
Anonymous
Nov 17th 2016
8 years ago
Anonymous
May 22nd 2017
7 years ago