Analyzing MQTT Attack Scenarios: A Systematic Formalization and

TLC Model Checker Simulation

Amina Jandoubi

1 a

, M. Taha Bennani

1 b

, Olfa Mosbahi

2 c

and Abdelaziz El Fazziki

3 d

LIPSIC Laboratory, Faculty of Sciences of Tunis, University of Tunis El Manar,

Tunis, 2092, Tunisia

LISI Laboratory, National Institute of Applied Sciences and Technology (INSAT), University of Carthage,

Tunis, 1080, Tunisia

Computer Science Dept, LISI Laboratory, Caddi Ayyad University of Marrakesh, Marrakech, Morocco

Keywords:

SIGIRO, MQTT, LTL, Formalizing, Attack Scenarios, TLC Model Checker.

Abstract:

The SIGIRO project seeks to create an intelligent system for managing water resources in Marrakech-Saﬁ

and Tunisia’s northwest regions. The project introduces a systematic monitoring process to ensure adaptive

control to address climate change. SIGIRO gathers data using the MQTT protocol, which has been the target

of several cyberattacks in recent years. The absence of a formal description of these attacks leaves the ﬁeld

open to interpretation, leading to distinct implementations for a given attack. In this article, we formalize these

attacks, provide descriptions, and check their exactness. We offer a systematic approach to formalizing seven

attack scenarios targeting the MQTT protocol. Using the LTL temporal logic formalism, we generate 12 LTL

formulas, each precisely describing a speciﬁc attack scenario. We classify these formulas into four categories

according to a sequence of observation and injection events. These events are the abstract elements needed

to control the attacks’ implementation. We verify our proposed formulas using the TLC Model Checker. We

show the procedure to encode the LTL formula using TLA+ language. For each attack formula, the veriﬁcation

process generates a counterexample proving the occurrence of the formalized attack. These counterexamples

model the execution sequence leading to the breach while providing key metrics such as the number of states

generated, the number of pending states, the elapsed time, and the identiﬁcation of redundant states. Based on

the execution traces obtained, we formulate proposals for enhancing the speciﬁcation of the MQTT protocol.

1 INTRODUCTION

The SIGIRO project aims to set up an intelligent sys-

tem for the integrated management of water resources

in the Marrakech-Saﬁ and Tunisia’s northwest regions

in response to the challenges imposed by climate

changes. The initiative is based on the systematic col-

lection of data relating to the quality, quantity, and

availability of water from various sources, including

rivers, lakes, water tables, reservoirs and groundwa-

ter. This information will serve as a basis for plan-

ning climate change adaptation measures in the re-

gion. The data is collected via an IoT platform re-

lying on IoT sensors. Monitoring the water manage-

ment platform encompasses monitoring the IoT sen-

https://orcid.org/0000-0002-1824-1238

https://orcid.org/0000-0001-6693-6352

https://orcid.org/0000-0002-0971-2368

https://orcid.org/0000-0002-0302-234X

sors used, network, data exchanged, and communi-

cation protocols associated with water resource man-

agement. It ensures the correct functioning of the

platform, including hardware and software compo-

nents, data quality, security, and integrity. Indeed,

compromised or incorrect data can have a signiﬁ-

cant impact on the quality of decisions taken. How-

ever, problems arise when protocols cannot preserve

data integrity, when hardware is misconﬁgured, ex-

posing it to the risk of intrusion, and when gaps are

found in the management platform. In such circum-

stances, there is no guarantee, for example, that wa-

ter level readings or pollution data will remain un-

changed. The consequences of such problems can

be severe, such as failure to detect pollution in water

used for irrigation or incorrect programming of dam

gate openings. That’s why the SIGIRO project is de-

ploying a systematic process to strengthen monitor-

ing at the water management platform level. It aims

370

Jandoubi, A., Bennani, M., Mosbahi, O. and El Fazziki, A.

Analyzing MQTT Attack Scenarios: A Systematic Formalization and TLC Model Checker Simulation.

DOI: 10.5220/0012625600003687

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 19th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2024), pages 370-378

ISBN: 978-989-758-696-5; ISSN: 2184-4895

2009 2012 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023

Evaluation rate of number of attacks

MQTT

AMQP

COAP

Figure 1: Evaluation rate of number of attacks by CVE.

to identify vulnerabilities and potential risks linked to

climatic factors.

The rapid expansion of the Internet of Things

(IoT) and the diversity of connected devices, often

need more adequate security measures. According to

the latest IoT analytic report published in May 2023

(IoT-Analytics, 2023), over 16.7 billion IoT devices

are expected to be connected worldwide, heighten-

ing concern about the increase in attacks in this area.

The NVD (National Vulnerability Database) is cru-

cial in addressing this issue. This public database is

