IoT Security

Security of MQTT
Mridul Sankar Barik

Jadavpur University

2024-25
Introduction

▶ MQTT is a Client Server publish/subscribe messaging

transport protocol
▶ It is lightweight, open, simple, and designed to be easy to
implement.
▶ These characteristics make it ideal for use in many situations,
including constrained environments such as for
communication in Machine-to-Machine (M2M) and Internet
of Things (IoT) contexts where a small code footprint is
required and/or network bandwidth is at a premium.
▶ MQTT uses a binary message format for communication
between clients and brokers. This is in contrast to other
protocols that use text-based formats, such as HTTP or
SMTP.
MQTT Usage
▶ Smart Homes: MQTT is used to connect various devices in a smart
home, including smart thermostats, light bulbs, security cameras, and
other appliances. This allows users to control their home devices remotely
using a mobile app.
▶ Industrial Automation: MQTT is used to connect machines and sensors
in factories and other industrial settings. This allows for real-time
monitoring and control of processes, which can improve efficiency and
reduce downtime.
▶ Agriculture: MQTT is used in precision agriculture to monitor soil
moisture levels, weather conditions, and crop growth. This helps farmers
optimize irrigation and other crop management practices.
▶ Healthcare: MQTT is used to connect medical devices and sensors, such
as glucose meters and heart rate monitors, to healthcare providers. This
allows for remote monitoring of patients, which can improve patient
outcomes and reduce healthcare costs.
▶ Transportation: MQTT is used in connected cars and other
transportation systems to enable real-time tracking and monitoring of
vehicles. This can improve safety and help optimize traffic flow.
MQTT Publish-Subscribe Model

▶ Publisher:
▶ Responsible for publishing messages on a topic
▶ Can send data only to one topic at a time
▶ Not concerned about whether subscribers are online when publishing a message

▶ Subscriber:
▶ Receives messages by subscribing to a topic
▶ Can subscribe to multiple topics at once
▶ MQTT supports load-balancing subscriptions among multiple subscribers through shared
subscriptions

▶ Broker:
▶ Responsible for receiving messages from publishers and forwarding them to the appropriate
subscribers
▶ Handles requests from clients for connecting, disconnecting, subscribing, and unsubscribing

▶ Topic
▶ MQTT routes messages based on topics
▶ A topic is typically leveled and separated with a slash / between the levels, this is similar to URL
paths
▶ Topics are expressed as UTF-8 strings
▶ For example, a topic could be sensor/1/temperature
▶ Multiple subscribers can subscribe for the same topic
▶ Multiple publishers can also send messages to the same topic
▶ Subscribers can subscribe to multiple topics simultaneously using topic wildcards
▶ MQTT topics depict the following characteristics:
MQTT for IoT

▶ Lightweight and Efficient:

▶ Message header: only 2 bytes
▶ Run stably in bandwidth-constrained network environments
▶ MQTT clients need very small hardware resources and can run on a variety of resource-constrained
edge devices
▶ Reliable Message Delivery
▶ Provides 3 levels of Quality of Service for messaging, ensuring reliable messaging in different
network environments

▶ Connect IoT Devices at Massive Scale

▶ MQTT-based IoT applications and services can easily have the capabilities of high concurrency,
high throughput, and high scalability

▶ Secure Bi-Directional Communication

▶ Supports secure bidirectional communication via TLS/SSL
▶ The client ID, username and password provided in the MQTT protocol allow users to implement
authentication and authorization at the application layer

▶ Keep Alive and Stateful Sessions

▶ In the event of a long period of no message interaction, Keep Alive message keeps the connection
from being disconnected
▶ Will Message allows the server to help the client post a will message to a specified MQTT topic if
the client is found to be offline abnormally
MQTT Message Format
MQTT QoS Levels

▶ QoS 0: The message is transmitted at most once.

▶ If the client is not available at that time, the message is lost.
▶ After a publisher sends a message, it no longer cares if it is sent to the other side or not, and no
retransmission mechanism is set up.

▶ QoS 1: The message is transmitted at least once.

▶ It contains a simple retransmission mechanism: The publisher sends a message, then waits for an
ACK from the receiver, and resends the message if the ACK is not received.
▶ This model guarantees that the message will arrive at least once, but it does not guarantee that
the message will be repeated.

▶ QoS 2: The message is transmitted only once.

▶ A retransmission and duplicate message discovery mechanism is designed to ensure that messages
reach the other side and arrive strictly once.
Last Will and Testament (LWT)

▶ The Last Will and Testament (LWT) in MQTT is like a

