Researchers discovered that an unpatched Domain Name System (DNS) issue in a popular standard C library can be used to launch DNS poisoning attacks against millions of IoT devices and routers, potentially allowing attackers to seize control of them.
Researchers from Nozomi Networks Labs uncovered a problem impacting the implementation of DNS in all versions of uClibc and uClibc-ng, prominent C standard libraries used in a wide range of IoT products, according to a blog post published this week.
An attacker deceives a DNS client into accepting a falsified answer in a DNS poisoning attack, also known as DNS spoofing or DNS cache poisoning. This forces a software to communicate across the network with an arbitrary endpoint rather than the genuine one.
Because key vendors like Linksys, Netgear, and Axis, as well as Linux distributions like Embedded Gentoo, employ uClibe in their devices, the issue has a wide reach. uClibc-ng, on the other hand, is a fork specifically intended for OpenWRT, a common OS for routers deployed across a variety of critical infrastructure sectors, according to researchers. The bug’s impact on specific devices was not revealed as part of this study.
Furthermore, experts warned that if an attacker successfully performs a DNS poisoning assault on an impacted device, they can then launch a man-in-the-middle attack. This is because they can reroute network communications to a server under their control by poisoning DNS records, according to researchers.
“The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them,” researchers wrote. “The main issue here is how DNS poisoning attacks can force an authenticated response.”
Researchers are currently collaborating with the uClibe library’s developer to find a remedy for the flaw, which leaves devices susceptible, according to the researchers. To keep attackers at bay, Nozomi researchers have declined to reveal detailed data about the device on which they were able to reproduce the bug.
The DNS hole reminds us of last year’s Log4Shell flaw, which caused a flurry of anxiety in the cybersecurity industry when it was found in December due to its scale. The issue affects the widely used open-source Apache Log4j framework, which is utilised in a wide range of Java applications. In fact, despite the existence of a patch, the issue continues to put millions of Java programmes at risk, according to a recent report.
Despite the fact that it affects a diverse set of targets, the DNS issue has a broad scope, according to researchers, not only because of the devices it could affect, but also because of the intrinsic necessity of DNS to any device connected over IP.
DNS is a hierarchical database that is responsible for translating a domain name into its associated IP address. Aside from the normal 5-tuple–source IP, source port, destination IP, destination port, protocol–and the query, each DNS request contains a field called “transaction ID” to distinguish the responses of various DNS inquiries.
The transaction ID is a one-of-a-kind number produced by the client and included in each request sent. It must be included in a DNS response for the client to accept it as the correct response for the request, according to the researchers.
The weakness was identified when studying the trace of DNS requests made by an IoT device, according to the researchers. They observed anything unusual in the pattern of DNS requests in Wireshark’s output. The request’s transaction ID was initially incremental, then reset to 0x2, and then incremental again.
“While debugging the related executable, trying to understand the root cause, we eventually noticed that the code responsible for performing the DNS requests was not part of the instructions of the executable itself, but was part of the C standard library in use, namely uClibc 0.9.33.2,” they explained.
The uClibc library implements DNS requests by invoking the internal “__dns lookup” function, which is located in the source file “/libc/inet/resolv.c,” according to the researchers. Researchers stated they eventually discovered a flaw in certain of the library’s lines of code, notably lines #1240, #1260, #1309, #1321 and #1335, to which they could ascribe the abnormality in the DNS request pattern, which makes the transaction ID predictable.
To exploit the weakness, an attacker would have to design a DNS response that has the correct source port, as well as win the race against the legal DNS response inbound from the DNS server, according to the researchers.
The ability to exploit the weakness is also contingent on how an OS handles source port randomization, which means an attacker would have to bruteforce the 16-bit source port value by sending repeated DNS queries while beating the legitimate DNS response, according to the researchers.
Because the problem is still patched on millions of IoT devices, researchers aren’t revealing the individual devices that are vulnerable to attack. In the meanwhile, Nozomi Networks advises network managers in both IT and operational technology contexts to improve network visibility and security.
“This vulnerability remains unpatched, however we are working with the maintainer of the library and the broader community in support of finding a solution,” they wrote.
