Part II: Vulnerability Study Chapter 12

IoT & Embedded Systems Security

IoT protocols, firmware analysis, hardware hacking, ICS/SCADA security, and embedded device defense

Chapter 12: IoT & Embedded Systems Security

The Jeep Hack That Changed Automotive Security

In July 2015, security researchers Charlie Miller and Chris Valasek demonstrated something that sounded like science fiction: they remotely hacked a 2014 Jeep Cherokee while Wired journalist Andy Greenberg drove it on Interstate 64 in St. Louis at 70 mph.

From Miller’s living room 10 miles away, they disabled the transmission, cut the brakes, and controlled the steering. They accessed the vehicle through its Uconnect entertainment system (powered by Harman Kardon hardware and Sprint’s cellular network). From there, they pivoted through the vehicle’s CAN bus to reach critical systems including the engine, brakes, and steering.

Fiat Chrysler Automobiles (FCA) initially recalled 1.4 million vehicles equipped with 8.4-inch touchscreen Uconnect systems—the first automotive recall for a cybersecurity vulnerability. The incident prompted the National Highway Traffic Safety Administration (NHTSA) to issue its first cybersecurity best practices for modern vehicles. Congress introduced legislation (the SPY Car Act) requiring automotive cybersecurity standards.

More importantly, the demonstration—published in Wired’s “Hackers Remotely Kill a Jeep on the Highway”—showed the world that the explosion of connected devices had created an entirely new attack surface.

From smart thermostats to industrial control systems, embedded devices now control critical infrastructure, homes, vehicles, and medical equipment. This chapter explores the unique security challenges of IoT and embedded systems, and how attackers exploit them.

IoT Attack Surface

IoT devices differ fundamentally from traditional IT systems, creating unique security challenges.

IoT Attack Surface

IoT Attack Surface:
═══════════════════════════════════════════════════════════════════

┌─────────────────────────────────────────────────────────────────┐
│                    DEVICE LAYER                                 │
├─────────────────────────────────────────────────────────────────┤
│ • Hardware debug interfaces (UART, JTAG, SPI)                   │
│ • Firmware vulnerabilities                                      │
│ • Insecure boot process                                         │
│ • Default credentials                                           │
│ • Physical tampering                                            │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                   NETWORK LAYER                                 │
├─────────────────────────────────────────────────────────────────┤
│ • Unencrypted protocols (MQTT, CoAP)                            │
│ • Weak authentication                                           │
│ • Insecure firmware updates                                     │
│ • Exposed management interfaces                                 │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                   CLOUD LAYER                                   │
├─────────────────────────────────────────────────────────────────┤
│ • Insecure APIs                                                 │
│ • Weak cloud authentication                                     │
│ • Data privacy issues                                           │
│ • Account takeover                                              │
└─────────────────────────────────────────────────────────────────┘

IoT Security Challenges

Challenge	Description
Resource Constraints	Limited CPU, memory, power for security
Long Lifespan	Devices may run for 10+ years
Update Difficulty	No automatic updates, physical access needed
Physical Access	Attackers can physically access devices
Scale	Millions of identical devices, one vuln affects all
Diverse Protocols	MQTT, CoAP, Zigbee, Z-Wave, BLE, etc.
Supply Chain	Components from many vendors

MITRE ATT&CK Reference

IoT attacks map to ATT&CK for ICS:

T0800 - Activate Firmware Update Mode

T0839 - Module Firmware

T0873 - Project File Infection

T0846 - Remote Services

IoT Protocols

MQTT (Message Queuing Telemetry Transport)

Lightweight publish/subscribe messaging protocol, widely used in IoT.

MQTT Architecture

MQTT Architecture:
═══════════════════════════════════════════════════════════════════

Publishers ───► MQTT Broker ───► Subscribers
                    │
    ┌───────────────┼───────────────┐
    │               │               │