managed by the National Institute of Standards and

Technology (NIST) in the USA. The NVD collects

information on software vulnerabilities from vari-

ous sources, including security researchers, software

manufacturers, government organizations, and public

reports (NVD, 2023). The NVD uses CVE (Common

Vulnerabilities and Exposures) to standardize refer-

ence vulnerabilities in its database, enabling IT secu-

rity professionals to track, report, and resolve these

vulnerabilities consistently and standardized (CVE,

2023). According to the latest data, there have been

1,210 IoT-related attacks since 2015. This signiﬁcant

increase in attacks reﬂects growing security concerns

in the IoT ﬁeld. In our IoT platform, data is transmit-

ted via the Internet using IoT communication proto-

cols such as CoAP, AMQP, and MQTT. As ﬁgure 1

shows, there is an annual assessment of the number

of attacks discovered. With the CoAP protocol, 24

attacks we recorded since 2018. On the other hand,

with the AMQP protocol, the number of attacks has

increased to 37 since 2009. Finally, we observed a

signiﬁcant increase with the MQTT protocol, totaling

112 attacks. In 2023, domain experts discovered 30

new attacks linked to the MQTT protocol. This trend

underlines the importance of remaining vigilant and

reinforcing the security of IoT communications, par-

ticularly with the MQTT protocol.

We noted a crucial aspect in these sources, namely

that the descriptions of attacks are informal, provid-

ing only information on the nature of the incidents.

This poses challenges for attack prevention and re-

sponse, as the lack of detailed descriptions can make

it challenging to identify appropriate countermeasures

to avoid or mitigate attacks. Effective vulnerability

and incident management often require formal docu-

mentation, as informal descriptions can lead to a non-

deterministic interpretation. Such formal documenta-

tion would detail attacks and vulnerabilities and pro-

pose speciﬁc actions to prevent or mitigate risks. In

this context, we set out to systematically explain in-

tentional attacks, using a structured process to provide

a formal description of a set of vulnerabilities.

Our description approach uses a temporal logic

formalism called Linear Temporal Logic (LTL). In

this article, we present a formalization of seven com-

mon attacks against the MQTT protocol, which led to

the creation of 12 LTL formulas, each precisely rep-

resenting a speciﬁc attack scenario. We then veriﬁed

these formulas using the TLC simulator. TLC is a

software tool widely used for model checking, par-

ticularly in computer systems and protocols. When

a formula is violated, TLC generates a counterexam-

ple that models the execution sequence leading to the

violation while providing four key metrics: the num-

ber of states generated, the number of distinct states

found, the number of states waiting, and the elapsed

time. Based on the execution traces obtained with

TLC, it becomes possible to design a set of patches

aimed at improving the protocol, which has a signiﬁ-

cant impact on IoT platform monitoring.

The remainder of this document is organized as

follows: Section 2 provides an overview of previous

work, reviewing related research and studies in the

ﬁeld. The following section outlines the essential pre-

liminary elements for formalizing and verifying at-

tack scenarios. It establishes a contextual basis by

detailing two speciﬁc languages: the temporal logic

formalization LTL and the algorithmic modeling lan-

guage PlusCal-2.Section 4 examines the seven attack

scenarios and their classiﬁcations and explains the as-

sociated formalization method. Section 5 discusses

the formula veriﬁcation process, illustrated by an ex-

ample run. Finally, Section 6 includes an evaluation

of the results obtained, concluding with a proposal for

a set of corrections to be made to the speciﬁcation.

2 RELATED WORK AND

MOTIVATION

There are two main ways of verifying protocols: test-

ing and formalizing properties.

Testing involves executing concrete tests to evalu-

ate the protocol’s behavior in various situations. The

study in (Stijn et al., 2017) offers a detailed exam-

Analyzing MQTT Attack Scenarios: A Systematic Formalization and TLC Model Checker Simulation

371

ple of applying this method. Researchers are work-

ing to develop and apply a formal approach to eval-

uating protocol implementations, also known as con-

formance testing. Speciﬁcally, they examine whether

each protocol implementation conforms to standards

moderated by regulations previously deﬁned by the

security community. In this article, the research

team reviewed the implementation of the MQTT pro-

tocol, recently standardized by ISO. To carry out

these compliance tests, the researchers used TTCN-

3, a speciﬁcation and execution language that has

demonstrated its effectiveness in conducting compli-

ance tests. The researchers evaluated the compliance

of three open-source implementations of the MQTT

protocol, namely Mosquitto, Emqtt, and RabbitMQ.

The tests during this research involve sending mes-

sages to the SUT (System Under Test) and analyzing

the corresponding responses. The researchers suc-

ceeded in automatically running 13 tests, each rep-

