Responsible Disclosure: Ouvis C2 HD Security Camera

As a part of our ongoing IoT vulnerability research project, one of the recently tested devices included the Ouvis C2 HD Wireless Security Camera. This is a wireless camera which includes Android, iOS and browser-based remote viewing.

Open Telnet Access Vulnerability

After connecting an IoT device to my test network, my first task always involves a port scan to identify open services on the device.

A port scan of the Ouvis camera showed open Telnet on TCP/23 and an HTTP web server running on TCP/81 – a non-standard port for web servers. I immediately noted the open Telnet access as a potential security vulnerability, since Telnet offers no encryption. There is no reason for the IoT devices to allow Telnet-based management access, especially when more secure options like SSH exist. Furthermore, in a consumer IoT device there is generally no need to allow command-line management access at all. Malicious applications like the Mirai botnet thrive because of open Telnet access combined with weak default passphrases.

After detecting an open Telnet port, a penetration (pen) tester typically tries to obtain privileged command line access to the device through Telnet. To gain such access, the pen tester needs to figure out the username and password for the 'root' account on the service. Since these CLI interfaces are often left for diagnostic purposes, manufacturers don't share credentials for them, and don't necessarily intend them for the customer's use.

Brute forcing to the rescue. In respect to authentication, a brute force attack is the act of rapidly trying different username and password combinations against a login. Using an application called THC Hydra, I attempted to brute force the credentials for the device. To speed up the attack, I configured Hydra to use a wordlist containing thousands of common passphrases. After several hours of trying different username and password combinations, Hydra was unable to find valid credentials.

After failing to brute force valid credentials for telnet access, I was forced to find other methods for obtaining root access. The next step involved disassembling the camera in search of console serial access. Luckily, one of the circuit boards in the camera had UART pads.

After soldering a USB-TTY to UART cable to the empty pads, I accessed the camera’s serial console with a baud rate of 115200.

After halting the boot process, I modified the U-Boot configuration to initialize a shell after mounting the filesystem.

I was finally greeted with a command line shell for the camera. Once connected, I checked /etc/passwd for any user accounts and found the root account and its hashed password.

Access to a password hash allows for faster, more efficient offline password cracking. In one last attempt to obtain the root password, I fed the password file through hashcat, a popular hash cracking application. After several days of cracking, attempting every possible combination up to and including eight characters, hashcat failed to yield any results. I still consider this open Telnet access a weakness, especially since the device includes a hard-coded root password (which some might call a backdoor account). The good news is the root password has withstood several significant cracking attempts so far. It seems the device manufacturer was at least conscious enough to use a strong password. That said, if anyone ever recovers this password, it could provide a backdoor to all these devices. In fact, I have since correlated with other researchers' analysis, and have confirmed that all these Ouvis cameras, along with several cameras under a different brand, share the same root password hash. If the password ever leaks, it will provide attackers with unrestricted access to these devices.

Authenticated Remote Code Execution Vulnerability

In auditing IoT devices like webcams, I frequently find web application flaws in web management portals due to un-sanitized user inputs. After finding a remote code execution vulnerability in one of the web management pages of a similar IoT camera, I checked the same location (FTP backup settings) for this Ouvis camera, and found the exact same vulnerability.

A packet capture of DNS traffic from the camera showed an attempted name resolution for ‘rce.bad’, confirming the remote code execution vulnerability.

As it turned out, the Common Gateway Interface (CGI) handler for FTP configuration (set_ftp.cgi) did not sanitize the user input before saving it to an ftp upload script located at /tmp/ftpupload.sh. The camera then runs this script as a privileged user, which in turn executes any command an attacker injects into this un-sanitized input (in our example, the ping command).

Conclusion

After confirming both vulnerabilities, I immediately wrote and submitted a report to Ouvis via their support contact. Ouvis did not respond to my contact attempts over a 90 day period.

After 60 days, a separate researcher disclosed the same, and further vulnerabilities in a series of cameras appearing to be manufactured by the same OEM supplier. Because the Ouvis C2 was not present in Pierre Kim’s list of affected models, I continued the originally planned 90 day disclosure period.  After further unanswered contact attempts over a 90+ day period, I am releasing this disclosure publicly.

Timeline

• 2 January 2017 - Vulnerabilities discovered
• 4 January 2017 - Reported to manufacturer
• 3 February 2017 – Manufacturer contacted a second time
• 6 March 2017 – Manufacturer informed if imminent public disclosure
• 8 March 2017 – Similar vulnerabilities zero-day’d by Pierre Kim
• 3 April 2017 – Manufacturer contacted a final time
• 9 May 2017 – Public Disclosure