Modux was recently commissioned by Which? to perform a security assessment of the Enabot Ebo Air, a small robotic device which moves around your home and lets you interact with pets and family remotely. We tested the robot to see how it would hold up against a cyber attack and found some serious security issues that could pose direct risks to the privacy of the end-user.
About the Enabot Ebo
The Enabot Air is billed as a smart companion robot that keeps your family company while you are away. You can chat through the robot; it can take photos and videos as well as recognise faces. By automatically detecting motion, the robot has the capability to act as a mobile security camera that the user can steer around the house via Wi-Fi. It’s controlled remotely through the smartphone app, where the user can view Ebo’s on-board camera.
Security Assessment
We wanted to understand any potential risks within the device itself and within the control applications for Android and iOS mobile devices. During our testing, amongst other issues, we uncovered two serious security flaws:
1. Shared password
The most severe security issue we found concerned the use of a shared password for the system administrator (root) user account. The Enabot Ebo robot comes pre-configured with a hardcoded system administrator password that is weak and shared across all devices. Anyone who knows this password and is suitably positioned on a users’ network could potentially connect to the robot over SSH and gain full administrative permissions. An attacker could then gain access to all underlying hardware functionality, including the camera or microphone.
Our team of testers found it was even possible to access the onboard SD card within the device and download photos and videos held on the card. Because of the shared password flaw, it would also be possible for a hacker to access logs on the device that disclosed the password of the Wi-Fi networks.
With sufficient time spent reverse engineering the device firmware in use, it’s possible that a skilled individual could directly issue commands to the camera, microphone, speaker and motors -effectively gaining remote control of the device.
To discover this password, it was necessary to intercept a firmware update intended for the device and unpack it, revealing the protected (hashed) password. Cryptographic cracking attacks were then undertaken against this password hash until the cleartext version of the password was recovered.
While local network connectivity is required for initial access to the Enabot robot, our testers found that the onboard software provided could be used to establish a remote connection back to an external server via the Internet. This connection remains as long as the device does not run out of battery, even when the device is in ‘sleep’ mode. This could be used to set up a remote link to control the device over the Internet without the owner’s knowledge.
The end risk posed by this issue is complex, currently a degree of skill is required to obtain the password and determine the methods to gain access to the underlying SD card and to establish a remote external connection. A high level of skill would be required to reverse engineer the connections to the hardware in order to gain complete remote control of the device. However, due to the nature of the device and the attacks, if the password itself and the methods used were made public, the barrier to exploitation would drop considerably.
2. Missing secure-delete functionality
The second issue we identified was the lack of secure-delete functionality, which could potentially disclose information from the previous owner if the robot was resold.
We found that the robot did not effectively perform a secure deletion of data when a factory reset was initiated, leaving behind artifacts from previous uses of the device, including cleartext Wi-Fi passwords and session tokens from the previous owner.
These logs could be accessed via the hardcoded password discussed above. If someone were to buy one of these devices pre-owned, with relatively little technical skill, they could retrieve this sensitive information from the previous owner - allowing access to their enabot account or home WiFi network.
Our recommendations to fix the security issues
Modux worked with Which? to disclose the two issues to the manufacturer who have since addressed the risks and fixed the vulnerabilities.
To resolve the shared password issue, we recommended that the manufacturer should disable the remote access SSH service, since it does not appear to be in use during normal operation of the device. This was enacted by the manufacturer and confirmed by Modux.
We also recommended that the password for the system administrator account should be removed entirely or set to a unique value. If the password is required, it could either be included within the packaging of each device, in a similar manner to passwords issued with home routers, or could be set via the mobile application upon initial configuration.
To remediate the risk associated with the lack of secure-delete functionality, we recommended that a factory reset of the device should employ secure deletion functionality, overwriting all sensitive data multiple times to prevent its retrieval by unauthorised users.
Comments