Revocation of authority to publish and subscribe

From: "Jia, Yan" <yj15@iu.edu>From: "Jia, Yan" <yj15@iu.edu>

Dear  OASIS MQTT Technical Committee,
We are a security research group. Recently we found a kind of security vulnerability about the authorization of clients by the server, which affects many popular MQTT server implementations. Specifically, because of the inadequate understanding of the message sending/receiving mechanism in MQTT, a client once gains the rights could still publish or receive messages from the broker after its rights are revoked.
The problem
The problem occurs when a client is first granted the rights of PUBLISH,  then its rights are revoked. The client publishes a retained message or registers a Will Message to a topic when it has right to, then its rights of that topic is revoked. However, the retained message or Will Message will still be published to clients that subscribe to that topic.
Similarly, the client firstly subscribes to a topic, then its right of SUBSCRIBE is revoked. This client is still able to receive messages from that topic if it keeps the MQTT session.
Further analysis
We found most MQTT server implementations normally authorize actions directly performed by the client soundly, which means that the normal PUBLISH and SUBSCRIBE messages will be denied immediately if a client does not have rights of corresponding topics. However, in the scenario above, the actions of delivering messages to the target device are triggered by events and performed by the broker server instead of the subject who performs the actions. This kind of action, if not authorized rigorously, will leave a security hole for attackers.
Impact
MQTT is one of the most popular messaging protocols in IoT. We find the legitimate usage rights of IoT devices can be transferred from the adversary to victim users, such as when the adversary checks out of hotel rooms, apartments, etc. equipped with IoT devices and then a victim user checks in. The reference [1-4] provides some evidence that hotels and apartments are installing IoT devices including the smart lock. Utilizing the attacks illustrated above, in this scenario, an attacker who stayed in a hotel room or apartment once can unlock the door and monitor device status when other guests live in the room later. The former user’s usage rights of the IoT device should have been revoked rigorously.
The issues we discovered affect many major IoT cloud platforms, including AWS IoT, IBM Watson IoT, Tuya Smart, etc. who all acknowledged our findings. Eclipse Mosquitto assigned the retained message issue CVE-2018-12546 [5]. In addition, based on the problems mentioned above, we did successful PoC attacks on our real smart home devices.
RecommendationWe hope the committee carefully consider our report. Meanwhile, we believe It would be helpful to build a secure MQTT system by reminding developers to take good care of the issues we reported in “Chapter 5 Security” of MQTT 5 specification.
If you need any further information, please feel free to let us know.

Reference[1] https://newsroom.hilton.com/corporate/news/hilton-announces-connected-room-the-first-mobilecentric-hotel-room-to-begin-rollout-in-2018, 2017. Accessed: 2019-01.[2] https://learnairbnb.com/smart-home-technology/[3] https://www.the-ambient.com/guides/host-smart-airbnb-home-tech-217[4] https://www.remotelock.com/smart-locks-airbnb-hosts[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=543127

Best Regards,
Yan JIASchool of Cyber Engineering, Xidian UniversityNational Computer Network Intrusion Protection Center, University of Chinese Academy of SciencesIndiana University Bloomington