resenting a test of a speciﬁc standard. According to

these tests’ results, all three evaluated implementa-

tions demonstrated partial compliance with the stan-

dard norms. While TTCN-3 can be crucial in validat-

ing telecommunications systems, it is not explicitly

oriented toward modeling security aspects such as at-

tacks or vulnerabilities.

Formalizing properties means expressing a sys-

tem’s characteristics or expected behaviors precisely

and formally. Using proper analysis tools, such as

model checking (UPPAL SMC, TLC), it is possible

to check whether the system respects the speciﬁed

formal properties automatically. In (Houimli et al.,

2017), the authors provided a semi-formal modeling

of the MQTT protocol using UML, followed by im-

plementing a formal model with timed and probabilis-

tic automata using the UPPAAL toolset. UPPAAL

offers the possibility of verifying the MQTT proto-

col using its SMC model-checker for in-depth qual-

itative and quantitative analysis. However, a notable

limitation of this approach lies in the general nature

of the properties veriﬁed, which need to be speciﬁ-

cally formulated to capture particular attack scenar-

ios. While important, general properties such as per-

manence, security, reachability, number of active and

inactive nodes, and message transfer and reception

success rates are not necessarily designed to detect

speciﬁc vulnerabilities to potential attacks. By focus-

ing exclusively on general properties, there is a risk

that particular attack scenarios will go undetected, as

generic properties are not always suitable for identi-

fying speciﬁc malicious behavior.

Temporal Logic of Actions (TLA+) is frequently

used to specify distributed and concurrent systems. In

(Akhtar and Zahoor, 2021), Akhtar and Zahoor ap-

plied a formal method based on TLA+ to verify the

correctness of the MQTT protocol. They used the

PlusCal-2 algorithmic language to deﬁne the three

components of the protocol, which were then trans-

lated into formal TLA+ speciﬁcations. These spec-

iﬁcations were submitted to the TLC model checker

for validation of the safety and durability properties

deﬁned for the system. Precisely, the TLC model-

checking tool reproduces speciﬁc unexpected system

behaviors. Compared with existing methods, TLC en-

ables a particular behavior or execution trace to be

generated each time a property is violated. The au-

thors have taken an initial step in attack formaliza-

tion. They have formalized a speciﬁc attack scenario

in which an attacker monitors the network trafﬁc of

the MQTT broker. The attacker intercepts a CON-

NECT message sent to the Broker by any client and

substitutes his own CONNECT message instead. In

this context, the Broker authorizes the connection, as

no security measures are in place to detect or prevent

such an attack.

In this context, we have proposed a set of formu-

las specifying seven distinct attacks targeting MQTT

protocol services and their variants using Linear Tem-

poral Logic (LTL). Our LTL-based formalization re-

lies on the combination of event sequences model-

ing the moments when vulnerabilities are injected

into the protocol during the execution of the attack

scenarios. Before formalizing the attacks, we tested

whether or not these attacks existed in the MQTT pro-

tocol using the Mosquito tool (Mosquitto, 2018). We

have posted the code for the attack scenarios in the

following link : https://github.com/aminajandoubi/

formalization-of-attacks-MQTT. This formalization

is of crucial importance for describing vulnerability

injections. Further, we tested these formulas using

the MQTT speciﬁcation proposed by the researchers

in (Akhtar and Zahoor, 2021). This speciﬁcation of-

fers the possibility of tracing the violation of a for-

mula, enabling us to design solutions to prevent the

realization of these attack scenarios.

3 PRELIMINARIES

This section recapitulates the essential preliminary el-

ements for formalizing and verifying attack scenarios.

It establishes a contextual basis by detailing two spe-

ciﬁc languages: the temporal logic formalization LTL

and the algorithmic modeling language PlusCal-2.

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

372

3.1 Linear Temporal Logic (LTL)

Linear Temporal Logic (LTL) is a formal language

used to express and reason about systems’ temporal

properties. It is a type of temporal logic that deals

with ordering events in time. It speciﬁes the expected

behavior of a transition system (TS) by selecting the

only possible future (Baier and Katoen, 2008).

Let K = (S,AP,L,R) be a Kripke structure, where

S is a set of states, AP is a set of atomic propositions,

L is a mapping L : S → 2

and R is a total relation.

The following grammar deﬁnes LTL:

Φ |= true | f alse | a | Φ1 ∧ Φ2 | ¬ Φ | ◦ϕ | Φ1 ∪ Φ2

| Φ1 ⇒ Φ2 | Φ1 ↔ Φ2

The semantics of a temporal formula is provided by

the satisfaction relation:

TS |= : (K × S × FORMULA) → {True, False}

LTL is given by the standard boolean logic enhanced

with temporal operators:

• ♢ : “eventually” (eventually in the future)

• □ : “always” (now and forever in the future)

• ¬ : “Not” (negation)

3.2 PlusCal-2 Language

The PlusCal-2 version, developed by Sabina Akhtar,

extends and perfects the PlusCal algorithmic model-

ing language, initially designed by Leslie Lamport

under the name +Cal. Once a PlusCal-2 model has

been established, it can be compiled in TLA+ to en-

able model veriﬁcation using tools such as The TLC

(The TLA+ Model Checker) (Akhtar et al., 2011).

To facilitate the veriﬁcation of properties, PlusCal-2

offers a section within its code structure dedicated

to the deﬁnition of properties. In this section, we

use a temporal term marking the beginning of a

temporal assertion to express properties. PlusCal-2

uses temporal logic, more speciﬁcally TLA+ logic,

to formulate and verify temporal properties within

concurrent and distributed systems, according to the

following grammar:

• Propositional Logic

Propositional logic is the mathematics of the two

Boolean values TRUE/ FALSE, and the ﬁve oper-

ators (disjunction (or), conjunction (and), negation

(not), implication (implies), equivalence (is equiva-

lent to)) are as follows :

\/ | /\ | ∼ | => | <=>

• Sets

Sets denoted (S), represent groupings of elements.

They can be deﬁned and manipulated in TLA+ speci-

ﬁcations to model states and transitions within a sys-

tem. The most common operations on sets are:

∩ | ∪ | ⊆ | \

• Predicate Logic

Once sets are available, asserting that a formula is

valid for all or some elements becomes natural. Pred-

icate logic extends propositional logic by introducing

the two quantiﬁers :

\A | \E

The formula \A x ∈ S : F, asserts that formula F is

true for every element x in the set S. In contrast, the

formula \E x ∈ S : F asserts that formula F is valid

for at least one element x in S.

• Temporal Operators

Temporal operators are used to express temporal

properties about the behavior of a system. Three of

the most commonly used temporal operators are :

❖ []F : F is always true

❖ <>F : F is eventually true

3.3 Rules for Transforming

Table 1 shows the equivalences between the symbols

we have used in LTL and the operators used in TLA+:

• ”Temporal”: This symbol is speciﬁc to TLA+

and represents the notion of time in logic. In LTL,

there is no equivalent symbol.

• ”Eventually”: indicates that a proposition will be

true at some point in the future.

• ”ψ” and ”φ”: are used to represent atomic propo-

sitions, where I.ψ = T RUE or I.φ = T RUE means

that the proposition is true.

• ”Implication”: indicates that if a proposition is

true, then another proposition will also be true.

• ”Negation”: is used to negate a proposition.

Table 1: Rules for transforming.

LTL TLA+

temporal

♢ <>

ψ I.ψ = T RUE

φ I.φ = T RUE

⇒ =>

¬ ∼

Analyzing MQTT Attack Scenarios: A Systematic Formalization and TLC Model Checker Simulation

373

4 ATTACKS SPECIFICATIONS

This section examines the seven attack scenarios and

their classiﬁcations and explains the associated for-

malization method.

4.1 Attack Scenarios

As a ﬁrst step, we formalized seven common attacks

targeting the MQTT protocol. The attack scenarios

are detailed in (Wang et al., 2021) and (Jia et al.,

2020). Table 2 shows the main characteristics of each

attack scenario. The ﬁrst three columns detail each

scenario’s identiﬁer, the Attack Name, and impact.

First, an attacker intentionally publishes malicious

messages on a speciﬁc topic to mislead the system and

induce a subscription. The second attack involves the

interception and recording of communication data,

followed by re-transmission, which can lead to var-

ious consequences such as identity theft, data manip-

ulation, or violation of the integrity of the informa-

tion exchanged. The malware can return nine differ-

ent types of messages the MQTT client sends: CON-

NECT, PUBLISH, PUBREL, SUBSCRIBE, UN-

SUBSCRIBE, PUBACK, PUBREC, PUBCOMP, and

DISCONNECT. The third attack involves identity

theft. In the fourth attack, an attacker maliciously sub-

scribes to topics, violating conﬁdential data. The ﬁfth

attack consists of manipulating or surpassing a cus-

tomer’s will by injecting an unauthorized malicious

connection message (will) into the topic dedicated to

the will. The sixth attack involves maliciously inject-

ing PUBLISH (retain) messages into an unauthorized

issue. The last attack allows an attacker to take con-

trol of a client’s session to access conﬁdential data.

In the fourth column, we have speciﬁed the se-

curity attributes impacted by each attack. These

attributes are essential to ensure conﬁdentiality, in-

tegrity, availability, and other security-related aspects,

where each attack can impact two aspects, either data

