Security Analysis of Embedded Devices

Version	Summary	Created by	Modification	Content Size	Created at	Operation
1		Peng Xun	--	1377	2023-12-17 11:56:39	\|
2	layout	Camila Xu	Meta information modification	1377	2023-12-18 03:21:45	\|

This entry is adapted from the peer-reviewed paper 10.3390/s23229221

Embedded devices are pervasive nowadays with the rapid development of the Internet of Things (IoT). This brings significant security issues that make the security analysis of embedded devices important.

embedded device security analysis fuzzing emulation static analysis

1. Introduction

With the rapid development of the Internet of Things (IoT) and modern smart devices, embedded computing systems that are small and cheap become ubiquitous. Embedded devices are applied in industry, education, and our everyday life. We can find embedded devices almost everywhere, such as WiFi routers at home, IP cameras in the streets, network printers at offices, traffic lights on roads, the control systems in modern cars, the smartwatch we wear, drones we fly, and even toys our children play with. As IoT Analytics estimated, there were 12.2 billion active IoT devices globally by the end of 2021. The number will grow by 18% to 14.4 billion by the end of 2022, and it is expected to be approximately 27 billion by 2025 ^[1]. The estimated number only includes the embedded devices that are connected to the Internet.

Embedded devices bring severe security problems to the Internet for three reasons ^[2]^[3]. First, the hardware resource of embedded devices is often limited, e.g., lower capacity of CPU, memory and power. Consequently, embedded software (often referred to as firmware, including an operating system and applications) is often tailored to suit the hardware. As a result, modern advanced security mechanisms (e.g., ASLR, DEP, Control-Flow Integrity) are often missing in embedded systems because they may take additional computational power and memory capacity, thus making embedded systems prone to attack. Second, embedded devices lack security updates. Many manufacturers do not provide security updates for their cheap products due to economic reasons. Even worse, users tend to not update their firmware as long as the device is functioning. Third, the number of embedded devices is especially large as we have discussed, which makes them very easy to reach.

As a result, attacks that target embedded devices are increasing. For example, the Mirai malware that affects IoT devices, especially DVR or IP cameras, can create a large botnet of as many as 50 thousand devices ^[4]. Recently, a vulnerability involving an out-of-bounds read was discovered in the module library of TPM2.0 ^[5]. Exploiting this vulnerability allows an attacker to access sensitive data stored in the TPM, potentially affecting billions of embedded devices. This issue is not limited to consumer devices, as demonstrated by a vulnerability revealed in Cisco ISE’s Embedded Service Router (ESR) by CVE-2023-20193. This vulnerability enables authenticated local attackers to read, write, or delete arbitrary files on the underlying operating system and escalate their privileges to root. The 2022 Microsoft Digital Defense Report ^[6] reveals that more than 10 critical vulnerabilities are present in 32% of firmware images, making embedded devices an increasingly popular target.

2. Embedded Device

An embedded device is a specialized computer system equipped with a small operating system or a single application running on it. An embedded device is often designed for one or very few specific purposes, e.g., controlling the traffic lights, driving a camera, printing pages on demand, doing WiFi routing, etc. Since the embedded devices are not designed for multiple purposes, the hardware is often tailored for an economic reason, e.g., using embedded CPU with low computing capability, using small on-chip memory, using small flash memory as storage, and using minimum I/O ports and peripherals. As a result, embedded OSes are also tailored for limited hardware. According to ^[7], embedded systems (embedded hardware plus embedded OS) can be divided into three categories.

