Opening Framing
IoT devices communicate wirelessly using protocols designed for low power and convenience—often at the expense of security. BLE-enabled fitness trackers, Zigbee smart home hubs, Z-Wave locks, and proprietary RF remotes all broadcast signals that travel through walls, across parking lots, and into an attacker's receiving equipment.
Each protocol has evolved with varying security maturity. BLE 4.0's "Just Works" pairing offered no protection against eavesdropping. Zigbee's default "ZigBeeAlliance09" trust center key is publicly known. Many proprietary protocols use simple encoding with no encryption at all.
This week covers wireless attack techniques: BLE sniffing and exploitation, Zigbee network infiltration, RF replay attacks with SDR, and RFID/NFC cloning. You'll learn to capture, analyze, and exploit wireless communications using tools from budget RTL-SDR dongles to the versatile Flipper Zero.
Key insight: Wireless attacks can be performed from a car in a parking lot—physical proximity without physical access.
1) BLE Security Deep Dive
Bluetooth Low Energy dominates wearables, fitness trackers, smart locks, and medical devices:
BLE ARCHITECTURE:
CONNECTION FLOW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PERIPHERAL CENTRAL │
│ (e.g., Smart Lock) (e.g., Phone App) │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Advertising │ ───────────────→ │ Scanning │ │
│ │ (Beacons) │ │ (Passive) │ │
│ └─────────────┘ └─────────────┘ │
│ │ │ │
│ │ Connection Request │ │
│ │ ←───────────────────────────────│ │
│ │ │ │
│ │ Pairing (Optional) │ │
│ │ ←──────────────────────────────→│ │
│ │ │ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ GATT │ ←───────────────→ │ GATT │ │
│ │ Services │ Read/Write │ Client │ │
│ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
GATT (Generic Attribute Profile):
┌─────────────────────────────────────────────────────────────┐
│ Profile │
│ ├── Service 1 (UUID: 0x180F - Battery Service) │
│ │ └── Characteristic (Battery Level) │
│ │ ├── Properties: Read, Notify │
│ │ └── Value: 85% │
│ │ │
│ ├── Service 2 (UUID: Custom - Lock Control) │
│ │ ├── Characteristic (Lock State) │
│ │ │ ├── Properties: Read, Write │
│ │ │ └── Value: 0x00 (Locked) │
│ │ │ │
│ │ └── Characteristic (PIN Code) │
│ │ ├── Properties: Write │
│ │ └── Value: [Protected] │
│ │ │
│ └── Service 3 (UUID: 0x180A - Device Info) │
│ ├── Manufacturer Name │
│ ├── Model Number │
│ └── Firmware Version │
└─────────────────────────────────────────────────────────────┘
BLE PAIRING MODES:
┌─────────────────────────────────────────────────────────────┐
│ Just Works (Legacy): │
│ - No user interaction required │
│ - VULNERABLE: No MITM protection │
│ - Attacker can intercept pairing │
│ │
│ Passkey Entry: │
│ - 6-digit PIN displayed/entered │
│ - Brute-forceable (1 million combinations) │
│ - Better than Just Works │
│ │
│ Numeric Comparison (BLE 4.2+): │
│ - Both devices display 6-digit number │
│ - User confirms they match │
│ - Resistant to MITM │
│ │
│ Out-of-Band (OOB): │
│ - Uses separate channel (NFC, QR code) │
│ - Strongest when implemented correctly │
│ - Rarely used in consumer devices │
└─────────────────────────────────────────────────────────────┘2) BLE Attack Techniques
BLE ATTACK WORKFLOW:
STEP 1: DISCOVERY
┌─────────────────────────────────────────────────────────────┐
│ Tools: Bettercap, nRF Connect, hcitool │
│ │
│ $ sudo bettercap │
│ > ble.recon on │
│ │
│ Or with hcitool: │
│ $ sudo hcitool lescan │
│ │
│ Output identifies: │
│ - MAC address (may be random or static) │
│ - Device name │
│ - Signal strength (RSSI) │
│ - Advertised services │
└─────────────────────────────────────────────────────────────┘
STEP 2: ENUMERATION
┌─────────────────────────────────────────────────────────────┐
│ $ sudo bettercap │
│ > ble.enum AA:BB:CC:DD:EE:FF │
│ │
│ Reveals: │
│ - All GATT services │
│ - Characteristics and their UUIDs │
│ - Properties (Read/Write/Notify) │
│ - Descriptors │
│ │
│ Look for: │
│ - Writable characteristics without authentication │
│ - Custom services (non-standard UUIDs) │
│ - Sensitive data exposed via Read │
└─────────────────────────────────────────────────────────────┘
STEP 3: READ/WRITE OPERATIONS
┌─────────────────────────────────────────────────────────────┐
│ Using gatttool: │
│ $ gatttool -b AA:BB:CC:DD:EE:FF -I │
│ > connect │
│ > char-read-hnd 0x000f │
│ > char-write-req 0x0010 01 │
│ │
│ Using Bettercap: │
│ > ble.write AA:BB:CC:DD:EE:FF 0010 01 │
│ │
│ Attacks: │
│ - Read sensitive data (WiFi creds, tokens) │
│ - Write commands (unlock, disable, configure) │
│ - Fuzz characteristics to find crashes │
└─────────────────────────────────────────────────────────────┘
STEP 4: PAIRING CAPTURE
┌─────────────────────────────────────────────────────────────┐
│ Equipment: Ubertooth One or HackRF with BLE support │
│ │
│ $ ubertooth-btle -f -c capture.pcap │
│ │
│ Capture pairing exchange: │
│ - Pairing Request/Response │
│ - Security parameters │
│ - Key exchange (vulnerable in Just Works) │
│ │
│ Cracking Legacy Pairing: │
│ $ crackle -i capture.pcap -o decrypted.pcap │
└─────────────────────────────────────────────────────────────┘
STEP 5: MAN-IN-THE-MIDDLE
┌─────────────────────────────────────────────────────────────┐
│ Tools: GATTacker, btlejack │
│ │
│ Attack flow: │
│ 1. Clone target device's GATT profile │
│ 2. Jam legitimate connection │
│ 3. Central connects to attacker │
│ 4. Attacker relays to real peripheral │
│ 5. Intercept and modify traffic │
│ │
│ $ sudo btlejack -f AA:BB:CC:DD:EE:FF │
│ $ sudo btlejack -x # Start hijacking │
└─────────────────────────────────────────────────────────────┘
COMMON BLE VULNERABILITIES FOUND:
┌─────────────────────────────────────────────────────────────┐
│ 1. No pairing required │
│ - GATT accessible without authentication │
│ - Direct control of device functions │
│ │
│ 2. Just Works pairing │
│ - No MITM protection │
│ - Keys can be captured and cracked │
│ │
│ 3. Static MAC addresses │
│ - Device tracking across locations │
│ - Privacy violation │
│ │
│ 4. Unencrypted characteristics │
│ - Sensitive data readable │
│ - Commands replayable │
│ │
│ 5. Command injection │
│ - Improper input validation │
│ - Write malformed data to crash/exploit │
│ │
│ 6. Weak authentication │
│ - Static PINs │
│ - Predictable tokens │
└─────────────────────────────────────────────────────────────┘3) Zigbee Network Attacks
ZIGBEE SECURITY MODEL:
NETWORK TOPOLOGY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────┐ │
│ │ Coordinator │ ← Trust Center │
│ │ (Hub) │ (manages keys) │
│ └──────┬──────┘ │
│ │ │
│ ┌────────────┼────────────┐ │
│ │ │ │ │
│ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │
│ │ Router │ │ Router │ │ Router │ │
│ │ (Bulb) │ │ (Outlet)│ │ (Switch)│ │
│ └────┬────┘ └─────────┘ └────┬────┘ │
│ │ │ │
│ ┌────┴────┐ ┌────┴────┐ │
│ │End Device│ │End Device│ │
│ │ (Sensor) │ │ (Lock) │ │
│ └─────────┘ └─────────┘ │
│ │
│ Mesh Network: Routers forward messages │
│ End Devices: Sleep most of time, low power │
└─────────────────────────────────────────────────────────────┘
ZIGBEE KEY HIERARCHY:
┌─────────────────────────────────────────────────────────────┐
│ Trust Center Link Key (TCLK): │
│ - Shared between device and coordinator │
│ - Used during joining to encrypt Network Key │
│ - DEFAULT: "ZigBeeAlliance09" (well-known!) │
│ Hex: 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39 │
│ │
│ Network Key: │
│ - Shared by all devices in network │
│ - Encrypts all Network layer traffic │
│ - Rotated periodically (ideally) │
│ │
│ Link Keys: │
│ - Pairwise keys between two devices │
│ - Application layer encryption │
│ - Optional, often not implemented │
└─────────────────────────────────────────────────────────────┘
ZIGBEE ATTACKS:
KEY SNIFFING DURING JOIN:
┌─────────────────────────────────────────────────────────────┐
│ Attack Scenario: │
│ 1. Victim adds new device to Zigbee network │
│ 2. Coordinator sends Network Key to new device │
│ 3. Network Key is encrypted with TCLK │
│ 4. If TCLK is default, attacker decrypts Network Key │
│ 5. Attacker now has full network access │
│ │
│ Using KillerBee: │
│ $ zbstumbler # Find networks │
│ $ zbdump -f 11 -w cap.pcap # Capture on channel 11 │
│ $ zbwireshark # Analyze with Wireshark │
│ │
│ In Wireshark: │
│ Edit → Preferences → Protocols → ZigBee │
│ Add pre-configured key: ZigBeeAlliance09 │
└─────────────────────────────────────────────────────────────┘
TOUCHLINK COMMISSIONING ATTACK:
┌─────────────────────────────────────────────────────────────┐
│ Touchlink: Allows devices to join without coordinator │
│ │
│ Attack: │
│ 1. Attacker sends Touchlink "Scan Request" │
│ 2. If device responds, attacker sends "Factory Reset" │
│ 3. Device leaves current network │
│ 4. Attacker claims device into their network │
│ │
│ Impact: Steal devices from victim's smart home │
│ │
│ Note: Requires physical proximity (~10cm for some devices) │
└─────────────────────────────────────────────────────────────┘
REPLAY AND INJECTION:
┌─────────────────────────────────────────────────────────────┐
│ Once Network Key obtained: │
│ - Decrypt all traffic │
│ - Inject commands (turn off lights, unlock doors) │
│ - Replay previous commands │
│ │
│ Protection: Frame counter (prevents simple replay) │
│ Weakness: Counter resets on power cycle │
└─────────────────────────────────────────────────────────────┘4) SDR and RF Analysis
SOFTWARE DEFINED RADIO FUNDAMENTALS:
WHAT IS SDR:
┌─────────────────────────────────────────────────────────────┐
│ Traditional Radio: Hardware determines frequency/modulation │
│ SDR: Software controls everything, hardware just digitizes │
│ │
│ Benefits for security research: │
│ - Receive any frequency the hardware supports │
│ - Decode any modulation with right software │
│ - Record and replay signals │
│ - Analyze unknown protocols │
└─────────────────────────────────────────────────────────────┘
SDR HARDWARE OPTIONS:
┌─────────────────────────────────────────────────────────────┐
│ RTL-SDR (~$25): │
│ - Receive only │
│ - 24 MHz - 1766 MHz │
│ - Great for learning, passive reconnaissance │
│ │
│ HackRF One (~$300): │
│ - Transmit and receive │
│ - 1 MHz - 6 GHz │
│ - Half-duplex │
│ - Industry standard for RF security │
│ │
│ Yard Stick One (~$100): │
│ - TX/RX sub-1GHz │
│ - 300-348 MHz, 391-464 MHz, 782-928 MHz │
│ - Great for garage doors, key fobs │
│ │
│ Flipper Zero (~$170): │
│ - Multi-tool with sub-GHz, NFC, IR, RFID │
│ - User-friendly for common attacks │
│ - Good for demonstrations │
└─────────────────────────────────────────────────────────────┘
RF ATTACK TECHNIQUES:
REPLAY ATTACK:
┌─────────────────────────────────────────────────────────────┐
│ Target: Devices without rolling codes │
│ Examples: Old garage doors, some car fobs, wireless outlets │
│ │
│ Steps: │
│ 1. Record legitimate transmission │
│ $ rtl_433 -S all # Auto-detect and save │
│ │
│ 2. Identify frequency and modulation │
│ - 315 MHz, 433.92 MHz common in US │
│ - ASK/OOK most common for simple devices │
│ │
│ 3. Replay signal │
│ Using HackRF or Flipper Zero │
│ │
│ Protection: Rolling codes (each transmission unique) │
└─────────────────────────────────────────────────────────────┘
PROTOCOL REVERSE ENGINEERING:
┌─────────────────────────────────────────────────────────────┐
│ Tool: Universal Radio Hacker (URH) │
│ │
│ Workflow: │
│ 1. Capture samples with RTL-SDR or HackRF │
│ 2. Import into URH │
│ 3. Auto-detect modulation (ASK, FSK, PSK) │
│ 4. Demodulate to bits │
│ 5. Analyze patterns (preamble, sync, data, checksum) │
│ 6. Fuzz or craft custom packets │
│ │
│ Common discoveries: │
│ - No encryption │
│ - Weak checksums (easy to forge) │
│ - Predictable sequences │
└─────────────────────────────────────────────────────────────┘
JAMMING (Denial of Service):
┌─────────────────────────────────────────────────────────────┐
│ Transmit noise on target frequency │
│ │
│ Impact: │
│ - Wireless alarms fail to report │
│ - Smart home devices unresponsive │
│ - Critical: Can defeat wireless security systems │
│ │
│ Legal: ILLEGAL in most jurisdictions │
│ Lab only with proper shielding (Faraday cage) │
└─────────────────────────────────────────────────────────────┘5) RFID and NFC Attacks
RFID/NFC OVERVIEW:
RFID TYPES:
┌─────────────────────────────────────────────────────────────┐
│ Low Frequency (125 kHz): │
│ - Access cards (HID, EM4100) │
│ - Often no encryption │
│ - Easy to clone │
│ - Examples: Office badges, hotel keys │
│ │
│ High Frequency (13.56 MHz): │
│ - MIFARE (Classic, DESFire, Ultralight) │
│ - NFC (Near Field Communication) │
│ - Variable security levels │
│ - Examples: Transit cards, payments, phones │
│ │
│ Ultra-High Frequency (860-960 MHz): │
│ - Asset tracking, inventory │
│ - Generally not used for access control │
└─────────────────────────────────────────────────────────────┘
RFID ATTACKS:
CLONING (LF Cards):
┌─────────────────────────────────────────────────────────────┐
│ Equipment: Proxmark3 or cheap USB cloner │
│ │
│ Process: │
│ 1. Read victim card (brief proximity) │
│ $ pm3> lf hid reader │
│ │
│ 2. Clone to blank T5577 card │
│ $ pm3> lf hid clone 2006XXXXXXXX │
│ │
│ Result: Physical access to secured areas │
│ │
│ Note: Possible to read from several inches away │
│ with amplified antenna │
└─────────────────────────────────────────────────────────────┘
MIFARE CLASSIC ATTACKS:
┌─────────────────────────────────────────────────────────────┐
│ MIFARE Classic: Widely deployed, BROKEN encryption │
│ │
│ Attacks: │
│ - Darkside attack: Recover keys with just a reader │
│ - Nested attack: If one key known, recover others │
│ - Hardnested: Improved nested for newer cards │
│ │
│ $ pm3> hf mf autopwn # Automated attack │
│ │
│ Once keys recovered: │
│ - Read all sectors (stored value, access bits) │
│ - Clone card │
│ - Modify balance (transit cards!) │
└─────────────────────────────────────────────────────────────┘
NFC RELAY ATTACKS:
┌─────────────────────────────────────────────────────────────┐
│ Extend NFC range using two devices: │
│ │
│ [Victim Card] ←→ [Attacker Phone A] ~~WiFi~~ │
│ [Attacker Phone B] ←→ [Reader] │
│ │
│ Use case: │
│ - Victim's card in pocket at coffee shop │
│ - Attacker A near victim │
│ - Attacker B at access-controlled door │
│ - Real-time relay opens door │
│ │
│ Tools: NFCGate (Android) │
└─────────────────────────────────────────────────────────────┘Guided Lab: BLE Device Security Assessment
Objective: Perform complete BLE security assessment using Bettercap.
Time: 90 minutes