While examining a device’s DNS requests, 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 220.127.116.11). Since the uClibc library maintainer has not found a solution to the problem, the current post aims to encourage experts to help find a solution.
The uClibc and uCLibc-ng libraries are used especially in devices with low memory and CPU 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 such as Embedded Gentoo use uClibc. These standard C libraries provide basic functions for applications programmed in the C programming language, such as outputting text to interfaces or handling DNS resolution.
Manipulated name resolution
A DNS query uses the UDP protocol, so it is connectionless. Along with 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 customer. Among other things, the DNS server must list this ID in the response, which the client otherwise rejects as invalid.
Within a network, the source IP address (of the requesting client), destination IP address and destination port (network DNS server, standard port for conventional DNS is 53), and protocol (DNS uses UDP) are known. The source port of the requesting device and the transaction ID therefore remain unknown. If the attacker guesses this correctly and sends the requesting device a specially crafted response targeting its own server for resolution, arriving before the response from the real DNS server, a malicious actor can redirect requests to its 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 carry out larger attacks within an affected network.
The discovered vulnerability affects the transaction ID generated by uClibc and uClibc-ng. It’s very easy to guess. In their blog post, Nozomi researchers describe how they were able to trace the vulnerability in the source code. They also explain some other secondary conditions that would be useful for attackers, for example, if devices generated DNS resolutions more frequently or if the specific implementation in the device also made the source port easier to predict.
Issue on IoT devices still unresolved
The cause currently remains unresolved. Therefore, the researchers do not want to name exactly which devices they performed the tests with. However, there were several well-known IoT devices with current firmware that are most likely installed almost everywhere in critical infrastructure.
Nozomi says he is working with the project manager to find a solution.
The timeline of the case lists numerous contacts with various CERTs (Computer Emergency Response Teams) since September 2021. In addition, more than 200 manufacturers have been contacted in this regard. Until finally, about six weeks ago, the project manager 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.