Automated Black-box Security Testing Of “Smart” Embedded Devices

Automated Black-box Security Testing Of “Smart” Embedded Devices

Speakers: Andrea Continella, Assistant Professor, University of Twente

Conference: HITB Amsterdam

YouTube: https://www.youtube.com/watch?v=F2TV7SsPxTQ

Overview

In this insightful talk, Andrea Continella, an Assistant Professor at the University of Twente, delves into the critical challenges and innovative solutions for automated security testing of "smart" embedded devices. While these devices are ubiquitous and increasingly integrated into daily life, Continella highlights that their security often falls short of expectations, revealing them to be "not so smart" when it comes to fundamental protections. The presentation focuses on overcoming the significant hurdles posed by the hardware-dependent and often opaque nature of firmware, particularly the frequent unavailability of firmware images for analysis.

Continella's research introduces novel black-box fuzzing techniques that leverage companion mobile applications to interact with IoT devices more effectively. By strategically identifying "fuzzing triggers" within these applications, his tools can generate precisely formatted, deeply penetrating inputs that bypass app-side sanitization, leading to the discovery of severe vulnerabilities. Beyond initial device exploitation, the talk also sheds light on the widespread insecurity of firmware update mechanisms, revealing how vulnerable Software Development Kits (SDKs) used across thousands of popular devices pose a systemic risk, enabling attacks ranging from device bricking to arbitrary code execution. This work underscores the urgent need for a paradigm shift in how embedded device security is approached, moving beyond traditional software analysis methods to address the unique complexities of the IoT ecosystem.

Background

▶ Watch: Introduction and speaker background (0:00)

The proliferation of Internet of Things (IoT) devices has introduced an unprecedented array of "smart" gadgets into homes and industries, from smart toasters and lights to more esoteric items like smart egg minders. Despite their convenience, these devices are notoriously insecure. Continella points out that the vulnerabilities found in IoT firmware are often "very old types of vulnerabilities"—issues that the security community has understood for decades, requiring no sophisticated exploitation techniques. This is largely due to the absence of modern security mitigations (such as Address Space Layout Randomization or Data Execution Prevention) that are standard in contemporary operating systems. The scale of this problem is starkly illustrated by events like the Mirai botnet, which leveraged vulnerabilities in hundreds of thousands of IoT devices to launch massive Distributed Denial of Service (DDoS) attacks, capable of taking down critical internet infrastructure.

Analyzing the security of firmware presents unique challenges that differentiate it significantly from traditional software. Firstly, firmware is inherently hardware-dependent, often relying on external peripherals and custom code. It operates in unique and minimal environments with non-standard configurations, hardcoded memory addresses, and custom interrupt handlers. Furthermore, firmware is frequently implemented on diverse and sometimes proprietary architectures, complicating analysis efforts.

Traditional security analysis techniques struggle in this domain. Dynamic analysis, which involves running firmware in emulated or virtualized environments, is particularly challenging. The strong hardware dependencies mean that emulating the full environment, including custom peripherals and interrupt handlers, is incredibly complex and often requires manual, labor-intensive setup. As a result, no generic, reliable dynamic analysis solution currently exists for firmware. Static analysis, while not constrained by runtime environment issues, suffers from its own set of problems, primarily generating a high number of false positives. This is exacerbated by the multi-binary nature of much IoT firmware, which is often Linux-based and distributed as a squash file system containing hundreds of interconnected executables. While Continella's team developed a tool using multi-binary taint analysis to reduce false positives in static analysis, a more fundamental limitation affects both static and dynamic approaches: the frequent unavailability of firmware images. Vendors often do not publish these images, and recovering them from devices or network connections can be difficult, time-consuming, and not scalable for widespread testing.

