Researchers at IoT security firm Nozomi Networks warn 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 implementation of the Domain Name System (DNS) of uClibc and uClibc-ng C libraries used in several popular IoT products generate predictable and incremental transaction identifiers (IDs) in DNS responses and request network communications.
uClibc was discontinued in 2012 after the release of uClibc-0.9.33.2, while the uClibc-ng fork is intended for use in OpenWRTa common operating system for routers “eventually deployed in various critical infrastructure sectors”, according to Palanca.
TO SEE: The Emotet botnet is back with new tricks to spread malware
uClibc is also known to be used by Linksys, Netgear and Axis, and Linux distributions, such as Embedded Gentoo, Palanca notes.
Nozomi chose not to disclose the specific IoT devices it tested because the bug is not fixed. However, Palanca notes that the devices tested were “a range of well-known IoT devices running the latest firmware versions with a high chance of being deployed in all critical infrastructures.”
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 Vulnerability Information and Coordination Environment (VINCE) case with CERT/CC. In April, CERT/CC approved its request to proceed with vulnerability disclosure on May 2. The issue is tracked under ICS-VU-638779, VU#473698.
CERT/CC invited the maintainer of uClibc-ng to the VINCE case in mid-March, but the developer said he was unable to implement the fix itself and suggested to share the vulnerability report on the mailing list with a “rather small community” that might be able to help implement a fix.
Six months after the initial bug report to ICS-CERT, the bug remains unfixed and serves as a reminder of the security challenges of open source software and the broader software supply chain due to a lack of resources and funding for developers.
The main risk of DNS poisoning attacks is that they can force an authentication response. The DNS, often described as the “directory of the Internet”, is responsible for translating IP addresses into domain names.
A DNS poisoning attack involves an attacker poisoning DNS records to trick a DNS client into accepting a forged response, and to have a program redirect network communication to an endpoint it control rather than good.
While testing an unnamed IoT device, Palanca noticed that transaction IDs – one of the two secret bits of request-response communication – were incremental. These credentials were generated by uClibc 0.9.33.2, which its original maintainer released in May 2012.
“For a DNS response to be accepted for a certain DNS query, the aforementioned 5-tuple, the query and transaction ID must be set correctly.” explains Palanca in a blog post.
TO SEE: Google: Several hacking groups are using the war in Ukraine as a decoy in phishing attempts
It says that – because the protocol is DNS, the publicly known information includes that destination port, the request is the target 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 used in a certain network – the only unknowns are 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.
“Since the transaction ID is now predictable, to exploit the vulnerability, an attacker would need to create a DNS response containing the correct source port, as well as win the race against the legitimate DNS response from the DNS server.
“The exploitability of the issue depends on exactly these factors. Since the feature does not apply any explicit source port randomization, it is likely that the issue can be easily exploited reliably if the operating system is configured to use a source fixed or predictable port.”
Palanca notes that modern Linux kernels allow randomization of the source port at the operating system level, which makes it more difficult to exploit for DNS poisoning attacks. However, if an attacker has sufficient bandwidth, they may be able to “brutally force the 16-bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response”.
