Source-linked AI summary
Snipuzz: Black-box Fuzzing of IoT Firmware via Message Snippet Inference
Xiaotao Feng, Ruoxi Sun, Xiaogang Zhu, Minhui Xue, Sheng Wen, Dongxi Liu, Surya Nepal, Yang Xiang
TL;DR
IoT firmware fuzzing must detect vulnerabilities despite security risks and challenges in designing effective message-based tests. Snipuzz uses device responses to infer message snippets and guide black-box mutation, finding five zero-day vulnerabilities across 20 consumer-grade IoT devices, including three exposed only by Snipuzz.
Problem
Detecting vulnerabilities in IoT firmware by sending messages to devices presents challenges for designing effective and efficient fuzzing methods.
Method
Snipuzz uses device responses to infer message snippets and guide mutation without grammatical rules or internal execution information.
Results
5 zero-day vulnerabilities were found on 5 different devices among 20 consumer-grade IoT devices, and 3 were exposed only by Snipuzz.
Takeaways & Limitations
Snipuzz provides a black-box fuzzing framework that uses response messages to guide mutation and generate test cases meeting device grammar without grammatical rules.
Takeaways & Limitations
Encrypted messages can reduce snippet-determination effectiveness, while missing API programs require more manual effort and limit examined functionality to API-covered features.
Abstract
from arXiv · showhide
The proliferation of Internet of Things (IoT) devices has made people's lives more convenient, but it has also raised many security concerns. Due to the difficulty of obtaining and emulating IoT firmware, the black-box fuzzing of IoT devices has become a viable option. However, existing black-box fuzzers cannot form effective mutation optimization mechanisms to guide their testing processes, mainly due to the lack of feedback. It is difficult or even impossible to apply existing grammar-based fuzzing strategies. Therefore, an efficient fuzzing approach with syntax inference is required in the IoT fuzzing domain. To address these critical problems, we propose a novel automatic black-box fuzzing for IoT firmware, termed Snipuzz. Snipuzz runs as a client communicating with the devices and infers message snippets for mutation based on the responses. Each snippet refers to a block of consecutive bytes that reflect the approximate code coverage in fuzzing. This mutation strategy based on message snippets considerably narrows down the search space to change the probing messages. We compared Snipuzz with four state-of-the-art IoT fuzzing approaches, i.e., IoTFuzzer, BooFuzz, Doona, and Nemesys. Snipuzz not only inherits the advantages of app-based fuzzing (e.g., IoTFuzzer, but also utilizes communication responses to perform efficient mutation. Furthermore, Snipuzz is lightweight as its execution does not rely on any prerequisite operations, such as reverse engineering of apps. We also evaluated Snipuzz on 20 popular real-world IoT devices. Our results show that Snipuzz could identify 5 zero-day vulnerabilities, and 3 of them could be exposed only by Snipuzz. All the newly discovered vulnerabilities have been confirmed by their vendors.
1 INTRODUCTION
IoT firmware vulnerabilities are difficult to test because firmware is often unavailable, black-box fuzzers lack execution feedback, and device input formats are diverse. Snipuzz addresses these challenges by inferring message snippets from device responses and using them to guide mutation.
- Motivation: IoT devices expose security risks, including vulnerabilities that can enable botnets, distributed denial-of-service campaigns, and lateral movement.The paper motivates vulnerability discovery by describing Mirai and risks to connected households and networks.
- Motivation: Firmware unavailability makes code-based dynamic analysis and emulation difficult, motivating network-based testing of IoT devices.Manufacturers often do not release firmware, while network messages can still expose crashes or abnormal responses.
- Challenges: Black-box IoT fuzzers lack internal execution feedback, making mutation-target selection difficult and often reducing testing to brute-force random mutation.Without feedback, mutated seeds are selected randomly and may be rejected before execution.
- Challenges: Diverse, non-standard communication formats make grammar-based fuzzing difficult because sufficient specifications or labeled training data may be unavailable.The paper identifies JSON, SOAP, key-value, string, and customized formats among IoT communication formats.
- Our approach: Snipuzz mutates message bytes, groups adjacent bytes with similar response behavior into snippets, and uses hierarchical clustering to reduce response-category misclassification.The snippet-based strategy uses device responses as feedback without requiring grammar rules or internal execution information.
- Contributions: 87.1% similarity to actual syntax rules, more response categories on most devices, and 5 vulnerabilities across 20 devices summarize Snipuzz’s reported evaluation.Three of the five vulnerabilities were exposed only by Snipuzz; the supplied passage reports this outcome for vulnerabilities involving denial of service and unknown crashes.
2 BACKGROUND
Fuzzing detects vulnerabilities by exercising software with mutated inputs and monitoring undesired behavior, while feedback can guide mutation beyond purely random testing. IoT devices commonly process network inputs through sanitization, function dispatch, execution, and response generation.
- Fuzz Testing: Fuzzing feeds programs numerous mutated inputs and monitors exceptions or other undesired behavior that may reveal vulnerabilities.The approach is used across domains including operating-system kernels, servers, and blockchains.
- Fuzz Testing: Feedback such as execution coverage helps fuzzers optimize mutation instead of relying on purely random input generation.Feedback can also indicate whether a generated test case meaningfully exercises the target.
- IoT Firmware Communication: A typical IoT communication architecture contains a Sanitizer, Function Switch, Function Definitions, and Replier for processing external inputs.The Sanitizer parses and validates input before dispatching accepted requests to device functionality.
3 MOTIVATION
Network-based IoT fuzzing lacks direct execution feedback and must handle strict, diverse input syntax. Snipuzz treats device responses as runtime status signals and infers byte-level message snippets to narrow mutation.
- Feedback Challenge: Network fuzzers cannot usually observe device execution status, making effective mutation guidance difficult and encouraging blind or brute-force testing.The central motivation is to establish feedback without instrumenting firmware.
- Response Feedback: Device responses provide runtime status information because response values can originate from parsing failures, exceptions, or different firmware function blocks.Different responses do not equal exact execution paths, but they can indicate that inputs reached different paths.
- Syntax Challenge: Strict and diverse IoT input syntax causes byte-level mutations to be rejected, while grammar-based fuzzing requires specifications or substantial training data.The paper notes that many IoT formats are non-standard, limiting the availability of grammar guidance.
- Message Snippet Inference: If mutating two positions in a valid message yields the same response, those positions may relate to the same firmware functionality.Snipuzz merges consecutive bytes with the same response into one snippet and applies mutation operators to snippets.
4 METHODOLOGY
Snipuzz acquires valid message-sequence seeds, infers message snippets from device responses, and mutates those snippets to generate new sequences. It compares response similarity and clusters responses to handle randomness while monitoring network traffic for crashes.
- Fuzzing workflow: Snipuzz operates as a client that sends message sequences, generates probe sequences for individual messages, and records device responses in response pools.A network monitor detects crashes during fuzzing when the device provides no response.
- Message sequence acquisition: Valid initial seeds are collected for resetting devices and exercising structured communication paths, but obtaining usable seeds still requires manual preparation.The authors report configuring test programs, defining monitored traffic formats, and filtering sequences that could cause false-positive crashes.
- Initial snippet determination: Snipuzz initially infers snippets by deleting each byte in a message, sending the resulting probe sequences, and grouping consecutive bytes with the same response category.For an 11-byte JSON message, this produces 11 probe messages whose responses determine the initial snippet boundaries.
- Response categorization: Response categories use edit-distance similarity rather than exact string comparison, reducing errors caused by timestamps, tokens, and other random response content.The similarity score normalizes edit distance by the longer response length; self-similarity from repeated probes provides the comparison threshold.
- Hierarchical clustering: Semantically identical responses can still be misclassified when probe-derived content changes their similarity, motivating hierarchical clustering to merge related response categories.In the example, responses with a similarity of 0.979 fall below self-similarity scores of 1.000 despite indicating the same parameter-syntax-error behavior.
5 EXPERIMENTAL EVALUATION
Snipuzz was evaluated against other IoT fuzzers on real devices, where it exposed crashes and generally explored more response categories. Its response-guided snippet strategy also achieved strong message-segmentation similarity, while showing some device- and format-specific limitations.
- Snipuzz Results: 13 crashes were found in 5 of 20 IoT devices after 24 hours of Snipuzz fuzzing.The crashes comprised 7 null pointer dereferences, 1 denial of service, and 5 unknown crashes.
- Snipuzz Results: Snipuzz uncovered malformed-input vulnerabilities involving broken JSON syntax, deleted data domains, and other message-format mutations.The reported findings included TP-Link null pointer dereferences, a Philips smart-bulb denial of service, and remotely exploitable Yeelight crashes.
- Runtime Performance: Snipuzz covered the most response categories on 15 of 20 devices after 24 hours, although it initially explored categories more slowly than IoTFuzzer.Its snippet-determination stage systematically explores message responses, while long messages can require many probe messages during startup.
- Runtime Performance: Snipuzz generally surpassed IoTFuzzer in response-category coverage, while Snipuzz-NoSnippet exceeded it on 5 devices and Nemesys remained below Snipuzz.Snipuzz-NoSnippet can miss categories requiring data-domain mutations, whereas Nemesys does not use device responses to determine data domains.
- Message Snippet Inference: Snipuzz achieved an average message-segmentation similarity of 87.1% through hierarchical clustering-based snippet inference.The clustering procedure is intended to reduce randomness in device responses and progressively conform snippets to hidden grammatical rules.
6 DISCUSSION AND LIMITATIONS
Snipuzz’s scalability is constrained by the effort needed to obtain and clean valid communication packets, while several conditions limit snippet determination and coverage. The authors identify automation, better preprocessing, and broader message generation as future directions.
- Scalability and manual effort: Snipuzz requires valid network packets, whose acquisition may involve recovering message formats from apps or intercepted communications.These approaches can introduce overhead and manual effort.
- Scalability and manual effort: 5 man-hours per device are required in the prototype to collect initial seeds during message-sequence acquisition.The effort mainly involves cleaning packets obtained from public first- and third-party API resources.
- Future work: Future work includes crawlers, scripted keyword preprocessing, and recombining snippets to reduce manual effort and broaden valid-input exploration.These proposals address packet collection and the limited coverage induced by available API messages.
- Threats to validity: Encryption can make snippet determination fail because it disrupts message formats and encrypts device responses.The authors identify encrypted communication as a threat to validity.
- Threats to validity: Snipuzz’s explored firmware coverage depends on the functionality supported by the API programs supplying its messages.Mutating packets captured for one function may not expose another unsupported function.
- Threats to validity: Insufficiently detailed device responses can make message-snippet determination difficult, especially when errors receive a uniform response.The detection effectiveness of Snipuzz depends on the information contained in device responses.
7 RELATED WORK
Related IoT-firmware analysis spans black-box fuzzing, emulation, and static analysis. Snipuzz differs from blind mutation by using device responses as feedback while avoiding the firmware prerequisite of emulation.
- Black-box fuzzing: Snipuzz uses device responses to optimize black-box mutation, whereas IoTFuzzer performs blind mutation on the data domain.The feedback mechanism helps distinguish input quality and supports more effective bug discovery.
- Black-box fuzzing: SPFuzz specifies protocol languages and state correlations, while IoTHunter uses grey-box feedback to explore IoT firmware protocol states.AFLnet instead uses response codes to identify execution states during message-sequence variation.
- Emulation: Emulation can analyze firmware more thoroughly than black-box fuzzing but requires firmware and substantial engineering effort.Its major challenges include scalability and throughput.
- Static analysis: Static firmware analysis complements dynamic analysis through semantic similarity over files, modules, control-flow graphs, parsers, and multi-binary interactions.These approaches target vulnerability detection across firmware architectures.
8 CONCLUSION
Snipuzz is a black-box IoT-firmware fuzzing framework that uses device responses to guide mutation and infer byte-level grammatical roles. Its conclusion presents response-driven snippet inference as the basis for generating suitable test cases.
- Conclusion: Snipuzz establishes feedback from device responses to guide the black-box fuzzing mutation process.This distinguishes it from other black-box network fuzzing approaches described by the authors.
- Conclusion: Snipuzz infers each message byte’s grammatical role from responses so it can generate test cases meeting device requirements.The supplied conclusion passage presents this as the framework’s central design.
A RUNTIME PERFORMANCE
During the first 10 minutes, Snipuzz generally discovers categories faster than the baselines after its snippet-determination stage. It performs best on 19 of the 20 evaluated IoT devices.
- Runtime performance: 19 of 20 devices show Snipuzz discovering the most categories within 10 minutes.Figure 6 reports this runtime comparison across all 20 IoT devices.
- Runtime performance: Snipuzz initially discovers fewer categories than IoTFuzzer because time is spent determining snippets.After this stage, Snipuzz gradually discovers more categories than IoTFuzzer and the other baselines.
B MUTATION EFFECTIVENESS: A CASE STUDY
The case study shows Snipuzz finding a vulnerability in an updated smart-plug firmware where IoTFuzzer did not, by mutating message snippets beyond grammar-preserving changes. The resulting malformed JSON led to a type mismatch and null-pointer exception in firmware using cJSON.
- IoTFuzzer found a vulnerability in HS110 firmware 1.3.1 by mutating the message data domain, changing “light” to 0.
- In firmware version 1.5.2, IoTFuzzer found no vulnerabilities, whereas Snipuzz triggered one by deleting message contents and breaking the JSON syntax structure.
- The malformed message was parsed by cJSON such that ‘schedule’ no longer contained the expected object, causing a null-pointer exception when firmware accessed ‘edit_rule’.
- Snipuzz’s snippet mutation can break syntax and alter both data and non-data domains, unlike grammar-constrained mutation.
- Grammar-based fuzzing prioritizes satisfying firmware grammar detectors, which ensures functional execution but leaves sanitizing code outside its test range.
- The crash reflects reliance on a third-party syntax-validation library combined with incorrect handling of a null-pointer exception caused by a data-type mismatch.