How secure is your "security" camera?

Executive summary

In the beginning of 2020, at my former workplace, I had a chance to take part in an internal pwn2own style event. There were several targets available, but I was interested the most in Accfly Wireless Security camera. Unfortunately I had not been able to finish my research for the actual event, but as there were no other attempts at this device, I kept it going.

The main focus of the research were vulnerabilities that could lead to remote code execution (RCE). This type of vulnerability allows an attacker to take over full control of the device and in case of video camera may result in a complete compromise of the owner's privacy. Unfortunately the device firmware have been found to be riddled with such issues.

First the device does not provide any authentication. As a result, an attacker capable of connecting to it can freely access and reconfigure it. In the simplest form it is possible to continuously restart the device, making it completely unusable for the legitimate user. The scope of this attack is slightly limited as the device is designed to be used within WiFi network, usually behind NAT, thus not directly reachable from the Internet. However, lack of an encryption between the device and its owner's smartphone app, along with use of vendor's server as proxy for the communication, creates an opportunity for a MitM or DNS manipulation attacks, which can break through the WiFi NAT restriction.

Furthermore, the application uses proprietary binary protocol for communication. It has been implemented in a mix of C and C++ and has been found to be full of insecure string handling functions. The main executable contains huge amount of unused code, which suggest that it is reused on other devices. It makes maintenance harder and increases the attack surface. The application does not enable any modern security mechanisms, which would protect it against many common exploitation techniques. In addition, it does not even limit user permissions, running as root - with the highest available privileges.

As a result of this research, following four vulnerabilities has been documented.

• CVE-2020-25782 - unauthenticated stack based buffer overflow in function CNetClientManage::ServerIP_Proto_Set on incoming message handling
• CVE-2020-25783 - unauthenticated heap based buffer overflow in function CNetClientTalk::OprMsg on incoming message handling
• CVE-2020-25784 - unauthenticated stack based buffer overflow in function CNetClientGuard::SubOprMsg on incoming message handling
• CVE-2020-25785 - unauthenticated stack based buffer overflow in function CFtpProtocol::FtpLogin during update procedure

For three of them a RCE exploits were developed, which allows an attacker to gain complete control over the device. However, due to the lack of vendor response to the vulnerability reporting attempts, this repository contains only limited PoC exploits, that just crash the application.

The issues has been found in software version V3.10.73 and verified in software version V4.15.77, the latest one available at the time of this publication (26th of January 2021).

In case of any questions do not hesitate to contact me by email (see git commit) or via Github issues. If you have an IoT device that you think might be interesting to hack, are looking for a Security Researcher or just want to say hi, I am happy to hear from you. You can also buy me a coffee!

Introduction

The target device is a video camera device, which is controlled from the accompanying mobile app. My analysis started with network traffic of the camera and continued into the camera firmware. Custom binary protocol is used for all communication. Commands are either send directly to the mobile device when in the same network or pass through the device manufacturer server. The camera software itself listens on multiple ports TCP (23456,34567) and UDP (34568, 34569). There is no encryption nor authentication for network traffic, which allows for MitM attacks or direct access when the camera is exposed over the network. It seems likely that access to the video stream is possible with no authentication as well, but I have not reverse engineered enough of the proprietary protocol to try this out.

After brief communication overview, the next step was trying to get access to the device firmware. My first attempt was to download it directly by hijacking the device update process, but nothing like this happened in the network traffic. I would have been stuck at this stage, if not for the very needed help from a colleague who extracted the firmware from the flash memory, which allowed me to continue with this research.

The firmware was found to be running Linux on MIPS little-endian CPU. There is exactly one interesting process, called Alloca, which is responsible for video capture and also handles all network communications. Application is created in C++ and contains a lot of code, which is unused on this device. This indicates that the same software is used on different devices as well.

The Leak

Even though this issue has been found last, it is crucial for actual exploitation of most others, because they stem from use of unsafe C-language string functions. While there exists several techniques that can be used for successful code execution in similar scenarios, the application is created in such way, that they are mostly useless. The main problem is that Alloca's code and data are statically allocated on low addresses ( <&nbsp;0x01000000). Thus attempts at reusing existing code (ie. ROP and similar) are not useful as they require the ability to write addresses into the program's memory. Because C-language strings use \x00 as a termination character, and string functions end processing at the first such byte, it is not possible to use more than a single NULL-byte. In addition, stack location is randomized and application is heavily multi-threaded which makes other techniques much less reliable.

This vulnerability is a result of sharing data between multiple threads and insecure use of strcpy. While I have analysed this particular issue for a long time, I have not spotted the chance to use it as a data leak vector until only few weeks before this publication. Interestingly enough, thanks to leaking heap address of C++ object, this vulnerability also allows for remote code execution. However, this attack is not included in this report.

Alloca application can update itself over FTP. This operation can be requested by a server, which also provides necessary username, password and filename. The function which initiates update is shown here:

Three calls to strcpy are obviously insecure and lead to heap overflow, as the ftpUpgrade object is dynamically allocated. Unfortunately the order in which copies are performed and the ftpUpgrade structure layout make it impossible to actually start a thread that will leak data. Taking a closer look, at the incoming packet reveals the following structure:

struct ftp_upgrade_pkt {
	struct pktHeader;
	char username[16];
	char password[16];
	char filename[128];
}

while the ftpUpgrade object looks something like: