But how is this different from any delayed message? What if the ACL is changed while the message is in flight e.g. through a satellite connection?
From: <mqtt-comment@lists.oasis-open.org> on behalf of "Jia, Yan" <yj15@iu.edu>
Date: Thursday, June 13, 2019 at 1:23 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" <mqtt-comment@lists.oasis-open.org>, "Xing, Luyi" <luyixing@indiana.edu>
Subject: Re: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization
We understand that âwillâ and âretainâ messages by their current definition, once accepted by the broker, are entitled to be delivered at a later time. However, we found this poses severe security risks to a very common use case
of MQTT, i.e., the Internet of Things (IoT). For example, a smart lock of a hotel room/apartment accepts any âwillâ messages intentionally published by the previous occupant who is malicious and may unlock the door; from the current occupantâs perspective,
the âwillâ message should be authorized on delivery though it was successfully authorized when published by the previous occupant.
We think it can be helpful for MQTT 5 to warn protocol adopters (e.g., IoT cloud and device manufacturers) of such risks of no authorization at delivery time. Since MQTT 5 does not have a notion of âend-to-endâ, we think client-to-server and server-to-client
messages need to be respectively authorized in certain real use cases. From a broader sense, the risk we stated is a TOCTTOU (Time-of-check to time-of-use) problem.
Yan JIA
From: Clemens Vasters <clemensv@microsoft.com>
Sent: Thursday, June 6, 2019 7:08
To: Jia, Yan; Bird, Rob; Ken Borgendale
Cc: mqtt-comment@lists.oasis-open.org; Xing, Luyi
Subject: RE: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization
There is no association between a message and the original sender identity in MQTT.
From: Jia, Yan <yj15@iu.edu>
Sent: Donnerstag, 6. Juni 2019 05:26
To: Bird, Rob <rbird@akamai.com>; Clemens Vasters <clemensv@microsoft.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
Iâm sorry for the confusing. The
point I want to make is that the âwillâ and âretainedâ message should be checked and we observed that only checking those messages at the moment when the broker receives them is not enough, for example
in the âsmart lock caseâ I mentioned. Because the time
of publishing this two kind of messages is delayed and the time interval between publishing and receiving will cause TOCTTOU problem.
Thus,
the developer indeed should pay additional attention to this two kind of special messages, e.g., checking the original senderâs identity at the MQTT client side when it receives the message, or checking
it at the broker when the messages is leaving (though
I understand that, from your comments, âwillâ and âretainâ are executing decoupled from the publisher and checking their senderâs identity at broker may not be impractical for some reasons as Bob said),
or the
broker could conceivably ask
for reauthorization at publish time.
How
to authorize âwillâ and âretainedâ messages is
outside
of the scope of the MQTT specification. But it would be helpful to remind developers to keep an eye on those special messages
in the
non-normative
section of
specification.
Yan JIA
From: Bird, Rob <rbird@akamai.com>
Sent: Wednesday, June 5, 2019 4:03
To: Clemens Vasters; Jia, Yan; Ken Borgendale
Cc: mqtt-comment@lists.oasis-open.org; Xing, Luyi
Subject: Re: çå: [mqtt-comment] [mqtt-security] Security Suggestions on MQTT Authorization
I agree with Clemens, but for alternate reasons:
-
Nowhere in the MQTT specification is there a notion of âend-to-endâ communications. Messages are sent from clients to servers or from servers to clients per section 1.2. Furthermore, the basic definitions contradict an end-to-end interpretation:
A serverââforwards Application Messages that match Client Subscriptions.â
My interpretation is that this is effectively an informed routing decision, not transparent bridging.
-
Practically, the notion of a âdelivery timeâ ACL implicitly assumes linearized operations on these ACLs across a network of brokers (i.e. all ACL changes must be visible simultaneously on all brokers). This requirement is impossible to meet without impacting
the availability of the system for a system of any size > 1 per even basic application of the CAP theorem (unless we should sacrifice security correctness!). This requirement is in sharp contrast to the need to enforce an ACL at publication time, which
is an inherently available operation by definition. To adopt the definition of end-to-end ACLs is to fundamentally limit the practical applications of the system and absolutely the scale which can be achieved. For example, we are operating hundreds of thousands
of brokers as a single functional service. This would be impossible under the definition suggested.
-
Philosophically, why would a retained message have an âownerâ other than the service? The specification doesnât indicate anything which points in this direction but even a loose interpretation has a hard time justifying as much. We donât, for example, expire
out retained messages when the publisher disconnects or establishes a clean session. Shouldnât these be tied together also based on the logic below?
I do generally agree that best practices should be crisply outlined that help people avoid misinterpretations, such as the ones being made in the original assertions.
Best regards,
Rob
From: Clemens Vasters <clemensv@microsoft.com>
Date: Wednesday, June 5, 2019 at 3:32 AM
To: "Jia, Yan" <yj15@iu.edu>, "Bird, Rob" <rbird@akamai.com>, Ken Borgendale <kwb@us.ibm.com>
Cc: "mqtt-comment@lists.oasis-open.org" <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:
- 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.
- 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:
- 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.
- 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.
- 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:
- 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.
- 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 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
"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