or system behavior. As the table shows, attacks 1, 2

and 4 affect behavioral integrity and data conﬁden-

tiality, while attacks 3 and 7 affect conﬁdentiality.

The last two attacks 5 and 6 only affect behavioral

integrity.

Each attack scenario is characterized by a speciﬁc

set of events. This is crucial, as it facilitates under-

standing of the sequential stages of the attack. More

precisely, by examining these events, we can under-

stand the different stages leading to the satisfaction of

the attack scenario. This detailed understanding of the

events associated with each attack scenario can con-

tribute signiﬁcantly to formalizing these attacks. In

short, formalizing attacks based on this in-depth un-

derstanding of events offers a powerful means. It en-

ables attacks to be simulated using a model checker

and provides a formal, systematic system analysis.

4.2 Classiﬁcation of Attack Scenarios

Table 3 presents a classiﬁcation of the seven attack

scenarios into four classes based on the LTL formula.

In our formalization approach, the formulas are

divided into two types of properties, namely φ and

ψ. The φ properties encompass events related to fault

injection, while the ψ properties designate observa-

tional events concerning system behavior in the event

of possible fault injections. The table shows that the

classes are classiﬁed according to their implementa-

tion complexity. For example, class 1 is considered

the simplest to implement, as it contains only injec-

tion properties. However, class 4 is the most com-

plex, incorporating two observation properties, mak-

ing it more delicate to implement. We can conclude

that the presence of observation properties makes sce-

narios more challenging to realize.

We have created graphical representations for all

the LTL formulas we have formulated.

4.2.1 Class C1

As depicted in Figure 2, the formula asserts that, at

some future point, φ1 will inevitably lead to φ2 being

true.

φ1 φ1 φ2

. . . . . .

Figure 2: Graphic representation of C1.

4.2.2 Class C2

As we mentioned in ﬁgure 3, the formula is eventually

true that if ψ is true, then φ will be accurate at some

point in the future.

φ φ

. . . . . .

Figure 3: Graphic representation of C2.

4.2.3 Class C3

This formula ensures that at some time in the future,

if φ1 and ψ2 become true, then φ2 will necessarily be

true later. Figure 4 shows the graphical representation

of this formula. There are two possible representa-

tions due to the ﬂexibility in the order of occurrence

of the ﬁrst two properties φ1 and ψ.

4.2.4 Class C4

This formula means that if ψ1 is accurate at a given

time, then at a later time, ψ2 will become true. If

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

374

Table 2: Characteristics of attack scenarios.

ID Attack Name Attack Effect Security Attributes

1 Malicious Response Topic Publish Force the subscription

2 Replay Attack

3 Client Identity Hijacking Usurpation of identity • Conﬁdentiality

4 Malicious Topic Subscription

5 Unauthorized Will Message

6 Unauthorized Retained Message

7 Faults in Managing MQTT Sessions

• Behavioral integrity

• Data conﬁdentiality

Violation of the integrity

of exchanged information

• Behavioral integrity

• Data conﬁdentiality

Duplication of subscription

• Behavioral integrity

• Data conﬁdentiality

Publication via the

connection

• Behavioral integrity

Force publication (retain) • Behavioral integrity

Access to conﬁdential data

• Conﬁdentiality

Table 3: Classiﬁcation of attack scenarios.

REP ψ φ

1 SUBSCRIBE

4 SUBSCRIBE

LTL formula ID

Events

C1 T S |= ♢(φ1 ⇒ ♢φ2)

φ1 : CONNECT

φ2 : PUBLISH

C2 T S |= ♢(ψ ⇒ ♢φ)

◦E

msg msg

CONNECT

C3 T S |= ♢((φ1 ∧ ♢ψ) ⇒ ♢φ2) ◦EE

φ1 : CONNECT

φ2 : PUBLISH

φ1 : CONNECT

φ2 : SUBSCRIBE

T S |= ♢((ψ1 ⇒ ♢ψ2) ⇒ ♢φ) 7 ◦ ◦ E

ψ1 : CONNECT

ψ2 : DISCONNECT

CONNECT

φ1

ψ ψ ψ

φ2

Rep 2 :

Rep 1 :

φ1

ψ2

φ2

. . . . . . . . .

. . .

Figure 4: Graphic representation of C3.

this implication occurs, then at an even last time, φ

will become true. A graphical representation of the

formula is given in ﬁgure 5.

ψ1

ψ2 ψ2 ψ2

. . . . . . . . .

Figure 5: Graphic representation of C4.

5 ATTACKS VERIFICATION

This section outlines the steps in compiling the

MQTT speciﬁcation. We then put these concepts into

practice by implementing an example. This example

illustrates the compilation process by examining the

attack scenario with ID 3 (Client identity hijacking).

