Last week, Nozomi Networks released an advisory (tracked as CVE-2022-30295) detailing a vulnerability in the DNS component of uClibc library used in many IoT products. The vulnerability also extends to all versions of the uClibc-ng library—specifically forked to support the popular OpenWRT router operating system used in home networks and across various critical infrastructure sectors. The uClibc library is used by major vendors including Linksys, Netgear, Axis, and in Linux distributions including Embedded Gentoo. The exploitable vulnerability lies in the uClibc library’s implementation of predictable transaction IDs which allows an attacker to send a ‘poisoned’ response to the device. Assuming source ports are random, the attacker now needs to flood the device with poisoned DNS ‘responses’ using every possible source port—and do so before the legitimate DNS response is received. Here’s a link to the Infoblox Knowledge Base document regarding this vulnerability: Infoblox products not vulnerable to uClibc and uClibc-ng issues.
Yay! Another as-yet-unpatched vulnerability. What’s the impact? An attacker can exploit the vulnerability to conduct DNS poisoning or DNS spoofing (in certain circumstances) to redirect the victim (router/embedded device) to a malicious domain under the attacker’s control rather than the legitimate domain infrastructure. DNS cache poisoning has been both a widely known attack and an attack enabler since the ‘90s. So what is DNS cache poisoning?
When a computer or other device requests the IP address for intra/internet destinations from a DNS server, the resolved address is stored in short term cache memory to speed up subsequent queries for the same destination. For instance, suppose you’re the first person in your office out of 100 employees on Monday morning. You grab your morning go-juice of choice, fire up your computer, and check Google for the where you can get the best price on something you saw over the weekend. Your computer requests the upstream DNS servers to provide the current IP address for Google, and subsequently, whatever website you click on. Now, imagine every employee does the same thing X 100. Your computer and the DNS server/router store the resultant information in local memory so that when your coworkers also search Google for [whatever], the network already has the answer rather than 100 requests to the internet for the same IP address. Network optimization at its finest.
However, when this vulnerability is exploited, that locally cached answer for any/all domains can be ‘poisoned’ such that a request for Google’s IP address (or any internet destination) could in fact be overwritten to point to a malicious domain. (See Figure 1) But wouldn’t you know immediately? As a user, not necessarily. Malicious domains can be set up to deliver additional malware via browser exploits that give them more access to your network, or they can conduct man-in-the-middle attacks to intercept all your internet traffic. While attackers may not be interested in your shopping habits, imagine if you were visiting your financial institution to make sure you have enough money to buy that designer coffee table you found. They could intercept your login credentials and steal your money.
Figure 1, DNS Cache Poisoning
While the potential impact is difficult to assess, whether it be to the individual or to the organization, one thing is certain: we want to keep unauthorized threat actors out of our networks. Given the state of many organizational networks, the common use of enterprise-grade DNS servers leveraging DNSSEC would render this attack vector largely ineffective. However, many home networks that utilize SOHO retail router access points are not as robust, which makes this vulnerability more impactful. Home networks are very susceptible to a litany of attacks, and for the work-from-anywhere (WFA) employee, this introduces additional risks to organizational systems operating on these home networks. Enterprise managers need to ensure they’re leveraging an organizationally configured protective DNS solution (i.e. BloxOne Threat Defense Cloud Resolver) and logging DNS queries/responses from WFA devices.
In summary, the technique is not new and is relatively easy to thwart: implement DNSSEC on enterprise DNS servers and leverage a protective DNS solution to stop resolution to malicious domains. As always, if you have any questions specific to your organization’s susceptibility to this vulnerability or any other DNS-related questions, we invite you to contact your account team.
