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

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

There are other examples that could be mentioned:

1) A publisher is authorised to create a publication with a long expiry interval.
The administrator decides to shorten the maximum expiry interval of publications to reduce the storage used by long lived
undelivered messages. The administrator would also want to reduce the lifetime of any previously published messages.

2) A client creates a session with a long expiry interval. The administrator decides to limit the maximum session lifetime
so that he constrains the amount of storage used to keep long lived but unused sessions.

There will be many cases where an authorisation policy has to be made more restrictive so,
in addition to specific examples it is worth describing the generic problem...

ÂAuthorisation for
writing any of the saved state is sensitive to when it is performed. It is also possible that data
that was written in the past might need to be re written by an administrator if the authorisation 
policies are changed.

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