Team82 Finds Broker Vulnerability

I was strugling on writing this and including it as a writup for RDME because, while it involves MQTT, it is not directly an MQTT vulnerability. None the less, if someone has used MQTT to create a vulnerability, it is probably important to know so we don't repeat the mistake.

I found out about this from Ed over at Low Level, where he reviewed Team82's recent article The Insecure IoT Cloud Strikes Again: RCE on Ruijie Cloud-Connected Devices. I really recommend checking both these sources out, but here is a TLDR.

Getting in the door

Team82 was perfoming vulnerability research on Ruijie networks, and eventually decided to purchase an access point for to use in their research. It seems that they used the firmware from that device, however they also pointed out that Ruijie does provide the firmware online for users to download. After obtaining the firmware, Team82 discovered the firmware was encrypted and utilized a vulnerability in the devices LAN listening services. This netted... this gave them access to the devices filesystem and ultimately lead them to discover a way to decrypt the firmware. After parusing the firmware they discovered a binary named mqlink.elf that handled the devices cloud communication.

How MQTT is involved

The mqlink.elf binary was a client for handling MQTT messaging. Looking further into mqlink.elf they discovered that the device was using a username password authentication strategy where the username is the device's serial number. Okay, pretty intuitive and simple way to generate a username. The password is generated by reversing the device serial number then making a SHA256 hash.

But it gets better...

When subscribing to a topic beginning with cloud/, Ruijie allowed wildcard matching patterns, allowing clients to read from any nested topic. The subsequent messages listed every connected device's serial number.

And more yet...

After examining other topics for messages received by the client, Team82 noticed a payload containing an operating system command. Those same topics also allowed for any clients to publish messages, essentially unsanitized user input, allowing remote code execution from any device.

Summary

• Don't authenticate with the username and password as the same credential.
• When requesting a client to update, don't just send a shell command for the client to execute. One possibility is to use a specific topic that needs a specific keyword, where only and authorized client can publish.