IoTFuzzSentry: Protocol-Guided IoT Fuzzing

• IoTFuzzSentry is a black-box, mutation-based fuzzer that leverages protocol guidance to apply lexical mutations on visible application fields.
• It integrates a protocol parser, mutation engine, packet injector, and result analyzer to test commercial devices without requiring proprietary firmware access.
• Evaluation on IP cameras and smart plugs revealed seven distinct vulnerabilities, including credential leakage and unauthorized command execution, measured by response coverage and mutation score.

IoTFuzzSentry is a protocol-guided, mutation-based fuzzing tool for automatic vulnerability testing in commercial Internet of Things devices. It is presented as a purely black-box, mutation-based lexical fuzzer tailored to application-level protocols in commercial IoT devices, with a focus on transport and application-layer packet injection against deployed devices that run lightweight servers for functions such as video streaming or image capture (&&^^^^2/2^^^^&&). The system is designed to uncover non-trivial vulnerabilities in commercial-off-the-shelf devices, especially vulnerabilities that do not necessarily manifest as crashes but instead enable unauthorized access, data leakage, live stream access, image retrieval, or command execution. In the reported evaluation, the tool was integrated into Cotopaxi and applied to IP cameras and a smart plug, yielding seven distinct vulnerabilities grouped into four categories, including two published CVEs and one case awaiting disclosure (&&^^^^2/2^^^^&&).

1. Definition, threat model, and scope

IoTFuzzSentry addresses the problem of protocol fuzzing for deployed IoT devices. The motivating setting is one in which IoT devices expose lightweight servers and process protocol messages that mediate user interactions. The paper situates the risk at the level of transport or application-layer security mechanisms, where implementation flaws can expose devices to unauthorized access and data leakage (&&^^^^2/2^^^^&&).

The tool is explicitly characterized as a purely black-box system. In the technical narrative, this black-box property is operationalized through passive traffic observation, field extraction, mutation, packet reinjection, and response analysis, rather than through firmware access or code instrumentation. The summary further states that IoTFuzzSentry can uncover vulnerabilities “without any proprietary firmware access,” which clarifies the intended deployment model and distinguishes it from firmware-assisted or coverage-guided analyses (&&^^^^2/2^^^^&&).

Its protocol scope is constrained. The supported traffic classes described in the architecture and evaluation are HTTP, RTSP, and TP-Link JSON, and the limitations section states that only plaintext protocols—HTTP, RTSP, and TCP/JSON—are supported. Encrypted channels such as HTTPS and DTLS are explicitly out of scope (&&^^^^2/2^^^^&&). This scope is technically significant because the tool targets syntax-preserving mutations over visible application fields rather than cryptographic or transport-session manipulation.

A central feature is protocol guidance. Protocol guidance enters in two ways: the parser knows field boundaries for each supported protocol, and the mutation engine selects only fields that make semantic sense to alter. This establishes IoTFuzzSentry as neither a blind byte-level mutator nor a stateful protocol sequence fuzzer. Instead, it occupies a narrower design space centered on lexical mutation over semantically chosen protocol fields (&&^^^^2/2^^^^&&).

2. System architecture

The architecture is organized into four main components: Seed Input Collector (Protocol Parser), Mutation Engine, Packet Injector, and Result Analyzer (Vulnerability Assessor) (&&^^^^2/2^^^^&&). The data flow is linear at a high level, but protocol specifications influence both parsing and mutation decisions.

The Seed Input Collector passively sniffs network traffic, for example via Wireshark or tcpdump, between the IoT device under test and its controller or cloud. It parses packets of interest such as HTTP, RTSP, and TP-Link JSON, then breaks each packet into a small set of seed inputs consisting of fields or fragments that carry commands, URIs, or credentials (&&^^^^2/2^^^^&&). In this design, a “seed input” is therefore not necessarily a full packet; it is a protocol field or fragment selected for subsequent lexical transformation.

The Mutation Engine receives these seed inputs and applies a suite of lexical mutation operators under a simple protocol-aware grammar. The stated goal is to produce a large pool of mutated fragments that remain syntactically valid for the target protocol. The emphasis on syntactic validity is important: IoTFuzzSentry is not attempting random corruption, but constrained mutation within recognized field structures (&&^^^^2/2^^^^&&).

The Packet Injector reassembles mutated fragments into complete packets, such as an HTTP request line with headers or an RTSP DESCRIBE, and sends those packets to the IoT device under test over raw sockets or via scapy. The injector may impersonate the legitimate controller, including spoofed source IP and port where needed (&&^^^^2/2^^^^&&). This gives the framework a direct operational path from passively harvested message structure to active adversarial replay with mutations.

