Risks in IoT Supply Chain

By and

Category: Unit 42


The image illustrates the concepts of adversaries, such as those that might attempt to attack the IoT supply chain

This post is also available in: 日本語 (Japanese)

Executive Summary

The COVID-19 pandemic has accelerated the adoption of IoT devices. As businesses slowly reopen during the pandemic, contactless IoT devices such as point of sale (POS) terminals and body temperature cameras have been widely adopted to keep business operations safe. Palo Alto Networks research shows 89% of IT decision-makers globally reported that the number of IoT devices on their organization's network increased over the last year, with more than a third (35%) reporting a significant increase. Additionally, International Data Corporation (IDC) estimates that there will be 41.6 billion connected IoT devices in 2025.

However, this trend increases the attack surface, which is likely to attract more attacks and exploits targeting IoT devices and IoT supply chains. Here, Unit 42 looks into the current IoT supply chain ecosystem, and explains the multi-layer threats and weaknesses impacting IoT supply chains. No layer is completely intact. We also examine potential types of motivation for attacking the IoT supply chain. Having an understanding of risks and real-world examples at hardware, firmware, operation and vulnerability layers can help effectively develop risk control and mitigation strategies, which prevent a successful cyber attack from becoming a reality.

IoT Supply Chain Risk

A supply chain is the series of links between a vendor, manufacturer or retailer and their providers, which make it possible to manufacture and provide hardware or software products or operational services to consumers.

An illustration that sketches out the IoT supply chain, ranging from material to producer to logistics to vendor to retailer to consumer.
Figure 1. A big-picture view of a supply chain.

Frequently, when someone talks about supply chain attacks in IoT, the conversation is about software that is going to be installed in a certain IoT device, such as a router or a camera, which has been compromised to hide malware. However, a supply chain attack in IoT can also refer to a piece of hardware that has been implanted or modified to change the devices’ behavior. It is also important to consider supply chain vulnerabilities, in which third-party software (such as libraries, drivers, kernels or hardware components) with vulnerabilities is installed or is part of certain components, such as an app or firmware.

IoT device components can also be subject to IoT supply chain attacks. Components shown here include hardware (SoC, Memory, Sensors, Peripherals), operating system, kernel, libraries, and applications or user programs.
Figure 2. IoT device components.

A common malpractice during the software development lifecycle and during the process of product design is to incorporate third-party software and hardware components without listing the components that have been added to the device. As a consequence, when a new vulnerability is uncovered on one of these components – such as a zero-day vulnerability – it is hard to know how many products of the same vendor are affected (here is an example of this scenario). Even worse, it may be difficult to determine how many devices in general, across different vendors and manufacturers, are affected by this vulnerability. Oftentimes, firmware installed on different devices is using deprecated libraries or components that are known to contain vulnerabilities. Nonetheless, this firmware may still be used in production in many devices that are in the market.

From the user perspective, it is difficult to know which components are operating inside any IoT device being purchased. Those components have intrinsic security properties and those properties depend on other components that in turn have their own security properties. If any one of these components is vulnerable, an attacker can compromise the entire device. Moreover, users managing networks with IoT devices do not always keep an inventory of the number of IoT devices connected to that network. As a consequence, keeping track of potentially vulnerable devices present in a corporate network turns security and risk management into a tough task – increasing the chances of a successful cyber attack.

Examples of IoT Supply Chain Attacks

Hardware Component – Counterfeit Cisco Switches

In July 2020, F-Secure analyzed counterfeit Cisco Catalyst 2960-X Series Switches discovered in a business environment. The equipment functioned smoothly for a long period of time, which made them hard to detect as counterfeit. Eventually, the devices were found failing after a software upgrade, which led to their discovery. The analysis not only highlighted how authentication control was bypassed, but also how the potential backdoor access might pose network security risks on affected companies.

Firmware – OpenWrt Devices

OpenWrt is an open source operating system that can replace the ones included on different vendors’ firmware from a number of network devices such as routers, access points and Wi-Fi repeaters. According to the OpenWrt Project webpage, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application. For developers, OpenWrt is a framework that can be used to build an application without having to build a complete firmware around it. For users, OpenWrt offers full customization and use of the device in ways the original device does not support.

In March 2020, a vulnerability found in OpenWrt allowed attackers to impersonate downloads from downloads.openwrt.org and make the devices download malicious updates. This means that several routers across different vendors and models were impacted by this vulnerability.

Operation Disruption – TeamViewer

Hoping for either operation disruption or access to internal business networks, malicious threat actors have had their eyes on remote operation software for years. Many of us are familiar with remote support software that allows users to share their desktop or administrator controls over the internet from anywhere in the world. TeamViewer is one of the most well-known examples of remote support software. As of May 2020, TeamViewer software has 200 million users across 200 countries in the world. TeamViewer is also used to monitor operational technology (OT) environments including manufacturing, energy and even healthcare.

Previously, we have seen hackers directly targeting TeamViewer users by brute-forcing account credentials and sending out spear-phishing emails to government agencies across the EMEA region (see this CheckPoint report). In addition, TeamViewer itself was allegedly targeted by APT threat actors back in 2016. Though the actual damage of these attacks is unknown, these incidents shed light on the activities of those with malicious intentions of abusing remote control software and the possible impact that can come with a successful attack.

Library Containing Vulnerabilities – Ripple20

