The Unencrypted Bus Between CPU and Cellular Module

▶ Watch (01:56)

Cellular traffic between towers and devices is encrypted and FCC-regulated. The traffic between a device’s main CPU and its onboard cellular module is neither. Deral Heiland and Carla Bidner spent two and a half years studying NB-IoT and LTE-M modules and found that interchip communications are unencrypted on most devices they examined. That bus, running over USB or UART, carries the full command stream that controls network access, private APN connections, and cloud authentication. That is where they chose to attack.

AT Commands: The Protocol Attackers Inherit

▶ Watch (04:09)

AT commands were designed in 1981 for the Hayes smart modem. They still run on every cellular module today, over the UART connection between the CPU and the module. Four categories exist: test, read, write, and execute. The 3GPP standard mandates only the basics, so manufacturers add their own commands for HTTP, socket management, and firmware updates, each documented in publicly downloadable manuals. Bidner noted that identifying the module model and searching for its AT command manual returns the full parameter list, including commands that modules sometimes support but do not advertise.

Physical Techniques for Tapping the Bus

▶ Watch (06:44)

Getting onto the interchip bus starts with a transposal: overlaying front and back PCB photos to locate UART pins and LAN grid array pads without disassembly. When pads are not exposed, Heiland uses acupuncture needles inserted under the edge of the cellular module to reach the USB and serial lines. If that fails, the module comes off the board entirely using heat reflow, then LAN run repair kits and UV masking establish new circuit runs before reflowing it back. The last resort is cutting into the board itself to reach traces on sub-layers.

UART Attack: AT-Command Tools and PPP Pivot

▶ Watch (10:58)

Once seated on UART, Bidner cut the TX/RX traces, placed an FTDI breakout board with switches in the gap, and wrote AT-command scripts that replicated pentesting tools: a port scanner, an HTTP proxy, and an S3 bucket enumerator. The S3 bucket scanner over AT commands (11:36) iterated bucket names over serial and saved results to JSON.

For more complex tooling, the PPP over UART live routing demo (14:36) established a PPP0 interface with an assigned IP and DNS, then ran a not-so-secure AWS enum script. The tool took 40 to 45 minutes over cellular versus 3 minutes on a home network, but it completed.

USB Attack: Multiplexer Splice and Full Network Hijack

▶ Watch (17:14)

LTE-M camera systems use USB rather than UART for interchip communication. Heiland spliced in a quarter-sized Texas Instruments USB 2.0 multiplexer between the CPU and the cellular module, accounting for impedance matching and trace length skew. The device booted normally, authenticated to its APN, and started sending images. Then he threw the switch.

The USB multiplexer + Metasploit attack (24:10) shows what happens: the laptop instantly gets a network interface card via ECM, the cellular module’s authenticated session transfers over, and a Metasploit SSH brute force runs through the IoT camera’s cellular link against a remote target.

Mitigations and Supply Chain Implant Risk

▶ Watch (28:04)

Bidner ranked case triggers above epoxy potting as tamper protection: a determined attacker with time can dissolve epoxy, but a case trigger that kills the device on open is harder to bypass. Other mitigations include disabling the unused communication channel, encrypting interchip traffic, and APN-side behavioral monitoring to catch a camera scanning internal networks.

Heiland raised a harder problem. Most IoT devices use only one channel, leaving the other idle and implant-ready. A small computer inserted during manufacturing could phone home, accept remote commands, and run surveillance through the device’s trusted cellular session.

Q&A

What attacker scenario are you simulating? An attacker wouldn’t have physical access to your IoT device. The scenario is an attacker who has the device, not one attacking it remotely. Buying one device can expose the trust relationships of every cloud service and private APN that device model connects to. ▶ 33:37

Who was providing the DHCP/IP assignment in your test, and have you coordinated with carriers on MAC tracking or anomaly detection? IPs came from the module’s public APN. They have not yet coordinated with carriers, but the plan is to work directly with device vendors and their deployed products, since IoT APNs often run through obscure sub-carriers that are difficult to reach independently. ▶ 34:48

At what point did you figure out you could use acupuncture needles for a cybersecurity exploit? The first day Heiland needed to reach pads on a module he couldn’t access otherwise, tried drilling from the side, damaged the board, and landed on needles as the practical solution. ▶ 37:51

Where did you find a complete list of AT commands used in the demo? Manufacturer-published AT command manuals, searchable by module model. The AT+CLAC command also prints supported commands, though some modules support commands they do not list in that output. ▶ 38:42

Notable Quotes

take advantage of the trust relationship Deral Heiland · ▶ 20:15

how do you mitigate a threat when the attack is how Deral Heiland · ▶ 31:53

necessity drives everything Deral Heiland · ▶ 38:39

Key Takeaways

  • Interchip UART and USB communications on cellular IoT modules are rarely encrypted, making them directly exploitable without touching the RF layer.
  • AT command manuals are publicly available for every module; an attacker can build a port scanner, HTTP proxy, or S3 enumerator in an afternoon.
  • A USB multiplexer the size of a quarter lets an attacker hijack a module’s authenticated cellular session and route arbitrary traffic through it.