[OASIS Issue Tracker] (MQTT-536) Revocation of authority to publish and subscribe

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=73882#comment-73882 ] 

Ken Borgendale commented on MQTT-536:
-------------------------------------

My take on this is that the two cases of publish authorization most implementations would choose to authorize the publish at the time of the publish. Once the publish is accepted and authorized by the server it may take any amount of time for that message to be delivered to a client.Â

I do not see the cases of will or retained messages as being any different. As an analogy, if a client with authority writes to a file system and then has the authority to do so revoked, we do not rollback any changes made while the client had such authority.

The case of authorization of a subscription is a more interesting one, and especially the authorization of subscriptions in a resumed session. Should the client have authorization to subscribe at the time the server sends a message to it, at the time the message is queued for deliver to a client, or only at the time of the subscription? All of these are valid points to check authority.

Besides changing the authority of a client, the server may allow an administrator to disconnect the client, and/or to expire the session of the client. For instance, only authorizing subscriptions at the time of the subscribe would be fine if when a client loses authority any open connection is closed and its session is expired.

All of this seems an interesting thing to discuss in our security documents, but there are a number of implementations which would satisfy the security concerns. Does it make sense at this point to discuss a committee note concerning this? While some details vary by version of MQTT, the basic issues are the same.

> Revocation of authority to publish and subscribe
> ------------------------------------------------
>
>                 Key: MQTT-536
>                 URL: https://issues.oasis-open.org/browse/MQTT-536
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: SecuritySC
>    Affects Versions: 3.1.1, 5
>            Reporter: Ken Borgendale
>            Priority: Major
>
> 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
> Â



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)