Sensor 1       Sensor 2         Client App
(temp)         (humidity)       (subscriber)
    │               │               │
    └── Publish ────┴───────────────┘
        to topic
        
Topics: home/livingroom/temperature
        home/livingroom/humidity
        factory/machine1/status

MQTT Security Issues:

MQTT Vulnerabilities

MQTT Vulnerabilities:
═══════════════════════════════════════════════════════════════════

1. DEFAULT ANONYMOUS ACCESS:
   Many brokers allow unauthenticated connections
   Can subscribe to # (wildcard = ALL topics)

2. UNENCRYPTED BY DEFAULT:
   MQTT typically runs on port 1883 (unencrypted)
   MQTTS on port 8883 (TLS) less common

3. TOPIC DISCLOSURE:
   Subscribe to # reveals all topics
   Topics often contain sensitive information

4. NO ACCESS CONTROL:
   Any authenticated user can subscribe/publish anywhere

MQTT Enumeration:

# Connect to open MQTT broker
mosquitto_sub -h broker.example.com -t "#" -v

# Output reveals all topics and messages:
# home/temp 72.5
# factory/plc1/status RUNNING
# security/cameras/motion DETECTED

# Publish malicious command
mosquitto_pub -h broker.example.com -t "factory/plc1/command" -m "STOP"

CoAP (Constrained Application Protocol)

REST-like protocol for constrained devices over UDP.

# CoAP discovery
coap-client -m get coap://device.local/.well-known/core

# Returns available resources
# </temperature>;ct=0,</switch>;ct=0

# Interact with resources
coap-client -m get coap://device.local/temperature
coap-client -m put coap://device.local/switch -e "1"

Zigbee and Z-Wave

Low-power mesh protocols for home automation.

Zigbee Security

Zigbee Security:
═══════════════════════════════════════════════════════════════════

NETWORK KEYS:
- Network-wide shared key
- If one device compromised, network key exposed

TRUST CENTER:
- Single point for key distribution
- Compromise = network compromise

KNOWN ATTACKS:
- Key sniffing during pairing
- Replay attacks
- Device impersonation

Zigbee Analysis:

# Using KillerBee (requires compatible hardware)
# Sniff Zigbee traffic
zbwireshark

# Replay captured packets
zbreplay -f capture.pcap

# Tools: Attify Badge, ApiMote, HackRF

Firmware Analysis

Firmware Extraction

Firmware Acquisition Methods

Firmware Acquisition Methods:
═══════════════════════════════════════════════════════════════════

1. VENDOR DOWNLOAD:
   - Check vendor website for updates
   - Often unencrypted firmware images

2. NETWORK CAPTURE:
   - MITM device during update
   - May reveal update server and protocol

3. HARDWARE EXTRACTION:
   - Read flash chip directly (SPI, NAND)
   - JTAG/debug interface dump
   - UART console access

4. DEVICE DUMP:
   - SSH/Telnet if accessible
   - dd if=/dev/mtd0 of=firmware.bin

Firmware Unpacking

# Binwalk - Firmware analysis tool
binwalk firmware.bin
# Shows embedded files, compression, filesystems

# Extract contents
binwalk -e firmware.bin

# Results in _firmware.bin.extracted/
# - squashfs-root/ (filesystem)
# - kernel
# - bootloader

# Analyze extracted filesystem
find . -name "*.conf" -o -name "*.cfg"
find . -name "passwd" -o -name "shadow"
grep -r "password" .
strings firmware.bin | grep -i "pass\|key\|secret"

Finding Vulnerabilities

# Look for hardcoded credentials
grep -r "admin\|root\|password" squashfs-root/

# Find web interface
ls -la squashfs-root/www/
cat squashfs-root/etc/passwd

# Check for command injection
grep -r "system\|exec\|popen\|shell" squashfs-root/www/

# Analyze binaries
file squashfs-root/usr/bin/app
strings squashfs-root/usr/bin/app | grep -i "key\|pass"

# Run static analysis
checksec --file=squashfs-root/usr/bin/app

Hardware Hacking

UART (Universal Asynchronous Receiver-Transmitter)

Serial console interface, often provides root shell.

UART Identification

UART Identification:
═══════════════════════════════════════════════════════════════════

TYPICAL PINOUT:
┌───┬───┬───┬───┐
│VCC│GND│TX │RX │
└───┴───┴───┴───┘

IDENTIFICATION:
- 4 pins in a row (sometimes 3 without VCC)
- Use multimeter to find GND (continuity to ground plane)
- VCC usually 3.3V or 5V
- TX/RX determined by logic analyzer or trial

TOOLS:
- USB-to-UART adapter (FTDI, CP2102)
- Baudrate: Common values 9600, 115200, 57600

Connecting to UART:

# List serial devices
ls /dev/ttyUSB*

# Connect with screen
screen /dev/ttyUSB0 115200

# Or minicom
minicom -D /dev/ttyUSB0 -b 115200

# Boot messages appear, often with root shell
# BusyBox v1.19.4 (2020-01-15) built-in shell
# / #

JTAG (Joint Test Action Group)

Debug interface for microcontrollers, allows memory read/write.

JTAG Capabilities

JTAG Capabilities:
═══════════════════════════════════════════════════════════════════

WHAT JTAG CAN DO:
- Read/write flash memory
- Read/write RAM
- Single-step CPU execution
- Set breakpoints
- Bypass secure boot (sometimes)

IDENTIFICATION:
- Look for labeled pins: TCK, TMS, TDI, TDO, TRST, VCC, GND
- Use JTAGulator or JTAGEnum for automatic detection

TOOLS:
- OpenOCD (software)
- Bus Pirate, Shikra (hardware)
- Segger J-Link (professional)

SPI Flash Reading

# Read SPI flash chip directly
# Using Bus Pirate or flashrom

# Identify chip
flashrom -p buspirate_spi:dev=/dev/ttyUSB0

# Read firmware
flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -r firmware_dump.bin

# Analyze with binwalk
binwalk firmware_dump.bin

ICS/SCADA Security

Industrial Control Systems Overview

ICS Architecture

ICS Architecture:
═══════════════════════════════════════════════════════════════════

┌─────────────────────────────────────────────────────────────────┐
│                    ENTERPRISE ZONE                              │
│  Business systems, ERP, email                                   │
└───────────────────────────┬─────────────────────────────────────┘
                            │ DMZ
┌───────────────────────────┴─────────────────────────────────────┐
│                  SUPERVISORY ZONE                               │
│  SCADA servers, HMI, Historian                                  │
└───────────────────────────┬─────────────────────────────────────┘
                            │
┌───────────────────────────┴─────────────────────────────────────┐
│                    CONTROL ZONE                                 │
│  PLCs, RTUs, DCS                                                │
└───────────────────────────┬─────────────────────────────────────┘
                            │
┌───────────────────────────┴─────────────────────────────────────┐
│                     FIELD ZONE                                  │
│  Sensors, Actuators, Physical Process                           │
└─────────────────────────────────────────────────────────────────┘

ICS Protocols and Vulnerabilities

Protocol	Port	Security Issues
Modbus	502	No authentication, plaintext
DNP3	20000	Optional auth, rarely used
EtherNet/IP	44818	CIP protocol vulnerabilities
S7comm	102	Siemens proprietary, weak auth
OPC	Various	Windows DCOM vulnerabilities

Modbus Exploitation

#!/usr/bin/env python3
"""
Modbus Exploration - AUTHORIZED USE ONLY
"""
from pymodbus.client import ModbusTcpClient