This critical lack of firmware images necessitates black-box fuzzing, where inputs are sent to a target device without prior knowledge of its internal code or structure, hoping to trigger vulnerabilities. However, naive black-box fuzzing is largely ineffective. Devices typically implement input validation as a first step, immediately discarding inputs that do not conform to expected formats (e.g., a device expecting an HTTP request will ignore a simple string of "A"s). This prevents fuzzed inputs from reaching deeper, potentially vulnerable code paths. Prior research, such as the IoT Fuzzer, attempted to address this by leveraging companion mobile applications. The rationale is that these apps, by definition, "know how to talk to the device" and contain the logic to package data in the correct format. While an improvement, this approach still faces a limitation: mobile applications themselves often implement input sanitization and validation (e.g., checking password length or character types) before sending data to the device, effectively filtering out many potentially vulnerability-triggering inputs. This sets the stage for Continella's work, which aims to find a "sweet spot" to bypass these app-side limitations.

Key Findings

▶ Watch: Black-box fuzzing: the only solution without firmware images (10:00)

The core contribution of Continella's research is the development of Diane, an automated black-box fuzzer designed to overcome the limitations of prior companion app-based fuzzing. Diane identifies a "sweet spot" within the mobile application's execution flow: functions that are executed after app-side validation and sanitization but before data encoding and serialization for transmission to the IoT device. These are termed fuzzing triggers, and by targeting them, Diane can generate valid, deeply reaching inputs that would otherwise be filtered by the app's front-end checks.

The effectiveness of Diane was rigorously tested across 11 IoT devices from various brands and categories. The results were compelling: 7 out of these 11 apps were found to contain input sanitization, underscoring the necessity of Diane's approach. On a broader scale, their analysis of a dataset of 40,000 Android IoT companion apps revealed that approximately 51% of them indeed implement sanitization before transmitting data to devices. For the 11 devices tested, Diane identified 54 fuzzing triggers, with only five false positives and five instances where the trigger was identical to the send message function (indicating no encoding).

Comparing Diane to the existing IoT Fuzzer (which operates at the UI level), Diane demonstrated significantly superior vulnerability discovery. It identified more vulnerabilities, including several zero-days, that the IoT Fuzzer could not detect because they required inputs that were sanitized by the mobile applications. A striking example involved a popular Smart Lock where Diane's fuzzing managed to overwrite a pointer within the device's firmware. This forced the device into an error-handling state, causing it to beep "SOS" in Morse code, a clear demonstration of a critical memory corruption vulnerability with tangible impact.

The adaptability of Diane's approach was further demonstrated by applying a similar methodology to a significantly more secure target: the Titan M core processor in Google Pixel devices. This dedicated chip implements a Trusted Execution Environment (TEE) for critical security operations like fingerprint verification. By implementing a fuzzer within the Android kernel to interact with the Titan M chip, Continella's team found both known vulnerabilities (used for validation) and two previously unknown bugs. While these bugs led to denial-of-service (causing the chip to halt) rather than remote code execution, their discovery was remarkably fast, often requiring less than 100 messages and taking only two to three minutes to trigger. This highlights the power of targeted fuzzing when the communication format can be inferred or directly intercepted.

Beyond direct device exploitation, the research also extended to an often-overlooked yet critical attack surface: the firmware update mechanism. Continella's team studied how mobile apps mediate these updates, identifying common steps: checking the current firmware version, retrieving the latest image, and transferring it to the device. They found that vulnerabilities frequently arise when devices fail to properly implement integrity and authenticity checks (e.g., cryptographic signature verification) for received firmware images, or when they lack version validation to prevent firmware downgrades. This can lead to device bricking, downgrading to known vulnerable versions, or even arbitrary code execution. A key finding was that many firmware update mechanisms are implemented using shared Software Development Kits (SDKs). By reverse-engineering popular IoT SDKs and creating fingerprints for vulnerable ones, they conducted a large-scale analysis. Out of almost 40,000 Android IoT companion apps from the Google Play Store, 1,356 apps were found to use at least one of six identified vulnerable SDKs. Most of these were susceptible to modification attacks (leading to bricking or downgrading), with 8 apps vulnerable specifically to downgrade attacks, and 1 app to bricking attacks. Alarmingly, 24 of these vulnerable apps control 61 devices listed in Amazon's top 50 bestseller categories, indicating a significant real-world impact.

