An issue was discovered in Meatmeet Android Mobile Application 1.1.2.0. An exported activity can be spawned with the mobile application which opens a hidden page. This page, which is not available through the normal flows of the application, contains several devices which can be added to your account, two of which have not been publicly released. As a result of this vulnerability, the attacker can gain insight into unreleased Meatmeet devices.

As UART download mode is still enabled on the ESP32 chip on which the firmware runs, an adversary can dump the flash from the device and retrieve sensitive information such as details about the current and previous Wi-Fi network from the NVS partition. Additionally, this allows the adversary to reflash the device with their own firmware which may contain malicious modifications.

The ESP32 system on a chip (SoC) that powers the Meatmeet Pro was found to have JTAG enabled. By leaving JTAG enabled on an ESP32 in a commercial product an attacker with physical access to the device can connect over this port and reflash the device's firmware with malicious code which will be executed upon running. As a result, the victim will lose access to the functionality of their device and the attack may gain unauthorized access to the victim's Wi-Fi network by re-connecting to the SSID defined in the NVS partition of the device.

The Meatmeet Pro was found to be shipped with hardcoded Wi-Fi credentials in the firmware, for the test network it was developed on. If an attacker retrieved this, and found the physical location of the Wi-Fi network, they could gain unauthorized access to the Wi-Fi network of the vendor. Additionally, if an attacker were located in close physical proximity to the device when it was first set up, they may be able to force the device to auto-connect to an attacker-controlled access point by setting the SSID and password to the same as which was found in the firmware file.

An unauthenticated attacker within proximity of the Meatmeet device can perform an unauthorized Over The Air (OTA) firmware upgrade using Bluetooth Low Energy (BLE), resulting in the firmware on the device being overwritten with the attacker's code. As the device does not perform checks on upgrades, this results in Remote Code Execution (RCE) and the victim losing complete access to the Meatmeet.

The firmware on the basestation of the Meatmeet is not encrypted. An adversary with physical access to the Meatmeet device can disassemble the device, connect over UART, and retrieve the firmware dump for analysis. Within the NVS partition they may discover the credentials of the current and previous Wi-Fi networks. This information could be used to gain unauthorized access to the victim's Wi-Fi network.

The mobile application was found to contain stored credentials for the network it was developed on. If an attacker retrieved this, and found the physical location of the Wi-Fi network, they could gain unauthorized access to the Wi-Fi network of the vendor. Additionally, if an attacker were located in close physical proximity to the device when it was first set up, they may be able to force the device to auto-connect to an attacker-controlled access point by setting the SSID and password to the same as which was found in the firmware file.

The mobile application is configured to allow clear text traffic to all domains and communicates with an API server over HTTP. As a result, an adversary located "upstream" can intercept the traffic, inspect its contents, and modify the requests in transit. TThis may result in a total compromise of the user's account if the attacker intercepts a request with active authentication tokens or cracks the MD5 hash sent on login.

An unauthenticated attacker within proximity of the Meatmeet device can issue several commands over Bluetooth Low Energy (BLE) to these devices which would result in a Denial of Service. These commands include: shutdown, restart, clear config. Clear config would disassociate the current device from its user and would require re-configuration to re-enable the device. As a result, the end user would be unable to receive updates from the Meatmeet base station which communicates with the cloud services until the device had been fixed or turned back on.

The ESP32 system on a chip (SoC) that powers the Meatmeet basestation device was found to lack Secure Boot. The Secure Boot feature ensures that only authenticated software can execute on the device. The Secure Boot process forms a chain of trust by verifying all mutable software entities involved in the Application Startup Flow. As a result, an attacker with physical access to the device can flash modified firmware to the device, resulting in the execution of malicious code upon startup.

Due to a lack of certificate validation, all traffic from the mobile application can be intercepted. As a result, an adversary located "upstream" can decrypt the TLS traffic, inspect its contents, and modify the requests in transit. This may result in a total compromise of the user's account if the attacker intercepts a request with active authentication tokens or cracks the MD5 hash sent on login.

The application uses an insecure hashing algorithm (MD5) to hash passwords. If an attacker obtained a copy of these hashes, either through exploiting cloud services, performing TLS downgrade attacks on the traffic from a mobile device, or through another means, they may be able to crack the hash in a reasonable amount of time and gain unauthorized access to the victim's account.

The mobile application insecurely handles information stored within memory. By performing a memory dump on the application after a user has logged out and terminated it, Wi-Fi credentials sent during the pairing process, JWTs used for authentication, and other sensitive details can be retrieved. As a result, an attacker with physical access to the device of a victim can retrieve this information and gain unauthorized access to their home Wi-Fi network and Meatmeet account.