Type I has full-functional hardware and a general operating system. The computing power is lower than desktop hardware, while important features (e.g., MMU) are integrated. The OS running on it is general purpose with modern desktop OS features, but tools and libraries are slimmed down to a small size to fit the hardware. A typical example of this kind is a home WiFi router. It is a small but is a whole computing system with, for example, ARM CortexM CPU, memory and flash storage, Ethernet and WiFi network, USB ports, etc. Most WiFi routers run the OpenWrt ^[8] operating system, which is a variant of Linux designed for embedded devices. OpenWrt uses a simplified toolset like busybox—the firmware is often as small as several MBs, but functions just like the Linux operating system. Similar operating systems include Android, Windows Embedded CE, RT-Thread IoT, Nucleus RTOS, etc. Vulnerabilities in Type I embedded systems are mainly related to the user applications and services provided by these devices. For example, these kind of embedded devices often have web pages for administrators to maintain the device. Typical vulnerabilities in such a system are like XSS, Command Injection, etc. Network services provided by such embedded systems such as DNS, Samba, etc. may also introduce overflow or configuration vulnerabilities.

Type II has more limited hardware resources than Type I. Though Type II still maintains an OS abstraction, the OS is not general purpose. The OS is used to ship several applications to perform a single task. The characteristic of a Type II system is that its hardware may lack advanced processor features such as a MMU. As a result, the applications running on such a system are usually highly coupled. Such operating systems include uClinux, ZephyrOS, and VxWorks ^[7]. Type III often works as a slave device such as a Bluetooth dongle, USB storage, PLC, etc. The hardware of this kind is often a single-chip microcomputer. Type III has no operating system abstraction, which means such an OS is just a library for development. More specifically, applications are integrated into the OS running directly on the hardware. Hence, the firmware of this kind of embedded system is often called monolithic firmware ^[7]^[9]^[10]. The corresponding OS for developing Type III systems include Contiki, TinyOS, mbed OS2 ^[7], ThreadX, eCos, RT-Thread nano, FreeRTOS, etc. Since embedded systems of Type II and Type III devices are simple binaries, vulnerabilities in such systems are often buffer overflows. These vulnerabilities are relatively easy to exploit because these systems lack security mechanisms. The exploit of these devices such as Bluetooth may be escalated to the host system (e.g., Android), causing the underlying host to be exploited (e.g., CVE-2019-11516) ^[11].

Security risks. There are more serious security risks in current embedded systems due to their distinct characteristics, as shown in Figure 1. Different privilege levels in an embedded system expose various attack surfaces. In embedded software, such as applications, operating systems, and firmware, attacks resemble those on general desktop or server OSes. An attacker can exploit design defects (vulnerabilities) in the platform to inject malicious code (malware inject) into the runtime system in different devices. In embedded hardware components, such as CPUs and memory, the design is often simplified to optimize cost and performance, resulting in a lack of protection. This allows attackers to bypass software protections and gain direct access to the hardware. For instance, an attacker can exploit the workflow of a process by accessing the CPU through a debugger channel (compromised debugging interface). Furthermore, the attacker can directly access specific memory, exploiting user-sensitive data through techniques like DMA, bus snooping, and cache buffer (side channel attacks). In a compromised embedded device, attackers can even install malicious firmware (firmware modification or flash reinstall), enabling them to launch attacker-designed applications on the device and provide erroneous services.

Figure 1. Security risks in embedded device system.

Despite the security threats of embedded devices, doing security analysis for these devices is not easy. The diverse hardware and software configurations make it difficult to create a general emulation environment for security analysis, especially for monolithic firmware. For example, monolithic firmware often needs to identify the entry point for firmware initialization ^[12] or dump the state of a running snapshot ^[11], which requires additional reverse engineering efforts and resources for execution dumping. Currently, firmware code and workflow are evaluated for security using dynamic and static analysis mechanisms. However, these mechanisms have become ineffective for several reasons. Dynamic analysis has become more challenging because of the increased difficulty in injecting malformed data or monitoring crashes and coverage. Similarly, static analysis has also become harder due to the increased coupling between the operating system and application code. Additionally, the increasing diversity of hardware and operating systems from Type I to Type III hampers security analysis at large scales.

References

