This unpatched DNS bug could put ‘known’ IoT devices at risk

This unpatched DNS bug could put ‘known’ IoT devices at risk

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 currently its maintainers couldn’t fix it.

Andrea Palanca, a security researcher at Nozomi, discovered that the Domain Name System (DNS) implementation of uClibc Y uClibc-ng The C libraries used in several popular IoT products generate predictable, incremental transaction identifiers (IDs) on DNS request and response network communications.

uClibc went out of maintenance in 2012 after the release of version uClibc-, while the uClibc-ng fork is designed to be used within OpenWRTa common operating system for routers “possibly deployed in various critical infrastructure sectors,” according to Palanca.

WATCH: The Emotet botnet is back and has 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 has chosen not to reveal the specific IoT devices it tested because the bug is not fixed. However, Palanca notes that the devices tested were “a range of known IoT devices running the latest firmware versions with a high probability of being deployed across 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 that he reported the problem to ICS-CERT in September to carry out a VINCE (Vulnerability Information and Coordination Environment) case with CERT/CC. In April, CERT/CC approved their request to proceed with the vulnerability disclosure on May 2. The issue is tracked as ICS-VU-638779, VU#473698.

CERT/CC invited the maintainer of uClibc-ng to the VINCE case in mid-March, but the developer said that could not implement the solution itself Y suggested sharing the vulnerability report on the mailing list with a “pretty small community” that could help implement a fix.

Six months after 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 generally in the software supply chain due to lack of funds and resources for developers.

The main risk of DNS poisoning attacks is that they can force an authentication response. Often described as the ‘phone book of the Internet’, DNS 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 spoofed response and causing a program to redirect network communication to an endpoint they control instead of the correct one.

While testing an unnamed IoT device, Palanca noticed that transaction IDs, one of two secret bits in query-response communication, were incremental. These IDs were generated by uClibc, which was released by its original maintainer in May 2012.

“In order for a DNS response to be accepted for a given DNS request, the aforementioned 5-tuple, query, and transaction ID must be set correctly.” explains Palanca in a blogpost.

WATCH: Google: Multiple hacking groups are using the war in Ukraine as a lure in phishing attempts

He says that because the protocol is DNS, the publicly known information includes that destination port, the query is the target an attacker wants to compromise, the source IP address is the destination machine, and that the destination IP address is the address of the DNS Server in use on a given 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 occur,” says Palanca.

“Since transaction identification 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 coming from the DNS server.

“The exploitability of the problem depends on exactly these factors. As the function does not enforce any explicit source port randomization, it is likely that the problem can be easily exploited reliably if the operating system is configured to use a fixed or predictable source . Port.”

Palanca points out that modern Linux kernels allow source port randomization at the operating system level, which makes it harder to exploit DNS poisoning attacks. However, if an attacker has enough bandwidth, they may be able to “brute-force” the 16-bit source port value by sending multiple DNS responses, while also winning the race against the legitimate DNS response. “.

Leave a Comment