The Home of the Security Bloggers Network

Home » Security Bloggers Network » Hardware Supply Chain Compromise in Human Interface Devices: Nozomi Networks + Hydro Quebec Joint Research

Threat actors have been leveraging vulnerabilities found in the less secure parts of a supply chain in an effort to launch large-scale attacks. Such attacks can occur in any institution or industry, from electrical energy providers and transportation to pharmaceutical manufacturing and food production. For more information on software supply chain attacks you can read our 2021 OT/IoT Security report .

There are two main types of supply chain compromises that can potentially lead to cyberattacks:

Compromised Human Interface Devices (HID) such as a mouse, keyboard, or other USBs, which can be found in offices or industrial environments, can be adapted to perform physical attacks. Imagine the cyber-physical effect of an insider plugging a compromised keyboard/mouse into a workstation or Human Machine Interface (HMI). With the aim of setting up a proof of concept, Nozomi Networks and the Hydro-Québec Research Institute (IREQ) will explain how to detect, notify, and recommend proper countermeasures around compromised hardware devices.

Nozomi Networks Labs’ and Hydro Quebec’s joint research demonstrates how air-gapped HID devices like keyboards could be compromised by threat actors at the supply chain level, which could pose a threat to OT environments. 

Supply chain risks are still very impactful and can lead to process disruption and cyber espionage. Nozomi Networks Labs and IREQ’s cybersecurity research teams are currently reproducing real-world attack scenarios to aid in the development of technology that contributes to detecting supply chain attacks, reducing cybersecurity risks, and providing full visibility to asset owners and security engineers.

The current challenge that industrial operators are facing is the limited visibility inside critical devices potentially exposed to supply chain compromise. To address this challenge, Nozomi Networks Labs has been working with IREQ on a cutting-edge cybersecurity research project. By building a compromised USB device which executes a malicious payload once connected to the target machine, this research project provides insights into how to detect hardware supply chain compromises that can be a component of more complicated attack scenarios.

To prepare for the research, Nozomi Networks Labs purchased the necessary hardware used to demonstrate an example of supply chain compromises (Figure 1):

Figure 1 – Research project hardware (from left to right) Trust USB keyboard , Raspberry Pi Zero, optical mouse.  

The Raspberry Pi can be easily embedded into both target devices to ensure it will be connected to the PC using a single USB cable. There are two different approaches that can be used to connect the USB controller and the Raspberry Pi using a single wire. The first approach leverages a tiny USB hub that receives inputs from the USB cables of the Raspberry Pi and the device, while the second approach maps all of the functional keys to the Raspberry Pi’s general purpose input/outputs (GPIOs). Both approaches present pros and cons:

Approach 1: During the first stage of our research, we started exploring the first approach by adding the malicious hardware inside a classic optical mouse, as shown in the images below.

This approach is easy to implement by creating space in the keyboard to host the Raspberry Pi and a tiny USB hub model . Once the USB cables are connected and the Raspberry Pi is properly programmed, it is possible to use both the Raspberry Pi and the device simultaneously. A con to this approach is that the detection of such a compromised hardware is very easy. In fact, it can be done by simply counting the number of HIDs that are added when the keyboard is plugged into the PC.

Figure 2a and 2b – Malicious hardware embedded into an optical mouse

Approach 2: The second approach (based on the keyboard) aims at making hardware detection a bit more challenging, by mapping all the keyboard keys to the Raspberry Pi’s GPIOs. Unlike the first approach, the PC in this approach does not have the ability to detect malicious hardware by counting the number of HIDs connected. Since the keyboard USB controller is not used in this approach and the keys are directly connected to the Raspberry Pi, the Raspberry Pi USB interface will be detected and not the HID itself. A con to this approach is the complexity of the connections.

We decided to expand the complexity of our research by considering the second and more challenging approach that aims at creating a hard-to-detect scenario. Now let’s take a look at the hardware implementation in detail.

The internal USB keyboard (Figure 3) is made up of a small Printed Circuit Board (PCB) hosting the keys’ connection, the USB controller, and the two plastic layers containing the conductive tracks. Think of the keyboard layout like a matrix, with rows and columns where each key is identified through the row and the column it is connected to. So, when a key is pressed, the two layers that meet at a single point in the PCB is short circuited; this is how the USB controller processes that a certain key has been pressed.