Technical Deep Dive

▶ Watch: Diane: Automatic 'fuzzing triggers' for deeper code coverage (17:35)

Diane's methodology for identifying fuzzing triggers is a sophisticated blend of static and dynamic analysis, specifically tailored for Android companion applications. The process begins by taking an Android Application Package (APK) as input.

1. Call Graph Construction: Diane first constructs a comprehensive call graph of the application. This graph maps all functions within the APK and their interdependencies, with edges representing calls from one function to another. The analysis primarily focuses on Java code within the Android ecosystem, benefiting from the rich semantic information available in Dalvik bytecode.

1. Candidate Send Message Functions (Static Analysis): Using static analysis, Diane identifies candidate send_message functions. These are functions within the application that appear to be responsible for sending data over the network to the IoT device. This step provides an initial set of potential communication points.

1. Validate Send Message Functions (Dynamic Analysis): To confirm the static findings and ensure accuracy, Diane employs dynamic analysis. The application is run, and the identified candidate send_message functions are monitored to verify that they indeed send network messages to the target IoT device. This validation step filters out false positives from the static analysis.

1. Hybrid Analysis for Fuzzing Trigger Identification: This is the most critical and innovative part of Diane's process, combining both static and dynamic techniques.

• Backward Slice to UI: Starting from the validated send_message functions (which are considered the "bottom" of the communication path), Diane performs a backward slice upwards towards the application's User Interface (UI). This identifies all possible execution paths and functions that contribute to the data eventually sent by the send_message function, tracing back to where user input or internal application logic originates.
• Entropy-Based Encoding Detection: For each function identified in the backward slice, Diane dynamically instruments it during runtime. The tool monitors the function's input and output variables (including return values and object fields). It then applies heuristics to compare the entropy of the output values against the input values. A significant increase in entropy in the output, beyond a predefined threshold (leveraging prior research on entropy-based encoding detection), is a strong indicator that the function is an encoding function—it performs some form of data transformation or serialization.
• Fuzzing Trigger Selection: The "fuzzing trigger" is then identified as the data transforming function that is not dominated by other data transforming functions. In simpler terms, it's the highest-level encoding function in the call graph along the path from the UI to the send_message function. This point is crucial because it executes after any app-side sanitization (which would typically occur closer to the UI) but before the final data encoding that prepares the message for the device. This allows the fuzzer to inject mutated inputs at a stage where they are already in a valid, encoded format but haven't been constrained by the app's earlier validation logic.

Implementation Details:

Diane leverages Frida, a dynamic instrumentation toolkit, to inject code and monitor Android applications at runtime. To interact with the application and explore its functionalities, Diane uses another tool called Rerun, which records initial manual user interactions with the app and then replays them for subsequent, automated fuzzing runs. This ensures that the application reaches the desired code paths where fuzzing triggers can be activated.

Fuzzing Process and Vulnerability Detection:

Once a fuzzing trigger is identified and activated at runtime, Diane begins mutating its input parameters. For example, if the trigger expects a string, Diane might inject a "bunch of A's" or other malformed data. The modified output from the fuzzing trigger is then passed down the application's call chain, eventually forming a network request that is sent to the IoT device.

Since the fuzzing is black-box, direct observation of firmware crashes is not possible. Instead, Diane relies on several heuristics to detect vulnerabilities:

• Monitoring device responses: The fuzzer checks if the device stops responding, sends unexpected error messages, or provides abnormally short responses compared to normal operation.
• External state monitoring: A separate smartphone or device is used to monitor the target IoT device's physical state (e.g., if it becomes unresponsive, reboots, or exhibits unusual behavior like the Smart Lock beeping SOS).

