Hacking Furbo - A Hardware Research Project: Part 6 – The Finale

Introduction

What a journey it has been so far. Over the last 5 parts of this blog series, we detailed our acquisition, tear down, reverse engineering of the mobile application and devices, as well as a number of vulnerabilities found along the way. Hopefully you’ve enjoyed it just as much as we did. In our final part we will round up the last few vulnerabilities we found as we reviewed the filesystem.

‍

Insecure Storage of Sensitive Information

A common problem on IoT devices is the assumption that no one will get access to a terminal. This is especially true when a device has been locked down quite well—as is the case of the Furbo devices. As a result, sensitive information is often insecurely stored on the devices. For the most part this isn't an issue, they're often correct in their assumption. However, occasionally, devices which are returned to Amazon are re-sold to other consumers, if they are in good enough condition. In fact, one of the Furbo Mini devices we received had been previously owned by someone else.

‍

Wi-Fi Credentials

Seen in the first part of our series (linked here), we were able to retrieve information about the victim's Wi-Fi network including their SSID and password from the decrypted POST request to the firehose logs server. Wi-Fi credentials were also found in the following locations:

/mnt/flash/config.json

/tmp/wpa_supplicant.conf

In both instances they would persist across factory resets which is the main concern. An attacker who received someone else's Furbo, by any means, would be able to extract the SSID and password from these locations. With that, they could use a tool like wigle.net to geo-locate the person, drive to their house, and connect to their Wi-Fi or launch BLE-based attacks against any new Furbo devices they may have.

‍

x-amz-grant-full-control

One of the files we had a keen interest in was the collect_logs.sh bash script which we had identified while reviewing the filesystem. We theorized that it was likely used by support when a device was experiencing problems, it could be triggered remotely to collect a vast array of logging information from the system, compress it into a tar file, and then POST it to an S3 bucket.

In order to do this, the script utilized an older authentication method for sending the data, an x-amz-grant-full-control header. Seen below is a snippet from that script which handles the upload.

We figured that if the Furbo device could use this script, why can’t we? By re-creating what this function was doing and running it locally, we were able to upload whatever we wanted to the S3 bucket. In this case, we just passed it an empty text file.

As we were unable to determine how exactly this data was being processed – whether it was being ingested into another endpoint, or if it were retrieved by a support agent – we refrained from uploading any malicious content.

We also ensured that we only uploaded to our own device's endpoint, though it's likely we could write content anywhere on that S3 bucket. In theory, an attacker could abuse this, with a known device ID, to upload malware or a reverse shell to someone else's endpoint in a tar file and obtain code execution on a support agent's host (if that is where it finally ends up).

As you can see in the previous function, upload_file_to_s3(), the curl command uses the -k argument when it is run. This means that it allows insecure connections and would (in theory) be susceptible to our mitmrouter and certmitm attack we demonstrated in Part 1 of the Hacking Furbo blog series. However, we had yet to figure out a method of triggering this script, without being on the system, all we had were theories. Another catch was the fact that there was another binary located in the same directory, named: collect_logs.

We had to determine two things: which of the two were used and how was it called?

To do this, we turned back to our work we had done reversing the mobile application. In the same Java file we had identified the P2P commands we found the following:

Fairly straightforward if you ask us. It took us a while, however after getting a working Frida script we were able to determine that, unfortunately for us, the collect_logs.sh script was no longer the one being called. Rather, this command invoked the binary which did not suffer from the same TLS downgrade vulnerability.

‍

Debug Log Server

Whilst reviewing the UART logs, after issuing the CPC_UPLOAD_LOGS_REQ, we observed the following POST request which retrieves a pre-signed S3 Bucket URL (the more secure and newer method of handling these requests) for the log upload.

Although this wasn’t, on its face, as exploitable as a TLS downgrade attack, we decided to test how long the device token which is used to authenticate this request remains active. After copying the request details and constructing a curl from them, we waited a week.

Sure enough, a week later our request worked; far longer than is likely to be necessary as these device tokens are only used for a limited number of options. We did not find the true length of time that these remained usable, but we wager that they don’t expire unless they are invalidated by some process, such as disassociating the device from your account.

‍

MQTT

One of the things we observed while reviewing the WireShark logs was constant communication over MQTT. This was an area we didn't immediately investigate because, frankly, it wasn't something we were all too familiar with. However as we were rounding out the project, we decided to dig deeper.

We had spent some time trying to determine what exactly the certificates on the device were used for and as it turned out they were used for authenticating to the MQTT server!

By reading the content of the certificate file, we had an indication that this might be their purpose.

‍

We were able to confirm our suspicions by using them to connect to the MQTT servers with mosquitto_sub.

We quickly realized that the connections that were quickly streaming past our screen were coming from various Furbo devices around the world which were publishing information to the MQTT server. Each of these requests was made to an endpoint, under production or development, which corresponded to the device's MAC address. Within that Publish request was a body that contained the action a device was taking at that very moment. We had just subscribed to the “root” of the MQTT server, allowing us to view each and every device.

In the screenshot above we can see some are running the TossTreat, CollectLog, and GetDeviceInfo actions. We could, theoretically, use this to determine what a device's owner was doing at any given moment if we could determine their MAC address—something which we could absolutely do if we were within BLE range or if we were located upstream and decrypted their POST request to the firehose log server. For example, if someone were tossing a treat, it’s likely they were viewing the camera.

This was all possible because these certificates were the same across all devices and because no access control mechanism had been implemented to prevent us from subscribing to the root of the MQTT server, as we had done above.

We aren't entirely sure how this information is used by Furbo but we imagine it's incorporated into some sort of logging and analytics dashboard which allows them to track devices.  

‍

Conclusion

On June 23rd, 2025 we contacted the Tomofun Security Team to disclose all of the vulnerabilities detailed across these blogs. After some initial hiccups with communication, we were put into contact with the right people who were very happy to have been the target of our endeavours. We then spent the next three months working diligently with their team to provide assistance and guidance where needed to remediate the vulnerabilities. We’d like to thank their team for the open communication, speedy responses, and their efforts! They have done a great job putting together well-secured devices that posed a great challenge at times.

And that is all folks! Again, we thank you for following along and hope you enjoyed this blog series.