The eufyCam Long-Term Observation

research

The eufyCam home security system by Anker was analyzed repeatedly in a long-term observation over the last two years as one of our researchers bought this product for his home for testing.

During this time various vulnerabilities were identified, which were fixed by the vendor in the meantime. While the vendor claims that privacy is a priority, privacy issues are still a big problem in the firmware. EufyCam advertises local storage of images captured by the security cameras, but the thumbnails of video files are still stored in the cloud. The login credentials for physical shell access to the system were also found and are published to foster further community research.

Introduction

In the summer of 2020, Bernhard Gründling, one of our SEC Consult vulnerability researchers, bought an Anker eufyCam 2 for his home. A main selling point was the vendor's claim of cloud-less storage of footage and operation of the system. Their marketing claims "Privacy is Our Priority" and "Stored locally", "Military-Grade Encryption", according to their website. 

Example image uploaded to eufyCam cloud servers

The system consists of a central hub - the Homebase - that all peripheral devices like cameras, doorbells and sensors connect to. When he tried setting it up in a network without Internet access, it was noticed that it did not work - so he tried again with Internet access. This fostered our curiosity - how does this system work behind the scenes and why would it need access to the Internet if their claim was local storage only?

The first insights were surprising to say the least. We looked at the traffic between the smartphone app and the Homebase and saw that it mainly communicates via the cloud for transmission of commands and video streams. Their claim of local storage is apparently limited to the actual recordings stored on the device. But the thumbnails of the recordings for example, are stored in the AWS cloud.

Code snippet showing a thumbnail being fetched from an S3 bucket
(click to enlarge)

As visible in the screenshot below, such a thumbnail from the image above is fetched from an S3 bucket:

Screenshot showing unencrypted traffic via UDP
(click to enlarge)

Furthermore, lots of unencrypted traffic via UDP was apparent, including the device's username, account ID and the commands sent to the device:

Screenshot showing the HTTP request and response for the eufyCam API call
(click to enlarge)

In the response to one request to the API endpoint "/v1/app/get_hub_list", the following two suspiciously named key-value pairs were apparent:

wipn_enc_dec_key":"ZXSecurity17Cam@
wipn_ndt_aes128key":"ZXSecurity17Cam@


The following screenshot shows the HTTP request/response for this API call.

Close up image of eufyCam hardware showing UART port
Close up image of eufyCam hardware showing UART port
Screenshot of command line during reboot
Screenshot of command line during reboot

These look like hard-coded encryption/decryption keys which are identical for all sold Homebase devices! It is not clear for what these keys are used, as the time available for this research was rather limited.

At this point, the trust in the system plummeted and our researcher's curiosity rose. However, the time resources remained small during the past two years for this device and therefore not much further work went into reverse engineering the system.

Opening the Device

About half a year later, the colleagues of our hardware security laboratory in Vienna and Bernhard opened the device and found a UART port, through which it was possible to read the boot log output of the device and to finally get an "Eufy login" password prompt. However, a login was not possible because of missing credentials. With the help of this blog post, they found a way to boot into a "mini"/recovery while also disabling the annoying watchdog timer which constantly rebooted the device.

Booting into this recovery system required entering "u" at the right moment during system boot.

Inside of the recovery they found the following file: /etc/Wireless/RT2860/RT2860.dat. This configuration file contains lots of interesting data, however because of limited research time it was uncertain if this data would be helpful:

[...]
MeshDefaultkey=0
MeshWEPKEY=
MeshWPAKEY=
MeshId=
WPAPSK=
WPAPSK1=Zjk0YTA3
WPAPSK2=02cd4991
WPAPSK3=
WPAPSK4=
WPAPSK5=
WPAPSK6=
WPAPSK7=
[...]

The recovery also had the following account in the /etc/passwd file:

# cat /etc/passwd 
admin:s/bCpS1AolauU:0:0:Adminstrator:/:/bin/sh

Cracking the password hash, it quickly became clear that the password is "admin". Sadly, this username/password combination did not work in the actual operating system but only in recovery. As the blog post above mentions, the Ethernet port is fully functional while in the recovery system and you can use these credentials to connect via Telnet. Moreover, it was possible to transfer the device's MTD blocks to our computer using TFTP. As binwalk did not manage to extract a usable file system, some manual analysis was conducted. Two years ago our partners at ONEKEY did not have their new firmware extraction tool unblob released but we shortly tested it now and it seems to be able to extract more information than binwalk, including the relevant credential files.

Screenshot referencing a "WPAPSK1" NVRAM entry

Finding the Shell Credentials

In multiple partially extracted MTD blocks, YAFFS binaries can be found. Although they were not extracted by binwalk, some data (e.g. scripts) can be reviewed by running strings on the files or opening them in a hex editor (or using the newly released unblob tool).

So we identified the following part of a password checking script in the extracted file 718D5D at offset 0x01293600:

$ strings 718D5D | grep pass
[...]
Bad password - name/password pair in a Tree Connect or Session Setup are invalid.
pass
        #pass=`nvram_get 2860 Password`
        pass="`nvram_get WPAPSK1`"
        if [ "$pass" == "" ];then
                pass="Anker39#*"
        fi
[...]

 

As visible above, this references a "WPAPSK1" NVRAM entry loaded as "pass" variable. This closes the deal. The previously found WPAPSK1 key from the config file (seemingly stored in NVRAM) is indeed the actual password for the shell login of the operating system. So with the username "eufycamera" and the password "Zjk0YTA3" it is possible to log into the operating system of the Homebase devices via UART and explore it further. If the WPAPSK1 entry was empty, the password Anker39#* would be used. As mentioned above, because of time constraints, no further research could be conducted to identify other security vulnerabilities in the devices.

Conclusion

Now, in 2022 we took another short look at the system. A lot has happened since we last researched the device.

Anker/eufyCam had their first severe security incident where attackers were able to look into other users' camera feeds. After this, a series of CVEs related to Eufy was published by Talos Intelligence and Anker made affirmations to improve the security to prevent something similar from happening again. Looking at the device traffic now, it seems that indeed a lot of improvements were made. The commands are not transmitted unencrypted anymore, and the account identifier and usernames are also encrypted in transit now. This is pleasant news and shows that incidents and community research can really make a difference. 

But sadly, thumbnails of all recorded images still seem to be transferred into AWS, so the device does not fit our requirements for privacy. With this blog post we want to foster further community research which may lead to further interesting findings like the following research SEC Consult has published in the past:

SEC Consult highly recommends to perform a thorough security and privacy review of the Anker eufyCam products by security professionals to identify and resolve potential further security issues.

Affected users around the globe

Originally, we intended to publish this review mid of December. Today we stumbled upon an angry mention of Paul Moore to eufyCam on Twitter. With Blackfriday shopping mania just around the corner, we felt it was urgent to wait no more. Feel free to take a look at his video proof-of concept.

This research has been performed by Bernhard Gründling, Gerhard Hechenberger and Steffen Robertz and published on behalf of the SEC Consult Vulnerability Lab. 

SEC Consult is always searching for talented security professionals to work in our team. More information can be found at: https://www.sec-consult.com/career

Back