IP cameras in pentesting. Improper use of security cameras

Pentesting reports often include pictures from security cameras controlled by pentesters.

Such pictures look cool, but what is the impact of such actions? Unlike Watchdogs 2, in real life you cannot hack devices on the basis of camera footage. An attacker could probably gain some information by watching employees walking up and down the hallways and then use this information for social engineering… But frankly speaking, it’s all water under the bridge.

From a pentesting perspective, it’s much more interesting to run a shell on a seized camera: every camera has a small computer inside, and access to it can be useful for an attacker.

Case #1: Default password

I have no doubt that you’ve seen similar login pages on cameras’ web interfaces.

And of course, the first thought is to search Google for default logins and passwords.

Imagine that you’re lucky and gained access to the web interface with admin rights. The easiest and fastest thing you can do is check whether you can run SSH or Telnet. In the example below, such a possibility exists.

Let’s try to enable SSH by checking the respective box and clicking “Save”.

Port 22 (TCP) is now available. It’s logical to try to connect to SSH using the same login and password (i.e. credentials for the web interface). Success! Although I must admit, it’s not always the case.

As you can see, this is a BusyBox shell, which significantly limits your options. There are two ways. The first one is to try to escape from BusyBox to a ‘normal’ shell (Bash, Ash, etc.). This approach can potentially bring a greater effect, but it’s too time-consuming for a time-limited pentesting audit.

Alternatively, you can try to use the standard SSH functionality: traffic proxying. In this particular case, you are dealing with a Dropbear SSH server. It’s lightweight and often installed on cameras. For maximum optimization, its traffic proxying functionality should be removed, but many manufacturers leave it, which can be exploited.

To proxy traffic via a camera, let’s try to connect to it over SSH using the following command:

This command deploys on your system a port with SOCKS5 support, and this port uses SSH to proxy your connection via the target device (in this particular case, a camera). Let’s check whether the connection is working properly.

Even though you were unable to circumvent BusyBox limitations, the main goal has been achieved: you are proxying traffic via the camera. In my pentesting studies, I encountered infrastructures having no access restrictions when they are accessed from the camera network, which is very convenient for hackers.

Case #2: Vulnerability in firmware

Using this case as an example, I will show how to get RCE and perform pivoting on a camera in a situation when access initially wasn’t possible.

Initial conditions in this case are more complicated: you encounter a familiar web interface, try default passwords and a number of other popular passwords – but nothing works, and you cannot log into the admin panel. Time to give up? No way! Let’s search Google for registered vulnerabilities (preferably with ready-made exploits).

I managed to find a bug identified as CVE-2021-36260. Important: this is just an example; when you deal with other hardware, you can get any other sorts of bugs. But I was lucky to immediately find a ready-made exploit.

The impact of exploitation is remote code execution (RCE). Exploitation with ready-made exploits is usually performed in one command.

The script successfully executes, and you get a shell on the camera. In this particular case, it’s fully-functional Ash. You further actions depend only on your imagination. For instance, you can upload a C2 agent to gain a foothold and perform pivoting. The simplest attack vector has already been described above: traffic proxying over SSH.

Case #3: Hardcode in firmware

This time, the situation is more interesting. A firmware function will help you proxy traffic.

You log into the camera’s web interface using basic authentication (the default credentials are correct in this case). Then you check whether it’s possible to run SSH or Telnet… and find out that this is impossible.

You scan ports and see that Telnet is available.

You try to connect to it using the login and password for the web interface… with no success. You don’t give up, search Google and see that the manufacturer says: Telnet is only intended for developers; while ordinary users have nothing to do with it. Accordingly, no passwords are available in the public domain. You could sink into despair, but hackers pentesters aren’t ordinary users! You download the firmware from the manufacturer’s website and examine it.

You try to open the firmware using a regular archiver (e.g. 7-Zip)… and succeed! Surprisingly, the firmware is neither protected in any way, nor encrypted, nor employs a sophisticated file system. Everything is simple and accessible.

Congrats! You gained access to the rootfs file system. It contains the /etc directory, which, in turn, contains a file called passwd. You open it and see the hash of the root account.

Comment is needless!

Of course, you try to brute-force this hash. The firmware is pretty old (2019), and the chance to brute-force it is quite high. Looking ahead, I can tell you that everything will work out.

Brute-forcing with hashcat:

Let’s try to connect to Telnet using the brute-forced password.

