NAME:WRECK vulnerabilities impact millions of smart and industrial devices
Security researchers have found a new set of vulnerabilities that impact hundreds of millions of servers, smart devices, and industrial equipment.
Called NAME:WRECK, the vulnerabilities have been discovered by enterprise IoT security firm Forescout as part of its internal research program named Project Memoria — which the company describes as “an initiative that aims at providing the cybersecurity community with the largest study on the security of TCP/IP stacks.”
Although never visible to end-users, TCP/IP stacks are libraries that vendors add to their firmware to support internet connectivity and other networking functions for their devices.
These libraries are very small but, in most cases, underpin the most basic functions of a device, and any vulnerability here exposes users to remote attacks.
The NAME:WRECK research is the fifth set of vulnerabilities impacting TCP/IP libraries that have been disclosed over the past three years, and the third set disclosed part of Project Memoria:
- URGENT/11 (discovered by Armis)
- Ripple20 (discovered by JSOF)
- Amnesia:33 (discovered by Forescout in Project Memoria)
- NUMBER:JACK (discovered by Forescout in Project Memoria)
But while previous research looked at various mechanisms in TCP/IP communications, the NAME:WRECK research looked at how these libraries handle DNS (Domain Name System) traffic rather than at the actual TCP or IP communications.
More precisely, researchers looked at the “message compression” feature of the DNS protocol and how it’s been implemented across TCP/IP stacks.
Because DNS server replies can often contain multiple domain names, some of which may repeat, the DNS message compression feature allows DNS servers to cut down on the size of DNS replies by avoiding the duplication of the same domain names.
Seven of 15 TCP/IP stacks found vulnerable
Forescout said it found a total of nine vulnerabilities impacting seven of the 15 TCP/IP stacks they analyzed over the past few months for bugs in their DNS message compression implementations.
Three TCP/IP stacks were vulnerable to DNS message compression-related bugs discovered in previous research projects like Ripple 20 and Amnesia:33, while four TCP/IP stacks were vulnerable to new bugs discovered during the more recent NAME:WRECK research push.
Of the other eight libraries they tested, FNET, cycloneTCP, uC/TCP-IP, FreeRTOS+TCP, Zephyr, and OpenThread were found to implement message compression securely, while Nut/Net and lwIP did not support message compression, to begin with, which made them not vulnerable by design.
Descriptions for the nine vulnerabilities discovered during the NAME:WRECK research push are available in the table below:
However, despite reporting the issues to their respective developers, only three of the four TCP/IP stacks discovered to be vulnerable have released patches.
Per the table above and according to an in-depth technical report released today, only FreeBSD, Nucleus NET, and NetX have released patches, while IPNet still remains to address NAME:WRECK-related issues.
Unpatched devices to linger around for years
Nonetheless, while releasing patches may sound reassuring, in reality, the situation is far from perfect. This is because patching smart and industrial equipment usually entails a long waiting period, during which time device vendors will have to integrate the patches and release firmware updates of their own.
And even if updated firmware images are available, this doesn’t mean that customers will bother updating their devices, many of which may be deployed in remote locations and hard to reach without a firmware-over-the-air (FOTA) update mechanism, which very few devices support.
This inherently also means that many of the devices that use the vulnerable TCP/IP stacks will most likely remain exposed to attacks for years to come, while other equipment may remain vulnerable until they’re decommissioned, either due to a lack of human resources to apply the patch, lack of knowledge needed to deploy such a patch, or the lack of an actual update mechanism in the device firmware.
But even this sounds as bad as it gets, it also gets a lot worse, as some device owners may not even be aware that their servers, smart devices, or industrial equipment even use the vulnerable TCP/IP stacks — primarily because most software these days comes without a bill of materials.
Unfortunately, this means that many devices will remain vulnerable to attacks.
To make matters worse, while some of the NAME:WRECK vulnerabilities require that threat actors have the ability to tamper with a victim’s DNS traffic, in a phone call last week, Forescout lead researcher Daniel dos Santos told The Record that there are vulnerabilities that also allow remote attacks just by bombarding vulnerable systems with malformed DNS replies in a spray-like attack, meaning that NAME:WRECK attacks can’t also be dismissed as unexploitable in the real world.
Standards are just too complex
But dos Santos also told The Record that exposing these vulnerabilities and devices to attacks was not the primary purpose or the only conclusion of Forescout’s research.
What the research team discovered following their work was that most vendors had made similar mistakes in interpreting DNS standards, which resulted in their products being exposed to similar attacks, making the Forescout team ask themselves if the DNS standard wasn’t too complex for its own good, or just poorly written.
“The NAME:WRECK report brings a message that goes significantly beyond the discovery and the fixing of a very widespread vulnerability,” said Professor Sandro Etalle, Eindhoven University of Technology, which reviewed Forescout’s NAME:WRECK research.
“When half of the implementations of a given specification are faulty one can only conclude that is not a question of bad programming, it is the underlying methodology that does not deliver what it should, even when the methodology is applied at its best,” Prof. Etalle added.
“To a point, we all know this. However, this report gives us a kind of measure of the extent to which this is true, and the measure lies in the astonishing amount (7 out of 15) of independently done implementations that are vulnerable to the same bug. Personally, I was surprised.”