NAME:WRECK is the short name for a collection of nine DNS based vulnerabilities discovered by the security researchers at JSOF and Forescout. This research is arguably an extension of the previous Ripple20 and AMNESIA:33 research as much like Ripple20 the NAME:WRECK vulnerabilities are found in commonly used TCP/IP stacks utilized by potentially millions of IoT devices. Several DNS vulnerabilities were discovered in the previous Ripple20 and AMNESIA:33 research with the vulnerable IP stacks being: Treck TCP/IP, uIP, PicoTCP, FreeBSD, IPNet, NetX and Nucleus NET, however these newly reported Name:Wreck vulnerabilities are inFreeBSD, IPNet, Nucleus NET, and NetX. TheTrech, uIP, PicoTCP, vulnerabilities were disclosed as part of the Ripple20 and Amnesia:33 research papers.
What are TCP/IP stacks?
TCP/IP stacks are common network libraries that allow devices with limited hardware resources to communicate over the network. These device focused TCP/IP stacks are usually found in IoT devices, which typically lack the resources to run the more demanding types of software that are common on PCs or servers. These vulnerable network libraries consequently are in widespread use, and likely places millions of devices at risk. Those devices represent a broad category of IoT use cases, from Industrial Control Systems (ICS), to healthcare equipment and beyond.
What are the effects of NAME:WRECK?
The most serious NAME:WRECK vulnerabilities disclosed are the remote-code execution attacks, in which threat actors take control of an affected device in order to harvest private data from the device or run malicious software on it and gain access to the network its connected to. That being said, exploitation of these vulnerabilities are made more difficult by the fact that it would require a malicious actor to either take control of a DNS server utilized by a vulnerable device or utilize a man-in-the-middle (MITM) style attack where communication to a legitimate DNS server is intercepted and manipulated with malicious intent. This exploitation difficulty does not change the fact that these TCP/IP stacks are vulnerable, but given the complexities of compromising a DNS server or setting up a MITM attack it does lessen the probability of these vulnerabilities being utilized by attackers.
The following table displays a number of common vulnerabilities and exposures (CVE) that correspond to specific types of attacks and risks that have emerged from NAME:WRECK.
CVEs that correspond to NAME:WRECK
|
CVE ID |
Stack |
Description |
Affected Feature |
Potential Impact |
CVSSv3.1 Score |
|
2020-7461 |
FreeBSD |
In FreeBSD 12.1-STABLE before r365010, 11.4-STABLE before r365011, 12.1-RELEASE before p9, 11.4-RELEASE before p3, and 11.3-RELEASE before p13, dhclient(8) fails to handle certain malformed input related to handling of DHCP option 119 resulting a heap overflow. The heap overflow could in principle be exploited to achieve remote code execution. The affected process runs with reduced privileges in a Capsicum sandbox, limiting the immediate impact of an exploit. |
Message Compression |
RCE |
7.7 |
|
2016-20009 |
IPnet |
** UNSUPPORTED WHEN ASSIGNED ** A DNS client stack-based buffer overflow in ipdnsc_decode_name() affects Wind River VxWorks 6.5 through 7. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
Message Compression |
RCE |
9.8 |
|
2020-15795 |
Nucleus NET |
The DNS domain name label parsing functionality does not properly validate the names in DNS responses. The parsing of malformed responses could result in a write past the end of an allocated structure. An attacker with a privileged position in the network could leverage this vulnerability to execute code in the context of the current process or cause a denial-of-service condition. |
Domain name label parsing |
RCE |
8.1 |
|
2020-27009 |
Nucleus NET |
The DNS domain name record decompression functionality does not properly validate the pointer offset values. The parsing of malformed responses could result in a write past the end of an allocated structure. An attacker with a privileged position in the network could leverage this vulnerability to execute code in the context of the current process or cause a denial-of-service condition. |
Message Compression |
RCE |
8.1 |
|
2020-27736 |
Nucleus NET |
The DNS domain name label parsing functionality does not properly validate the name in DNS responses. The parsing of malformed responses could result in a read past the end of an allocated structure. An attacker with a privileged position in the network could leverage this vulnerability to cause a denial-of-service condition. |
Domain name label parsing |
DoS |
6.5 |
|
2020-27737 |
Nucleus NET |
The DNS response parsing functionality does not properly validate various length and counts of the records. The parsing of malformed responses could result in a read past the end of an allocated structure. An attacker with a privileged position in the network could leverage this vulnerability to cause a denial-of-service condition. |
Domain name label parsing |
DoS |
6.5 |
|
2020-27738 |
Nucleus NET |
The DNS domain name record decompression functionality does not properly validate the pointer offset values. The parsing of malformed responses could result in a read access past the end of an allocated structure. An attacker with a privileged position in the network could leverage this vulnerability cause a denial-of-service condition. |
Message Compression |
DoS |
6.5 |
|
2021-25677 |
Nucleus NET |
The DNS client does not properly randomize DNS transaction ID (TXID) and UDP port numbers, allowing attackers to perform DNS cache poisoning/spoofing attacks. |
Transaction ID |
DNS cache poisoning |
5.3 |
|
Yet to be Assigned |
NetX |
In the DNS resolver component, functions do not check that the compression pointer does not equal the same offset currently being parsed, which could lead to an infinite loop. In the function. The pointer can also point forward and there is no out-of–bounds check on the packet buffer. |
Message Compression |
DoS |
6.5 |
The effects of NAME:WRECK could include; stealing data or allowing a malicious actor to gain access to a network that a IoT device running a vulnerable TCP/IP stack is connected to through the RCE vulnerabilities. Or attackers use NAME:WRECK disclosed DoS vulnerabilities they could use it to disrupt operations through effectively disabling vulnerable IoT devices which could lead to downtime and significant financial loss. The list of potential attack scenarios could go on. The takeaway is that NAME:WRECK affects a large amount of devices in the IoT ecosystem.
Identifying devices vulnerable to NAME:WRECK
Currently the Ordr engineering team is working on functionality within our active scanning feature to utilize Internet Control Message Protocol (ICMP) “pings” to be able to identify IoT devices utilizing these vulnerable TCP/IP stacks. We plan to quickly have this feature included and rolled out to all Ordr customers this week.
Unfortunately accurately identifying IoT devices utilizing these vulnerable TCP/IP stacks is extremely difficult to do by passively listening to the network alone. It may be possible to detect some of these vulnerable TCP/IP stacks by listening to certain events like DHCP handshakes which include option data in a specific order, which could be used to identify vulnerable TCP/IP stacks DHCP implementation, but that would require IoT devices to be setup to use DHCP or some special configuration and circumstances that could lead to misdetection. Therefore, active scanning devices for vulnerable TCP/IP stacks is the preferred method of accurate detection.
However, for critical devices in regulated industries like healthcare and manufacturing, the active scanning technique is not a preferred method so as to not interfere with their mission critical operations. Ordr has passive scanning methods to accurately identify these devices and could create exclusion lists if the customer chooses to apply active scanning methods on customer class IoT devices to identify these vulnerabilities.
How to detect NAME:WRECK
Currently there are no known exploits for the NAME:WRECK vulnerabilities. The Ordr security team is actively monitoring the security communities for any proof-of-concept (PoC) exploits, or malicious actors that maybe creating exploits for these vulnerabilities. If that happens the Ordr security team will release network detection signatures for the known PoC or malicious NAME:WRECK exploits.
How to protect vulnerable devices from NAME:WRECK
Although identifying devices that are impacted by NAME:WRECK and patching them is an obvious step for responding to the NAME:WRECK vulnerabilities, organizations must take broader steps to ensure that their networks are hardened against threats like NAME:WRECK. That includes embracing the principles of Zero Trust security to help ensure that your network will be resilient against undiscovered vulnerabilities, regardless of which form they take.
When applying the Zero Trust concept to devices, it means that networks are configured in such a way that, whenever a new device appears on a network, or an existing device’s configuration changes, the device has no access to the network or the hosted resources until a security administrator has verified that the device should be granted access.
In addition, network administrators should adhere to several other best practices associated with Zero Trust:
- Do not rely on firewalls or private IP addresses to establish which devices are “safe.” Instead, identify each device that exists on a network and ensure that it can be trusted before you grant it access to network resources.
- Implement least-privilege access. Grant devices only the minimal access privileges they need to operate.
- Use Multi-Factor Authentication (MFA). MFA is a security enhancement that requires a user to present two or more pieces of evidence when logging in to an account.
- Implement microsegmentation. Grant access privileges to each device on a highly granular basis, rather than assigning broad access rights. Policies are tailored to the individual needs of each device on the network.
Proactive protection of IoT devices with Ordr
The NAME:WRECK vulnerabilities highlight the risk of having IoT and unmanaged devices, even when they run software that has been used and trusted for decades – proving the need again for proactive protection and deep visibility.
Organizations globally, use Ordr to protect their network and devices from vulnerabilities like NAME:WRECK by discovering all network-connected devices, identifying vulnerable assets impacted by NAME:WRECK and other CVEs, detecting and flagging anomalous behavior using a built-in intrusion detection engine, and then using these device insights to proactively protect devices from vulnerabilities by dynamically generating policies and enforcing them on next-generation firewalls or NAC solutions.
Share now
Jeff Horne
Jeff Horne is currently the CSO at Ordr where he is responsible for security direction both within Ordr products and internal security. Prior to Ordr Jeff was the VP of Information Security for Optiv where he was responsible for all Security Operations, Governance Risk and Compliance, Endpoint, Internal Incident Response, Physical Security, and Employee Security Awareness groups. Before Optiv Jeff was the Senior Director of Information Security for SpaceX where he was responsible for the overall security strategy of SpaceX and managing the Information Security, Compliance (ITAR), Security Operations, and Physical Security groups. Previous to SpaceX Jeff was the Vice President of R&D and Chief Architect for Accuvant LABS where he managed teams of researchers and consultants specializing in reverse engineering, malicious code, incident response, breach analysis, and vulnerability assessment. Prior to Accuvant Jeff was the Director of Threat Research at Webroot Software where he led several teams of malware researchers, reverse engineers, and a development organization specializing in creating anti-malware functionality and detection signatures for all Webroot products. Jeff began his career as a Vulnerability Researcher at Internet Security Systems where he was responsible for vulnerability discovery, exploit creation, IDS evasion research, and behavioral detection of malware. Jeff is well known for his insight in interviews for numerous news channels and publications, speaking roles at various security conferences, as well as authoring several vulnerability disclosures and patents.
Follow by Author
