OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization


One consideration added for completeness: A client could conceivably pass an OAuth2 refresh token to the broker during the connection handshake and the broker could conceivably ask for reauthorization at publish time â but I consider that entirely outside of the scope of the MQTT specification.

 

From: Clemens Vasters
Sent: Mittwoch, 5. Juni 2019 09:33
To: Jia, Yan <yj15@iu.edu>; Bird, Rob <rbird@akamai.com>; Ken Borgendale <kwb@us.ibm.com>
Cc: mqtt-comment@lists.oasis-open.org; Xing, Luyi <luyixing@indiana.edu>
Subject: RE:
çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

First, messages are never individually âauthorized by receiversâ in MQTT, so your statement doesnât make sense as it stands. I will assume that you mean that âwillâ and âretainâ message send operations should to be subject to authorization based on the original sender identity at the moment when the messages are made available to receivers:

 

You donât observe there being an authorization check, because the actor for publishing retained and will messages is the MQTT broker who took possession and of those messages when they were published.

 

Both features, âwillâ and âretainâ, are executing decoupled from the publisher. In the case of âwillâ, the prior disconnection of the publisher is the trigger for the message to be delivered. In the case of âretainâ, the message becomes part of the topic state and stays there, even if the publisher has disconnected.

 

In any modern scenario where the broker doesnât manage user accounts internally but relies on authorization tokens (e.g. Kerberos, OAuth2), the âfew weeks laterâ authorization you insist ought to happen would require a client-initiated roundtrip interaction with an authorization server for acquiring a current authorization token.

 

Even if I ignore the fact that thereâs no mechanism for the server to request such a token from the client, itâs simply impossible to implement what you ask for because for âwillâ, the client is â by definition â disconnected when the operation happens. Itâs also impossible for âretainâ, because the lifecycle of that message isnât even bound to the connection.

 

Thus, authorization as it relates to the client is done and final as the âretainâ and âwillâ messages are accepted, because thereâs literally no way to do it otherwise. Again quoting from below:

 

  1. A client with authority to connect and publish specified a will messages, but no longer has authority to publish at the time the will message is sent. The will message is sent.

 

The Will message is accepted at the time it is set. That act of acceptance grants the permission for it to be delivered at a later time. The key MQTT 5.0 spec sentence is in 3.1.3.2.2  âThe Server delays publishing the Clientâs Will Message until the Will Delay Interval has passed or the Session ends, whichever happens firstâ. That implies that the server has accepted it and will deliver it later, at its discretion. With that, the client is out of the picture.

 

  1. A client with authority publishes a retained message, the authority to publish the message is removed, but the retained message is send to a new subscriber after this point. As an extension of this, the same problem may exist for any message queued for delivery.

 

A retained message is accepted at the time it is set and becomes part of the topic state. The MQTT 5.0 spec states in 3.3.1.3 âWhen a new Nonâshared Subscription is made, the last retained message, if any, on each matching topic name is sent to the Client as directed by the Retain Handling Subscription Optionâ â which is an act by the server that is independent of who sent that message and a relationship to the sender is not maintained.

 

Clemens

 

From: Jia, Yan <yj15@iu.edu>
Sent: Mittwoch, 5. Juni 2019 03:50
To: Clemens Vasters <clemensv@microsoft.com>; Bird, Rob <rbird@akamai.com>; Ken Borgendale <kwb@us.ibm.com>
Cc: mqtt-comment@lists.oasis-open.org; Xing, Luyi <luyixing@indiana.edu>
Subject:
çå: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

In real implementation, we

found the âWill Messageâ and âRetained Messageâ mentioned in issue 1 and 2 are often not authorized by receivers or any other party, though they may be checked when published (e.g., a few weeks ago). Hence, in

non-normative

section 5.4.2, we suggest

the specification warn of the security risks if such messages are not authorized in receiving, as an additional note on authorizing publishing a message.

 

Yan JIA


åää: Clemens Vasters <clemensv@microsoft.com>
åéæé: 2019å5æ24æ 14:40
æää: Jia, Yan; Bird, Rob; Ken Borgendale
æé: mqtt-comment@lists.oasis-open.org
äé: RE: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

A âsmart lockâ mechanism will most certainly check the legitimacy of the unlock request at the time when the unlock request is issued. Whether the request is initiated now or has been initiated three weeks ago as a Will message is irrelevant. If the sender of the message is not the current occupant of the room, the request will be denied. The authorization gate for the unlock operation is at the receiver of the request and not at the ingress gateway of the MQTT broker.

 

