The Internet of Things or IoT is a buzzword that we encounter a lot these days. Smart boxes, light bulbs, thermostats, voice assistants, and smart equipment are gradually entering our homes and industrial environments. As we incorporate more technologies into our life, it is only natural that we find some means to regulate them.
The Message Queuing Telemetry Transport (MQTT) protocol is used to connect and control smart home devices. It works as a messaging protocol and enables communication between devices in an IoT ecosystem.
One question that is always been relevant with IoT is that of security. The prevalent concerns in the data security of IoT applications are due to insecure communications over the internet. To overview and analyze the security status of IoT devices over the internet, we can use tools like Shodan. Shodan is a search engine, which searches the web for internet-connected devices like routers, servers, IoT devices (thermostats, baby monitors) if they are public.
Recently I scanned the web for IoT devices through Shodan, there are nearly 7,50,000 MQTT servers (count varies) publicly visible on the internet due to misconfigured MQTT protocol. This includes more than 32,000 servers that have no password protection, putting these smart homes and businesses using such MQTT servers at risk of data leakage. With this, many servers are affected by vulnerabilities like Denial and Service (DOS) and Remote file execution.
In case of any misconfiguration in the MQTT protocol, cybercriminals can get access to a home, allowing them to learn when their owners are at home, manage entertainment systems, voice assistants, domestic equipment, and even physically open smart doors.
Here, we will discuss various attack scenarios and security considerations for implementing MQTT Protocol.
Architecture
From the above architecture, IoT devices are situated at home to capture various details from sensors. The sensing outputs will be forwarded to the MQTT broker via the gateway to be processed on the cloud and later pushed to the user application.
Nowadays, devices are more vulnerable due to their protocols and their functionalities. According to a recent report by Palo Alto Networks, 83% of the medical imaging devices are running on unsupported operating systems.
Working
MQTT protocol works in the publisher/subscriber model, while devices work as publishers or subscribers.
MQTT Broker simply works as a mediator between Publisher(sensors) and subscriber(mobile application).
The publisher is the device that gathers the information by sensing attributes like humidity, light intensity, heat, motion, moisture, etc. So, publishers provide the sensed input for the application as per the required condition.
When a publisher sends a message, its identity must be verified at the MQTT broker. To verify that it must share the unique client ID, username/password, and client certificate, he received at the beginning. After verification, Its message gets accepted by the MQTT broker.
We have 2 publishers, for example
- Water level sensor: checks if the bathroom/kitchen sink tap is properly closed or not.
- Light intensity: check if the lights of the house are on or off.
After detecting the status, both sensors send digital signals to MQTT Broker.
When a user wants to check home appliances, subscriber requests for the data(light intensity or water level) the request is bypassed through a gateway and gets stored at Broker. The publisher at its timescale publishes the data to the broker. The broker later delivers it to the respective subscriber.
Security Considerations for the components from IoT architecture
1. IoT Device(Publisher client):
The publisher is the prime component of the application. The attacker will get access to the signal information by exploiting the publisher. Using signal information, the attacker can change the working of home devices.
The following security aspects must be considered for Publisher client:
- The client’s name must be unique.
- The username password must be complex.
- Consider client ID prefix restrictions on the client’s name for extra security.
- Use transport encryption of credentials to establish secure connections.
- x509 Client Certificates must be added to the clients.
- Boundaries must be defined on client to set up and access topics, to simplify the architecture.
- The cache, logs stored on the device must be implemented with CIA (Confidentiality, Integrity, Availability) Triad.
- Avoid the use of wildcards like # and + to set the targets.
2. MQTT Broker:
As shown in Shodan report above, there are around 46 MQTT brokers exposed to DOS attacks.
For better security, we bridged our local MQTT Broker to the cloud platform. If an attacker hacks the MQTT Broker, they can see every publisher (sensor) data and analyze the pattern of subscriber requests.
Following are some MQTT Broker security tactics:
- Use Client ID to analyze the topic restrictions, allowed operations.
- Use appropriate access control lists or Role based control access on the client.
- On cloud platform make sure the IAM policies are appropriate.
- Use throttling MQTT clients to avoid overloading of Broker.
- Allocate appropriate maximum message size to avoid attackers blocking bandwidth.
- Choose the inbound/outbound rules for security groups wisely. Confirm that authorized IP ranges can only access the MQTT Broker.
- Use MQTTSA tool to securely implement MQTT Broker.
- Apply appropriate IDS technique to avoid tampering of data.
3. Gateway:
Between the local network and cloud environment, the gateways are present to monitor and filter the requests to MQTT Broker with authority. Eavesdropping gateway traffic can provide sensitive information.
Use following tactics to secure connection.
- Make sure to use appropriate security group settings.
- Restrict required range of IPs for incoming and outgoing application traffic.
- Configure a whitelist and blacklist.
- Use WAF automation to avoid attacks like DOS, SQL injection, etc.
- Implement logging to analyze the API’s.
4. End user and cloud connection:
The connection between the user and cloud shares the finalized result of the application and can be secured as follows:
- The connection between cloud and end user must be secured, encrypted, and implemented with CIA triad.
- Appropriate IAM policy and IoT policies must be applied to the end user.
- Use multi-factor authentication (MFA) for the user account.
- Use SSL/TLS to communicate with cloud resources.
- Use monitoring tools in cloud to set up API and user activity logging.
5. Mobile Device:
The mobile device is the user interface, gets the finalized output about the home environment.
We must check the complete mobile environment for internal and external attack vectors as follows.
- The Wi-Fi connections for the mobile device must use WPA3 protocol.
- The application must be robust with data encryption implementation.
- Use biometrics for application authentication.
- Perform VAPT(Vulnerability Assessment & Penetration Testing) to analyze and secure the mobile application.
Conclusion
With the increased rate of data breaches, incorporating security features in smart home networks becomes an important factor to make the environment more reliable and secure. By implementing CIA (Confidentiality, Integrity, Availability) triad, valid client certificates, tools like MQTTSA, appropriate gateway rules, strong authentication techniques, a good VAPT approach, etc. we can reduce the risk of attacks on IoT Home automation applications.
eInfochips provides end-to-end solutions for Home Automation systems, across multiple segments like lighting, security, cameras, audio/video systems. With strong expertise and in-depth knowledge in connectivity protocols and industry standards, eInfochips provides foundational technologies that help in addressing challenges and enabling a connected home experience. We also provide Cybersecurity services like VAPT and Security Implementation, Assessment Consulting, Managed security services, among others. To know more about our services, talk to our experts.