[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=74325#comment-74325 ] 

Jonathan Levell commented on MQTT-536:
--------------------------------------

When we have the implementers guide up and running, we may want to include some words that discuss the timing of auth checks. 

As a first pass something like:



Timing of Authorisation Checks

The timing of authorisation checks on actions such as publishing or subscribing are implementation dependent. The asynchronous nature of messaging means that there can be an extended time period between the check occurring and data being processed, for example:

â If the authorisation of a publisher is (only) checked when the server receives a message from the publisher, then that publisher may be no longer authorised by the time that a subscribing application receives (or later processes) a message.

â If the authorisation for a retained publication is (only) checked when the server receives the publication, then the message may be given to new subscribers long after the original publisher is no longer authorised to publish new messages

â If the authorisation for a will message is (only) checked when a client connects, the will message may be published on a topic that the publisher is no longer authorised to publish on when the client disconnects

â If the authorisation for a subscription is (only) checked when the subscription request is processed by the server then it is possible for subscriber to receive messages published on topics that they are no longer authorised to subscribe to.

There are commonly-used MQTT implementations that perform authority checks as described in the examples above however authority checks could be performed at different points in the message flow with different implementation choices and trade-offs.

> 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)