Hello!
As already pointed out by Grant Ramsay in the comments in the page MQTT Request-Response Pattern – MQTT 5 Essentials Part 9 there seems to be a privilege escalation scenario in request response patterns as recommended.
By having the requester specify the response topic, it can direct a more privileged responder to respond to a topic outside of the requester’s publishing access rights.
The example for Grant Ramsay
//Requester publishes request
Mqtt5PublishResult result = requester.publishWith()
.topic(“debug/echo”)
.correlationData(“1234”.getBytes())
.responseTopic(“ssh/command”)
.payload(“rm -rf *”.getBytes())
.send();
Do you have any recommended way to solve this according to best practice?
Really struggling with this one. Does anyone happen to know the preferred solution for mitigating this? or have encountered it?
So one mitigation design I’ve thought of is that:
requester does:
publish_topic = host1/subuser2/debug/echo
response_topic = ssh/command
Responder does:
-
special logic in host1 that says that if I received a command on host1/subuser2/ all responses are on host1/subuser2/ prefix.
-
Meaning that the responder would publish on host1/subuser2/ssh/command.
This would make it such that subuser2 any other subuser can only mess upp their own system. However I don’t know if this is the prefered and most elegant solution to this. I feel there must be something else.
Best,
T
Hi @thremore,
and a warm welcome to the HiveMQ Community! We’re excited that you’re interested in MQTT and the HiveMQ broker. Your presence adds value to our community.
I would suggest that you make not only the response topic specific to the publisher MQTT client, but also the requested topic, such as in .topic(“debug/echo”), to be also client-specific, such as .topic(“host1/subuser2/debug/echo”)
This way you could be in control at any step, so only authorized client has access.
Let me know what you think
Warm regards,
Dasha from HiveMQ Team