def enumerate_modbus(host, port=502):
    """
    Read Modbus registers
    """
    client = ModbusTcpClient(host, port=port)
    
    if not client.connect():
        print("[-] Connection failed")
        return
    
    print(f"[+] Connected to {host}:{port}")
    
    # Read holding registers
    result = client.read_holding_registers(0, 10, unit=1)
    if not result.isError():
        print(f"[*] Holding registers: {result.registers}")
    
    # Read coils (digital outputs)
    result = client.read_coils(0, 10, unit=1)
    if not result.isError():
        print(f"[*] Coils: {result.bits}")
    
    client.close()

# DANGER: Writing to Modbus can affect physical processes!
# def write_coil(host, address, value):
#     client = ModbusTcpClient(host)
#     client.write_coil(address, value, unit=1)

ICS Attack Case Studies

Notable ICS Attacks

Notable ICS Attacks:
═══════════════════════════════════════════════════════════════════

STUXNET (Discovered June 2010):
- Target: Natanz uranium enrichment facility, Iran
- Targets: Siemens S7-315/S7-417 PLCs controlling centrifuges
- Method: USB delivery, zero-day exploits, Siemens Step 7 exploitation
- Effect: Destroyed ~1,000 IR-1 centrifuges by varying rotor speeds
- Attribution: United States (NSA) and Israel (Unit 8200) joint operation

UKRAINE POWER GRID (December 23, 2015):
- Targets: Prykarpattya Oblenergo, Chernivtsi Oblenergo, Kyiv Oblenergo
- Method: BlackEnergy malware via spear phishing → SCADA system access
- Effect: 230,000 customers without power for 1-6 hours
- Attribution: Sandworm (Russian GRU, Unit 74455)
- Note: First confirmed cyberattack to cause power grid blackout

UKRAINE POWER GRID (December 17, 2016):
- Target: Ukrenergo transmission station near Kyiv
- Malware: Industroyer/CrashOverride (first ICS-specific framework)
- Effect: Transmission station blackout, power loss in Kyiv district
- Attribution: Sandworm (Russian GRU)

TRITON/TRISIS (December 2017):
- Target: Petrochemical plant in Saudi Arabia (later identified as Petro Rabigh)
- Targets: Schneider Electric Triconex Safety Instrumented System (SIS)
- Method: Pivot from IT network to SIS engineering workstation
- Effect: Inadvertent plant shutdown; intended to disable safety systems
- Attribution: Central Scientific Research Institute of Chemistry and 
              Mechanics (TsNIIKhM), Russia
- Significance: First malware designed to target industrial safety systems

IoT Botnet Analysis

Mirai Architecture Review

Mirai Propagation

Mirai Propagation:
═══════════════════════════════════════════════════════════════════

SCANNING:
Infected device scans random IPs for:
- Port 23 (Telnet)
- Port 2323 (Alt Telnet)
- Port 22 (SSH)

CREDENTIAL STUFFING:
Uses hardcoded list of default credentials:
- admin/admin
- root/root
- admin/password
- user/user
- ... (62 pairs in original Mirai)

INFECTION:
1. Login successful
2. Determine architecture (ARM, MIPS, etc.)
3. Download appropriate payload
4. Execute and persist
5. Begin scanning

ATTACK COMMANDS:
- UDP flood
- TCP SYN flood
- ACK flood
- GRE flood
- DNS water torture

Detecting IoT Compromise

# Network indicators:
# - High outbound traffic
# - Connections to known C2 IPs
# - Telnet scanning (random port 23 connections)
# - Unusual DNS queries

