Ordr Announces Integration with ServiceNow Vulnerability Response Read more here!

Yesterday, our Chief Security Officer, Jeff Horne shared his perspective on NAME:WRECK and the vulnerabilities associated with DNS that were found. As a follow up, I wanted to share some best practices for DNS security.

The most common DNS exploits are exploits like exfiltration, payload delivery, and commands and control. Sometimes outright flaws in code (like a few mentioned in NAME:WRECK) are leveraged also. DNS is a venerable and necessary service that can be secured with good practices and solid Zero Trust policy.

In this blog we will explore a number of DNS configurations, explore what’s right and wrong and steps you can take to secure your configuration.

Scenario 1 (Worst Case) 

In this scenario, endpoints of all sort query some internet source (typically Google or Verizon) for name lookups directly. This is a typical home user configuration and unfortunately a typical configuration for IoT devices and guest networks across many verticals in enterprise. In this scenario attacks can come from nearly any ware upstream, and in any form from bad packets, bad answers (sending the host to a malicious location) or worse.

Even a Next-Generation firewall capable of DNS application understanding is not enough.

Scenario 2 (Typical Enterprise) 

This is the most common implementation of DNS in enterprises across the world where a local authoritative name server is the ‘first hop’ and provides recursion out to the internet. Some enterprises are further adding some layer of DNS security in response policy zones, leveraging Next-Generation firewalls, or Secure DNS solutions on the internet side. If this is set up in best practice, this delivers minimal security(yes minimal) but if we are working in Cyber-Physical Systems like Manufacturing, Healthcare or Financial Services then this is not nearly enough.

What is Best Practice? 

The Firewall would block all DNS requests (outbound/inbound) except to the Internal DNS server that was running DNS security in the form of response policy zones, and furthermore the internet resolver would be a Secure DNS source (i.e., Cisco Umbrella, Akamai, Neustar or other such provider).  

Scenario 3 (Reference DNS) 

This is a better set up and is often considered the ‘reference’ DNS architecture for many. This scenario will protect most internal hosts from many, many sorts of exploits and attacks. However, this configuration still falls short for Cyber-Physical Systems (and even some core services servers) when we apply Zero Trust concepts to the DNS service.

Scenario 4 (Best Practice for Cyber Physical Systems) 

Following the Reference DNS set up with Best Practices, we need to add yet another dimension to the architecture for Cyber Physical systems.

Most Cyber Physical Systems do not rely on internet lookups to function and if we apply Zero Trust ideology to the DNS architecture we should deny them access that is not necessary.  This architecture permits internal look ups and communications as needed but stops any communications, lookups, payloads, C &C, or other DNS mischief dead in its tracks. For the few systems that look up a single address for Firmware download or other sort of check ins or even for cloud-based management, simply add conditional forwarders for those domains. (i.e. an imaging system might store images in the cloud and need a set of internet facing addresses so only allow lookups for that domain).

This method can take some time to set up, but is overall much more secure and will protect your most valuable and critical systems from DNS-related exploit and harm.

In Summary 

  1. Do not allow internal HOSTS to query the internet directly.
  2. Do not trust external nameservers (like Verizon and Google).
  3. Leverage Secure DNS providers like Cisco Umbrella, Neustar, Akamai and others for recursion and further leverage DNS Security in the form of Response Policy Zones (RPZ) internally.

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-ofbounds 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:

  1. 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.
  2. Implement least-privilege access. Grant devices only the minimal access privileges they need to operate.
  3. 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.
  4. 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.