backup plan for when a device unexpectedly goes offline
▶ Imagine a smart device that suddenly loses its connection
without warning.The LWT is a special message the device
prepares in advance. If the device disconnects without saying
goodbye properly, the MQTT broker automatically sends this
message to let other devices know something went wrong.
▶ For example, in a smart home, if a sensor stops working, the
LWT could notify the system to alert the user or switch to a
backup sensor. It helps keep everything running smoothly
even when a device fails
Retained Messages

▶ Retained Messages ensure that the latest message is always

available to new subscribers, even if they weren’t connected
when it was first sent.
▶ It’s like leaving a sticky note with the most recent information
for anyone who checks later.
▶ Example: Imagine you have a weather station that publishes
temperature data. If a new device (like a phone or dashboard)
subscribes to the weather topic, without retained messages, it
would only get new updates and miss the latest temperature.
With a retained message, the MQTT broker keeps the most
recent temperature data and immediately sends it to any new
subscriber.
MQTT Security: Protecting Data and Devices During
Communication

▶ Username and Password: Devices can use a username and

password to connect, like logging into an account. This helps
ensure that only authorized devices can communicate.
▶ Encryption (TLS/SSL): MQTT can use encryption (like
HTTPS on websites) to keep data safe while it’s being sent, so
no one can read or change the messages during transmission.
▶ Access Control: The broker can control who can publish or
subscribe to topics, making sure only the right devices can
send or receive specific messages.
DoS Attacks Against MQTT (1)

▶ Last Will Payload Flooding Attack:

▶ Exploits the Last Will and Testament feature available in the MQTT
protocol
▶ Last Will message is set by the publisher client when it connects to the
broker
▶ It is stored by the broker
▶ If the client is abruptly disconnected, the broker sends the message on
behalf of the publisher to all its clients that are subscribed to the topic
specified in the last will message
▶ Attacker sends a massive number of CONNECT messages to the broker
with a greater size of the last will payload (more than 10000 characters)
in order to increase the size of the packets, which will have a strong
impact on the bandwidth at the victim broker
▶ It will also increase the resources needed to process messages, which may
cause the overall usage of RAM and CPU to be higher than normal
▶ Serious consequences if the attackers frequently connect and disconnect
to the broker
▶ This will force the broker to publish the message, and thus increase the
impact of the attack on server resources more, preventing it from
processing new TCP connections
Source: [Hadded et al., 2022]
DoS Attacks Against MQTT (2)
▶ Unauthorized Subscription Flooding Attack:
▶ An attacker with valid credentials information but no authorization to
access various topics seeks to make the broker resource unavailable to
legitimate clients
▶ Attacker floods the broker with invalid subscribe or publish requests
▶ This results in consumption of broker CPU and RAM resources in
verifying individual requests
▶ ACK-PSH Flooding Attack:
▶ Attacker sends PSH-ACK packets to the broker without establishing a
TCP handshake
▶ Broker will detect this packet as not belonging to a session and respond
with a RST packet
▶ Goal is to disrupt the activity of the MQTT network by saturating the
bandwidth and resources of the MQTT broker
▶ SlowTT Attack:
▶ Slow denial of service attack against MQTT
▶ Attacker after establishing communication with the broker uses KeepAlive
parameter, to keep connections alive for an indefinite time
▶ Attacker can also use PINGREQ and PINGRESP packets to simulate
legitimate behavior
Source: [Hadded et al., 2022]
DoS Attacks Against MQTT (3)
▶ Connect Flooding Attack:
▶ Attacker sends a large number of CONNECT packets to the victim broker
to overwhelm it with the processing of authentications requests
▶ Attackers can exhaust the CPU or memory resources on the target broker
by sending a considerable number of CONNECT packets that have a
higher QoS level 2 making services unavailable for legitimate clients
▶ Elevation of Privilege Attack:
▶ The wildcard feature (e.g. #) available in the MQTT protocol allows the
clients to subscribe to multiple topics simultaneously and learn about the
list of topics available on the broker and log every message exchanged
▶ As a result, all data published by MQTT clients will be vulnerable to
access by the attackers due to wildcard topics
▶ OpenSSL Infinite Loop Attack:
▶ CVE-2022-0778 with a CVSS score of 7.5
▶ Problem arise while parsing malformed security certificates that contain
invalid elliptic curve public keys, resulting in what’s so called an “infinite
loop”
▶ This vulnerability can be exploited by the attackers to trigger a DoS and
remotely crash TLS servers consuming client certificates
Source: [Hadded et al., 2022]
References I
Hadded, M., Lauras, G., Letailleur, J., Petiot, Y., and Dubois, A. (2022).
An assessment platform of cybersecurity attacks against the mqtt protocol using
siem.
In 2022 International Conference on Software, Telecommunications and
Computer Networks (SoftCOM), pages 1–6.