# On device (if shell available):
ps aux | grep -v "^\["  # Running processes
netstat -an              # Network connections
ls -la /tmp /var/tmp    # Suspicious files
cat /proc/*/cmdline     # Process commands

IoT Security Best Practices

Device Hardening

IoT Device Security Checklist

IoT Device Security Checklist:
═══════════════════════════════════════════════════════════════════

AUTHENTICATION:
□ Change default credentials immediately
□ Use strong, unique passwords
□ Implement certificate-based auth where possible
□ Disable unused accounts

NETWORK:
□ Segment IoT devices from main network
□ Use encrypted protocols (MQTTS, HTTPS)
□ Disable UPnP
□ Firewall unnecessary ports
□ Use VPN for remote access (not port forwarding)

UPDATES:
□ Enable automatic updates if available
□ Monitor for firmware releases
□ Verify update signatures
□ Have rollback plan

MONITORING:
□ Log device activity
□ Monitor for anomalous behavior
□ Alert on default credential usage
□ Track firmware versions

Network Segmentation

IoT Network Architecture

IoT Network Architecture:
═══════════════════════════════════════════════════════════════════

                    Internet
                        │
                   ┌────┴─────┐
                   │ Firewall │
                   └────┬─────┘
                        │
          ┌─────────────┼────────────┐
          │             │            │
    ┌─────┴──────┐ ┌────┴────┐ ┌─────┴─────┐
    │  Corporate │ │   IoT   │ │   Guest   │
    │   Network  │ │  VLAN   │ │   VLAN    │
    │  VLAN 10   │ │ VLAN 20 │ │  VLAN 30  │
    └────────────┘ └────┬────┘ └───────────┘
                       │
              No direct access to
              corporate network
              Only necessary cloud
              services allowed

Lab Exercise: IoT Security Assessment

Objective

Assess security of IoT device in controlled environment.

Environment

Lab Setup

Lab Setup:
├── Target: Consumer IoT device (smart plug, camera, etc.)
├── Tools: Kali Linux, Wireshark, Binwalk
├── Network: Isolated lab network
└── Hardware: USB-UART adapter (optional)

Exercise 1: Network Reconnaissance

# Identify device on network
nmap -sn 192.168.1.0/24

# Scan device ports
nmap -sS -sV -p- <device_ip>

# Look for:
# - Web interface (80, 443, 8080)
# - Telnet (23)
# - SSH (22)
# - MQTT (1883)
# - Custom services

Exercise 2: Traffic Analysis

# Capture device traffic
sudo tcpdump -i eth0 host <device_ip> -w iot.pcap

# Analyze in Wireshark
# Look for:
# - Unencrypted protocols
# - Default credentials in traffic
# - Cloud communication endpoints
# - Update mechanisms

Exercise 3: Firmware Analysis

# If firmware available
binwalk -e firmware.bin

# Search for credentials
grep -r "password\|admin\|secret" _firmware.bin.extracted/

# Check for vulnerable services
# Analyze web application code

Key Takeaways

IoT devices lack traditional security—constrained resources and long lifecycles create vulnerabilities
Default credentials are the #1 IoT vulnerability—Mirai proved this at scale
Hardware interfaces (UART, JTAG) often provide root access—physical security matters
ICS/SCADA systems control critical infrastructure—air gaps are often myths
Network segmentation is essential—IoT should never share networks with sensitive systems
Firmware analysis reveals hardcoded secrets and vulnerabilities—always check vendor downloads

Self-Assessment

Comprehension: Why are IoT devices particularly susceptible to botnet recruitment?
Application: You’ve identified an open MQTT broker. What reconnaissance steps do you take?
What if: During an assessment, you gain root via UART on an industrial controller. How do you proceed safely?

Review Questions

What makes IoT devices fundamentally different from traditional IT systems for security?
Explain MQTT’s publish/subscribe model and its security implications.
How do you identify and connect to UART on an unknown device?
What is the Purdue Model for ICS architecture?
How did Mirai achieve such massive scale?
What network segmentation strategy should be used for IoT devices?

MITRE ATT&CK Mapping (ICS)

Attack	Technique ID	Tactic
Default Credentials	T0812	Initial Access
Firmware Manipulation	T0839	Persistence
UART Access	T0801	Initial Access
Modbus Exploitation	T0801	Execution
Network Sniffing	T0842	Discovery