Adaptation for Titan M Fuzzing:

The principles of Diane were adapted for fuzzing the Google Pixel's Titan M chip. Instead of a companion app communicating with an IoT device, the target was the Android kernel communicating with the secure core processor. The fuzzer was implemented directly within the Android kernel, targeting the specific interfaces and functions responsible for interacting with the Titan M chip. This demonstrates the versatility of the "find the sweet spot between validation and encoding" approach even in highly controlled and secure environments.

Firmware Update Mechanism Analysis:

The technical deep dive into firmware update mechanisms focused on identifying vulnerabilities within the Software Development Kits (SDKs) commonly used by developers.

• Methodology: Researchers collected popular IoT devices and their corresponding SDKs. They then engaged in a laborious process of reverse engineering these SDKs to understand their internal logic for handling firmware updates. Dynamic testing was performed on identified vulnerable SDKs to confirm their exploitability.
• SDK Fingerprinting and Large-Scale Scan: To assess the widespread impact, fingerprints were created for the vulnerable SDKs. These fingerprints were then used to scan a massive dataset of approximately 40,000 Android IoT companion apps from the Google Play Store. This large-scale analysis revealed the alarming prevalence of vulnerable update mechanisms embedded within popular apps and devices. The findings highlighted that many SDKs lacked robust cryptographic checks for firmware integrity and authenticity, or failed to enforce versioning, thereby enabling various attacks.

Demo / Proof of Concept

▶ Watch: Critical vulnerabilities in firmware update mechanisms (34:00)

While the talk did not feature a live, interactive demonstration, Andrea Continella presented a compelling proof of concept through the discovery of a critical vulnerability in a popular Smart Lock. This finding perfectly illustrated the efficacy of Diane's black-box fuzzing approach.

During the fuzzing process, Diane generated an input that, when processed by the Smart Lock's firmware, resulted in an overwrite of a pointer within the device's memory. This memory corruption caused the Smart Lock to enter an unexpected error handling state. The physical manifestation of this error was quite unusual: the device began to beep "SOS" in Morse code. This audible signal, recognized by a lab member, served as a clear and undeniable indication that a severe vulnerability had been triggered, demonstrating the ability of Diane to not only crash devices but also to force them into observable, critical failure states. This specific example highlights how memory safety issues, even in seemingly simple embedded devices, can have profound and unexpected consequences, validating Diane's capability to uncover deep-seated vulnerabilities that bypass standard app-level protections.

Defensive Implications

▶ Watch: Conclusions: Rethinking security analysis for embedded devices (41:20)

The research presented by Andrea Continella offers several critical defensive implications for both IoT device vendors and the broader security community. The findings underscore the urgent need for a fundamental shift in how security is approached for embedded devices, moving beyond traditional software paradigms.

1. Rethink Security Analysis for Embedded Devices: Vendors and security engineers must acknowledge that applying traditional static or dynamic analysis techniques directly to firmware is often impractical or impossible due to hardware dependencies, unique environments, and the frequent unavailability of firmware images. Automated black-box fuzzing, particularly approaches like Diane that intelligently leverage companion apps, should be integrated into the security development lifecycle (SDL) as a primary testing method.

1. Implement Robust Input Validation and Sanitization Deeply: While companion apps often implement input sanitization, this research shows it's insufficient if not paired with robust checks within the device firmware itself. Developers must ensure that all inputs, regardless of their source (UI, network, internal APIs), are thoroughly validated and sanitized at multiple layers within the device's firmware. This includes checks for length, format, character sets, and expected values to prevent common vulnerabilities like buffer overflows.

1. Secure Firmware Update Mechanisms: This is a critical area of weakness.