Including something in the normative section would mean that thereâs something particular that an implementation SHOULD or MUST do, and since the spec doesnât prescribe an authorization model, thereâs nothing to anchor such rules on.

 

From: Jia, Yan <yj15@iu.edu>
Sent: Freitag, 24. Mai 2019 20:02
To: Clemens Vasters <clemensv@microsoft.com>; Bird, Rob <rbird@akamai.com>; Ken Borgendale <kwb@us.ibm.com>
Cc: mqtt-comment@lists.oasis-open.org
Subject:
çå: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

Issue 1 and 2 will pose security risk in the scenarios when a client's rights need to be revoked immediately.

 

For example, in IoT scenarios, 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.

 

In this scenario, an attacker who stayed in a hotel room or apartment once can unlock the door using the Issue 1. Specifically, he can register a Will Message when he has right of the smart lock and keep that connection after his right are revoked. Then he can disconnect at any time triggering the Will Message to control it, even though the smart lock belongs to the victim thereafter. Similarly, the attacker could set a timer using issue 2 (retained message).


As far as I know, MQTT has been applied in many IoT platforms , and most of the implementations check the normal PUBLISH message correctly. But this two kind of messages are omitted, which poses practical risks to users.

 

I understand that the MQTT specification cannot cover all issues, but it would be helpful to remind some complicated but important issues in normative section.

 

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

 

Yan JIA


åää: Clemens Vasters <clemensv@microsoft.com>
åéæé: 2019å5æ23æ 17:18
æää: Jia, Yan; Bird, Rob; Ken Borgendale
æé: mqtt-comment@lists.oasis-open.org
äé: RE: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

On issues 1 and 2, I donât believe thereâs any security issue, at all. The act of sending/accepting the message is clearly delineated from the act of usage of the message by the server at its own discretion in the spec as it stands.

 

For 3, while I donât think 5.4. can ever be exhaustive, it might be worth adding some wording to an errata release explaining the scenario whenever one is created. Since the text will not be normative, that would seems like a reasonable addition.

 

 

From: Jia, Yan <yj15@iu.edu>
Sent: Thursday, May 23, 2019 11:07 PM
To: Clemens Vasters <clemensv@microsoft.com>; Bird, Rob <rbird@akamai.com>; Ken Borgendale <kwb@us.ibm.com>
Cc: mqtt-comment@lists.oasis-open.org
Subject:
çå: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

I agree that's not a vulnerability in protocol. The acts of the server should depend on the scenarios.

However, considering the impact of the issues in some scenarios as reported, I believe it would be helpful to remind everyone in the specification on Section "5.4 Implementation notes". Because these issues are subtle.

 

 

 

Yan JIA


åää: Clemens Vasters <clemensv@microsoft.com>
åéæé: 2019å5æ23æ 16:02
æää: Jia, Yan; Bird, Rob; Ken Borgendale
æé: mqtt-comment@lists.oasis-open.org
äé: RE: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

If I may:

 

  1. A client with authority to connect and publish specified a will messages, but no longer has authority to publish at the time the will message is sent. The will message is sent.

 

The Will message is accepted at the time it is set. That act of acceptance grants the permission for it to be delivered at a later time. The key MQTT 5.0 spec sentence is in 3.1.3.2.2  âThe Server delays publishing the Clientâs Will Message until the Will Delay Interval has passed or the Session ends, whichever happens firstâ. That implies that the server has accepted it and will deliver it later, at its discretion. With that, the client is out of the picture.

 

  1. A client with authority publishes a retained message, the authority to publish the message is removed, but the retained message is send to a new subscriber after this point. As an extension of this, the same problem may exist for any message queued for delivery.

 

A retained message is accepted at the time it is set and becomes part of the topic state. The MQTT 5.0 spec states in 3.3.1.3 âWhen a new Nonâshared Subscription is made, the last retained message, if any, on each matching topic name is sent to the Client as directed by the Retain Handling Subscription Optionâ â which is an act by the server that is independent of who sent that message and a relationship to the sender is not maintained.

 

  1. A client with authority subscribes to a topic and then the client loses the authority over that topic. Messages are still send on the subscription. This includes the case of a resumed session so that messages could still be received after subsequent reconnects.

 