IOT Analytics. IoT Connections Market Update. 2022. Available online: https://iot-analytics.com/number-connected-iot-devices/ (accessed on 11 October 2023).
Mahmoud, R.; Yousuf, T.; Aloul, F.; Zualkernan, I. Internet of things (IoT) security: Current status, challenges and prospective measures. In Proceedings of the 2015 10th International Conference for Internet Technology and Secured Transactions (ICITST), London, UK, 14–16 December 2015; pp. 336–341.
Bures, M.; Klima, M.; Rechtberger, V.; Ahmed, B.S.; Hindy, H.; Bellekens, X. Review of Specific Features and Challenges in the Current Internet of Things Systems Impacting Their Security and Reliability. In Proceedings of the Trends and Applications in Information Systems and Technologies, Azores, Portugal, 30–31 March and 1–2 April 2021; Rocha, Á., Adeli, H., Dzemyda, G., Moreira, F., Ramalho Correia, A.M., Eds.; Springer: Cham, Switzerland, 2021; pp. 546–556.
Partners, P.T. What is Mirai? The Malware Explained. 2022. Available online: https://www.pentestpartners.com/security-blog/what-is-mirai-the-malware-explained/ (accessed on 11 October 2023).
Github. An Out-of-Bounds Read Vulnerability Exists in TPM2.0. 2023. Available online: https://github.com/advisories/GHSA-cr8w-xxqw-fm2m (accessed on 11 October 2023).
Microsoft Security. Microsoft Digital Defense Report 2022. 2022. Available online: https://www.microsoft.com/en-us/security/business/microsoft-digital-defense-report-2022?rtc=1?rtc=1 (accessed on 11 October 2023).
Muench, M.; Stijohann, J.; Kargl, F.; Francillon, A.; Balzarotti, D. What you corrupt is not what you crash: Challenges in fuzzing embedded devices. In Proceedings of the NDSS, San Diego, CA, USA, 18–21 February 2018.
Fainelli, F. The OpenWrt embedded development framework. In Proceedings of the Free and Open Source Software Developers European Meeting, Brussels, Belgium, 23–24 February 2008; p. 106.
Clements, A.; Gustafson, E.; Scharnowski, T.; Grosen, P.; Fritz, D.; Kruegel, C.; Vigna, G.; Bagchi, S.; Payer, M. Halucinator: Firmware re-hosting through abstraction layer emulation. In Proceedings of the 29th USENIX Security Symposium, Boston, MA, USA, 12–14 August 2020.
Scharnowski, T.; Bars, N.; Schloegel, M.; Gustafson, E.; Muench, M.; Vigna, G.; Kruegel, C.; Holz, T.; Abbasi, A. Fuzzware: Using Precise MMIO Modeling for Effective Firmware Fuzzing. In Proceedings of the 31st USENIX Security Symposium (USENIX Security 22), Boston, MA, USA, 10–12 August 2022; pp. 1239–1256.
Ruge, J.; Classen, J.; Gringoli, F.; Hollick, M. Frankenstein: Advanced Wireless Fuzzing to Exploit New Bluetooth Escalation Targets. In Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), Boston, MA, USA, 12–14 August 2020; USENIX Association: Berkeley, CA, USA, 2020; pp. 19–36.
Shoshitaishvili, Y.; Wang, R.; Hauser, C.; Kruegel, C.; Vigna, G. Firmalice-automatic detection of authentication bypass vulnerabilities in binary firmware. In Proceedings of the NDSS, San Diego, CA, USA, 8–11 February 2015; Volume 1, p. 1.

© Text is available under the terms and conditions of the Creative Commons Attribution (CC BY) license; additional terms may apply. By using this site, you agree to the Terms and Conditions and Privacy Policy.

Upload a video for this entry

Information

Subjects: Computer Science, Cybernetics

Contributors MDPI registered users' name will be linked to their SciProfiles pages. To register with us, please refer to https://encyclopedia.pub/register :

Xu Zhou

Pengfei Wang

Lei Zhou

Peng Xun

Kai Lu

View Times: 160

Update Date: 18 Dec 2023

Table of Contents

Video Upload Options

Confirm

1. Introduction

2. Embedded Device

References