BUG reports

[MQTTactic]

Hello,

Dear developers of Emitter, as we study Emitter, we have discovered some new security flaws that would lead to unauthorized access to the topics/channels that are managed by Emitter. The details of these flaws have been sent to you last month but no response. Consequently, we want to check that the email “[email protected]” is correct and that these security flaws are confirmed?
Thanks! If you need any further information, please email me back at [email protected].

[Florimond]

Hello,

We didn't get the email you are referring to. I sent you an email, with @kelindar in CC to ask for more information.

Thanks!

[MQTTactic]

*Hi Florimond,We are a security research group from HUST China, IU USA, and NKU China. Recently we studied the Emitter broker and discovered three new security flaws that would lead to unauthorized access to IoT devices or channels that are managed by Emitter. We elaborate on these problems as follows.Threat modelWe consider the tenant scenario of the shared smart home system (e.g., hotel/Airbnb houses) which uses the MQTT protocol (e.g., Emitter) for IoT devices and user management (or channels in the Emitter). We consider three roles — The home owner (a.k.a., the administrator with secret key in the Emitter) shares smart devices with guests.We assume that the guest (as the adversary) can be granted access to some devices or channels after checking in. The permissions of the guest may be revoked (with `keyban` in the Emitter) and expired after checking out. We consider the administrator and devices are benign, while guests may be malicious and will try to gain unauthorized access to the device as much as possible (overreach or maintain revoked permissions).Problem 1: lack of authorization for the QoS1 message after the guests’ access to the channel is revokedQoS1 is an MQTT feature meaning "At least once delivery" that controls the qualities of service for message delivery. However, the QoS1 message appears in the Emitter as a stored message which can still take effect even after its publisher’s permission has been revoked (with `keyban` in the Emitter). A security risk here is, in the tenant scenario, the malicious guest with “store permission” can leave a malicious QoS1 message which can be triggered after checking out. Thus the guest can perform some malicious actions (e.g., open the smart door) when he checks out with his permission being revoked.Problem 1: proof-of-concept attackAfter checking in, the guest is granted the "write permission" and "store permission" on channel "A". 1. The guest published a QoS1 message (channel="A", payload="").Emitter.publish("", "A", "Hello Emitter!", {Client.with_ttl(604800), Client.with_at_least_once()})2. The privilege of the guest is revoked by the home owner (with `keyban`) when checking out.``` pythondef pubKeyBan(): client = mqtt.Client(client_id="user1123", protocol=mqtt.MQTTv311) #client.username_pw_set(username="user1", password="pass1") client.on_connect = connect_callback_v3 try: conProperty = p.Properties(PacketTypes.PacketTypes.CONNECT) pubProperty = p.Properties(PacketTypes.PacketTypes.PUBLISH) client.connect(host="192.168.179.128", port=8080, keepalive=1000) client.loop_start() while (input() != "xxx"): request = {"secret": "D8qiQ2kOHD5b3xth2_xtOsCs7Mjl2aUZ", "target": "P1-LbZvpKvYk7Fzu1nSXvT3Y20Rl5W09", "banned": False} client.publish(topic="Emitter/keyban/", payload=json.dumps(request), qos=0, retain=True) except Exception as e: print(e) client.disconnect()```3. The unauthorized message will be delivered to the victim users or devices who subscribe to the channel “A” even after the attacker checks out.Problem 2: lack of authorization for the Retained message after the guests’ access to the channel is revokedSimilar to problem 1, the Retained message also appears in the Emitter as a stored message which can still take effect though its publisher’s permission has been revoked.Problem 2: proof-of-concept attackAfter checking in, the guest is granted the "write permission" and "store permission" on channel "A". 1. The guest published a retained message (channel="A", payload="").Emitter.publish("", "A", "Hello Emitter!", {Client.with_ttl(604800), Client.with_retain()})2. The privilege of the adversary is revoked by the home owner (with `keyban`) when checking out.3. The unauthorized message will be delivered to the victim users or devices who subscribe to the channel “A” even after the attacker checks out .Problem 3: Un-updated privilege of the keyUntil now, Emitter can only revoke the permission of the user by disabling the channel with `keyban`. However, this way doesn’t affect already connected users.A security risk here is, the guest can retain the capability to receive the sensitive messages from the channel.Problem 3: proof-of-concept attackAfter checking in, the guest is granted the "read permission" on channel "A". Emitter.keygen({ key: "<your secret key>", channel: "A", type: "r", ttl: 600}); 1. The privilege of the guest is revoked by the home owner (`keyban`) when checking out.2. The guest maliciously keeps the connection between his MQTT client and athe Emitter broker.3. The guest can still receive any messages that are published to channel "A".Possible Defense: add permission check when delivering messages to the channelBefore delivering the message to a channel, the broker should verify whether the user is authorized to access the topic, including both the publisher and the subscribers of the message. Please let us know if you have any questions.Also, please let us know whether our proposed fixes can effectively defeat the attacks.We are always happy to help and discuss with you for the attacks and defense.Regards,Bin*

…

On Tue, Jun 21, 2022 at 2:21 AM Florimond Husquinet < ***@***.***> wrote: Hello, We didn't get the email you are referring to. I sent you an email, with @kelindar <https://github.com/kelindar> in CC to ask for more information. Thanks! — Reply to this email directly, view it on GitHub <#389 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AY7VWNTMLZLKLGGJ4T6KJRLVQCZDVANCNFSM5Y55O2PQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mrbluecoat]

Any update on fixing these public vulnerabilities?