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
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
** 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.
|
|
|
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
The DNS client does not properly randomize DNS transaction ID (TXID) and UDP port numbers, allowing attackers to perform DNS cache poisoning/spoofing attacks.
|
|
|
|
|
|
|
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.
|
|
|
|
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.
