A weakness in the DNS component of a popular C standard library, which is used in a wide range of IoT products, might expose millions of devices to DNS poisoning attacks.
Instead of the authentic destination, a threat actor can use DNS poisoning or DNS spoofing to send the victim to a malicious website hosted at an IP address on a server controlled by the attacker.
The OpenWRT team’s fork of the uClibc library, uClibc-ng. Major vendors such as Netgear, Axis, and Linksys, as well as Linux releases for embedded applications, use both kinds.
According to Nozomi Networks experts, a remedy from the uClibc developer is presently unavailable, putting the products of up to 200 suppliers at danger.
The uClibc library is a C standard library for embedded systems that provides numerous resources required by devices’ functionalities and configurable modes.
That library’s DNS implementation provides a framework for conducting DNS-related queries such as lookups, translating domain names to IP addresses, and so on.
Nozomi examined the uClibc library’s trace of DNS requests made by a connected device and discovered several oddities produced by an internal lookup function.
The analysts observed that the transaction ID for the DNS lookup request was predictable after further investigation. As a result, DNS poisoning could be conceivable in some scenarios.
A specifically crafted DNS response sent to devices utilizing uClibc could launch a DNS poisoning attack if the operating system does not use source port randomization, or if it does but the attacker is still capable of brute-forcing the 16-bit source port value.
DNS poisoning works by fooling the target device into referring to an arbitrary endpoint and communicating with it via the network.
By doing so, the attacker will be able to redirect traffic to a server that they control directly.
“The attacker might then steal or manipulate information sent by users, as well as launch further attacks against those devices, compromising them altogether. The key concern is how DNS poisoning might compel an authenticated answer ” – Nozomi Networks, Inc.
In September 2021, Nozomi uncovered the issue and contacted CISA. The vulnerability was then reported to the CERT Coordination Center in December, and then publicized to over 200 potentially vulnerable vendors in January 2022.
As previously stated, there is still no patch for the flaw, which is now being tracked as ICS-VU-638779 and VU#473698 (no CVE yet).
All stakeholders are currently working together to produce a feasible patch, and the community is anticipated to play a key role in this, as this was the original intent of the disclosure.
It will take some time for the changes to reach end users because impacted vendors will have to install the patch by applying the updated uClibc version on firmware updates.
Even then, end-users will have to update their devices’ firmware, which is another bottleneck that delays the solution of significant security problems.
“We cannot divulge the precise devices we tested on because this vulnerability remains unpatched for the community’s safety,” explains Nozomi.
“However, we can reveal that they were a variety of well-known IoT devices running the most recent firmware versions, with a high likelihood of their being installed across all critical infrastructure.”
Users of IoT and router devices should keep a watch on new firmware releases from suppliers and upgrade their equipment as soon as possible.