Exposed UART, vulnerable MQTT: the doors we forget to close

Two new DVID trainings on forgotten services and interfaces that should not be there

On an IoT/OT device in production, there is what is documented — and what is left over from development. Debug interfaces, technical ports, services left listening to ease tuning. Most of the time, nobody looks at them once the product is on the market. And that is exactly where attackers get in.

Two new DVID trainings illustrate this phenomenon with two distinct but complementary scenarios: UART debugging left active on an industrial device, and remote code execution on a misconfigured MQTT broker. Two different entry points, but the same logic: what is useful to the developer is also useful to the attacker.

Unsecured UART debug: the developer's console, shipped with the product

The first training goes back to basics: the serial interface. On almost every microcontroller, UART is used during development to display logs, run test commands or flash a new firmware. Once the device is in production, this interface should be disabled, or at least protected. In practice, it is not.

The scenario puts the participant in front of a device whose debug shell remains accessible over UART, without authentication. Participants learn how to:

• physically locate the UART pins on an undocumented board;
• establish a working serial connection with the right settings (baud rate, bits, parity);
• enumerate the commands available in the debug shell;
• read and write arbitrary memory areas from this interface;
• change the behavior of the running firmware.

What this training highlights is that the debug UART is not just a logging interface: it is often an entry point giving full access to the device's runtime, bypassing all application-level protections.

This flaw falls directly under Annex I of the CRA — requirement 2k (attack surface minimization) and requirement 2d (access control). It is also one of the first checkpoints of any serious hardware security assessment.

RCE on an MQTT broker: when the message bus becomes an attack bus

The second training changes scale. We leave the device to look at the infrastructure around it — more specifically the MQTT broker, the central component that orchestrates exchanges between dozens, hundreds or thousands of IoT devices.

MQTT is a simple, lightweight protocol designed for the constraints of connected objects. Sometimes too simple. Many production deployments rely on default configurations: authentication disabled, no ACLs, topics open for reading and writing to all clients. And when the broker also runs server-side application code — routing rules, transformation scripts, plugins — the combination becomes explosive.

The training's scenario puts the participant in the role of an attacker with only network access to the broker. The goal: go from a simple CONNECT to arbitrary code execution on the machine hosting the broker. Participants explore:

• how to enumerate active topics and identify the structure of an MQTT deployment;
• how to exploit poor message validation on the broker side to inject code;
• how to use internal routing mechanisms to pivot to other devices;
• how to harden an MQTT configuration to make this kind of exploitation impossible.

This module goes beyond the MQTT protocol itself. It is a concrete demonstration of what happens when an infrastructure component designed for easy deployment ends up exposed without the security layers that should come with it. The same pattern plays out with CoAP, AMQP or proprietary protocols.

This issue overlaps several CRA requirements: 2c (integrity), 2d (access control), 2k (attack surface minimization) and 2g (protection against unauthorized communications).

A 100% hands-on approach, true to DVID's DNA

As with all our modules, these two trainings rely on real hardware and real running services. Learn by doing, not by theorizing — that is what sets apart a pentester able to carry out an audit from an engineer who has simply read a document.

Participants work with:

• an ESP32 or STM32 microcontroller for the UART scenario;
• an MQTT broker (Mosquitto or equivalent) deployed in an isolated environment for the network scenario;
• standard tools: screen / minicom / pyserial for UART, mosquitto-clients and Python scripts for MQTT;
• a kit of exploitation and hardening scripts, designed to be reusable in a professional environment.

Each step is progressive and reproducible. The goal is not only to succeed in the exploitation, but to understand exactly why it works — and therefore how to prevent it.

Key takeaways for participants

Beyond each scenario, these two modules build a set of reflexes that every serious IoT/OT security team should have:

• disable debug interfaces in production, or protect them with hardware authentication;
• never consider physical access as out of scope — it is precisely the scenario the CRA targets;
• enforce strong authentication on MQTT brokers and any IoT messaging service;
• segment topics and apply strict ACLs per device or per device class;
• treat the broker as a critical component: monitoring, updates, hardening of the underlying OS;
• rigorously validate every incoming payload on the broker side before interpreting it.

Who is it for?

These two modules are designed for technical profiles who design, operate or audit IoT/OT architectures:

• firmware engineers and embedded developers;
• IoT/OT architects and cloud engineers;
• hardware and infrastructure-focused pentesters;
• SOC and CERT teams investigating IoT incidents;
• product security managers preparing for CRA compliance.

No advanced prerequisites are needed. Basic knowledge of TCP/IP networking and serial interfaces makes it easier to get started, but each concept is introduced throughout the exercises.

Available now

These two trainings fit naturally into an IoT/OT upskilling path, whether to strengthen an internal team, prepare for CRA compliance or structure a security-by-design approach.

Learn more: https://dvid.eu
Contact us: https://dvid.eu/#contact
Follow our news: https://www.linkedin.com/company/dvid/