TryHackMe Walthrough — Bugged
In this post I will walk you through the Room Bugged from Try Hack me. This room (Bugged) is designed to be an IoT hacking exercise, the room description reads as follows:
<<John was working on his smart home appliances when he noticed weird traffic going across the network. Can you help him figure out what these weird network communications are?>>
We know that IoT defines a really extensive category of online connected devices. In one or another degree, the chances are that we all have some ioT device in our homes. And this is precisely what makes it so scary.
We know that most of the communications for IoT rely on communication between the machines themselves, the communication from the device to the gateway (this would be the adapter that allows the different devices to connect to the internet), or the connection to the cloud. So most of the IoT protocols that we know will fall into one of these three categories: machine-to-machine, machine-to-gateway, or machine-to-cloud.
Here is a summary of the most common protocols used in IoT:
MQTT (Message Queuing Telemetry Transport) Middleware -> A lightweight protocol that relies on a publish/subscribe model to send or receive messages.
CoAP (Constrained Application Protocol) Middleware -> Translates HTTP communication to a usable communication medium for lightweight devices.
AMQP (Advanced Message Queuing Protocol) Middleware -> Acts as a transactional protocol to receive, queue, and store messages/payloads between devices.
DDS (Data Distribution Service) Middleware -> A scalable protocol that relies on a publish/subscribe model to send or receive messages.
HTTP (Hypertext Transfer Protocol) Device-to-Device -> Used as a communication method from traditional devices to lightweight devices or for large data communication.
WebSocket Device-to-Device-> Relies on a client-server model to send data over a TCP connection.
Once we have a general notion of what do we have and what we are looking for we can get started. We should, obviously start the target machine from hack the box and wait for it to boot. And then connect our attack machine to the VPN, or use the online attack machine.
We will start, as in any other case, by scanning the target IP. In this case a simple service scan did not provide any results for me.Therefore I explicitly scanned all the ports of the machine:
nmap -p 1-65535 -T 500 10.10.169.104
From the scan, we can see that there is a port open that uses TCP and the service running behind it is MQTT (Message Queuing Telemetry Transport), also known as Mosquito.
With that info, the next step is to attempt some communication with the device itself. We can do so using mosquitto (https://mosquitto.org/). If I recall properly I had to install mosquitto the first time I was playing with IoT hacking in Kali, but it might come pre-installed now. If it does not work you have the link above to download and install it.
As we are not sure what we can send to the device we can use a wildcard . According to the MQTT documentation we can use a “#” as wildcard:
So when we send a wildcard we start receiving all the data from the temperature sensor until we receive a weird string.
For some reason the device is sending a string that seems base64 encoded, we can use the terminal or tools like Cyberchef (https://cyberchef.org) to figure out the content of that string:
We can see that there are several commands that can be executed in the device. As well as a couple of the keys that we will need in order to be able to listen or speak with the device.
We can open a listener, by using the same mosquitto subscriber as in the past and passing along the publisher_topic key intercepted in the message above.
In my case that would be something like this:
mosquitto_sub -h 10.10.169.104 -t U4vyqNlQtf/0vozmaZyLT/15H9TF6CHg/pub And at the same time, in another terminal, we can use a mosquitto publisher to send any message and ensure that we can receive the responses from the device:
mosquitto_pub -h 10.10.169.104 -t XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub -m 'hello'We can see that we receive another base 64 message in the subscriber. We can use Cyberchef again in order to decode the message:
We can see that we have not only validated that the subscriber is receiving messages. But we have also discovered what is the proper format for the message that we want to transmit.
So let’s simply format the message with the ID, that we have found in the original encoded message, and access the CMD command that we saw in that same message. In this case the arguments for that message will be the commands that we want to execute inside the CMD.
So in this case and being unaware of what is inside the device I will simply send a list command:
Then we simply send that using the mosquitto publisher and wait for a reply in the subscriber:
osquitto_pub -h 10.10.169.104 -t XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub -m 'eyJpZCI6ICJjZGQxYjFjMC0xYzQwLTRiMGYtOGUyMi02MWIzNTc1NDhiN2QiLCAiY21kIjogIkNNRCIsICJhcmciOiAibHMifQ=='
We can see in the decoded reply that there is a file called flag.txt inside the root folder on the device so we know which command we have to craft next:
We send the command using the publisher and wait for the response from the subscriber as we have done in the past :
mosquitto_pub -h 10.10.169.104 -t XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub -m 'eyJpZCI6ICJjZGQxYjFjMC0xYzQwLTRiMGYtOGUyMi02MWIzNTc1NDhiN2QiLCAiY21kIjogIkNNRCIsICJhcmciOiAiY2F0IGZsYWcudHh0In0='
And just like that we should be able to retrieve the flag.
Hopefully, you have at this point realized how simple can be to hack an IoT device. A simple simile from this exercise is how you can read the config file of a temperature sensor like the one in the example in order to retrieve usernames/ passwords or WiFi passwords.
