Hi Folks, this is another blog-post on internet of “broken things”. As many of you are familiar with MQTT is one of the most used protocol over the Internet of Things. It’s widely used in private area network – to make communications quick and light – and on public network as well – to build communication channels between sensors end / or servers messages –
MQTT is a machine-to-machine (M2M)/”Internet of Things” connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios. t is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers.
Inspired by Luca Lundgren talk on Defcon 24 titled: “Light Weight Protocol! Serious Equipment! Critical Implications!” I decided to verify myself the state of the art on MQTT implementations.
How MQTT works:
Understanding how MQTT protocol works, invented by Andy Stanford-Clark di IBM and Arlen Nipper Cirrus Link Solutions, is crucial to figure out why poorly authentication implementations will cause serious information disclosure issues.. MQTT stands for Message Queue Telemetry Transport and now is an OASIS standard. It has been designed for sending telemetry data and often runs the challenge against REST HTTP API in modern IoT environments. While is not a common protocol to build communication between clouds (and servers) since AMQP (Advanced Message Queuing Protocol) is much more expressive and performant it is often preferred to to build communication between small objects (things) to small objects (things).
The protocol relays on a central node called “Broker” who is organised in specific programmable topics. Publishers (things) are able to publish informations to specific topics (such as but not limited to: temperature, localization, humidity, etc. ) while subscribers (applications) are able to get data from an interested and explicit topic. The following image represents a general architectural view. It’s clear that a poorly implemented authentication mechanism will let the subscribers free to get the overall published data.
MQTT Architecture Flow
The beauty of unauthenticated MQTT sessions is in the subscriber topic list. Indeed it is able to subscribe to every topic on the selected brokers by simply putting an # as topic even if it does not know the topics list.
Simple Experiment: Let assume we might find some unauthenticated MQTT brokers, what kind of message could be identified ? Hopefully not sensible data. Let’s see it !
Step 1: Discovery.
masscan even if not assiduously upgraded is still one of my best solution to map Internet. I performed a simple massive scan in order to figure out servers with open ports on 1883 (it’s the default MQTT broker port). I know… if a server owns a 1883 open port does not mean it runs a MQTT broker on it.. I totally agree but my point is not a quantitative analysis but a quality analysis, so I do not care about how many real MQTT brokers are out there but if I can find sensible data on one of them.
After few hours thousands of ip populate my “mas1883.xml” file
Step 2: Identification.
Assuming we get thousands of valid IPs running MQTT brokers we need to try to subscribe to all of them and try to subscribe to every topic. Let’s write a quick’n dirty 20 lines of code to make it happens.
Quick’n dirty script automation subscriptions (click to enlarge)
Step 3: Results Analysis
After few running hours, I’ve got back interesting results (they were piped into different files from the launch bash script, so simple I did not even mentioned it). In order to describe the results I’d like to classify them into two simple sections: Note sensible data and Sensible data.
Not sensible data. MQTT messages that does not refer directly to sensible information but still interesting from attackers such as: Temperature, Presence, Lights sensors and commercial. If those informations get to malicious physical attacker’s hands he can figure out if when to physically attack the building since it is easy to detect human presence. The following image shows records belonging to Presence Sensors (PIR), Power Sensors, Humidity Sensors, Temperature Sensors and Noise Sensors.
Anonymised Not Sensible Data (click to enlarge)
For example an attacker could use those data to understand if in a room — of such anonymised building — are people in there (thanks to the value of the PIR sensor) or if someone is close to the room (thanks to noise sensors) or if somebody has been in the room (thanks to delta temperature sensors). Those informations are useful to plan an attack. So even these informations are not sensible per se it is still important to protect them.
Another great example comes from an unauthenticated server hosting Samsung Smartthings devices.
Samsung Smartthings devices data (click to enlarge)
As you might see (enlarging the previous image.. 🙂 we can totally monitor the “building”. We know where sensors have been placed (network_cabinet, master_bedroom, parkers_closet, garage_door, home_assistant) and what value do they have. It is not hard to find an empty room or an empty room_door_path to a target in the building.
Sensibledata. MQTT data that directly refers to private informationsuch as (but not limited to): Text Messages and Phone Geolocalization. The following image shows text messages between two users. The used language is Italian and a close translation could be:
– “Talk to you soon”
Anonymised Private Messages (click to enlarge)
The following image shows private information between pharmaceutical products (please do not ask me more about it… I wont give out much details, the pharmaceutical service has been alerted).
Anonymised Private Message between pharmaceutical services (click to enlarge)
The following image shows an interesting “spying” service (actually it’s owntracks.org) which communicates geo-location over MQTT unauthenticated brokers.
Geo-location tracks (click to enlarge)
Naturally such a private information should not be freely accessible. For example knowing where people are without their permissions is illegal in many states, or reading their application messages without judiciary consent is illegal in many states as well. Naturally the correlation to such information is illegal as well. Unfortunately attackers are everywhere and thanks to internet and telecommunication their malicious activities could have global impacts. Nowadays everybody has got a smart devices, everybody keeps trace of own steps, everybody keeps monitored own heart and everybody put everything on a cloud who does not belong to him. On the other hand applications are not always well protected making data freely available and exposing data owner to incredible indirect risks.
Final Thoughts: Unfortunately Is not possible to stop this process: Tomorrow there will be more smart things that today. Unfortunately is not possible to protect everything: products have to get to the market as quick as possible to gain market. This process is quicker than the ability of the security community to safely test everything. De facto we will continue to use even more “smart things” which will monitor everything about our life.