Chapter 31 Key Takeaways: IoT and Embedded Systems Hacking

Core Concepts

  1. IoT Security Spans Five Layers. The IoT attack surface encompasses the device layer (hardware, firmware), communication layer (MQTT, BLE, Zigbee, WiFi), gateway/edge layer, cloud/platform layer, and application layer. Comprehensive security testing must cover all five layers, as weaknesses in any layer can compromise the entire system.

  2. Hardware Interfaces Are Often the First Way In. UART provides serial console access (often a root shell), JTAG/SWD provides deep processor-level debugging capability, and SPI/I2C enables direct reading of flash memory containing firmware. These debug interfaces are frequently left enabled in production devices, providing attackers with full system access through physical contact.

  3. Firmware Is a Goldmine for Attackers. Firmware analysis using binwalk reveals hardcoded credentials, encryption keys, service configurations, vulnerable binaries, and hidden functionality. Firmware can be obtained through hardware extraction (SPI flash reading), network capture (intercepting updates), or direct download from manufacturer websites.

  4. Default Credentials Remain the Top IoT Vulnerability. The Mirai botnet compromised hundreds of thousands of devices using just 62 default username/password combinations. Despite widespread awareness, many IoT devices still ship with known default credentials that users never change, or worse, credentials that cannot be changed.

  5. MQTT Security Is Critical for IoT Deployments. MQTT brokers that allow anonymous access, lack TLS encryption (port 1883 vs 8883), or have overly permissive topic ACLs expose all device data to any network attacker. Testing should verify authentication, authorization, and encryption for all MQTT communication.

  6. BLE Communication Requires Active Security Testing. BLE vulnerabilities include Just Works pairing (no MITM protection), unencrypted data transmission, writable characteristics without authentication, and static MAC addresses enabling tracking. Healthcare IoT devices transmitting patient data over BLE without encryption violate HIPAA requirements.

  7. Embedded Web Interfaces Contain Basic Vulnerabilities. IoT web interfaces commonly suffer from default credentials, command injection in diagnostic tools, directory traversal, authentication bypass, and unencrypted credential transmission. These are often well-understood web vulnerabilities that persist because IoT devices receive less security scrutiny than enterprise applications.

  8. ICS/SCADA Testing Demands Extreme Caution. Industrial control systems control physical processes that can affect human safety. Modbus and other industrial protocols lack native authentication and encryption. Testing must occur in isolated environments with safety protocols, process engineer involvement, and documented rollback procedures.

  9. Network Segmentation Is Essential for IoT Safety. The Jeep Cherokee hack demonstrated the catastrophic consequences of connecting internet-facing interfaces directly to safety-critical systems. IoT networks must be segmented from corporate networks, and within IoT deployments, internet-facing components must be isolated from sensitive control and data pathways.

  10. IoT Security Has Real-World Physical Consequences. Unlike traditional IT security where the primary concern is data confidentiality and availability, IoT security failures can cause physical harm — compromised vehicles, falsified medical readings, disrupted industrial processes, and invaded privacy. Every IoT finding must be assessed for its physical safety impact.

Practical Reminders

  • Always check for default credentials first when testing IoT devices
  • Use a multimeter to identify UART pins before connecting any adapter
  • Verify firmware dump integrity by reading twice and comparing hashes
  • Use binwalk with the -Me flag for recursive extraction of nested archives
  • Run entropy analysis to distinguish encrypted from unencrypted firmware sections
  • Test MQTT by subscribing to the # wildcard topic to check for anonymous access
  • Never test ICS/SCADA systems in production environments
  • Document all hardware modifications with photographs for your report
  • Use isolated networks for all IoT security testing
  • Consider both data security and physical safety implications in every finding
  • Build your IoT testing lab incrementally: start with a Raspberry Pi and a UART adapter