1. Overview
The author proposes a novel automated black-box Fuzz testing framework—IOTFUZZER, aimed at monitoring memory corruption vulnerabilities in IoT devices.
Main Advantages
-
No need to obtain firmware images of IoT devices.
-
No reverse engineering required.
-
No need to know the specifics of the protocol.
Purpose of Work
Only Fuzz testing, used to guide subsequent security analysis and identify the root causes of vulnerabilities.
Application-Based Fuzz Testing Framework
-
Firmware is difficult to obtain and unpack.
-
Most IoT devices come with official apps.
-
The app contains rich command (seed) messages, URLs, and encryption/decryption information.
-
Lightweight, no complex reverse engineering and protocol analysis required.
2. Related Background
IOT Communication Model
-
Mobile phones communicate directly with IoT devices.
-
Communicate using vendor-provided cloud services.
Challenges and Solutions in Work
-
Different devices may use different known or unknown protocols, requiring automatic identification and fuzzing of unknown protocol fields => mutate protocol fields at the data source.
-
Handling encrypted messages and extracting keys => reuse encryption functions at runtime.
-
Uncracked IoT devices make real-time monitoring difficult => heartbeat mechanism to detect activity.
3. Framework Implementation
1. UI Analysis The goal is to identify the UI elements that ultimately lead to messaging. Perform static analysis to associate UI elements in different activities with the target network API. Tools: Monkeyrunner
2. Data Analysis Identify protocol fields and log functions parameterized by protocol fields. Dynamic taint tracking of hardcoded strings, user inputs, or system APIs. Tools: TaintDroid
3. Dynamic Fuzz Hook target functions and pass mutated parameters. Pass mutations to multiple hook functions, fuzzing them multiple times, and possibly hook the same function to fuzz multiple protocol fields.
Randomly select a subset of fields to mutate instead of mutating all fields (as messages with all fields mutated may be easily rejected by the device).
Mutation-Based Fuzz
-
Change the length of strings to achieve stack overflow or heap overflow and out-of-bounds.
-
Change values of integers, doubles, or floats to cause integer overflow and out-of-bounds.
-
Change types or provide null values for uninitialized variables.
Tools: Xposed
4. Real-Time Monitoring
Four types of responses – expected response – unexpected response – no response – disconnection.
Use a heartbeat mechanism to extract heartbeat messages from the IoT application; insert a heartbeat message every ten fuzz tests during the fuzz testing process.
4. Evaluation and Analysis
Test Devices 17 best-selling products from mainstream manufacturers, all of which can be operated via the official IoT application through a local Wi-Fi network. No restrictions on communication protocols and data transmission formats..
Test Results By using the IOTFUZZER automation framework (running each device for 24 hours) to fuzz test 17 IoT devices, 15 severe vulnerabilities (memory corruption) were found in 9 devices, including:
-
5 stack-based buffer overflows
-
2 heap-based buffer overflows
-
4 null pointer dereferences and 4 crashes
Further checks will be conducted after IOTFUZZER identifies vulnerabilities.
Efficiency Compared to Sulley and BED, it generally has higher efficiency.
UI Performance Analysis
The application is relatively simple, with not many events and activities invoked.
Not many functions are called simultaneously, and important functions are called repeatedly.
Fuzz Accuracy
No heartbeat response from the device or disconnection of TCP-based connections may be caused by unpredictable communication errors during the experiment. Therefore, accuracy is generally low.
5. Test Cases
Wi-Fi based TP-LINK smart plug
The ‘name’ field should be a string but was fuzzed to an integer.
When the mutated message was sent to the Wi-Fi smart plug, the device flashed red and rejected any valid messages.
Through complex firmware analysis, these vulnerabilities were triggered by using uninitialized pointers.
Belkin WeMo Switch
If the command message ‘SetSmartDevInfo’ content is not provided, this message causes the switch to crash and automatically restart.
This message triggers an invalid read access at 0x00000000.
If not, the pointer in the data structure is uninitialized, leading to reading from 0x00000000.
6. Discussion and Limitations
Limitations
-
Testing Scope
The mobile application provides the main data input channel for device management, and other data channels (such as sensors or debugging ports) could be attempted.
-
Connection Modes
Currently only devices connected via Wi-Fi, which may be expanded to other communication modes in the future, such as Bluetooth, Zigbee.
-
Result Judgment
IOTFUZZER cannot directly generate types and root causes of memory corruption; in black-box testing, final vulnerability confirmation often requires some manual intervention.
-
Result Accuracy
There are many false positives.
In some cases, memory corruption does not lead to crashes.
Source: GoSSIP