5.1 Compilation Phases for the MQTT

Speciﬁcation

Compiling the MQTT speciﬁcation takes place in

three stages, as shown in the ﬁgure 6. The ﬁrst

phase involves drafting the various MQTT function-

alities, formulating the LTL formula to be veriﬁed,

and representing the attack scenario in the PlusCal-

2 language. This step serves as a prerequisite for

the next phase of the process. This next phase in-

cludes a PlusCal-2 compiler that translates these into

TLA+ speciﬁcations. It is responsible for creating the

TLA+ speciﬁcation. More speciﬁcally, the primary

role of this phase is to produce two ﬁles for the TLC

model checker. The ﬁrst ﬁle, called ”TLA”, contains

the TLA+ speciﬁcations for the algorithm, while the

second ﬁle, the conﬁguration ﬁle, contains the algo-

rithm’s conﬁguration parameters. We used the MQTT

protocol speciﬁcation written by Sabina (Akhtar and

Zahoor, 2021). Sabina has modeled the protocol’s

roles: Broker, Publisher, and Subscriber. Our arti-

Analyzing MQTT Attack Scenarios: A Systematic Formalization and TLC Model Checker Simulation

375

Speciﬁcation MQTT +

Formula + Attack scenario

PlusCal-2 compiler

Input

Output

TLA ﬁle Conﬁguration ﬁle

TLC checker

Figure 6: The compilation phases for the MQTT speciﬁca-

tion.

cle only includes the code for one attack scenario.

We have grouped all the code for the other attack

scenarios in the following link: https://github.com/

aminajandoubi/formalization-of-attacks-MQTT.

5.2 Example of Veriﬁcation of Scenario

We have chosen to illustrate this compilation process

by examining one attack scenarios. In this attack

an attacker can use the victim’s identity to connect

to the server and take the victim ofﬂine. Figure 7

shows the structure of the input ﬁle. The ﬁrst part

of the ﬁle presents the three-component MQTT spec-

iﬁcation developed by Sabina (Akhtar and Zahoor,

2021). The second part covers the speciﬁcation that

models the attack scenario. The attack process be-

gins by monitoring packets on the broker’s network.

When the length of the list of ”network[BrokerID]”

packets is more signiﬁcant than zero, it retrieves the

ﬁrst packet in the list, checks its type, records the

sender’s identiﬁer in the ”pk” variable, then sends a

new ”CONNECT” packet to the ”BrokerID” address.

This attack can allow the attacker to access private

information or disrupt communication between the

client and the broker, leading to signiﬁcant security

and conﬁdentiality risks in networks using MQTT.

The ﬁnal section of the ﬁle contains the formula to

be checked, which in our example corresponds to the

formula for class C2 explained in the table 3. In ac-

cordance with the transformation rules for the table 1,

this LTL formula is presented in 1.

temporal¬(∀I ∈ attaque : (I.OBS

= TRUE ⇒ ⋄(I.INJ = TRUE)))

(1)

We performed the negation of all formulas to iden-

tify possible counterexamples using the TLC checker.

The result is shown in ﬁgure 8, clearly indicating

1 \\ Spec MQTT

2 \\ Spec attacker

3 process attaque[1]

4 CONNECT:

5 when Len(network[BrokerID]) > 0;

6 with packet = Head(network[BrokerID])

7 if packet.type = ”CONNECT” then

8 pk := packet.sender;

9 network := send(BrokerID, [type |−> ”CONNECT”,

sender |−> packet.sender]);

10 network[BrokerID] := Tail(network[BrokerID]);

11 OBS := TRUE;

12 end if;

13 end with;

14 if OBS = TRUE then

15 INJ := TRUE;

16 break;

17 end if;

18 end loop;

19 end process

20 \\ Formula to be veriﬁed

Figure 7: Structure of the input ﬁle for the Client identity

hijacking attack scenario.

the detection of a violation of the temporal proper-

ties speciﬁed in our input ﬁle. The ”Error” section

1 TLC Model−checking

2 Error: Temporal properties were violated.

3 The following counter−example:

4 STATE 1: <Initial predicate>

5 .......

6 STATE 17: Back to state 16.

7 1297 states generated, 534 distinct states found, 0

8 states left on queue.Time elapsed:3.481(s)

Figure 8: Execution results produced by TLC model

checker.

suggests that speciﬁc temporal properties were not

respected during the state space exploration. Subse-

quently, the output generates a ”counterexample” de-

tailing 17 system states violating the speciﬁed prop-

erties. Within this sequence of conditions, we can

observe the temporal evolution of a series of events.

Initially, the system is in a state where no client is ac-

tive, three subjects are in the pool, and an ”attacker”

