Over the course of a research project focusing on a specific cable modem, we identified that the system was using a dual-SoC design. The main SoC was running a Linux system, while the second SoC – a dedicated Realtek RTL819xD chipset implementing all the access point functions – was found to be running another, stripped-down Linux system from Realtek.
Realtek chipsets are found in many embedded devices in the IoT space. RTL8xxx SoCs – which provide wireless capabilities – are very common. We therefore decided to spend time identifying binaries running on the RTL819xD on our target device, which expose services over the network and are provided by Realtek themselves. Such binaries are packaged as part of the Realtek SDK, which is developed by Realtek and provided to vendors and manufacturers who use the RTL8xxx SoCs.
Supported by IoT Inspector’s firmware analysis platform, we performed vulnerability research on those binaries and identified more than a dozen vulnerabilities – ranging from command injection to memory corruption affecting UPnP, HTTP (management web interface), and a custom network service from Realtek.By exploiting these vulnerabilities, remote unauthenticated attackers can fully compromise the target device and execute arbitrary code with the highest level of privilege.
We identified at least 65 different affected vendors with close to 200 unique fingerprints, thanks both to Shodan’s scanning capabilities and some misconfiguration by vendors and manufacturers who expose those devices to the Internet. Affected devices implement wireless capabilities and cover a wide spectrum of use cases: from residential gateways, travel routers, Wi-Fi repeaters, IP cameras to smart lightning gateways or even connected toys.
Realtek SDK Vulnerabilities
As awareness for supply chain transparency is on the rise among security experts, this example is a pretty good showcase of the vast implications of an obscure IoT supply chain. As opposed to recent supply chain attacks such as Kaseya or Solar Winds, where perpetrators went to great lengths to infiltrate the vendor’s release processes and place hidden backdoors in product updates, this example is far less sophisticated – and probably way more common, for three simple reasons:
On the supplier’s end, insufficient secure software development practices, in particular lack of security testing and code review, resulted in dozens of critical security issues to remain untouched in Realtek’s codebase for more than a decade (from 2.x branch through “Jungle“ SDK to “Luna” SDK).
On the product vendor’s end, we see manufacturers with access to the Realtek source code (a requirement to build Realtek SDK binaries for their own platform) who missed to sufficiently validate their supply chain, left the issues unspotted and distributed the vulnerabilities to hundreds of thousands of end customers – leaving them vulnerable to attacks.
But supply chain issues can go upstream, too. During our research, we discovered that security researchers and pen-testers have previously identified issues in devices relying on the Realtek SDK, but didn’t link these issues to Realtek directly. Vendors who received reports of these vulnerabilities fixed them in their own branch but did not notify Realtek, leaving others exposed.
Our firmware analysis platform IoT Inspector can support in detecting such crucial supply chain issues. It automatically detects whether a firmware is based on a vulnerable Realtek SDK, along with its specific version. It can also detect each vulnerability we reported, and whether or not the provided patch has been applied.
Please keep reading for the full details of our research process.
[...CONTENT OMITTED FOR BREVITY BUT REMAINS UNCHANGED...]
2021-05-17 – Ask Realtek security team for a way to send our report securely.
2021-05-18 – Realtek security team provides their PGP key, we send encrypted advisories.
2021-05-25 – Realtek security team request Python PoC scripts.
2021-05-25 – We provide scripts for every reported vulnerability.
2021-06-10 – Realtek security team provides us the patched code, along with a patched firmware for the 96D_92D demo boards.
2021-06-10 – We review the patch and send our comments related to checks that could still be bypassed.
2021-06-11 – Realtek security team provides us with the exact list of affected versions for “Jungle” and “Luna” SDKs. The 2.x branch is no longer supported by Realtek, being 11 years old.
2021-06-16 – We request CVE identifiers from MITRE.
2021-08-05 – We receive CVE identifiers from MITRE.
2021-08-13 – Realtek publish its advisory.
2021-08-16 – End of 90 days disclosure window, releasing this post.
List of (known) affected manufacturers
<code>Key Takeaways
As awareness for supply chain transparency is on the rise among security experts, this example is a pretty good showcase of the vast implications of an obscure IoT supply chain. As opposed to recent supply chain attacks such as Kaseya or Solar Winds, where perpetrators went to great lengths to infiltrate the vendor’s release processes and place hidden backdoors in product updates, this example is far less sophisticated – and probably way more common, for three simple reasons:
On the supplier’s end, insufficient secure software development practices, in particular lack of security testing and code review, resulted in dozens of critical security issues to remain untouched in Realtek’s codebase for more than a decade (from 2.x branch through “Jungle“ SDK to “Luna” SDK).
On the product vendor’s end, we see manufacturers with access to the Realtek source code (a requirement to build Realtek SDK binaries for their own platform) who missed to sufficiently validate their supply chain, left the issues unspotted and distributed the vulnerabilities to hundreds of thousands of end customers – leaving them vulnerable to attacks.
But supply chain issues can go upstream, too. During our research, we discovered that security researchers and pen-testers have previously identified issues in devices relying on the Realtek SDK, but didn’t link these issues to Realtek directly. Vendors who received reports of these vulnerabilities fixed them in their own branch but did not notify Realtek, leaving others exposed.
Our firmware analysis platform IoT Inspector can support in detecting such crucial supply chain issues. It automatically detects whether a firmware is based on a vulnerable Realtek SDK, along with its specific version. It can also detect each vulnerability we reported, and whether or not the provided patch has been applied.
Please keep reading for the full details of our research process.
[...CONTENT OMITTED FOR BREVITY BUT REMAINS UNCHANGED...]
Timeline
2021-05-17 – Ask Realtek security team for a way to send our report securely.
2021-05-18 – Realtek security team provides their PGP key, we send encrypted advisories.
2021-05-25 – Realtek security team request Python PoC scripts.
2021-05-25 – We provide scripts for every reported vulnerability.
2021-06-10 – Realtek security team provides us the patched code, along with a patched firmware for the 96D_92D demo boards.
2021-06-10 – We review the patch and send our comments related to checks that could still be bypassed.
2021-06-11 – Realtek security team provides us with the exact list of affected versions for “Jungle” and “Luna” SDKs. The 2.x branch is no longer supported by Realtek, being 11 years old.
2021-06-16 – We request CVE identifiers from MITRE.
2021-08-05 – We receive CVE identifiers from MITRE.
2021-08-13 – Realtek publish its advisory.
2021-08-16 – End of 90 days disclosure window, releasing this post.
Appendix
List of (known) affected manufacturers
</code>
Key Takeaways
As awareness for supply chain transparency is on the rise among security experts, this example is a pretty good showcase of the vast implications of an obscure IoT supply chain. As opposed to recent supply chain attacks such as Kaseya or Solar Winds, where perpetrators went to great lengths to infiltrate the vendor’s release processes and place hidden backdoors in product updates, this example is far less sophisticated – and probably way more common, for three simple reasons:
On the supplier’s end, insufficient secure software development practices, in particular lack of security testing and code review, resulted in dozens of critical security issues to remain untouched in Realtek’s codebase for more than a decade (from 2.x branch through “Jungle“ SDK to “Luna” SDK).
On the product vendor’s end, we see manufacturers with access to the Realtek source code (a requirement to build Realtek SDK binaries for their own platform) who missed to sufficiently validate their supply chain, left the issues unspotted and distributed the vulnerabilities to hundreds of thousands of end customers – leaving them vulnerable to attacks.
But supply chain issues can go upstream, too. During our research, we discovered that security researchers and pen-testers have previously identified issues in devices relying on the Realtek SDK, but didn’t link these issues to Realtek directly. Vendors who received reports of these vulnerabilities fixed them in their own branch but did not notify Realtek, leaving others exposed.
Our firmware analysis platform IoT Inspector can support in detecting such crucial supply chain issues. It automatically detects whether a firmware is based on a vulnerable Realtek SDK, along with its specific version. It can also detect each vulnerability we reported, and whether or not the provided patch has been applied.
Please keep reading for the full details of our research process.
[...CONTENT OMITTED FOR BREVITY BUT REMAINS UNCHANGED...]
Timeline
2021-05-17 – Ask Realtek security team for a way to send our report securely.
2021-05-18 – Realtek security team provides their PGP key, we send encrypted advisories.
2021-05-25 – Realtek security team request Python PoC scripts.
2021-05-25 – We provide scripts for every reported vulnerability.
2021-06-10 – Realtek security team provides us the patched code, along with a patched firmware for the 96D_92D demo boards.
2021-06-10 – We review the patch and send our comments related to checks that could still be bypassed.
2021-06-11 – Realtek security team provides us with the exact list of affected versions for “Jungle” and “Luna” SDKs. The 2.x branch is no longer supported by Realtek, being 11 years old.
2021-06-16 – We request CVE identifiers from MITRE.
2021-08-05 – We receive CVE identifiers from MITRE.
2021-08-13 – Realtek publish its advisory.
2021-08-16 – End of 90 days disclosure window, releasing this post.
Appendix
List of (known) affected manufacturers
Key Takeaways
As awareness for supply chain transparency is on the rise among security experts, this example is a pretty good showcase of the vast implications of an obscure IoT supply chain. As opposed to recent supply chain attacks such as Kaseya or Solar Winds, where perpetrators went to great lengths to infiltrate the vendor’s release processes and place hidden backdoors in product updates, this example is far less sophisticated – and probably way more common, for three simple reasons:
On the supplier’s end, insufficient secure software development practices, in particular lack of security testing and code review, resulted in dozens of critical security issues to remain untouched in Realtek’s codebase for more than a decade (from 2.x branch through “Jungle“ SDK to “Luna” SDK).
On the product vendor’s end, we see manufacturers with access to the Realtek source code (a requirement to build Realtek SDK binaries for their own platform) who missed to sufficiently validate their supply chain, left the issues unspotted and distributed the vulnerabilities to hundreds of thousands of end customers – leaving them vulnerable to attacks.
But supply chain issues can go upstream, too. During our research, we discovered that security researchers and pen-testers have previously identified issues in devices relying on the Realtek SDK, but didn’t link these issues to Realtek directly. Vendors who received reports of these vulnerabilities fixed them in their own branch but did not notify Realtek, leaving others exposed.
Our firmware analysis platform IoT Inspector can support in detecting such crucial supply chain issues. It automatically detects whether a firmware is based on a vulnerable Realtek SDK, along with its specific version. It can also detect each vulnerability we reported, and whether or not the provided patch has been applied.
Please keep reading for the full details of our research process.
[...CONTENT OMITTED FOR BREVITY BUT REMAINS UNCHANGED...]
Timeline
2021-05-17 – Ask Realtek security team for a way to send our report securely.
2021-05-18 – Realtek security team provides their PGP key, we send encrypted advisories.
2021-05-25 – Realtek security team request Python PoC scripts.
2021-05-25 – We provide scripts for every reported vulnerability.
2021-06-10 – Realtek security team provides us the patched code, along with a patched firmware for the 96D_92D demo boards.
2021-06-10 – We review the patch and send our comments related to checks that could still be bypassed.
2021-06-11 – Realtek security team provides us with the exact list of affected versions for “Jungle” and “Luna” SDKs. The 2.x branch is no longer supported by Realtek, being 11 years old.
2021-06-16 – We request CVE identifiers from MITRE.
2021-08-05 – We receive CVE identifiers from MITRE.
2021-08-13 – Realtek publish its advisory.
2021-08-16 – End of 90 days disclosure window, releasing this post.
Appendix
List of (known) affected manufacturers