Figure 4 – Keyboard’s USB controller

Figure 5 – Compromised keyboard using a Raspberry Pi

To build the compromised keyboard, the PCB had to be replicated, so instead of embedding the USB controller (Figure 4), only the connection of the plastic layers had been reproduced, making it easy to connect them to the Raspberry Pi.

As seen in Figure 3, the keyboard matrix is organized into 8 rows and 18 columns, so 26 connections (for the 26 letters of the English alphabet) need to be mapped into the Raspberry Pi GPIOs. The Raspberry Pi Zero has exactly 26 configurable GPIOs, so it was a perfect choice for this application.

Figure 5 shows the complete keyboard with the 26 jumper wires coming from it and going into the Raspberry Pi’s GPIOs. From the Raspberry Pi, only one USB cable is connected to the PC, so the operating systems will detect only the “fake” HID generated by the Raspberry. Once the USB is connected, the Raspberry Pi sends a set of predefined inputs (i.e. Powershell commands) that will be executed into the target machine. It is sufficient to plug in the compromised keyboard just once for the malicious payload to start executing in the target machine, thus enabling the Raspberry Pi to proxy the keystrokes through its GPIO with the keyboard remaining undetectable.

Of note, the purpose of this research study is to focus on the best ways to detect compromised HIDs in multiple attack scenarios, hence why we decided to use visible hardware outside of the keyboard. One important step in our roadmap is to build hardware small enough to be placed inside the keyboard, ensuring that the malicious components are completely hidden.

Below, Figure 6 shows the output of the List USB command lsusb before the malicious keyboard is connected to the PC, while Figure 7 shows the output of lsusb after the malicious keyboard is connected to the PC. Figure 7 lists the compromised keyboard, connected to the PC via a Raspberry Pi, as legitimate due to the ability to modify/create a name and serial number of the keyboard. Last but not least, only one additional HID is present, confirming that the extra hardware is invisible to the operating system and lowering the chances of detection by an operator.

Figure 6 – Output of the List USB command lsusb

Figure 7 – Output of lsusb after the malicious keyboard is connected to the PC

Nozomi Networks & IREQ are currently working on a proof of concept that aims at creating a new technology for the detection of malicious devices that may appear legitimate to a PC, including hard-to-detect scenarios. Being that an attacker may want to run malicious code as fast as possible, a promising approach in detecting a malicious device is the typing rate; the typing rate for running code being too high for it to feasibly be a human being. Nozomi Networks and the IREQ cybersecurity research teams will continue to explore additional methods for detecting HID supply chain compromises, working on solutions to support asset owners and sharing more insights in the future. Stay tuned.

The post Hardware Supply Chain Compromise in Human Interface Devices: Nozomi Networks + Hydro Quebec Joint Research appeared first on Nozomi Networks.

*** This is a Security Bloggers Network syndicated blog from Nozomi Networks authored by Nozomi Networks Labs. Read the original post at: https://www.nozominetworks.com/blog/hardware-supply-chain-compromise-in-human-interface-devices-nozomi-networks-hydro-quebec-joint-research/

Step 1 of 6 16% Have security concerns slowed or prevented your use of Kubernetes? Yes, security concerns are preventing us from deploying Kubernetes Yes, but we are moving forward and working to improve Kubernetes security No, we know how to secure Kubernetes No, but we still have security concerns What are your top Kubernetes security concerns? Pod security policy management Image supply chain integrity Configuration errors Over provisioning of permissions Writing and enforcing security policies Runtime threat/incident detection What are your greatest challenges securing Kubernetes? Lack of the necessary K8s security skills Time and resources to address K8s security Point K8s security solutions don't fit into our DevOps workflows Current vendors we use do not adequately address K8s security Lack the understanding of K8s security policy best practices Is Kubernetes pod security a priority for your organization? Yes, we have an funded, active project Yes, it is a priority for 2023 Somewhat, we address on a project-by-project basis No, but we know we need to do more with Kubernetes security No, not currently a significant issue What are your sources for Kubernetes policy management? Open source software Kubernetes native Pod Security Policies Commercial security product offering Cloud service provider security offerings Do not have a solution at this time What role is responsible for Kubernetes security in your organization? Development DevOps DevSecOps Security Platform Engineering Δ