process is deﬁned, listening to the broker’s network.

The following states allow processing to be applied

until a state is found that helps the value of the OBS

variable, which represents the ψ property, change to

TRUE. In the following states, up to state 17, the

INJ variable representing the φ property is changed to

TRUE, which causes the TLC model checker to stop

the state exploration process. The complete execution

can be found at the following link: https://github.com/

aminajandoubi/formalization-of-attacks-MQTT.

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

376

6 EVALUATION

This section includes an evaluation of the results ob-

tained, concluding with a proposal for a set of correc-

tions to be made to the speciﬁcation.

6.1 Results and Discussion

We have compiled a table containing the information

that appears to result from running the TLC model

checker on the attack scenarios.

The three key measures in the table 4 are:

Table 4: Test results for attack scenarios.

CONNECT 3606 1386

PUBLISH 5046 1799

PUBREL 593 235

SUBSCRIBE 1081 431

1297 534

1800 669

States

generated

Distinct

states found

Time

elapsed (s)

2 3.882

2 4.119

2 2.496

2 2.636

3 3.481

4 4.234

1. Number of States Generated. This ﬁrst measure

indicates the number of system states generated

during model execution. This measure is essential

for assessing the performance of model checking

and indicates the time needed to complete the pro-

cess.

2. Number of Distinct States Found. The second

measure represents the number of unique and dif-

ferent states among those generated. A high num-

ber of distinct states concerning the total num-

ber of states generated may suggest the presence

of redundancies in the model, requiring optimiza-

tions to speed up the veriﬁcation process.

3. Time Elapsed. The fourth measure indicates the

time that has elapsed since the start of the opera-

tion or process.

A fourth metric is the number of states remaining in

the model checker’s queue. As the tool explores sys-

tem states, it places them in a queue for subsequent

veriﬁcation. In our veriﬁcation of these attack sce-

narios, we obtained a value of zero for this metric,

testifying to the effectiveness of the proof.

The results in the table show that we have suc-

cessfully tested the attack scenarios with the respec-

tive identiﬁers 2, 3, and 4, except for ﬁve message

types in attack 2: UNSUBSCRIBE, PUBACK, PUB-

REC, PUBCOMP, and DISCONNECT. In addition,

we could not test the attacks on identiﬁers 1, 5, 6,

and 7 due to the lack of certain features in the MQTT

protocol speciﬁcation. This highlights the importance

of updating the existing speciﬁcation to include these

missing aspects, allowing the veriﬁcation model to

consider these essential elements. By ensuring that

the speciﬁcation is updated correctly, we can close

the identiﬁed gaps and guarantee more comprehen-

sive protection against all classes of potential attacks.

6.2 Recommended Modiﬁcations

In this section, we have suggested modiﬁcations to the

speciﬁcation developed by researcher Sabina (Akhtar

and Zahoor, 2021). All corrections apply to the code

specifying the Broker process, which constantly lis-

tens on the network. As a ﬁrst step, we’ve rec-

ommended adding a condition when a ”CONNECT”

packet is received, enabling veriﬁcation of the client

ID. This is intended to prevent class C2 and C3 at-

tacks. The condition consists of checking the ID of

each connection request received in the client list be-

fore accepting it. This measure aims to prevent the

duplication of users with the same ID number, thus

preventing the attacker from reusing messages in the

event of a connection failure. In other words, adding

this condition would reinforce system security by pre-

venting both attacks based on reusing client ID num-

bers and repeated attempts to send the same message.

Secondly, in line with scenario 4 of class C3, it would

be necessary to incorporate a new index at the MQTT

broker level listing all the clients in the network with

which it needs to communicate. Before processing

each connection request, checking whether the re-

quester belongs to our network would be impera-

tive. This veriﬁcation would prevent attacks seeking

to connect to the network, which could result in ac-

cess to shared sensitive data or data tampering.

7 CONCLUSION

The observation that attack descriptions are often in-

formal is of crucial importance in the security ﬁeld.

The lack of formality in these descriptions deﬁnes a

signiﬁcant challenge by restricting the clarity and pre-

cision necessary for a thorough understanding of inci-

dents. This shortcoming compromises effective pre-

vention and response measures, as it hinders the accu-

rate identiﬁcation of vulnerabilities and the formula-

tion of appropriate countermeasures. This underlines

the imperative need to formalize attack descriptions.

In this context, we have developed a proposal to

remedy this shortcoming. We have introduced a sys-

tematic and structured process speciﬁcally designed

to formalize a set of vulnerabilities. This approach

Analyzing MQTT Attack Scenarios: A Systematic Formalization and TLC Model Checker Simulation

377

aims to create a robust basis for a deeper understand-

ing of attacks, facilitating the implementation of more

