BUG reports

[Just1ceP4rtn3r]

Dear developers of Moquette,
We are a security research group from HUST China, IU USA, and NKU China. Recently we studied the MQTT service in Moquette of the latest version (3e6043b) and discovered some security flaws that would lead to unauthorized access to the victim clients (e.g., IoT devices) in Moquette. We elaborate on these problems with the practical threat models as follows.

Threat model

Consider a practical scenario where the Moquette is used to manage multiple IoT devices and applications. An attacker (a.k.a., a malicious user) registered as a regular user in the system and aims to control devices (e.g., a smart door) that are not belonging to him or are authorized to him.
For example, the attacker “user1” attempts to steal messages from or send commands to the device that belongs to the admin with username “admin” (see below configuration).

# moquette.conf
#*********************************************************************
# The interface to bind the server
#  0.0.0.0 means "any"
#*********************************************************************
host 0.0.0.0

#*********************************************************************
# The file for the persistent store, if not specified, use just memory
# no physical persistence
#*********************************************************************
#persistent_store ./moquette_store.h2

#*********************************************************************
# acl_file:
#    defines the path to the ACL file relative to moquette home dir
#    contained in the moquette.path system property
#*********************************************************************
acl_file config/acl.conf

#*********************************************************************
# allow_anonymous is used to accept MQTT connections also from not
# authenticated clients.
#   - false to accept ONLY client connetions with credentials.
#   - true to accept client connection without credentails, validating
#       only against the password_file, the ones that provides.
#*********************************************************************
allow_anonymous false

#*********************************************************************
# password_file:
#    defines the path to the file that contains the credentials for
#    authenticated client connection. It's relative to moquette home dir
#    defined by the system property moquette.path
#*********************************************************************
password_file config/password_file.conf

# acl.conf
user admin
topic readwrite /topic/test

# password_file.conf 
#*********************************************
# Each line define a user login in the format
#   <username>:sha256(<password>)
#*********************************************
#NB this password is sha256(passwd)
# admin:pass
admin:d74ff0ee8da3b9806b18c877dbf29bbde50b5bd8e4dad7a3a725000feb82e8f1
# user1:pass1
user1:e6c3da5b206634d7f3f3586d747ffdb36b5c675757b380c6a5fe5c570c71434

Problem 1: Unauthorized Will message

In Moquette 1.5, any user with correct Credentials can connect to the broker with a malicious Will message in the packet. And the broker simply accepts the request without checking what topic is contained in the Will message and without checking whether the user is authorized to access the topic in the Will message. Consequently, a malicious user can send CONNECT requests to the broker containing a malicious Will message, which will be delivered to the victims (e.g., a smart lock belonging to another victim user) who subscribes to the topic in the Will message whenever the attacker disconnects himself.

That is, an unauthorized attacker can choose when (e.g. when he disconnects himself) to control which device (e.g., as long as the attacker knows the corresponding topic, which normally is not difficult) at his wishes.

PoC attack of Problem 1

Consider a more practice scenario:
After checking in, the malicious guest has no permissions on topic "A".

1. The guest connects to the broker with a will message (topic="A", payload="bad will").

2. The guest stays connected.

3. The guest can trigger its will message by closing the network or other operations, and then the will message will be delivered to the victim devices who subscribe to the topic “A”.

Possible Defense to Problem 1: add permission check when accepting the Will messages
Before accepting the Will message, the broker should verify whether the user is authorized to access the topic.

Problem 2: Session Takeover

If a new session connects to the broker with the same clientID as an existing session, the broker would close the existing session. This is called “Session taken over” in MQTT specification [MQTT-3.1.4-3]. However, in the Moquette, unauthorized operations can be performed by utilizing this processing due to the lack of permission checks which can cause some harmful effects to the victim devices/applications.

We summarize the possible attacks as follows:

1. The malicious user can trigger the Will message of the existing session by "Session taken over". Although the malicious user cannot control the content of the Will message, he can choose the timing of triggering the Will message. By the way, the malicious user does not need to have permission to send the will message.

2. DoS attack, kicking the victim with the same clientID offline

Possible Defense to Problem 2
A possible fix to problem 2 is to add permission checks when accepting the new session, such as checking whether the user in the new session is authorized to PUBLISH and SUBSCRIBE to certain topics.

Regards,
Bin

[Bas83]

@andsel curious about whether this has been evaluated and confirmed as a real bug, and if so when it will be or has been fixed.

[andsel]

Hi @Bas83
I just read it. I haven't tried the POC but Will topic is not evaluated for access, so the problem 1 is still present. The problem 2 is intrinsic of MQTT protocol, as explained and Moquette, as of version0.16 doesn't have any counter measure implemented.

[Bas83]

@andsel Yeah that problem 2 is just MQTT makes sense to me, we have our own permissions checks in the IAuthenticator interface implementation to avoid this.

[andsel]

Hi @Bas83 nice! May I ask you how do you use Moquette?

[Bas83]

@andsel sure, but maybe not in this bug report?

[andsel]

Great, if you can read my personal email address, write there.

…

On Wed, Feb 1, 2023 at 8:15 AM Bas83 ***@***.***> wrote: @andsel <https://github.com/andsel> sure, but maybe not in this bug report? — Reply to this email directly, view it on GitHub <#689 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH5RUNKG5YZIXBLJXUIHTLWVIESVANCNFSM6AAAAAARYYEGEI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Bas83]

@andsel if your github commit email address is correct, you should have an email now