The specification does not mandate any particular authorization method. Itâs legitimate, and this is how I would implement it, to enforce an authorization check when a session is being recovered. Itâs also legitimate to cut an existing connection when the access control rule is changed or an access token expires, and Iâm aware of brokers who do that. Thatâs not a vulnerability in the spec, because the spec doesnât take a stance.

 

 

From: mqtt-comment@lists.oasis-open.org <mqtt-comment@lists.oasis-open.org> On Behalf Of Jia, Yan
Sent: Thursday, May 23, 2019 9:27 PM
To: Bird, Rob <rbird@akamai.com>; Ken Borgendale <kwb@us.ibm.com>
Cc: mqtt-comment@lists.oasis-open.org
Subject:
çå: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

This wiki link maybe helpful for understanding such kind of problem.

It's called "time of check to time of use".

https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use

 

Yan JIA


åää: Bird, Rob <rbird@akamai.com>
åéæé: 2019å5æ23æ 14:18
æää: Jia, Yan; Ken Borgendale
æé: mqtt-comment@lists.oasis-open.org
äé: Re: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

Wouldnât this then be true for any delivery delay+ACL change race condition? For example:

 

  • I publish a message to a topic with a subscriber that is on the moon
  • The ACL is changed blocking the publisher
  • Moon client receives message already in flight

 

It seems that aside from the âwillâ message case (where publication is actually initiated after the ACL change) that the others (including the one I list above) would imply requiring generically that all MQTT ACLs are implemented (at least) as delivery-side guarantees. This issue would appear to raise potential philosophical questions.

 

From: <mqtt-comment@lists.oasis-open.org> on behalf of "Jia, Yan" <yj15@iu.edu>
Date: Thursday, May 23, 2019 at 10:16 AM
To: Ken Borgendale <kwb@us.ibm.com>
Cc: "mqtt-comment@lists.oasis-open.org" <mqtt-comment@lists.oasis-open.org>
Subject:
çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

Thanks for your response. That's the point. And I believe , in some scenarios, these issues will pose practical security risks.

 

I will track this issue on this mailing list and the MQTT issue system. We are happy to address the issues with TC.

 

Best Regrads,

 

Yan JIA
School of Cyber Engineering, Xidian University
National Computer Network Intrusion Protection Center, University of Chinese Academy of Sciences
Indiana University Bloomington


åää: Ken Borgendale <kwb@us.ibm.com>
åéæé: 2019å5æ22æ 16:13
æää: Jia, Yan
æé: <mqtt-comment@lists.oasis-open.org>
äé: Re: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization

 

Thank you for you comment. I have forwarded it on to the full mqtt TC mailing list as many TC members do not monitor the mqtt-comment list. I have created this as issue NQTT-536 in the MQTT TC issue system. https://issues.oasis-open.org/projects/MQTT/issues/MQTT-536 Note that the MQTT TC has not been very active since the publication of MQTTv5.0.

As I understand it three security issues are raised here:

  1. A client with authority to connect and publish specified a will messages, but no longer has authority to publish at the time the will message is sent. The will message is sent.
  2. A client with authority publishes a retained message, the authority to publish the message is removed, but the retained message is send to a new subscriber after this point. As an extension of this, the same problem may exist for any message queued for delivery.
  3. A client with authority subscribes to a topic and then the client loses the authority over that topic. Messages are still send on the subscription. This includes the case of a resumed session so that messages could still be received after subsequent reconnects.



Ken Borgendale -- kwb@us.ibm.com
Senior Programmer -- IBM MessageSight and Watson IoT Platform Connect - Architect


Inactive hide details for "Jia, Yan" ---05/21/2019 02:36:53 PM---Dear  OASIS MQTT Technical Committee, We are a security resear
"Jia, Yan" ---05/21/2019 02:36:53 PM---Dear OASIS MQTT Technical Committee, We are a security research group. Recently we found a kind of

From: "Jia, Yan" <yj15@iu.edu>
To: "mqtt-comment@lists.oasis-open.org" <mqtt-comment@lists.oasis-open.org>
Cc: "jiay@nipc.org.cn" <jiay@nipc.org.cn>
Date: 05/21/2019 02:36 PM
Subject: [EXTERNAL] [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization
Sent by: <mqtt-comment@lists.oasis-open.org>





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.


Recommendation
We 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 JIA
School of Cyber Engineering, Xidian University
National Computer Network Intrusion Protection Center, University of Chinese Academy of Sciences
Indiana University Bloomington

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]