IOT-SECURITY
Authorized use only. Offensive reference for systems you own or are explicitly permitted to test. You are responsible for staying within the law.
Comprehensive guide to IoT device security testing covering firmware analysis, hardware interfaces, protocols, and RF attacks.
FIRMWARE EXTRACTION AND ANALYSIS#
Obtaining firmware:
1. Manufacturer website (download updates)
2. Intercept OTA update (MITM the update server)
3. Extract from flash chip (hardware method)
4. Read from debug interfaces (UART, JTAG, SPI)
5. Mobile app analysis (sometimes contains firmware URLs)
Binwalk (firmware analysis):
# Scan for embedded files and signatures
binwalk firmware.bin
# Extract all files
binwalk -e firmware.bin
# Recursive extraction
binwalk -eM firmware.bin
# Entropy analysis (find encrypted/compressed sections)
binwalk -E firmware.bin
# Specific signature scan
binwalk -A firmware.bin # opcodes/CPU architecture
binwalk -R "\x89PNG" firmware.bin # custom signature
Common findings:
- Squashfs filesystem (most Linux-based IoT)
- JFFS2 filesystem
- CPIO archives
- Gzip/LZMA compressed data
- Linux kernel images
- U-Boot bootloader
- Certificate files
Firmware-mod-kit:
git clone https://github.com/rampageX/firmware-mod-kit.git
# Extract firmware
./extract-firmware.sh firmware.bin
# Modify files in extracted filesystem
# e.g., add backdoor, change passwords, modify configs
# Rebuild firmware
./build-firmware.sh
# Flash modified firmware back to device
Post-extraction analysis:
# Search for credentials
grep -r "password\|passwd\|secret\|key\|token" ./extracted/
grep -r "admin\|root\|user" ./extracted/etc/shadow
grep -r "http\|https\|ftp\|ssh" ./extracted/
# Find hardcoded keys and certs
find ./extracted -name "*.pem" -o -name "*.key" -o -name "*.crt"
find ./extracted -name "*.conf" -o -name "*.cfg" -o -name "*.ini"
# Check for known vulnerable binaries
find ./extracted -name "busybox" -exec strings {} \; | head -1
find ./extracted -executable -type f
# Analyze web application
find ./extracted -name "*.php" -o -name "*.cgi" -o -name "*.lua"
find ./extracted -path "*/www/*" -o -path "*/htdocs/*"
# Check startup scripts
cat ./extracted/etc/init.d/*
cat ./extracted/etc/rc.local
cat ./extracted/etc/inittab
# Password hashes
cat ./extracted/etc/shadow
cat ./extracted/etc/passwd
# SSH keys
find ./extracted -name "authorized_keys" -o -name "id_rsa"
Firmwalker:
git clone https://github.com/craigz28/firmwalker.git
./firmwalker.sh ./extracted/ ./firmwalker.txt
# Automated search for passwords, keys, URLs, emails, etc.
EMBA (firmware analysis framework):
git clone https://github.com/e-m-b-a/emba.git
sudo ./emba -f ./firmware.bin -l ./results/
# Comprehensive automated firmware analysis
HARDWARE INTERFACES#
UART (Universal Asynchronous Receiver-Transmitter):
Purpose: Serial console access (often root shell)
Identifying UART pins:
- Look for 3-4 pin headers on PCB (TX, RX, GND, VCC)
- Use multimeter: GND is ground, VCC is constant voltage
- Use logic analyzer to identify TX (data at boot)
- Baud rate typically: 9600, 19200, 38400, 57600, 115200
Connection:
Device TX -> Adapter RX
Device RX -> Adapter TX
Device GND -> Adapter GND
(Do NOT connect VCC usually)
Tools:
- USB-to-UART adapter (FTDI FT232, CP2102, CH340)
- Bus Pirate
- Tigard
Software:
screen /dev/ttyUSB0 115200
minicom -D /dev/ttyUSB0 -b 115200
picocom -b 115200 /dev/ttyUSB0
# Auto-detect baud rate
# baudrate.py (from devttys0)
python3 baudrate.py -p /dev/ttyUSB0
Common findings:
- Boot log with kernel version and build info
- Root shell without authentication
- Debug information and error messages
- Bootloader access (U-Boot)
JTAG (Joint Test Action Group):
Purpose: Hardware debugging, memory read/write, firmware dump
Identifying JTAG pins:
- Look for pin headers (TDI, TDO, TMS, TCK, TRST, GND)
- Use JTAGulator to auto-detect pinout
- Check chip datasheets for JTAG pins
Tools:
- JTAGulator (pinout detection)
- Bus Pirate (basic JTAG)
- Segger J-Link
- FTDI-based adapters
- Tigard
Software:
- OpenOCD (Open On-Chip Debugger)
- GDB (for debugging via JTAG)
OpenOCD basic usage:
openocd -f interface/ftdi/tigard.cfg -f target/stm32f4x.cfg
# Then connect GDB:
arm-none-eabi-gdb
target remote localhost:3333
monitor reset halt
monitor flash read_image firmware.bin 0x08000000 0x100000
SPI (Serial Peripheral Interface):
Purpose: Read/write flash memory chips directly
Common flash chips: W25Q32, W25Q64, W25Q128, MX25L series
Tools:
- flashrom + SPI programmer (CH341A, Bus Pirate)
- Tigard
- SPI flash clip (SOIC-8 clip)
Reading flash:
flashrom -p ch341a_spi -r firmware_dump.bin
flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -r dump.bin
Writing flash:
flashrom -p ch341a_spi -w modified_firmware.bin
Verification:
flashrom -p ch341a_spi -v firmware_dump.bin
I2C (Inter-Integrated Circuit):
Purpose: Read EEPROM, sensor data, configuration
Tools:
- Bus Pirate
- Logic analyzer
- i2c-tools (Linux)
Usage:
i2cdetect -y 1 # scan for devices
i2cdump -y 1 0x50 # dump EEPROM at address 0x50
i2cget -y 1 0x50 0x00 # read byte
i2cset -y 1 0x50 0x00 0xFF # write byte
NETWORK PROTOCOL ANALYSIS#
MQTT (Message Queuing Telemetry Transport):
Default port: 1883 (unencrypted), 8883 (TLS)
Testing:
# Subscribe to all topics
mosquitto_sub -h <broker_ip> -t '#' -v
mosquitto_sub -h <broker_ip> -t '$SYS/#' -v # system topics
# Publish test message
mosquitto_pub -h <broker_ip> -t 'test/topic' -m 'hello'
# With authentication
mosquitto_sub -h <broker_ip> -u <user> -P <pass> -t '#'
Common vulnerabilities:
- No authentication required
- No encryption (plaintext MQTT)
- Sensitive data in topics (credentials, sensor data)
- Wildcard subscriptions allowed
- $SYS topics exposed (broker info)
- Command injection via topic/message handling
Tools:
- MQTT Explorer (GUI client)
- mqtt-pwn (MQTT penetration testing)
- mosquitto_sub/pub (CLI clients)
CoAP (Constrained Application Protocol):
Default port: 5683 (UDP)
Testing:
# CoAP client
pip install aiocoap
coap-client -m get coap://<device_ip>/.well-known/core
coap-client -m get coap://<device_ip>/sensor/temperature
# Nmap CoAP scan
nmap -sU -p 5683 --script coap-resources <target>
Vulnerabilities:
- No authentication/authorization
- Resource enumeration via .well-known/core
- DTLS not implemented
- Amplification attacks (CoAP responses larger than requests)
ZigBee (802.15.4):
Frequency: 2.4 GHz (most common), 868/915 MHz
Range: 10-100 meters
Tools:
- KillerBee (Python framework)
- ApiMote (ZigBee sniffer)
- RZUSBstick
- HackRF (with GNU Radio)
Attacks:
# Sniff ZigBee traffic
zbstumbler # find ZigBee networks
zbdump -f 15 -w capture.pcap # capture on channel 15
zbwireshark # view in Wireshark
- Key sniffing (capture network key during joining)
- Replay attacks
- Packet injection
- Network key extraction from devices
Vulnerabilities:
- Default/well-known trust center link keys
- Key transmitted in plaintext during device pairing
- Insecure rejoin mechanism
- Lack of frame counter validation
BLE (Bluetooth Low Energy):
Tools:
- nRF Connect app (Android/iOS)
- Ubertooth One (BLE sniffer)
- btlejuice (MITM framework)
- GATTacker
- bettercap
Testing:
# Scan for BLE devices
hcitool lescan
bluetoothctl > scan on
# Enumerate services and characteristics
gatttool -b <MAC> -I
> primary # list services
> characteristics # list characteristics
> char-read-hnd <handle> # read value
# bettercap BLE
bettercap
ble.recon on
ble.enum <MAC>
Vulnerabilities:
- No pairing required for data access
- Weak or no encryption
- Static MAC addresses (tracking)
- Plaintext characteristic values
- Unauthenticated write to characteristics
DEFAULT CREDENTIAL DATABASES#
Online resources:
- https://www.defaultpassword.com/
- https://cirt.net/passwords
- https://default-password.info/
- https://datarecovery.com/rd/default-passwords/
- Shodan: search for device type, check known defaults
Common IoT defaults:
Device Type | Username | Password
-----------------|----------|----------
Routers (many) | admin | admin
IP cameras | admin | 12345
Hikvision | admin | 12345
Dahua | admin | admin
TP-Link | admin | admin
Ubiquiti | ubnt | ubnt
Mikrotik | admin | (blank)
Raspberry Pi | pi | raspberry
Arduino/ESP | (none) | (none)
Telnet IoT | root | (blank)
# Brute force with Hydra
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
<target> http-post-form "/login:user=^USER^&pass=^PASS^:F=incorrect"
hydra -l admin -P passwords.txt <target> ssh
hydra -l admin -P passwords.txt <target> telnet
RADIO FREQUENCY ATTACKS (SDR)#
Software Defined Radio tools:
Hardware:
- HackRF One ($300, 1MHz-6GHz, TX/RX)
- RTL-SDR ($25, 25MHz-1.7GHz, RX only)
- YARD Stick One (sub-GHz TX/RX)
- Ubertooth One (2.4GHz BLE)
- Flipper Zero (multi-protocol)
Software:
- GNU Radio (signal processing framework)
- SDR# (Windows spectrum analyzer)
- GQRX (Linux/Mac spectrum analyzer)
- Universal Radio Hacker (URH) - protocol analysis
- Inspectrum (signal analysis)
Common IoT RF frequencies:
315 MHz: Garage doors, car remotes (US)
433 MHz: IoT sensors, remotes (EU/worldwide)
868 MHz: LoRa, Z-Wave (EU)
915 MHz: LoRa, Z-Wave (US)
2.4 GHz: WiFi, BLE, ZigBee, Thread
Attack types:
Replay attack:
1. Record signal: hackrf_transfer -r capture.raw -f 433920000 -s 2000000
2. Replay signal: hackrf_transfer -t capture.raw -f 433920000 -s 2000000
Jamming:
- Transmit noise on target frequency
- Illegal in most jurisdictions (use in lab only)
Signal analysis:
1. Capture with SDR
2. Analyze with URH or inspectrum
3. Decode modulation (OOK, FSK, ASK, PSK)
4. Extract protocol data
5. Craft modified packets
URH (Universal Radio Hacker):
pip install urh
# GUI for recording, analyzing, and generating RF signals
# Supports: RTL-SDR, HackRF, USRP
# Features: signal recording, protocol analysis, fuzzing
MOBILE APP API TESTING#
IoT devices typically have companion mobile apps. Testing approach: 1. Install app on rooted/jailbroken device 2. Set up proxy (Burp Suite) 3. Bypass certificate pinning (Frida/Objection) 4. Capture and analyze API traffic 5. Test API endpoints for vulnerabilities Common findings: - Hardcoded API keys in mobile app - No authentication on API endpoints - IDOR (access other users' devices) - Command injection via API parameters - Firmware update URLs exposed in traffic - Cloud API over HTTP (no TLS) - Weak session management - No rate limiting on API # Extract API endpoints from APK apktool d companion_app.apk grep -r "http\|https\|api\|endpoint" ./decoded/ # Decompile and find API keys jadx companion_app.apk -d java_src/ grep -rn "API_KEY\|api_key\|token\|secret" java_src/
COMMON IOT VULNERABILITIES (OWASP IOT TOP 10)#
1. Weak, Guessable, or Hardcoded Passwords
- Default credentials not changed
- Hardcoded backdoor accounts
- No account lockout
Test: Try default creds, brute force, check firmware for hardcoded
2. Insecure Network Services
- Unnecessary open ports
- Telnet/FTP exposed
- UPnP enabled
- Unencrypted protocols
Test: nmap -sV -sC <device_ip>, check for telnet/FTP/HTTP
3. Insecure Ecosystem Interfaces
- Vulnerable web interface, API, cloud, mobile app
- No input validation
- Missing authentication
Test: OWASP web testing, API testing, mobile app analysis
4. Lack of Secure Update Mechanism
- No firmware signature verification
- Plaintext update delivery (HTTP)
- No rollback protection
- No update capability at all
Test: Intercept update, verify signature check, try modified firmware
5. Use of Insecure or Outdated Components
- Old Linux kernel with known CVEs
- Outdated OpenSSL, busybox
- Vulnerable web server (lighttpd, boa)
Test: Extract firmware, check versions, compare against CVE databases
6. Insufficient Privacy Protection
- PII collected unnecessarily
- Data sent to cloud without consent
- No data encryption
Test: Monitor network traffic, check data storage, review privacy policy
7. Insecure Data Transfer and Storage
- Plaintext communication
- Sensitive data in flash unencrypted
- Credentials in configuration files
Test: Traffic analysis, firmware extraction, flash dump
8. Lack of Device Management
- No asset management capability
- No security monitoring
- No capability to update
Test: Assess management interface, update mechanisms
9. Insecure Default Settings
- Debug interfaces enabled
- Default configurations insecure
- Unnecessary services running
Test: Check UART/JTAG, review running services, check configs
10. Lack of Physical Hardening
- Exposed debug ports (UART/JTAG)
- No tamper detection
- External storage easily accessible
- No secure boot
Test: Physical inspection, try debug interfaces, extract flash
IOT PENTESTING METHODOLOGY#
Phase 1: Reconnaissance [ ] Identify device type, manufacturer, model [ ] Find firmware (download or extract) [ ] Identify communication protocols [ ] Map network services (nmap scan) [ ] Identify companion apps [ ] Research known vulnerabilities Phase 2: Firmware Analysis [ ] Extract and analyze firmware (binwalk) [ ] Search for hardcoded credentials [ ] Identify vulnerable components [ ] Analyze web application code [ ] Check for debug/backdoor functionality Phase 3: Hardware Analysis [ ] Identify debug interfaces (UART, JTAG, SPI) [ ] Attempt console access [ ] Read/dump flash memory [ ] Analyze PCB for test points Phase 4: Network Analysis [ ] Scan all ports and services [ ] Test default credentials [ ] Analyze protocol security (MQTT, CoAP, etc.) [ ] Intercept and analyze cloud communication [ ] Test for MITM vulnerabilities Phase 5: Radio Analysis (if applicable) [ ] Identify RF protocols used [ ] Capture and analyze RF signals [ ] Test for replay attacks [ ] Check for encryption in RF communication Phase 6: Mobile/Cloud [ ] Test companion mobile app [ ] Test cloud APIs [ ] Check for IDOR and auth bypass [ ] Analyze data in transit
REFERENCES#
- OWASP IoT Top 10: https://owasp.org/www-project-internet-of-things-top-10/ - OWASP Firmware Security Testing Methodology - Binwalk: https://github.com/ReFirmLabs/binwalk - EMBA: https://github.com/e-m-b-a/emba - Attify IoT Exploitation: https://www.attify.com/ - IoT Village (DEF CON): https://www.iotvillage.org/ - Exploiting IoT (book by Aditya Gupta)