• Mandatory Cryptographic Integrity and Authenticity Checks: Every firmware image must be cryptographically signed by the vendor, and the device must rigorously verify this signature before accepting and installing any update. This prevents malicious or tampered firmware from being loaded.
• Version Rollback Protection: Devices must enforce checks to ensure that only the latest or approved firmware versions can be installed. This prevents attackers from downgrading devices to older firmware with known vulnerabilities.
• Robust Error Handling: Firmware update processes must include comprehensive error handling for corrupted, malformed, or unauthorized updates to prevent device bricking.
• Least Privilege and Trust Boundaries: Companion apps should not be implicitly trusted, especially in scenarios where the app user might be untrusted (e.g., Airbnb guests). The device firmware should always treat inputs from companion apps and cloud services as potentially malicious and apply all necessary security checks.
• Secure SDK Adoption: Developers should prioritize using well-vetted, secure SDKs for critical functionalities like firmware updates. SDK vendors, in turn, have a responsibility to design and maintain their libraries with security as a paramount concern, promptly patching and disseminating fixes for vulnerabilities.

1. Transparency and Firmware Availability: Wherever feasible and without compromising sensitive intellectual property, vendors should consider making firmware images publicly available to security researchers. This greatly facilitates independent security auditing and vulnerability discovery, ultimately leading to more secure products.

1. Focus on Lightweight Security Solutions: Given the computational constraints of many IoT devices, traditional security tools and approaches are often too resource-intensive. Future defensive strategies must prioritize the development of lightweight, efficient security mechanisms that can operate effectively within these minimal environments, such as anomaly detection systems specifically designed for low-power devices.

By adopting these defensive measures, vendors can significantly enhance the security posture of smart embedded devices, mitigating the widespread risks highlighted by Continella's research and contributing to a more secure IoT ecosystem.

Key Takeaways

• Pervasive Insecurity in IoT: Smart embedded devices are alarmingly vulnerable, often to "old types" of security flaws, due to a lack of modern security mitigations and the unique challenges of their hardware-dependent, minimal environments.
• Challenges of Traditional Firmware Analysis: Standard static and dynamic analysis methods are frequently impractical or impossible for firmware, primarily because vendors rarely provide firmware images and emulation is notoriously difficult.
• Diane's Innovative Black-Box Fuzzing: The Diane tool significantly advances black-box fuzzing by intelligently identifying "fuzzing triggers" within companion mobile apps. This allows it to inject deeply penetrating, valid inputs that bypass app-side sanitization, leading to the discovery of critical zero-day vulnerabilities.
• Adaptability to High-Security Targets: The core methodology of finding "fuzzing triggers" is adaptable, as demonstrated by its success in uncovering vulnerabilities in Google's highly secure Titan M core processor with remarkable speed.
• Critical Vulnerabilities in Firmware Update Mechanisms: Firmware update processes are a systemic weakness, with many implementations relying on insecure SDKs that lack proper cryptographic integrity, authenticity checks, or version validation, opening doors to device bricking, downgrades, and arbitrary code execution.
• Urgent Need for Vendor Rethink: IoT device vendors must fundamentally rethink their security strategies, implementing robust input validation throughout the device, securing firmware update mechanisms with strong cryptographic controls, and considering greater transparency in firmware availability to enable better security auditing.

About the Speaker(s)

Andrea Continella is an Assistant Professor at the University of Twente in the Netherlands, located east of Amsterdam. He is a key member of the SCS Group (Semantics, Cyber Security, and Services), where his research predominantly focuses on system security, a more practical and technical aspect of cybersecurity. His primary research lines include malware analysis and defenses, threat detection and response, and automated security testing, which was the central theme of this presentation. Continella is also a passionate enthusiast of Capture The Flag (CTF) competitions, having started playing during his bachelor's degree in Italy with teams like Tower of Annoy and the Macaroni Team. He later joined Shellphish during his time in the US at UCSB Santa Barbara and now leads the active Twente Hacking Squad. His CTF experience has taken him to numerous Defcon finals in Las Vegas, highlighting his deep practical engagement with cybersecurity challenges.