[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
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. 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>
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>
I agree with Clemens, but for alternate reasons:
A serverââforwards Application Messages that match Client Subscriptions.â My interpretation is that this is effectively an informed routing decision, not transparent bridging.
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>
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:
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 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>
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>
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>
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).
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
Yan JIA åää: Clemens Vasters <clemensv@microsoft.com>
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>
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>
If I may:
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 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.
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
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>
Wouldnât this then be true for any delivery delay+ACL change race condition? For example:
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>
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 åää: Ken Borgendale <kwb@us.ibm.com>
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]