Continued from Security Camera Hacking …

Overview and Goals

The goal of this phase of my analysis is to learn more about the camera and any vulnerabilities it might have. I will use a traditional dynamic analysis approach, including:

• Recon\Intelligence Gathering
• Threat Modeling
• Vulnerability Analysis & Exploitation

For reference, my standard setup can be found here.

Phase 1 - Recon and Intelligence Gathering

Before I start doing any recon though, I establish a screen session on my attack box in case I get disconnected. It’s frustrating to have your connection die in the middle of a long-running scan and lose all of your progress.

$ screen -S recon

Service Discovery

I like to start with a three-phased approach to port scanning. I first run a fast scan to identify the most common open ports and save the results:

$ nmap -Pn -F -n cam-1-wired -oA fast_scan

The first two are common for IP cameras (HTTP and RTSP), but the third port doesn’t look familiar to me. That one will be interesting to poke at, but my focus is going to start with the meat of the camera: HTTP.

That gives me a quick place to start while my next two longer-running scans are working:

$ nmap -Pn -p- -n cam-1-wired -oA all_tcp_scan

(Okay, 6 seconds wasn’t that long-running but this scan will take much longer when testing entire network segements!)

Now I feed the open ports into an aggressive scan to get versions and run some basic nmap scripts against them:

$ nmap -Pn -A -p80,554,40628,49153,50628,60630 -n cam-1-wired -oA aggressive_scan

The results are interesting. It shows the web server on port 80 is something called ‘Webs’ and the server is displaying ASP pages even though I suspect the camera is running some variant of Linux. This seems like the kind of thing that could be promising, since it is deviating from a standard web stack.

The results for port 554, while unknown to nmap, show that the ‘Webs’ server is requesting credentials before serving up any content.

The results for port 40628 show another web server is running, this time with a server header of ‘gSOAP/2.8’. Running curl against it shows us that the service is not expecting a GET command, but since it appears to be a SOAP web service, it might be expecting a POST.

The OPTIONS command does not yield any other help here:

Nmap has identified the service on port 49153 to be 'Portable SDK for UPnP devices 1.4.3 (Linux 2.6.28; UPnP 1.0)'

A curl against port 50628 returns a redirect from the ‘Webs’ server again to the default.asp page. At this point, I’m not sure how this differs (if at all) from what is running on port 80. Definitely makes me think there’s something different here worth investigating.

The same thing applies for port 60630 and port 554 - everything looks identical at this point.

We could do some more prodding of the UDP ports, but at this point, we seem to have enough to start looking for vulns in the web server.

Generic Scanning

To get an idea of what other pages might be found, I’m going to run a simple Dirb scan. I may need to run this again with a more robust wordlist, but this should be a good start:

$ dirb http://cam-1-wired/ -X .asp /usr/share/dirb/wordlists/big.txt \
  -u admin:ShhS3cr3t -o dirb.txt

It found 14 other pages under the root directory, and 12 under the /en directory:

Phase 2 - Threat Modeling

Now that I know what services are running on this device, I want to lay out a clear plan of attack by identifying where I should focus my time. Since this is my own device on my own network, part of my vulnerability analysis in the next phase will include noisy ‘dumb’ scanners, but I expect the majority of valuable information to come from manually exploring the device for key threat vectors.

Exploring the Web Interface

Upon browsing to the camera on port 80, I am prompted to enter credentials. Good old ‘admin | admin’ works as suggested in the operating manual. I’d much rather see a ‘randomly’ generated password printed on a sticker on the camera, but at least a warning to reset the password is displayed first thing after logging in. This feature needs to be tested further, so I make a note to look at this during the vulnerability analysis phase.

Looking through the different setup options, I come across a default wireless network that the camera can auto-join.

A quick Google search of “wirelessnc SSID” returns a lot of valuable links that help me understand who made the camera and what other models are available from other providers using this same base camera.

There are also some other interesting settings that might be able to be abused. The ability to set a time server and run scheduled tasks are jumping out at me as possibly command injection threat vectors.

Also, I can see where a backup and restore of a running config can be performed, as long as a firmware update. These all sound like great opportunities for ‘rooting’ the camera.

Analyzing the backup file using hexdump, shows the file may be a direct copy of a sys.conf file from the filesystem. It also looks like there are additional settings that were not made available to us from the UI, including one to enable telnet!

Threat Modeling Recap

A recap of the most-promising threat vectors:

• Password Reset
• Default Open SSID
• Can we broadcast this SSID and somehow remotely force a factory reset?
• Known vulnerabilities in the other cameras?
• Time Servers - command injection?
• Task Scheduling
• This might use Cron, and may be an opportunity to perform command injection
• Backup and Restore
• It looks like we can gain a shell to the device by enabling telnet here!
• Firmware Update

Vulnerability Analysis & Exploitation

I’m going to start with attacking the Task Scheduling feature first, since that seems to have potential.

I’ve set one of the tasks to attempt to email me every 15 seconds, but am not trying any attacks yet. At this point, I just want to make sure the job does what I expect and that the network connectivity works. This will make troubleshooting easier when I try an actual attack.

A few seconds later, I get a hit on a netcat listener I set up on my Kali box:

Okay, so the job looks like it does in fact run every 15 seconds and the camera is able to communicate with Kali. Now, let’s see if any of the parameters are being sent directly to the command line without any cleansing or escaping. I’m going to see if I can change the server name to a bash function that will result in the IP of the Kali box, and change the port to 26 to make sure I’m testing the updated job.

Success! At this point, I’ve verified that I can perform OS command injection.

With another quick check, I can see if Telnet can be enabled as proposed in this post since busybox is very frequently used on devices like this one.

Woohoo! We have a working shell on the camera.

This is great, but the main goal is to be able to gain control of the device unauthenticated, so I’ll have to find another vulnerability that allows me to access the task scheduling without credentials or some other issue that lets me get an unauthenticated shell. This new level of access will certainly help with the static analysis though.