precise and appropriate security measures. By for-

malizing these descriptions, we intend to enhance the

resilience of systems in the face of threats, thus con-

tributing to the overall improvement of the security

posture. We used a temporal logic formalism known

as Linear Temporal Logic (LTL) for our formaliza-

tion. This article outlines our approach to formalizing

seven common attacks against the MQTT protocol,

creating 12 distinct LTL formulas. Each of these for-

mulas precisely represents a speciﬁc attack scenario.

We have classiﬁed these attacks into four categories

based on their formulation, where each class is char-

acterized by two distinct property types, φ and ψ. The

number of properties in each formulation varies ac-

cording to the events modeling the attack scenario,

thus presenting an essential key to attack classiﬁca-

tion.

Next, we implemented a set of rules to transform

LTL formulations into TLA+ for veriﬁcation using

the TLC simulator. When a formula is violated, the

TLC simulator generates a counter-example that mod-

els the execution sequence leading to the violation.

We successfully tested the attack scenarios with iden-

tiﬁers 2, 3, and 4, except for ﬁve message types in at-

tack 2: UNSUBSCRIBE, PUBACK, PUBREC, PUB-

COMP, and DISCONNECT. In addition, we could not

test the attacks on identiﬁers 1, 5, 6, and 7 due to the

absence of certain functionalities in the MQTT proto-

col speciﬁcation. This highlights the importance of

updating the existing speciﬁcation to include these

missing aspects, allowing the veriﬁcation model to

consider these essential elements. By ensuring that

the speciﬁcation is updated correctly, we can close

the identiﬁed gaps and provide more comprehensive

protection against all classes of potential attacks. By

analyzing the execution traces obtained with TLC, we

have developed a set of patches to improve the speci-

ﬁcation.

For future systematic work, it is important to ex-

plore several avenues of research to improve security

veriﬁcation and extend the study. Firstly, developing

the speciﬁcation used to cover all the missing attack

scenarios is imperative. Secondly, it is essential to

consolidate all the attack scenarios in a single speciﬁ-

cation code and compare the results obtained.

ACKNOWLEDGEMENTS

The Moroccan-Tunisian Research and Development

project PR&D-19/23: SIGIRO funds the work intro-

duced in this paper. This project aims to monitor wa-

ter reservoirs in water-stressed regions.

REFERENCES

Akhtar, S., Merz, S., and Quinson, M. (2011). A High-

Level Language for Modeling Algorithms and Their

Properties. In Davies, J., Silva, L., and Simao, A., edi-

tors, Formal Methods: Foundations and Applications,

volume 6527, pages 49–63. Springer Berlin Heidel-

berg, Berlin, Heidelberg. Series Title: Lecture Notes

in Computer Science.

Akhtar, S. and Zahoor, E. (2021). Formal Speciﬁcation and

Veriﬁcation of MQTT Protocol in PlusCal-2. Wireless

Pers Commun, 119(2):1589–1606.

Baier, C. and Katoen, J.-P. (2008). Principles of model

checking. The MIT Press, Cambridge, Mass. OCLC:

ocn171152628.

CVE (2023). CVE. page https://cve.mitre.org.

Houimli, M., Kahloul, L., and Benaoun, S. (2017). For-

mal speciﬁcation, veriﬁcation and evaluation of the

MQTT protocol in the Internet of Things. In 2017

International Conference on Mathematics and Infor-

mation Technology (ICMIT), pages 214–221, Adrar,

Algeria. IEEE.

IoT-Analytics (2023). Iot analytics 2023. pages https://iot–

analytics.com/number–connected–iot–devices/.

Jia, Y., Xing, L., Mao, Y., Zhao, D., Wang, X., Zhao, S.,

and Zhang, Y. (2020). Burglars’ IoT Paradise: Un-

derstanding and Mitigating Security Risks of General

Messaging Protocols on IoT Clouds. In 2020 IEEE

Symposium on Security and Privacy (SP), pages 465–

481, San Francisco, CA, USA. IEEE.

Mosquitto (2018). Eclipse Mosquitto. page

https://mosquitto.org/.

NVD (2023). Nvd,. page https://nvd.nist.gov/.

Stijn, v. W., Chris, M., and KPMG, C. (2017). Formal veri-

ﬁcation of the implementation of the mqtt protocol in

iot devices. Amsterdam: University of Amsterdam.

Amsterdam: University of Amsterdam.

Wang, Q., Ji, S., Tian, Y., Zhang, X., Zhao, B., Kan, Y., Lin,

C., Deng, S., Liu, A. X., and Beyah, R. (2021). MPIn-

spector: A Systematic and Automatic Approach for

Evaluating the Security of IoT Messaging Protocols.

30th USENIX Security Symposium.

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

378