In June 2020, JSOF announced 19 zero-day vulnerabilities affecting millions of devices running a low-level TCP/IP software library developed by Treck. This group of vulnerabilities has been named "Ripple20" to reflect the widespread impact the exploitation of these flaws could have on a wide range of products from various industries. Ripple20 impacts critical IoT devices, including printers, infusion pumps and industrial control devices. By exploiting the software library flaws, attackers could remotely execute code and gain access to sensitive information. The impact of these vulnerabilities is exacerbated by the fact that Ripple20 is a supply chain vulnerability, which means that it’s hard to track all the devices that make use of this library.

As of now, the following vendors have inventory that are affected by Ripple20:

Aruba Networks HP Inc.
B. Braun Hewlett Packard Enterprise
Baxter Intel
Beck/HMS Industrial Networks AB MaxLinear (through HLFN)
CareStream Opto22
Caterpillar Ricoh
Cisco Rockwell automation
Dell Samsung
Digi International Schneider Electric/APC
Eaton Teradici
Green Hills Software Xerox
HCL Technologies Zuken Elmic

Types of Motivation for Attacks on the IoT Supply Chain

Cyberespionage Perspective

The main goals for cyberespionage campaigns are maintaining long-term access to confidential information and to affected systems without being detected. The wide range of IoT devices, the access they have, the size of the user base and the presence of trusted certificates make supply chain vendors attractive targets to advanced persistent threat (APT) groups. In 2018, Operation ShadowHammer revealed that legitimate ASUS security certificates (such as “ASUSTeK Computer Inc.”) were abused by attackers and signed trojanized softwares, which misled targeted victims to install backdoors in their system and download additional malicious payloads onto their machines.

Cybercrime Perspective

The potential access and impact of compromising a large number of IoT devices also make IoT vendors and unprotected devices popular choices for financially motivated cybercriminals. A NICTER report in 2019 shows close to 48% of dark web threats detected are IoT related. Also in 2019, Trend Micro researchers looked into cybercriminals in Russian-, Portuguese-, English-, Arabic-, and Spanish-speaking marketplaces and discovered various illicit services and products that are actively exploiting IoT devices. The commonly seen monetization approaches to cash out compromised IoT devices include:

  • Setting up a botnet or DDoS service for hire and charging other underground threat actors.
  • Selling infected devices as VPN exit nodes.
  • Selling camera access to spy on someone or selling access to their video.
  • Developing and selling cryptojacking malware targeting IoT devices.
This screenshot shows a Russian-language advertisement selling access to hacked IoT devices in Moscow.
Figure 3. Underground advertisement selling access to cameras in Moscow.

As the number of IoT devices increase in healthcare, manufacturing, energy and other OT environments, we expect to see both cyberespionage campaigns and cybercriminals developing new approaches to exploit the opportunities.


  • Implement secure software development lifecycles and consider the integration of third-party libraries.
  • Implement code reviews and security assessments of your own code and code integrated from external sources.
  • Avoid the usage of counterfeit hardware or hardware of dubious provenance.
  • Review the design and development process of third-party software and hardware, as well as vendors’ processes for addressing vulnerabilities.
  • Follow NIST’s cyber supply chain best practices:
    • Develop your defenses based on the principle that your systems will be breached.
    • Cybersecurity is never a technology problem. It is a people, process and knowledge problem.
    • Security is security: There should be no gap between physical security and cybersecurity.
  • Keep a list of hardware and software components used on the IoT/OT devices.


It is critical to maintain a list of devices connected to the network in order to identify devices, and the vendors or manufacturers of those devices, which make use of a vulnerable component so the administrator can patch them, monitor them or disconnect them if needed. Additionally, as mentioned before, sometimes the entire list of vulnerable devices is unknown. However, having complete visibility of the devices connected to the network and getting notified when a device is generating anomalous traffic is critical to defending your infrastructure.

Finally, it is imperative to implement secure software development lifecycles and consider the integration of third-party libraries. The National Institute of Standards and Technology has documented a series of best practices to facilitate supply chain risk management.

Palo Alto Networks Next-Generation Firewalls with an IoT Security subscription take different approaches to anomalous traffic detection:

  • Device identification: Analyzes network behavior and extracts various network data points from the IoT devices and derives device identity attributes such as vendor, model, firmware version, operating system, etc. This is done through an AI/ML-powered identity inference engine built as part of the IoT security service.
  • Identification of vulnerable devices: Based on CVE descriptions published by authorities such as MITRE and ICS-CERT, devices are matched with their corresponding vulnerabilities based on the device identification results. The IoT security service offers a real-time threat detection engine that also finds vulnerable devices when a targeted vulnerability scan or a malicious exploit triggers response from these devices.
  • Risk score: A risk score is given to every IoT device connected to the network. The calculated risk score is based on a risk model that factors in confirmed vulnerabilities, detected threats, behavioral anomalies and risks as a result of risky user practices, published manufacturer risks in MDS2, etc. This is a critical element for identifying devices that need priority attention and helping administrators determine the best policies needed in their networks.
  • Alerts: Several processes are involved to raise an alert based on abnormal network behavior, risky communications, known attacks and other factors. This feature is highly important for identifying attacks occurring in realtime.
The screenshot shows the type of information that can be determined about an IoT device on a network – in this case, an Axis camera.
Figure 4. Device attributes of an identified Axis camera.

Example of the IoT vulnerability dashboard page:

The screenshot shows an example of identifying devices on a network that are vulnerable to CVE-2019-1181. The detected devices are broken out in a graphic categorized by profile (i.e. Windows server).
Figure 5. Identified devices vulnerable to CVE-2019-1181.
The screenshot shows an example of identifying devices on a network that are vulnerable to CVE-2020-11896. The detected devices are broken out in a graphic categorized by profile (in this case, showing only one type of device).
Figure 6. Identified devices vulnerable to CVE-2020-11896.