Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - ICMP Unreachable DoS Attacks (aka "Black Nurse") InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

ICMP Unreachable DoS Attacks (aka "Black Nurse")

Published: 2016-11-10
Last Updated: 2016-11-10 15:37:13 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

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

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
7 comment(s)
Diary Archives