Unfixed vulnerability in popular library puts IoT products at risk

Researchers have found a vulnerability in a popular C standard library in IoT products that could allow attackers to perform DNS poisoning attacks against a target device.

The library is known to be used by major vendors such as Linksys, Netgear, and Axis, but also by Linux distributions such as Embedded Gentoo. Because the library maintainer was unable to develop a fix, this vulnerability remains unpatched. For this reason, the affected devices were not mentioned in detail.

Libraries

In computing, a library is a set of resources that can be shared among processes. Often these resources are specific functions aimed at a certain goal. These functions can be called upon when needed so they do not have to be included in the code of the software that uses it. Another example of such a library that caused some havoc was Log4j.

A C standard library is a library for the C programming language itself. Such a library provides macros, type definitions, and functions for tasks such as string handling, mathematical computations, input/output processing, memory management, and several other operating system services. As you can imagine, such a standard library is called numerous times by many programs that depend on these basic functions.

uClibc

In this case, the library at hand is uClibc, one of the possible C standard libraries available, which focuses specifically on embedded systems because of its size. Because uClibc is a relatively small C standard library intended for Linux kernel-based operating systems for embedded systems and mobile devices. Features can be enabled or disabled to match space requirements.

The alternative uClibc-ng is a fork of uClibc that was announced after more than two years had passed without a uClibc release, citing a lack of any communication from the maintainer. Unfortunately uClibc-ng shares the same vulnerability.

Similar to other C standard libraries, uClibc provides an extensive DNS client interface that allows programs to readily perform lookups and other DNS-related requests.

DNS poisoning

DNS poisoning, also known as DNS cache poisoning or DNS spoofing, is a cyberattack method in which threat actors redirect web traffic, usually toward fake web servers and phishing websites.

In a typical home setup, there is:

• A modem provided by your Internet Service Provider (ISP) which is your connection to the outside world.
• A router that distributes the internet connection across all the devices (often wireless).
• The devices like your laptop, phones, tablets and IoT (Internet of Things) devices such as TVs, temperature sensors, and security cameras.

These days, the modem and router are usually combined in the same device.

A DNS poisoning attack enables a subsequent Machine-in-the-Middle (MitM) attack because the attacker, by poisoning DNS records, is capable of rerouting network communications to a server under their control.

The vulnerability

One of the main ingredients to protect us against DNS poisoning is the transaction ID. This is a unique number per request that is generated by the client, added in each request sent, and that must be included in a DNS response to be accepted by the client as the valid one for that particular request. So while this transaction ID should be as random as possible, the researchers found that there is a pattern. At first the transaction ID is incremental, then it resets to the value 0x2, then it is incremental again.

While figuring out where this pattern comes from, the researchers eventually found out that the code responsible for performing the DNS requests is not part of the instructions of the executable itself, but is part of the C standard library in use, namely uClibc 0.9.33.2.

Image courtesy of Nozomi networks

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. 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.

Mitigation

Since the library maintainer has indicated he is unable to develop a fix, this vulnerability remains unpatched. The researchers are working with the maintainer of the library and the broader community in order to find a solution. The maintainer explicitly asked to publicly disclose the vulnerability, hoping for help from the community.

Because of the absence of a fix, the researchers did not disclose the specific devices that they found to be vulnerable. They did however, disclose that they 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 vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.

If you suspect that your router has been affected by DNS cache poisoning, have a look at our article DNS Hijacks: Routers where you will find some information on how to resolve such matters. When it is purely a case of router DNS caching, I have yet to find a router where resetting the router and leaving it off for at least 30 seconds did not clear the cache. But note that this does not resolve an ongoing attack or remove the vulnerability. It’s just a matter of symptom management.

Stay safe, everyone!