The Result Analyzer captures all responses from the device and applies per-vulnerability heuristics. The examples given are whether an HTTP 200 OK was returned, whether the RTSP CSeq was honored, or whether err_code==0. Each attempt is then classified as valid, invalid, or malformed, and the system computes summary statistics and generates a final vulnerability report (&&^^^^2/2^^^^&&). This response-centric assessment model is particularly relevant because the paper focuses on non-crash vulnerabilities whose presence must be inferred from semantically meaningful protocol responses rather than process termination or memory fault signals.

3. Mutation methodology and protocol guidance

IoTFuzzSentry uses a purely lexical approach. The paper states that it never reorders packets or inserts stateful sequences; instead, it applies mutation operators field-by-field (&&^^^^2/2^^^^&&). This design choice narrows the attack surface to syntactic and semantic perturbations of individual protocol components while excluding session-level exploration.

The character-level operators are bit-flips, case-flips, digit-replacements, and insertion or deletion of special characters such as "/", "?", "&", "%00", and "../". The structure-level operators are field repetition, length manipulation, and dictionary substitution. Field repetition repeats a path segment or header line; length manipulation pads or truncates numeric fields or length indicators; dictionary substitution replaces a seed segment with another known command fragment (&&^^^^2/2^^^^&&).

The paper provides pseudocode describing a loop over seed values, operators, and a configured number of mutations per seed. An operator is chosen at random or in round-robin fashion, applied to a seed value, then accepted only if validate_syntax(t, protocol) succeeds. The resulting mutated values are added to a mutated pool (&&^^^^2/2^^^^&&). The presence of syntax validation is a defining mechanism: it enforces protocol-level admissibility before packet reassembly and transmission.

Two quantitative measures are defined. “Response coverage,” described as analogous to AFLNet’s feedback, is

$$\mathrm{Coverage} = \frac{|\mathrm{ValidResponses}|}{|\mathrm{TotalMutations}|}.$$

“MutationScore” is

$$\mathrm{MutationScore} = \frac{|\mathrm{UniqueSuccessfulExploits}|}{|\mathrm{TotalMutations}|}.$$

The evaluation section also gives a protocol-specific formulation for response coverage:

$$\mathrm{Coverage} = \frac{|200 \times \#\mathrm{seeds\ producing\ 200\ OK}|}{|\mathrm{Total\ Fuzzed\ Packets}|}.$$

These definitions show that IoTFuzzSentry evaluates mutation efficacy through externally observable response validity and exploit distinctness rather than through internal execution coverage (&&^^^^2/2^^^^&&).

A plausible implication is that the protocol guidance serves two complementary purposes: it reduces the generation of malformed traffic and increases the chance that a mutated request will reach semantically meaningful logic in the device. That implication is consistent with the paper’s statement that the mutation engine alters only fields that make semantic sense to modify.

4. Integration into Cotopaxi

The implementation was integrated into Cotopaxi, described in the paper as a Python-based IoT protocol fuzzer supporting 14 protocols (&&^^^^2/2^^^^&&). The integration is presented as an extension rather than an independent execution environment.

The reported modifications are specific. A new submodule, cotopaxi.iotfuzzsentry, was added and contains seven Python classes, one per D3D, Ezviz, or TP-Link vulnerability. The file vulnerabilities.yaml was updated to register seven new entries—D3D_000, D3D_001, through TPLink_Kasa_000—each pointing to a raw payload template. The implementation was plugged into Cotopaxi’s existing vulnerability_tester framework, allowing invocation with a command of the form:

python3 -m cotopaxi.iotfuzzsentry 192.168.4.17 --protocol HTTP --vuln D3D_003 --verbose

In verbose mode, Cotopaxi prints each mutated fragment plus the status code returned by the device under test. In non-verbose mode, it prints only a summary. The paper further states that all new code passed Cotopaxi’s CI quality checks and was merged upstream under pull request #11 (&&^^^^2/2^^^^&&).

This integration is notable because it positions IoTFuzzSentry as a protocol-guided vulnerability module within a broader fuzzing framework rather than as a monolithic standalone scanner. The summary states that this broadens its reach to hundreds of additional protocols and devices. That statement appears verbatim in the supplied technical narrative, but it should be interpreted cautiously: the detailed evaluation described in the same source remains limited to three specific commercial devices (&&^^^^2/2^^^^&&).

5. Evaluation and discovered vulnerability classes

The reported evaluation was conducted on three commercial-off-the-shelf IoT devices: a D3D IP camera with HTTP and RTSP server support, an Ezviz IP camera with HTTP and RTSP server support, and a TP-Link Kasa Smart Plug using TCP port 9999 with JSON (&&^^^^2/2^^^^&&). The tracked metrics were total mutations attempted per test, valid versus invalid response counts, response coverage, time to complete test, and number of unique vulnerabilities triggered.

The paper reports that tests typically used 200 mutations per seed. For the cameras, the response coverage results are given as follows: D3D RTSP valid 48% and invalid 52%; D3D HTTP valid 44% and invalid 56%; Ezviz RTSP valid 35% and invalid 65%; Ezviz HTTP valid 32% and invalid 68% (&&^^^^2/2^^^^&&). These values characterize the proportion of mutated traffic that still elicited responses deemed valid under the analyzer’s heuristics.

In total, IoTFuzzSentry uncovered seven distinct vulnerabilities, classified into four broad types. Two were assigned CVEs—CVE-2024-41623 and CVE-2024-42531—and the TP-Link plug flaw was reported as under embargo (&&^^^^2/2^^^^&&).

Category	Identification	Exploit
IoT Access Credential Leakage	any HTTP request with Authorization: Basic …	decode Base64 to recover admin:admin123 plaintext credentials (D3D_000)
Sneak Live Video Stream	RTSP request mutation honoring incorrect CSeq or path	send DESCRIBE/PLAY to arbitrary RTSP URI and receive valid live H.264 feed (D3D_001, Ezviz_000)
Creep Live Image	HTTP GET to /tmpfs/auto.jpg?… or analogous paths	mutated query parameters still yield valid JPEG (D3D_002, Ezviz_001)
IoT Command Injection	inserting arbitrary query fields or JSON commands	mutate -act=left to -act=right for D3D, or mutate {"system":{"set_relay_state":{"state":0} to state 1 for TP-Link (D3D_003, TPLink_Kasa_000)

The exploit descriptions are concrete. For credential leakage, the paper states that Base64 decoding recovered the plaintext credentials admin:admin123. For live video stream access, the exploit path involved RTSP DESCRIBE/PLAY to an arbitrary RTSP URI, with real-world proof provided by streaming from a D3D camera using VLC although the authenticated controller never requested it. For live image retrieval, HTTP GET requests to /tmpfs/auto.jpg?… or analogous paths returned valid JPEG images despite mutated query parameters. For command injection, the D3D camera accepted mutation from -act=left to -act=right, causing the camera to pan, and the TP-Link device accepted JSON mutation to change relay state from 0 to 1, toggling power (&&^^^^2/2^^^^&&).

The D3D example exploit snapshots are also timestamped in the paper: 10:23:09 for the initial view, 10:23:10 when the camera pans right on attacker’s HTTP-fuzz, and 10:23:27 when rotation completed without any valid credentials refresh (&&^^^^2/2^^^^&&). These observations emphasize that the discovered flaws are operational vulnerabilities in deployed behavior rather than merely syntactic parser anomalies.

6. Generalization, limitations, and future directions

Beyond the three tested devices, the paper reports passive inspection of six additional products: Tapo, Netatmo, Kodak, and Imou IP cameras, a Wi-Fi spy-clock, and an Airveda air purifier (&&^^^^2/2^^^^&&). These devices were found to use HTTP/RTSP or variants Digest, WSSE, and OSS with cleartext URIs or auth tokens. The paper states that early traffic analysis shows they are similarly vulnerable to one or more of the four categories above. Because this is framed as traffic analysis rather than full vulnerability confirmation, the claim is best read as an observed extension of applicability rather than a complete reproduced exploitation corpus.

The limitations are explicit. Only plaintext protocols—HTTP, RTSP, and TCP/JSON—are supported. Encrypted channels, specifically HTTPS and DTLS, are out of scope. The fuzzing is purely lexical and stateless, with no session modeling, so advanced stateful attacks are not covered. There is also no code-coverage feedback because the method is black-box only (&&^^^^2/2^^^^&&). These constraints define the boundary conditions for interpreting the reported success cases.

The future directions proposed in the paper are correspondingly targeted. They include integrating DTLS and HTTPS man-in-the-middle primitives to fuzz pre-encrypted payloads; adding lightweight state machines such as HTTP cookies and RTSP SETUP→PLAY sequences; combining the approach with lightweight instrumentation on emulated firmware to measure true code path coverage; and automating field identification through lightweight protocol reverse-engineering (&&^^^^2/2^^^^&&). Taken together, these proposals suggest a trajectory from protocol-aware lexical mutation toward hybrid approaches that preserve the deployment realism of black-box testing while selectively incorporating state and instrumentation.

A plausible implication is that IoTFuzzSentry’s main contribution lies less in deep protocol state exploration than in showing that carefully chosen field mutations can expose unconventional, non-crash vulnerabilities at negligible overhead. That interpretation follows directly from the paper’s summary claim that simple, protocol-aware lexical mutation across carefully chosen packet fields can automatically uncover noncrash, high-impact vulnerabilities in deployed IoT devices with negligible overhead and without proprietary firmware access (&&^^^^2/2^^^^&&).