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

Andrew Banks commented on MQTT-536:
-----------------------------------

This issue could apply to all of the session state, and to retained messages. Leaving aside the question of what access control is policed by the server, this issue is raising the question of at what point in the processing, access control is applied. It is also asking whether revocation of access control should be applied retrospectively, and whether an action that was allowed in the past should be undone as a result of revoking some permission. Â

Â

Secton 4.1 describes the session state in the server as...

The Session State in the Server consists of:
 * The existence of a Session, even if the rest of the Session State is empty.
 * The Clients subscriptions, including any Subscription Identifiers.
 * QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.
 * QoS 1 and QoS 2 messages pending transmission to the Client and OPTIONALLY QoS 0 messages pending transmission to the Client.
 * QoS 2 messages which have been received from the Client, but have not been completely acknowledged.The Will Message and the Will Delay Interval
 * If the Session is currently not connected, the time at which the Session will end and Session State will be discarded.

Â

Retained messages do not form part of the Session State in the Server, they are not deleted as a result of a Session ending.

Â

... so. (to take an extreeme example) Suppose a server allows publication of a Qos=2 publication at a time when the publisher is allowed to publish it and the server responds with a PubRec Rc=0.

Publication authority is then revoked.

The footnote in section 4.4 says...

{color:#000000}The receiver does not need to complete delivery of the Application Message before sending the PUBREC or PUBCOMP. When its original sender receives the PUBREC packet, ownership of the Application Message is transferred to the receiver. However, the receiver needs to perform all checks for conditions which might result in a forwarding failure (e.g. quota exceeded, authorization, etc.) before accepting ownership. The receiver indicates success or failure using the appropriate Reason Code in the PUBREC.{color}

{color:#000000}... So the remainder of the dialogue with the publisher will contonue as if the publication is still authorised, but we might propose that the dialogue with the subscriber might not proceed.{color}

Â

Â

Â

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