Hacking the Meatmeet BBQ Probe — Part 3

In this final part of our blog series we will return to the mobile application in order to gain additional insights into the Bluetooth Low Energy (BLE) communications between the application and the base station, much as we had in part 5 of the Hacking Furbo research. Through this we discovered several GATT characteristics exposed which we leveraged to achieve some interesting results.

Reversing the Communications

The Meatmeet devices facilitate the initial setup of the base station through BLE. Additionally, should you choose, you could set up the device without an account and control it solely over BLE. On the other hand, if you decide to use an account, you are required to set up the device over BLE and pass along Wi-Fi credentials, after which the device associates its Node ID with your Account ID. 

Using the BLE-Connect Python script we wrote, we first scanned the Meatmeet base station to get a list of the UUIDs associated with each of the GATT characteristics. 

With these in tow, we grepped through the decompiled APK to determine how the communications are facilitated. Within the BTConstants Java file we found the following commands defined:

‍

Each of these were associated with a command code and GATT characteristic. Now we could create a Python script based on the commands and attempt to send them ourselves.

We quickly discovered that we could drive someone mad by sending the open_hub_buzzer command repeatedly. 

If we wanted to ruin someone’s day, we could also turn off their Meatmeet device using these exposed characteristics, which would result in their meat being overcooked or god forbid… burnt! We simply can’t imagine a world where anyone would do this… Only the most malicious hacker would dare mess with someone’s meat!

Device Takeover

Another command we had gained access to from this was “remove_config”. Each time it was run against the device, the light on the device would begin blinking as though it were back in the setup mode… 

Sure enough, when we set up a new account and searched for the probe to pair it to our account we were able to. If we were in BLE proximity of any Meatmeet BBQ probes we could clear the configuration which associated it with the victim’s account and then bind it to our own, very easily performing a device takeover!

OTA Updates

When we were grepping through the decompiled APK we found several other files which contained the UUIDs exposed by the device. The most interesting of these was the HubOtaManager Java file. We determined that this was how the mobile application would handle an Over-The-Air (OTA) update when the firmware of the base station required updating. 

Using these control codes, we updated the “Meat-Connect” script we had previously written to include this update method and attempted to force an update over BLE. Based on the smali file, it appeared to be that the commands would have to be sent in the following order:

1. Start OTA
2. Send Firmware
3. End OTA

When reviewing the mobile device traffic we were fortunate to discover a copy of the firmware located on a storage bucket that we could pull down to test whether or not this would work. In order to verify whether this was working correctly we connected to the device over UART to monitor the logs, in the screenshot below you can see the UART logs on the left and the BLE script on the right.

After waiting for around 20 minutes, the upload completed and the device rebooted. Unfortunately, though, it seemed that the firmware “upgrade” failed. 

Our hypothesis was that this was because the MTU, or packet size, sent for the firmware was too large and it wasn’t correctly handling the upgrade. Lowering the MTU would slow the upload but would hopefully succeed. Once we upgraded the script, we tried again. This time it took almost 2 hours to upload. Thankfully, though, our hypothesis was proven correct!

Now that we had confirmed we could upgrade the firmware, without any authorization or authentication, we decided to see what we could do… ESP32s are extremely versatile and have tons of online documentation. After watching Lozaning’s talk on the Toothbrush botnet, we decided to develop our own creation: the BLE BBQ Botnet! 

BLE BBQ Botnet

First we defined a couple of features we wanted our botnet firmware to have. This malicious firmware would scan the local area for Wi-Fi networks (to discover possible access points and aid with future geo-location), base64 encode the SSIDs and send them to a server. Once this was completed, it would fetch a JSON file which acted as a definition for what the device was to do next. 

This definition file would specify the request method (GET or POST), host to request, URL path, and request body if it were a POST. That way we could control each of our bots from a C2 server and point them at any target. We also programmed in a halt command to stop any requests which were in progress and wait for the next target. 

Here is a glimpse at the code:

Once we finished compiling this with the Arduino IDE all that was left was to use our BLE script to upload the firmware to the device. Once it rebooted we received confirmation that the device executed our custom firmware update! Seen below is the first GET request made by the device to our C2 server, validating that it was alive.

The next request we received was the base64 encoded Wi-Fi networks (redacted for privacy). 

And finally, we received the GET request to retrieve the configuration file, to direct the device to our botnet target, and the final request to /validate/c2-success which was dynamically built from that file.

Fully Probed

That concludes our research on the Meatmeet BBQ Probe. In this series we disassembled the devices, reverse engineered its operations, and identified a nice chunk of vulnerabilities; 15 in total. We hope you enjoyed this series as much as the last and we can’t wait to share our next vulnerability research project!

‍