Success! You managed to connect to the camera and get a fully-functional shell. But unlike SSH, Telnet doesn’t enable you to proxy traffic out-of-the-box. Accordingly, you need something else (e.g. SOCKS proxy or C2).

Let’s try the simplest and most common C2 variant: Metasploit with a Meterpreter payload. I have never encountered antiviruses on cameras; so, no need to take precautions.

Generating payload:

Now you have a binary, but how to upload it to the camera? Netcat is unavailable, curl is unavailable, almost nothing is available… All you can do is send it byte by byte (e.g. using printf). The payload can be generated as follows:

Here I must thank my colleague S0i37 who helped me to automate all this stuff.

The script executes, you copy its output and paste it on the camera. As a result, you gain a ready-to-use executable file.

Don’t forget to grant the uploaded file execution rights prior to running it. Success! The goal is achieved: you have RCE on a camera again. And you already know how to set up a proxy.

Case #4: Firmware modification

One of the most interesting cases involves firmware modification. Imagine that you have access to the camera’s web interface, but there is no way to enable SSH or Telnet. In such a situation, you can try to update camera’s firmware.

So, you’ve got network access to the camera’s web interface. As usual, don’t forget to search Google for default credentials.

You found the credentials and logged into the admin panel. But there is no possibility to enable Telnet or SSH there. However, there is a tab that can be used to update firmware from a file.

Creating firmware from scratch is an extremely time- and labor-consuming job. Therefore, let’s try to tinker with the firmware provided by the manufacturer. You go to the manufacturer’s website, find a suitable file there, download it, and open it using an archiver.

Inside you find an interesting script run.sh. Its name implies that it should be executed at startup. The script contains the string telnetd &, but it’s commented out. Perhaps, if you uncomment it, then Telnet will turn on when the camera starts? Let’s check it out!

The firmware contains the rootfs file system, which, in turn, contains the /etc directory with the passwd file containing the hash of the root account. But this time, there is no need to brute-force anything. Instead, you can simply generate the same hash from the password known to you. Then you substitute the hash and save the file.

Generating hash:

You are almost ready to reflash the firmware. Is it really that simple? Well, almost… You just have to take into account the file system type used in the firmware. In this particular case, it is cramfs. You can easily unpack it using an archiver, but it’s not that easy to pack it back. To perform this operation, you have to install the environment and execute the following command:

Now you are 100% ready to reflash the camera.

You press the “Reflash” button, and the camera stops responding to pings and doesn’t show any signs of life.

But after a minute, it comes to life again, and you can breathe a sigh of relief. Let’s see whether Telnet is up and running. Yes, it is, and you can connect to it using the password substituted into /etc/passwd.

This time, Netcat is available.

Using Netcat, you can easily drop any payload and run it. For instance, Meterpreter that was generated earlier.

You load C2 agent and start it on the camera; now you can launch the proxy. This time, you have to use several commands:

After that, you get fully-functional traffic proxying via the camera and a handy control over it in the form of a C2 agent.

Now that you’ve seized four cameras, an intermediate conclusion can be drawn. You’ve seen how quickly and easily a camera can be hacked used in a pentesting audit to get RCE on it and perform pivoting. The above-described scenarios can be implemented in a real-life project in a short time. Potentially, cameras can be used as footholds or traffic proxying points.

By the way, it’s quite easy to locate cameras by a combination of open TCP ports 80 and 554.

Protection

As you have probably noticed, all above-described cases involved cameras with default passwords. Cases involving manipulations with firmware exploited hardcoded passwords. Accordingly, the following steps can be recommended to protect your cameras:

• change default passwords; this will block almost all potential exploitation vectors;
• update software: manufacturers often release security updates;
• update hardware: if a device is no longer supported, it’s worth replacing it with a modern one;
• perform pentesting audits to detect such flaws in the infrastructures and take timely measures; and 
• isolate the camera segment from the main infrastructure.

In some organizations, cameras are under the jurisdiction of the security department, and the IT or IS departments cannot control and update them directly. In such a case, the only solution is to isolate network segments whose updates are beyond the control of your team.

Conclusions

In this article, I provided several real-life examples demonstrating that cameras can be used to deliver complex attacks against infrastructures. Of course, not all possible scenarios were examined, and each situation is unique; however, now you are familiar with techniques that should be tried first. Should you implement something new and more effective, don’t forget to share your findings in comments.

Good luck!