Understanding and Mitigating Security Risks of IoT Messaging Protocols
introduce
This is a 2020 S&P paper by Yan Jia, Luyi Xing, Yuhang Mao, Dongfang Zhao, XiaoFeng Wang, Shangru Zhao, and Yuqing Zhang.
overview
This paper is the first to conduct a systematic study on the security of the main IoT cloud platforms and device communication message protocols. The author finds that the message transmission protocols on these cloud platforms are vulnerable to attacks, and exploiting these vulnerabilities will cause serious consequences. To this end, the author proposes the security principle of IoT cloud general message protocol, and proposes and implements an end-to-end protection method.
Pre-knowledge
1. IoT communication based on cloud platform
A cloud-based IoT system usually consists of three parts: cloud (cloud platform in this article), IoT Device, and user's management console (mobile phone application). As depicted in Figure 1, the cloud is a key part of this type of system, which controls the communication between devices and applications, and requires pairing and authentication of devices and applications.
2. MQTT protocol
MQTT is a commonly used publish-subscribe (publish-subscribe) messaging protocol in IoT. It is an application-layer lightweight protocol that can run on resource-constrained devices. The core of the MQTT communication protocol is the MQTT message broker (message broker), as shown in Figure 1.
With the broker as the connection hub, MQTT uses the publish-subscribe model for communication: - The MQTT client (device or application) publishes a message to a specific topic (topic) hosted by the broker - The broker routes the message to another customer who has subscribed to the topic end
The MQTT client sends three basic types of messages to the broker: CONNECT (connection establishment), PUBLISH (publish topic message), SUBSCRIBE (receive subscription message), as shown in Figure 2.
First, an MQTT client, such as a smart air conditioner or an application, sends a CONNECT message to the broker to establish an MQTT session (if the broker accepts the connection). Session and client are uniquely identified by a ClientId field (embedded in the CONNECT message). When publishing state, the broker maintains subscription state for each session and delivers MQTT messages published to topics to its subscribers. Through this channel, an application can run on a device on behalf of its user by publishing recommendations to topics (for example, start or stop) to which the device subscribes. Additionally, a device can periodically update its state information into a topic, such as the current temperature, and all apps subscribing to that topic will receive that information.
3. MQTT protection mechanism
MQTT itself lacks identity authentication and authorization mechanisms. In practice, IoT cloud platforms of different vendors usually implement custom security mechanisms. This article focuses on the authentication and authorization mechanisms of MQTT.
- Client authentication: MQTT can be authenticated in different ways, such as username/password, certificate, etc.
- Client Authorization: The authorization mechanism ensures that each user can only communicate with allowed devices.
4.will message
The will message refers to the message automatically sent by the agent when the client disconnects abnormally. It is used to notify other clients that the client has disconnected. This message can be used to indicate that the client disconnected by error or intentionally. This message can also be used to indicate that the client has stopped working or stopped responding.
5. Keep the message
Retained message (retained message) means that when the MQTT client publishes a message to the corresponding topic, but no client subscribes to the topic (for example, the device is offline), the broker will store the last message of each topic (retained message), when When a client subscribed to this topic comes online, the broker will deliver the retained message to it.
threat model
- Attackers can open IoT platform accounts, collect and analyze network traffic between the platform, devices, and their own applications, but cannot eavesdrop on traffic between other user devices and applications.
- Device sharing. An attacker may have temporary access to the device. An example would be a resort granting temporary access to a device to a visitor.
MQTT IoT communication security analysis
The author divides MQTT communication into four entities: identifier, message, topic and session (session), and studies and analyzes the security of MQTT protocol respectively. The following describes the problems found by the author during the analysis of the MQTT protocol.
Unauthorized MQTT message
This scenario is when the user is trusted with temporary access to the device, but cannot obtain any information outside of other devices.
Unauthorized Will message
The Will message is set in advance by the client and can contain control commands or text. Once the client disconnects unexpectedly (without sending a DISCONNECT message), the broker will publish a Will message to all clients subscribed to the topic to make them take corresponding actions.
This exception handling mechanism can be problematic in the case of device access transfers. An attacker (former user) can register a Will message to trigger the message when he does not have access rights to achieve the attack. The author used iRobot Roomba 690 to implement PoC utilizing Will message on AWS IoT cloud, as shown in Figure 3. Cloud platforms such as IBM, Baidu, and Tuya Smart have the same problems as AWS.
Unauthorized retained message
An attacker (former user) can publish a reserved message to a topic subscribed to by the device while having access to the device, and then wait for the device to come online and receive reserved instructions when losing the permission to carry out the attack. The authors found that Baidu IoT Cloud and Eclipse Mosquitto (an open-source MQTT broker) are vulnerable to such attacks.
MQTT session management failure
MQTT communication is carried out by establishing a session between the client and the broker. The session is associated with the MQTT client state. Therefore, when the client state changes (such as revoking authorization), its established session state must also be updated.
Session subscription state not updated
The author found that in the MQTT protocol specification, there are no regulations and instructions on updating the session state when the client state changes. This will lead to if the attacker (former user) establishes a session to subscribe to the topic, even if his permission is revoked later to prevent him from subscribing to the topic, the proxy will still pass the message to the attacker (former user) through the established session, making the attack The user can receive the current user's message. The author confirmed this insecure session state management on many IoT platforms (IBM, Tuya, Alibaba, Baidu).
Session lifecycle state not updated
The MQTT client can be a device or a user. Generally, the IoT cloud platform regards devices as resources to be accessed, and users as subjects that need to be authenticated and authorized. The authors found this discrepancy to be a security risk. When a device is reset by a new user, the previous user's access to the device is removed, but the device's access to the MQTT broker topic cannot be revoked.
If an attacker (former user) obtains the device identity credentials (traffic analysis or reverse engineering) during the permission period, even if the new user resets the device, the attacker can use the device credentials to masquerade as the device and publish false messages to the corresponding topic. Some IoT platforms have taken measures to prevent this attack by forcing devices to expire when the user changes them.
But the authors found that if an attacker establishes a session before the credentials expire and keeps the session online, he can still forge device messages through the session even though the credentials expire. This is because the platform does not update the established MQTT session status when the device is reset. The author confirmed the problem in IBM, Tuya, Alibaba, Baidu and other platforms.
Unauthenticated MQTT identity
An IoT platform account can have multiple devices, and each device has its own identity, ClientId, and one device can be shared among multiple accounts. The authors point out that if this relationship is not securely managed, it will expose the MQTT communication to attacks.
client id hijacking
The MQTT protocol requires the agent to disconnect from the original client when it finds a new client with the same ClientId, which will cause a DDoS attack. The authors also found that in this case, the MQTT broker and client were able to reload the previous session, restoring the previous state.
The attacker can have a legitimate platform account, that is, be able to establish an MQTT connection with the platform. If the platform cannot correctly handle the security access mechanism of the platform account and device identity, the attacker can use the above mechanism to restore the session through the known ClientId and Steal information. For example, if the attacker uses his platform identity and the ClientId of the victim device obtained by some means to establish an MQTT connection on the platform, even if the attacker does not subscribe to the topic of the device, he can still receive messages from the device.
An attacker can obtain ClientId in two ways:
- Guess: ClientId is a sequence with specific semantics and format. Since the MQTT specification only requires the uniqueness of ClientId, most IoT cloud platforms recommend using ClientIds that are easy to manage, such as MAC addresses and incrementally assigned serial numbers. An attacker can perform an exhaustive search starting with a known ClientId.
- Shared device: If the attacker can access the device for a short period of time, the ClientId of the device will be exposed to the attacker forever.
The author used an iRobot Roomba 690 to carry out the attack on the AWS IoT cloud platform. By searching the sequence near the device token of the device, a group of possible iRobot product device ClientIds are speculated, and the results show that this can cause large-scale DDoS attacks. The author found such problems on AWS, Baidu IoT Cloud, IBM and other platforms.
Authorization of MQTT Topics
The MQTT topic structure is similar to hierarchical file paths, such as /doorlock/[device ID]/status. The authors found that the presence of incorrect descriptions of MQTT topics on IoT cloud platforms could lead to granting attackers excessive access rights.
MQTT Topic insecure shortcut
Since IoT platforms may need to manage thousands of devices and users, the author found that many IoT cloud platforms use shortcuts for authorization.
If an attacker can gain access to a target device for a short period of time, he can easily learn about the subject of that device (traffic analysis). In addition, some vendors use device unique identifiers for their MQTT topics, such as device serial number or MAC, which can be subjected to brute force attacks, so that attackers can still subscribe to the topic of the device and steal private information.
The author uses HONYAR Smart Plug IHC8340AL to carry out the attack. By analyzing the traffic between the Suning Smart Living mobile application and the cloud platform, the MQTT topic can be found. The author successfully subscribed to all the topics of the device using the script, and then even if the device is reset to use another account, the attack can also be carried out
Expression syntax for MQTT
A device may have many associated topics (for example, /deviceID/cmd is used to pass commands, /deviceID/status is used to update status), for ease of use, cloud platforms usually allow users to use wildcards # or + to subscribe to the device or even multiple Multiple themes for one device, which poses a great security risk.
On AWS, even if a user is prohibited from accessing a topic like deviceId/cmd, if an attacker can subscribe to deviceId/#, which represents all MQTT topics under deviceId on the broker, then the attacker can still access those protected topics (deviceId /cmd), causing the policy to be bypassed. A similar and more serious problem exists on the Suning Cloud platform, where any user can subscribe to the # topic, which represents all MQTT topics on the broker.
The author conducted an experiment, established MQTT communication with Suning Smart Living cloud platform through a script and passed the verification, and successfully subscribed to the #topic (a common topic on the platform). Through subscription, the author has received a large amount of private information from smart locks, cameras, surveillance, etc., and can even use this to infer family/cohabitation relationships, behavior habits, etc. In addition, the leaked information also includes the ClientId of all devices under the cloud, and the attacker can conduct a DoS attack to take any user device offline.
Measurement
The author evaluates the MQTT communication of the current popular IoT cloud platform, and the results are shown in Table 1.
In addition, the authors conducted experiments to evaluate the impact of these issues.
By subscribing to the general # topic of Suning agent, the attacker can collect messages of all devices under the cloud. The author collected a total of 800 million real MQTT messages within three weeks, including a large amount of device information (device ID, type, status, location, collected information, etc.) and user information (PII). The authors combined this information for longitudinal analysis, enabling inferences about users' private habits, behaviors, or relationships.