IoT Protocols
IoT devices use a variety of communication protocols, many designed for low-power constrained environments. Understanding these protocols is essential for effective security testing.
MQTT (Message Queuing Telemetry Transport)
Lightweight publish/subscribe messaging protocol. Extremely common in IoT for device-to-cloud communication.
Ports
- •
1883- MQTT (unencrypted) - •
8883- MQTT over TLS - •
8080/8083- MQTT over WebSocket
Common Issues
- • No authentication required
- • Weak/default credentials
- • No TLS encryption
- • Overly permissive topic ACLs
MQTT Reconnaissance
# Connect to MQTT broker (anonymous)
mosquitto_sub -h broker.example.com -t "#" -v
# Connect with credentials
mosquitto_sub -h broker.example.com -u "user" -P "password" -t "#" -v
# Subscribe to all topics (wildcard)
mosquitto_sub -h 192.168.1.100 -t "#" -v
mosquitto_sub -h 192.168.1.100 -t "$SYS/#" -v # System topics
# Common topic patterns to monitor
# home/+/temperature
# device/+/status
# cmd/+/control
# $SYS/broker/clients/connected
# Publish test message
mosquitto_pub -h 192.168.1.100 -t "test/topic" -m "hello"
# MQTT with TLS
mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt -t "#" -vMQTT Exploitation
# Brute force MQTT credentials
ncrack mqtt://192.168.1.100 -U users.txt -P passwords.txt
# Using mqtt-pwn for automated testing
# https://github.com/akamai-threat-research/mqtt-pwn
mqtt-pwn
> connect -h 192.168.1.100
> discovery # Discover topics
> subscribe -t "#" # Subscribe to all
# Injecting malicious commands (if device listens for commands)
mosquitto_pub -h 192.168.1.100 -t "device/123/cmd" -m '{"action":"unlock"}'
mosquitto_pub -h 192.168.1.100 -t "home/alarm/set" -m "OFF"
# Topic enumeration wordlist
home/+/status
device/+/telemetry
cmd/+/control
sensors/+/data
$SYS/broker/#CoAP (Constrained Application Protocol)
RESTful protocol designed for constrained devices. Uses UDP, similar to HTTP but much lighter.
Key Characteristics
- • Port:
5683(UDP),5684(DTLS) - • Methods: GET, POST, PUT, DELETE (like HTTP)
- • Supports observe (subscribe to resource changes)
- • Often lacks authentication
# Install CoAP client
pip install aiocoap
# Using coap-client (libcoap)
# Discovery - find resources
coap-client -m get coap://192.168.1.100/.well-known/core
# Get resource
coap-client -m get coap://192.168.1.100/sensor/temperature
# Set resource
coap-client -m put coap://192.168.1.100/actuator/led -e "on"
# POST data
coap-client -m post coap://192.168.1.100/data -e '{"temp":25}'
# Using Copper (Firefox plugin) for GUI testing
# Or coap.me for online testing
# Nmap CoAP scripts
nmap -sU -p 5683 --script coap-resources 192.168.1.100Bluetooth Low Energy (BLE)
Common in wearables, smart locks, beacons, and medical devices. Uses GATT (Generic Attribute Profile) for data exchange.
Hardware Required
BLE Reconnaissance
# Enable Bluetooth interface
sudo hciconfig hci0 up
# Scan for BLE devices
sudo hcitool lescan
# More detailed scan with bluetoothctl
bluetoothctl
> scan on
> devices
> info <MAC_ADDRESS>
# Using bettercap for BLE
sudo bettercap
> ble.recon on
> ble.show
> ble.enum <MAC_ADDRESS> # Enumerate services
# Using gatttool (deprecated but still useful)
gatttool -b <MAC_ADDRESS> -I
> connect
> primary # List primary services
> characteristics # List characteristics
> char-read-hnd 0x0010 # Read handleBLE Exploitation
# Enumerate all services and characteristics
gatttool -b <MAC> --primary
gatttool -b <MAC> --characteristics
# Read characteristic value
gatttool -b <MAC> --char-read -a 0x0025
# Write to characteristic (potential command injection)
gatttool -b <MAC> --char-write-req -a 0x0025 -n 01
gatttool -b <MAC> --char-write-req -a 0x0025 -n $(echo -n "unlock" | xxd -p)
# BLE sniffing with Ubertooth
ubertooth-btle -f -c capture.pcap
# Wireshark filter for BLE
btatt # Attribute protocol
btle # BLE link layer
# Common BLE attacks:
# - Eavesdropping (sniff pairing/data)
# - Spoofing (clone device MAC)
# - MITM (relay attacks)
# - Fuzzing (malformed GATT requests)Zigbee
Mesh networking protocol common in smart home devices (lights, sensors, locks). Operates on 2.4 GHz (and other bands).
Zigbee Security Levels
- • No Security - Unencrypted (rare now)
- • Network Key - Shared key for all devices
- • Link Key - Per-device keys (more secure)
- • Install Codes - Pre-shared keys from manufacturing
# Zigbee requires SDR hardware:
# - HackRF One
# - YARD Stick One
# - Atmel RZUSBstick (KillerBee compatible)
# - CC2531 USB dongle
# KillerBee framework
# Install: https://github.com/riverloopsec/killerbee
# Scan for Zigbee networks
zbstumbler
# Capture packets
zbdump -f 15 -w zigbee_capture.pcap # Channel 15
# Replay attack
zbreplay -f 15 -r zigbee_capture.pcap
# Key sniffing during pairing
# Many devices transmit network key in clear during join process
zbwireshark # Real-time capture in Wireshark
# Decrypt with known key in Wireshark:
# Edit > Preferences > Protocols > ZigBee > Security Level
# Add key: 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39 (default)Z-Wave
Proprietary protocol for home automation. Uses sub-GHz frequencies (908.42 MHz in US, 868.42 MHz in EU).
# Z-Wave testing requires:
# - HackRF One or similar SDR
# - Z-Wave USB stick (for legitimate testing)
# - Scapy with Z-Wave extensions
# Using EZ-Wave (research tool)
# https://github.com/cureHsu/EZ-Wave
# Capture Z-Wave with SDR
# Note: Requires appropriate SDR software and gnuradio
# Z-Wave security versions:
# S0 - Weak (key exchange flaw)
# S2 - More secure (use ECDH for key exchange)
# Common attacks:
# - S0 downgrade attacks
# - Signal replay
# - Network key extraction during pairingLoRaWAN
Long-range, low-power protocol for IoT. Used in smart city, agriculture, and industrial applications.
# LoRa testing requires SDR (HackRF, LimeSDR)
# Or dedicated LoRa hardware (SX1276 modules)
# Using gr-lora for GNU Radio
# https://github.com/rpp0/gr-lora
# LoRaWAN security:
# - AppKey: Application key (device specific)
# - NwkSKey: Network session key
# - AppSKey: Application session key
# Common vulnerabilities:
# - ABP devices with static keys
# - Replay attacks
# - Bit-flipping on unencrypted fields
# - Eavesdropping on join requests
# Tools:
# - ChirpOTLE: https://github.com/seemoo-lab/chirpotle
# - LoRa-SDR: https://github.com/myriadrf/LoRa-SDRUPnP / SSDP
Universal Plug and Play - automatic device discovery and configuration. Major source of IoT vulnerabilities.
# Discover UPnP devices
# Using miranda (UPnP pentesting tool)
miranda
> msearch
> host list
> host get 0
> host info 0
# Manual SSDP discovery
echo -e "M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: ssdp:discover\r\nMX: 2\r\nST: ssdp:all\r\n\r\n" | nc -u 239.255.255.250 1900
# Nmap UPnP scripts
nmap -sU -p 1900 --script=upnp-info 192.168.1.0/24
# Common UPnP attacks:
# - Port forwarding manipulation
# - Device information disclosure
# - XML injection in SOAP requests
# - Callback exploitation
# Using upnp-arsenal
# https://github.com/nccgroup/upnp-arsenalProtocol Comparison
| Protocol | Range | Data Rate | Security | Testing Tools |
|---|---|---|---|---|
| MQTT | N/A (TCP/IP) | Network speed | TLS optional | mosquitto, mqtt-pwn |
| CoAP | N/A (UDP/IP) | Network speed | DTLS optional | coap-client, aiocoap |
| BLE | ~100m | 1-2 Mbps | AES-CCM | gatttool, bettercap |
| Zigbee | ~100m | 250 Kbps | AES-128 | KillerBee, Wireshark |
| Z-Wave | ~100m | 100 Kbps | S0/S2 | EZ-Wave, SDR |
| LoRaWAN | ~15km | 0.3-50 Kbps | AES-128 | ChirpOTLE, gr-lora |