Analyzing the Firmware of a Cheap Video Doorbell

Analyzing the Firmware of a Cheap Video Doorbell

Recently, I was pointed towards an article from Consumer Reports about some cheap video doorbells that had terrible security. The doorbells were all based on boards made by the companies Eken and Tuck but were repackaged and sold under the names of a slew of other companies. The article mentioned the ease of re-pairing the doorbell after installation by an unauthorized individual and the ability to view screenshots from the camera using just the device's serial number. My curiosity was sufficiently piqued, so I decided to buy a couple of these doorbells to see what else was possible.

Initial Investigation

I bought two Aiwit video doorbells off of Amazon that appeared to match the ones from the CR article, one to keep in working condition and the other to tear apart. I usually like to start examining a new device by setting it up the way it is designed to assess the attack surface. After pairing the doorbell to a Wi-Fi access point, I verified that you could indeed put the camera back in pairing mode by simply holding down the doorbell button for about 8 seconds, allowing you to connect it to a different account which confirmed the finding made by CR. With that out of the way, I did a quick TCP port scan and found that there was a telnet port listening but nothing else. I tried connecting to the telnet port to see if I could just log in as the root user, but unfortunately it was password-protected and common default passwords did not seem to work. It was time to break open my spare device.

Inside-Out Analysis

The first thing I noticed as I was cracking open the case was that, while the doorbell takes two 3.7-volt rechargeable batteries, they are wired in parallel such that only one battery is needed to power it. It will only ever charge up to 54% like that, but it still works just fine. Once I finished scratching my head about that little design choice, I removed the inside cover to examine the board within. Inside, there were two boards connected by a series of 16 pins. The smaller of the two boards consisted mainly of some LEDs, the button for the doorbell itself, an antenna, and a speaker. The larger board contained what I was really after - the main CPU (shown in the figure below outlined in red) and a flash memory chip (outlined in yellow).

The main board of the Aiwit doorbell with CPU (red) and flash memory (yellow)

The CPU was an Allwinner V837S. I had never heard of Allwinner, but searching online revealed that they are a manufacturer of Arm-based SoC chips in China that specializes in android tablets, in-vehicle media systems, and video cameras among other things. Unfortunately, the datasheet for this chip was not available anywhere that I could find, but the flash chip was what I was most interested in anyway. The flash was an XMC XM25QH128C 16mb serial flash which was the most likely place to house the device's firmware, and this one did have a readily available datasheet. And even better, the SOP-8 form factor and SPI communication made it ideal for extracting data without the pain of having to desolder the chip from the board and put it in a specialized external reader. To communicate with a chip via SPI, you need at least 5 pins - data in, data out, clock, chip select, and ground, with an optional 6^th pin for voltage if you are providing power for the chip. According to the datasheet, those pins respectively are 5, 2, 6, 1, 4, and 8 for voltage.

Pinout from datasheet of XMC XM25QH128C

Using a simple I/O board that allows communication with a SPI device via USB, such as a Tigard or a Buspirate, it is possible to connect to those pins and dump the entire contents of the chip for analysis. It would also be possible to overwrite the contents of the chip with whatever firmware modifications you would like, provided the write protect pin (pin 3) is not in use, which in this case it is not since the device was also using this chip to store configuration data. After dumping the contents of the chip, I was left with a 16mb file full of binary data and strings. "So, what am I supposed to do now", you ask?

A Sneak Peek at Things to Come

Next week at RSA 2024, Keysight will be unveiling a new feature recently added to the IoT Security Appliance - firmware analysis - and I thought this would be a good opportunity to show off some of its capabilities. After uploading my dump file to the firmware analysis portal, I quickly saw that the device was vulnerable to several critically severe known CVEs and common configuration weaknesses. Most notable among the weaknesses was that there were default password hashes for the root user stored in the firmware.

Screenshot of new firmware analysis functionality

Oddly, there were actually two different hashes being used, one was stored in the /etc/shadow file and the other was stored in the /etc/passwd file, and while they were both for the root user, they were not the same password. I guess Eken runs both their batteries and their passwords in parallel. After using the IoT Security Appliance's firmware analysis functionality to extract and download both password files, I ran them through a password cracking utility and was able to recover them. And sure enough, the one in the /etc/passwd file was a winner!

Root access achieved via the telnet port

IoT Village at RSA 2024

If you would like to hear more about what I found in this device's firmware as well as try your hand at firmware extraction and analysis on an actual device, come and see us in the IoT Village at RSA 2024. We will have a demo set up where you can see for yourself just how easy it is to pull the contents off a chip, turn that data into a readable file structure, and find vulnerabilities that you can then use against a device. And while you're there, you can also attempt to beat our CTF challenge for a chance to win a Riscure training kit to really take your hardware hacking to the next level. Hope to see you there!

Public link

Please use the above public link if you want to share this noodl on another website.