This is really old news. These kinds of attacks have been well documented for over a decade.[1] An ICMP type 3 code 3 or type 3 code 2 packet MUST be treated the same as a TCP Reset packet (per RFCs). You can also do blind performance degradation attacks with ICMP type 4 or type 3 code 4 packets. Thankfully, ICMP type 4 has been deprecated for a while now so those packets can be safely ignored.
Out of curiosity, why is this called Blacknurse? I couldn't make a connection from ICMP Destination Unreachable / port unreachable packet to the BlackNurse? (not that it matters, I am merely curious).
Also - PoC is for IPv4; does anyone know if systems fail in a similar manner if ICMP6 Destination Unreachable / Port unreachable (ICMP6 T:3, C:4) is being used? (https://tools.ietf.org/html/rfc4443#section-3.1)
I can only guess that it's a play on "black hat" hacking as opposed to "white hat"[1].
Since ICMP messages are related to network "health" by way of pinging & diagnostics, a good "white nurse" would use that to monitor the health of the patient. However, an evil "black nurse" would use the ICMP protocol against the patient to kill it.
Because maybe not everyone projects their own racism onto innocent words such as black, white, and yellow. We should "go there", because thought-crime and "watch what you say" type ideas are much more dangerous to our society than the term blacknurse.
I don't think any harm is intended in this choice of words, but that doesn't mean one shouldn't try to be cognizant of the subtle cumulative effect they might have.
The problem is that it's really obvious, too. It's not like they used some term that just happened to have been used in the past as slang but is now a commonplace word without the same meaning. You don't need to get out a dictionary to spot the problem.
So is black metal music racist? Give me a break, people have associated black with evil things such as monsters stalking the night, plague, and death for 3000 years and probably before it. You are paranoid and overreacting. You're projecting your own racial insecurities onto the world where there simply is none, especially in this case.
I didn't suggest any of this was racist. I despise the hysterical, wolf-crying, race-baiting PC police, but that doesn't mean that we can't try to make the word a better place by avoiding to pile on the black=evil association in our culture and in the English language, especially when coining new terms. It's not a horrible moral failing not to do so, but it would be nice.
Metal is not a person, but a nurse is. All the difference. My point isn't to suggest it's racist, but to ask why even go there? If they changed the term slightly no one would have to double think.
I think the reason that Black Nurse might be particularly bad is that during slavery, black women were forced to feed their owners' children instead of their own.
Just because you don't see something as problematic doesn't mean that it isn't.
I haven’t thought of the term in that sense until reading your post. Not because I am unaware of black issues, but because I’m not an American and my context simply lacks the implied connotation for the term in question.
The political correction you ask for is USA-centric. I don’t know if the people behind blacknurse.dk are American, but, if the domain is an indication, they may not be.
To be honest I've always been pretty amazed that the web doesn't fall apart much more easily than it actually does.
The fact is that most sites work only with some kind of caching in front of them at any scale; my guess would be on a site by site basis there will be a slow performing piece of code somewhere that can be exploited with low resources on the part of the attacker.
In a lot of cases, simply creating a session a couple of 100000 in a short enough space of time, would be enough to overload the majority of sites...
These aren't web technologies at all, but firewall issues. This doesn't have anything to do with websites being inefficient, but how some firewalls handle some ICMP edge cases. I feel like the complexity of IPv4/6 is high and stuff like this will continue to be found. If you want a world-wide networking protocol, you need to deal with complexity, and complexity comes with issues like this.
We should be geared up to fix stuff like this via quick patching. This stuff shouldn't be terribly surprising. I think the idea of "install and forget" for any internet enabled device is a dangerous line of thinking, especially for firewalls.
Yes, I know that... my point is if you wanted you could take down Hacker News for example; pretty easy if you thought about it for a while right? You don't need this bug or a massive botnet.
Botnets are a lot simpler to wield and make you a more credible threat vs a website who thinks they have no "slow code", but to who 1TB/sec would certainly do the trick.
I'm not a so called security expert nor I'm in the security business anymore, so please take this with a pinch of salt.
Isn't rate limiting a thing anymore? Especially for packets that should not be coming at this rate. 40k-50k pps? Who gets that amount of ICMP type 3 code 4 as a baseline to consider it normal? Also, many networks out there "deprioritize" ICMP packets.
I see how (mainly) Cisco seems to have screwed up on their ASAs, but in all honesty they've never been the paradigm of firewall security. Before the -X line, which is when I was a very active user of ASAs, the interface buffers of almost any ASA up to the 5580 were insufficient for some kinds of traffic that generated high pps with not so huge bandwidth.
Actually, now that I think about it, I wonder if this "Black Nurse" is partly the result of the ASA's insufficient buffers and not just an actual firmware issue.
All in all, this feels very amateurish to me and I'm surprised people are buying into it - I guess doom and gloom sells pageviews. I mean, if their conclusion is the below, I don't see how this is making so much noise:
"We believe,that what we see when our customers get hit by the BlackNurse attack is that the firewall admins have just followed recommendations or misconfigured firewalls. Mitigation on firewalls could be to change default config or to patch any code that can lead to a DoS state."
It seems that ZyWall USG 50 requires less than 10 Mbit/s of traffic to go totally braindead due to CPU load. - This attack works like a charm, and 10 Mbit/s is quite much less than reported 180 Mbit/s.
There's generic name for these attacks: Resource consumption attack.
> Even a single computer can take down big servers using BlackNurse Attack (...) Researchers at TDC Security Operations Center have discovered a new attack technique that lone attackers with limited resources (in this case, a laptop and at least 15Mbps of bandwidth) can use to knock large servers offline. (...)
> By sending a Type 3 ICMP packets with a code of 3, a hacker can cause a Denial of Service (DoS) state by overloading the CPUs of certain types of server firewalls, regardless of the quality of internet connection.
The BlackNurse traffic volume is very small, ranging from 15 Mbps to 18 Mbps (or about 40,000 to 50,000 packets per second), which is laughable compared to record-breaking 1.1 Tbps DDoS attack recorded against French Internet service provider OVH in September.
The worrying thing is that a suitably insane whackjob somewhere could spin up their ipcamera botnet and knock, say, half the planet's ISP offline at once.
All routing would stop, the internet would simply grind to a halt. Am I missing something?
Not all routing by any means. Just anyone using those particular Cisco and other routers. Fortunately the net routes around damage by design; as routers went offline, other paths would be found.
Huh. The solution is to not handle icmp type 3 or "hire official anti-ddos services"? I assume there's a way to maintain ICMP type 3 functionality while still mitigating this attack...?
Given that there's a list of products unaffected by this attack, I assume it can be fixed without impacting functionality. It seems like a widespread implementation problem, rather than an inherent design flaw.
Blocking ICMP type 3 breaks path MTU discovery. When the path MTU is less than the server's MTU, the client will typically send a request which is smaller than the path MTU and then the server's response isn't so it's the server that gets the ICMP message.
Blocking type 3/3 can also make some other denial of service attacks easier because it takes longer for the server to figure out that the device at that IP doesn't want the packets the server is sending when the request is from a spoofed IP address.
But what about TCP only? AFAIK, TCP RST is usually used when a packet is received with no connection. The only place I'm aware of that uses ICMP 3/3 is the REJECT iptables target when the defaults are used.
This reminds me of an attack in the late 1990s called Pulse, which was a low-bandwidth flood of RST packets against Cisco routers. With a T1 line (1.5mbps) you could bring down a T3 (45mbps).
It is pretty nice that pfSense isn't bothered by it. I was also happy to see that pfSense wasn't included in the list of software targeted by the NSA's leaked weaponry.
If you get a Destination Unreachable at a firewall, what do you do with it? Unless the firewall has been passing traffic to the supposedly-unreachable destination, the firewall should drop it. Are firewalls mishandling this, or doing it too slowly?
So, what's the current recommendation on accepting public ICMP these days? There used to be some debate on the tradeoff between usefulness and security.
Looks like ASA >= 9.2.4 ships with `icmp unreachable rate-limit 1 burst-size 1`, which is I believe the workaround Cisco suggests:
We recommend that you grant permission for the ICMP unreachable message type (type 3). Denying ICMP
unreachable messages disables ICMP Path MTU discovery, which can halt IPsec and PPTP traffic.
See RFC 1195 and RFC 1435 for details about Path MTU Discovery
duplicates are explicitly allowed if previous submission had no traction. Please don't link to "duplicates" if there is neither a discussion nor there has been excess amount of them.
[1] https://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html