Researchers at IoT security firm Nozomi Networks are warning that a popular library for the C programming language for IoT products is vulnerable to DNS cache-poisoning attacks. The bug is 10 years old and, at present, could not be fixed by its maintainers.
Nozomi security researcher Andrea Palanca discovered that the Domain Name System (DNS) implementation of uClibc and uClibc-ng C libraries used in several popular IoT products generates predictable, incremental transaction identifiers (IDs) in DNS response and request network communications.
uClibc stopped being maintained in 2012 after the release of version uClibc-0.9.33.2, while the uClibc-ng fork is designed for use within OpenWRT, a common OS for routers “possibly deployed throughout various critical infrastructure sectors”, according to Palanca.
SEE: The Emotet botnet is back, and it has some new tricks to spread malware
uClibc is also known to be used by Linksys, Netgear, and Axis, and Linux distributions, such as Embedded Gentoo, notes Palanca.
Nozomi has opted not to disclose the specific IoT devices it tested because the bug is unpatched. However, Palanca notes the devices tested were “a range of well-known IoT devices running the latest firmware versions with a high chance of them being deployed throughout all critical infrastructure.”
The uClibc-ng fork is a small C library for developing embedded Linux systems with the advantage of being much smaller than the GNU C Library (glibc).
Palanca says he reported the issue to ICS-CERT in September to undertake a VINCE (Vulnerability Information and Coordination Environment) case with CERT/CC. In April, CERT/CC approved his request to proceed with vulnerability disclosure on May 2. The issue is being tracked as ICS-VU-638779, VU#473698.
CERT/CC invited uClibc-ng’s maintainer to the VINCE case in mid-March but the developer said he was unable to implement the fix himself and suggested sharing the vulnerability report on the mailing list with a “rather small community” that might be able to help implement a fix.
Six months on from the original bug report to ICS-CERT, the bug remains unpatched and serves as a reminder of the challenges in open-source software security and more broadly the software supply chain due to a lack of developer resources and funding.
The main risk of DNS-poisoning attacks is that they can force an authentication response. DNS, often described as the ‘phonebook of the internet’, is responsible for translating IP addresses into domain names.
A DNS-poisoning attack involves an attacker poisoning DNS records to dupe a DNS client into accepting a forged response, and from making a program reroute network communication to an endpoint they control rather than the correct one.
While testing an unnamed IoT device, Palanca noticed the transaction IDs – one of two secret bits in the query-response communication – were incremental. These IDs were generated by uClibc 0.9.33.2, which its original maintainer released in May 2012.
“To have a DNS response accepted for a certain DNS request, the aforementioned 5-tuple, the query, and the transaction ID must be correctly set,” explains Palanca in a blogpost.
SEE: Google: Multiple hacking groups are using the war in Ukraine as a lure in phishing attempts
He says that – because the protocol is DNS, publicly known information includes that destination port, the query is the target that an attacker wants to compromise, the source IP address is the target machine, and that the destination IP address is the address of the DNS server in use in a certain network – the only unknowns remain the source port and the transaction ID.
“It is vital that these two parameters are as unpredictable as possible, because if they are not, a poisoning attack could be possible,” notes Palanca.
“Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server.
“Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.”
Palanca notes that modern Linux kernels enable OS-level source port randomization, making it more difficult to exploit for DNS-poisoning attacks. However, if an attacker has enough bandwidth, they might be able to “brute-force the 16 bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response.”
