Your broker is a pimp…
The year was 1999; what an awesome year!! The Y2K bug made us all rich (or poor)… we all started to see dead people using our Sixth Sense … and primary coloured drugs became all the rage as we followed the white rabbit into The Matrix. On top of all that excitement, a couple of very cool cats, Andy Stanford-Clark and Arlen Nipper, partied “like it’s 1999” and authored a protocol which would change the way we interact with ‘things’ some 18 years later!
MQTT, or Message Queue Telemetry Transport, is a lightweight messaging protocol which uses a publish/subscribe methodology to transport messages between machines. Basically, MQTT allows a device (publisher), such as a sensor, to send data to a server (broker). This broker can be queried by clients (subscribers) who have an interest in the particular topic which includes the data sent by the sensor. The following diagram from HiveMQ demonstrates this perfectly.
Originally, MQTT was a solution to a problem we were having at the time.. How do we connect oil pipelines over low bandwidth satellite connections? Thankfully, with 18 years of superior technological advancement under our belt, we have been able to improve our way of life, and in turn improve the way we can use this protocol. In the great year of the Internet of Things, our unique way of thinking has enabled us to widely embrace MQTT and we can now connect much more important things together instead of silly oil pipelines. We now have the power to connect our toilets, our child’s toys, our fridges, our critical infrastructure, and even our sex toys together!
Here’s how it works. When we connect to a broker, the MQTT protocol is nice enough to give us a connect acknowledgement flag, or a CONNACK. This flag lets us know if the connection went okay, or if there was a problem. The following table shows the codes:
If we get a code 0, we’re in a happy place, and we can view any subscriptions we have access to. Easy right?
Sadly however, with greatness and ease also comes a negative side. 1999 is calling, and it wants it’s insecurity back. In all the excitement of showing everyone on the Internet just how big or impressive our ‘things’ are, we have forgotten about the security component of the MQTT protocol, and our brokers have now become pimps, sharing our things with everyone and anything that wants to play with them.
Let’s take a real world look into this. We know that if we get a code 0 it is a successful connection, so let’s take a quick squiz at Shodan using the query mqtt connection code 0 port:”1883″ to see how many pimps we might be able to make a deal with….
Roughly 23,000 hits with code 0! Code 0! … as in broker pimps which you do not have to authenticate with in order to have a good time! Sure.. some of these will be honeypots, but even then, the number of hits on Shodan is a case of far too many people exposing their things out in public. Who cares, MQTT is read only right? Um.. wrong.. very wrong. If your permissions are not set correctly, not only can you subscribe/query data, you can also publish.
Nice… we can see some topics such as home/carport/light 0 and openhab/family/lamp OFF. So what would happen if we combined the power of python and paho, and published something like this?
Correct! Gold star for you! If the appropriate authentication or other security methods are not configured we could publish a message which would turn on the carport light. Nice!
Hmmm.. Have you ever been curious where you left all those big ships when you finished playing in the bath? You have been? Sweet! … MQTT can help you with that!
Oh now I remember where I left it… it’s in Amsterdam!
Ok. One more example before I get a bit more serious. Let’s spin the magic MQTT wheel and see what we find next…..
A car of some sort.. nice. Oh, and it updates it’s information every second, including it’s long/lat.
There are vast amounts of shits and giggles available to us if we are bored and just want to have a look at what things people are stupid enough to put into the public realm with MQTT. However, all jokes aside, there is a serious and dark side to not securing your MQTT deployment. During my research, I identified a stupendous amount of MQTT brokers with topics which include a string ‘owntracks’. A quick google tells us that “OwnTracks allows you to keep track of your own location”. Hmmm… it was about then that my spidey sensors were going off. Why on earth would you keep track of your, or other people’s locations and not use some form of authentication and encryption??? Looking a bit deeper through OwnTracks’ documentation shows us that OwnTracks in fact supports authentication methods and encryption, however it is at the user’s discretion as to whether they enforce it on their own pimp brokers! W-T-F!? That situation is always going to end in disaster.. generally user’s are stupid, and let’s be honest, security is hard.
Let me give you an example of why I think it’s very dangerous to not take MQTT security seriously.
Ok. So… what we have here is an implementation of location tracking which has been set up for two mobile phones in a family. One belongs to a father, the other to who I assume is his daughter. This MQTT service continually updates the broker with the current location of the person’s mobile phone, as well as sends some encoded string which we obviously know is base64. Decoding the base64 encoded ‘face’ string gives us a jpeg image, which is that of the victim’s daughter, which I have obfuscated for obvious reasons.
With the continuous updating of the mobile phones location, it was possible to track over a period of time the movements of the person (I have not included the mapped data in the post to protect the person).
So what can you do to make sure your broker does not become a pimp, and that your ‘things’ aren’t exposed to the public? Here’s some quick steps…
1. Ask yourself whether you really need to put your ‘things’ on the Internet. Seriously… do you?
If you answered yes for some reason, continue with:
2. Turn off anonymous connections in the broker configuration.
3. Require a valid username and password from a client before allowing a connection.
4. Require transport encryption with TLS and x509 certificates.
5. Create access permissions which limit which topics an authenticated client can subscribe or publish to.
One final point…. always practice safe MQTT, and remember, friends don’t let other friends share their MQTT publish credentials with pimp brokers.
