Site Color

Text Color

Ad Color

Text Color

Evergreen

Duotone

Mysterious

Classic

Sign Up to Save Your Colors

or

Crack Open the IoT Vulnerabilities of Realtek by@z3nch4n

Crack Open the IoT Vulnerabilities of Realtek

image
Zen Chan Hacker Noon profile picture

Zen Chan

Interested in Infosec & Biohacking. Security Architect by profession. Love reading and running.

Photo by Daniele Levis Pelusi on Unsplash

Taiwanese chip designer Realtek has warned of four recent vulnerabilities in three SDKs in its WiFi modules. Realtek also published an advisory regarding those flaws used in almost 200 products made by multiple vendors.

The vulnerabilities, according to 
Realtek’s advisory
, allow remote access without authentication by the attacker.
Also, the flaws can lead to service denial, device crashes, inject arbitrary commands, and finally gaining complete control of the device's highest level of privilege.

Conservatively, according to the advisory, almost a million vulnerable devices may be in use, including VoIP devices, wireless routers, repeaters, IP cameras, and smart lighting controls, possibly any WiFi-connected devices with that chip design.

The list of hardware manufacturers affected by Realtek’s vulnerabilities includes ASUS, Belkin, D-Link, Edimax, Logitech, Netgear, ZTE, and more. After IoT Inspector reported the flaws, Realtek immediately responded and provided appropriate patches for the respective WiFi module.

Findings

IoT Inspector Research Lab disclosed the vulnerabilities, a security firm focused on IoT, in May. More than 65 hardware vendors use the Realtek chip RTL819xD module, which is widely used for wireless access points and includes one of the vulnerable SDKs.

Those four CVEs are rated as high and critical severity (CVSS score of two 8.1 and two 9.8 accordingly). One requirement for these flaws is the attacker need to be on the same WiFi network as the targeted device. However, if the device can reach over the internet, it is also vulnerable.

  • CVE-2021–35392 (High — ‘WiFi Simple Config’ stack buffer overflow via UPnP)
  • CVE-2021–35393 (High — ‘WiFi Simple Config’ heap buffer overflow via SSDP)
  • CVE-2021–35394 (Critical — MP Daemon diagnostic tool command injection)
  • CVE-2021–35395 (Critical — management web interface multiple vulnerabilities)

As such, these security bugs are possibly to be exploited by malware on someone’s PC to hijack their cable internet router and smart home gear. It can also be used to recruit public Wi-Fi spots, and so on. Unstudied ISP configurations could also expose vulnerable devices directly to the Internet.

Affected Versions

More details are available in the Realtek advisory, which lists these versions:

rtl819x-SDK-v3.2.x Series

rtl819x-SDK-v3.4.x Series

rtl819x-SDK-v3.4T Series

rtl819x-SDK-v3.4T-CT Series

rtl819x-eCos-v1.5.x Series

Fixed Versions

  • Realtek SDK branch 2.x: no longer supported by Realtek
  • Realtek “Jungle” SDK: patches will be provided by Realtek and needs to be backported
  • Realtek “Luna” SDK: version 1.3.2a contains fixes

Key Takeaways — Not Another Sunburst Incident but Deadly

As recognition for supply chain transparency is rising among the security industry, this example is a good showcase of the widespread implications of an obscure IoT supply chain.

Unlike recent supply chain attacks such as Kaseya or Solar Winds, attackers try all their effort to infiltrate the vendor’s release processes and place covert backdoors in product updates.

This time, these flaws are far less sophisticated, apparently more common, and could be prevented by enforcing better Cyber Hygiene.

  1. For Realtek: lacking secure software development practices, particularly insufficient security testing and code review, resulted in dozens of critical security issues remaining untouched in Realtek’s codebase for more than a decade (from 2.x branch through “Jungle“ SDK to “Luna” SDK).
  2. For product vendors: it is alarming that manufacturers have access to the Realtek source code (a requirement to build Realtek SDK binaries for their platform). Which they missed verifying their supply chain left the issues unnoticed adequately. As a result, they spread the vulnerabilities to hundreds of thousands of end customers — leaving millions of devices vulnerable to attacks.
  3. Supply chain attacks can go upstream, too. Without proper software development lifecycle practices, the problems previously identified by security researchers relying on the Realtek SDK did not link back to the root. As a result, issues fixed in vendors’ product level do not feedback Realtek, thus exposing others.

Identifying Affected Vendors

To identify devices affected by the vulnerabilities identified, I rely on the famous “IoT Google search engine”— Shodan. According to the advisory, the vulnerability exists in version 1.3 of the SDK, but older versions might also be affected.

image

The Simple search of “https://www.shodan.io/search?query=RealTek%2Fv1.3” | Screenshot by the author

Shodan exposes the model name, number, and description as the “product” aspect. Therefore, using Shodan can retrieve all vendors and model names exposed over the Internet based on the vulnerable Realtek SDK.

It’s worth noting that even a device does not respond to the search, only saying it is not vulnerable to the Internet directly. But it is still susceptible to attacks over the local network if it uses the vulnerable component.

Final Words

With the patch is released, there would still be a wide range of devices that remain unpatched — such as the case for public WiFi services, like coffee shops and restaurants.

Moreover, patching an IoT is not like what you do on your computer. After Realtek released the patches, it doesn’t imply product vendors follow; Say ASUS may be able to come up with a patch for the affected router, or at least not as timely. Needless to say, there are multiple vendors involved, with a wide range of products in use.

It is perhaps worth adding that everyone can find affected hardware using the Shodan vulnerability search engine, which means hackers can do the same.

Learning from mistakes, hardware vendors should consider the importance of maintaining a better SDLC with security embedded, not bolted-on. The more significant question, though, is how to push substantive changes — and implement adequate protection— as more and more of these types of vulnerabilities pile up.

Thank you for reading. May InfoSec be with you🖖.

Also published here.


Tags