Quantcast

Exploiting network surveillance cameras like a Hollywood hacker 5: Messing around with admin’s video feed

Mr. Heffner demonstrates a proof of concept where live video feed on TRENDnet camera gets replaced with a static image through the use of an old vulnerability.

But I wanted to kind of take a step back from that and say, okay, that’s great and all, but what can I do to the camera itself? I’ve got root on the camera, this is awesome. But if you go up to an average admin and say: “I got root on your camera,” – he’s like: “I don’t even know what that means, what the hell are you talking about?”

So I wanted to do something a little more interesting, something that would actually demonstrate what you can do. I wanted to take, say, a video stream that looks like this (see leftmost image below), and instead make it look like this (see middle image below). And this is kind of the classic Hollywood hack, right? You’ve got to get into the facility that’s guarded and it’s got security cameras, so the token hacker of the group has to break into this camera system and make it look like no one’s there, when really they are.

Camera for proof of concept

Camera for proof of concept

After interference

After interference

Actual video feed

Actual video feed

 

Backdoor account

Backdoor account

To demonstrate this and just do a little proof of concept, I picked TRENDnet TV-IP410WN (see rightmost image above). Now, I picked this camera for a couple of reasons. First of all, I can afford it, which is a big plus. But secondly, it has a backdoor account (see right-hand image) that can access certain restricted files (see leftmost image below), which have very obvious command injection bugs (see middle image below), which can be trivially exploited by anyone who can send packets to the camera (see rightmost image below). In other words, it’s the same stuff I’ve been up here talking about the whole time, just on a slightly less expensive camera.

Easy to exploit

Easy to exploit

Command injection bugs

Command injection bugs

Access to restricted files

Access to restricted files

 

Not 0-day

Not 0-day

As it turns out, this particular bug is also not an 0-day (see right-hand image). It was actually first published in 2011. The problem is I didn’t know about it, and neither did anyone else, because when they published this they didn’t mention any specific devices that were affected, they didn’t mention any specific firmware versions that were affected. So if you went and googled for, you know, TV-IP410WN vulnerabilities or exploits, you didn’t find anything.

Prevalence stats

Prevalence stats

And the problem with not providing this information when you do things like vulnerability reports is it’s difficult for other people in the security community to validate your claims, first of all. But it also makes it impossible for vendors and customers to determine what models need to be fixed and whether I’m actually vulnerable or not. So the easiest solution here is to just ignore it and hope it goes away, which is what everyone did. These devices, even though this is a known bug since 2011, have been shipping with this bug ever since.

The images streaming process

The images streaming process

The admin's actual video feed

The admin’s actual video feed

Let’s say, hypothetically, this is our admin’s video feed (see leftmost image to the right). We want to make sure it stays that way. For purposes of demonstration, we’ll assume that the admin is browsing the video feed through the web interface rather than maybe through a custom service or RTP or something like that. On this particular camera, when you’re viewing the video feed through your browser, the process responsible for streaming images to your browser is mjpg.cgi (see image above).

Killing the mjpg.cgi process

Killing the mjpg.cgi process

So, with command injection and the ability to see the output from our commands that we’re injecting, we can run process lists and see what processes are running, and then we can just kill off all the mjpg.cgi processes (see right-hand image). And this actually has the effect of temporarily freezing the admin’s video feed, because his browser is only going to show him whatever the last image it received was and he is no longer getting any more images.

Replacing CGI page with Bash script

Replacing CGI page with Bash script

But we don’t want to stop there because if the admin refreshes his browser or navigates away from the page and comes back, he starts up a new stream and then he’s going to see the live video feed. So, what we also want to do is replace mjpg.cgi, and this does not have to be difficult (see right-hand image). A two-line Bash script will suffice, particularly in a pinch. All you have to do is replace the CGI page on disk with a Bash script that echoes out some basic headers to make the browser happy and then cats out the contents of its static JPG image. Presumably, this JPG is a picture of the empty elevator but, you know, it can be Goatse or whatever you want.
 

Read previous: Exploiting network surveillance cameras like a Hollywood hacker 4: Attack surface analysis of 3S Vision

Read next: Exploiting network surveillance cameras like a Hollywood hacker 6: Demo time

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: