While examining DNS queries from a device, Nozomi Networks researchers discovered a vulnerability in the DNS resolution capabilities of uClibc and uClibc-ng. The Domain Name System (DNS) usually resolves human-readable addresses (eg heise.de) to the actual IP addresses of the target machines (here 193.99.144.80). Since the maintainer of the uClibc library has not found a solution to the problem, the current post is intended to encourage experts to help find a solution.
The uClibc and uCLibc-ng libraries are used in particular in devices with low memory and processor power, such as Internet routers and Internet of Things devices. uC stands for microcontroller, more correctly written as µC. While uClibc-ng is a version of the library specially adapted for OpenWRT, Axis, Linksys, Netgear or Linux distributions like Embedded Gentoo use uClibc. These standard C libraries provide basic functions for applications programmed in the C programming language, such as text output to interfaces or DNS resolution processing.
Manipulating name resolution
A DNS request uses the UDP protocol, so it is connectionless. In addition to the set of source IP, source port, destination IP, destination port, and protocol specification, it contains the requested data and a transaction ID parameter. This ID is a unique number created by the requesting client. Among other things, the DNS server must include this ID in the response, which the client will otherwise discard as invalid.
Within a network, the source IP (of the requesting client), the destination IP and the destination port (the network’s DNS server, the standard port for conventional DNS is 53), and the protocol (DNS uses UDP) are known. . Therefore, the source port of the requesting device and the transaction ID remain unknown. If the attacker guesses correctly and sends the requesting device a crafted response addressed to its own server for resolution, which arrives before the response from the actual DNS server, a malicious actor can redirect requests to their own server.
Therefore, for security reasons, both parameters should be as random and hard to guess as possible. Otherwise, after a successful attack, attackers could potentially perform larger attacks within an affected network.
The discovered vulnerability affects the transaction ID generated by uClibc and uClibc-ng. It is very easy to guess. In your Blog post describing the Nozomi investigatorshow they were able to trace the gap in the source code. They also explain some other secondary conditions that would be useful to attackers, for example, if devices generated DNS resolutions more often, or if the specific implementation on the device also made the source port easier to predict.
Problem in IoT devices still unresolved
The case currently remains unresolved. So the researchers don’t want to name exactly which devices they tested. However, there were several known IoT devices with current firmware that are probably installed almost everywhere in critical infrastructure.
Nozomi says that she is working with the project maintainer to find a solution.
The chronological course of the case lists numerous contacts with different CERTs (Computer Emergency Response Teams) since September 2021. In addition, more than 200 manufacturers were contacted in this regard. Until finally, about six weeks ago, the project maintainer himself was included in the communication. He explained that he couldn’t solve the problem and asked for help. Now everyone involved is hoping for help from the community.
(DMK)