Craig Heffner, a Vulnerability Analyst with Tactical Network Solutions, presented at Black Hat to cover common security issues in network surveillance cameras.
Hi, I’m Craig Heffner; this talk is, obviously, “Exploiting Surveillance Cameras Like a Hollywood Hacker”. As some of you may or may not know, when my talk was first announced it got a little bit of press, which as a speaker is really cool.The problem is that in order to hype their articles, all of the news stories that covered my talk decided to emphasize the fact that I used to work for a particular three-letter agency who has been in the press quite a bit themselves lately (see right-hand image). And although they couldn’t quite seem to agree what those three letters actually stood for, some of them did go as far as to claim that what I presented at Black Hat was actually work I had done for said agency.
Now, with current events being where they are, this resulted in some very interesting phone calls from my ex-employer (see leftmost image below). Luckily we have people who handle the phones for me and they got yelled at instead of me. But while my initial attempts to kind of assuage their fears didn’t work (see middle image below), I was eventually able to convince them that yes, sometimes people on the Internet are wrong (see rightmost image below).
So, just to be very clear, this talk is not about any work that I’ve ever done for any ex-employer. What this talk is about is work that I do for my current employer. I work as an embedded vulnerability analyst for Tactical Network Solutions. I also teach our Embedded Device Exploitation courses and dabble with wireless hacking from time to time as well.
What I’m going to be talking about today, obviously, is the security in surveillance cameras, or lack thereof as it may be. Back in early 2011 I started taking a look at the security that’s in the firmware actually running on these network-connected surveillance cameras. And since I’m up here talking about it, as you might surmise, I found a lot of interesting things. So I’ll be dropping some 0-days as well as some not so 0-days – and we’ll talk about that when we get to it – but also demonstrating how these vulnerabilities ultimately can be leveraged in true Hollywood style fashion.When I started looking at surveillance cameras I said, well, I’ve looked at a lot of embedded devices before but I haven’t looked at surveillance cameras. So I kind of wanted to start off for something easy, something that would be almost guaranteed to get me a win, so I picked D-Link because they never fail to disappoint. Specifically, I looked at the DCS-7410 (see right-hand image) which at around $900 is one of the more expensive business IP cameras. And like all the cameras that I’m going to be talking about today, they provide an administrative interface as well as access to the video feed through a web server running on the camera, which makes the web server a very attractive target for an attacker. Specifically, this camera uses Lighttpd, which is an open source web server that you find used quite a bit in embedded devices. And in the Lighttpd configuration they set up some very sane and restrictive access rules as to who can get to what through the web server (see right-hand image). You can see here that if you wanted to get to anything in the CGI admin directory, you have to be logged in as an admin. If you want to get to anything in the Video directory, you can be any user but you do have to be authenticated, you do have to be a valid user. So they had entries for every single directory in their web interface. Except one. They did not have an entry for cgi-bin. As it turns out, there’s not much in the cgi-bin directory (see right-hand image). Almost all of the CGI scripts are actually in the CGI directory which is protected. In fact, cgi-bin only has one file in it, and that was rtpd.cgi (see leftmost image below), which is a shell script that can be used to start and stop the Real-time Transport Protocol Daemon. So, for example, if you wanted to stop the RTP Daemon, you would simply send a request to rtpd.cgi, and in your query string you specify ‘action=stop’ to stop the service (see middle image below). The problem is, the way they handle this query string that you provide is they replace all ampersands with spaces and then eval the result, so they’re literally executing in a shell whatever you put in your query string, and not only that – it runs as root. So you can do something like this (see rightmost image above) and it reboots the device. And I actually had a hard time categorizing this because it’s not even command injection, we’re not injecting anything, it’s just running whatever we give it. So I’ve dubbed this the ‘Ron Burgundy’ because it will literally execute whatever you put in your query string (see right-hand image).
Not only will it execute what you put in your query string but it will send you the response back to your browser. So you can do something like this (see leftmost image below), this particular command will echo out the admin password, and you get that sent back to your browser. So you now have the admin password and access to the video feed; you’re not only root, you’re also admin (see middle image below).As it turns out, D-Link, like many vendors, really likes to reuse code, and so this popped up in a lot of their products (see rightmost image above). But it didn’t just affect D-Link, because it was also used by TRENDnet and several other off-brand devices as well. And due to the fact that there’s so much reuse of this code within vendors and throughout different vendors, it turns out there’re quite a few of them already publicly accessible and indexed by Shodan for you (see right-hand image). This vulnerability (see right-hand image) might sound familiar to some people and that’s because it probably is. Of course after my talk, I’d accept it, someone put a CVE out for this bug, so it’s technically not an 0-day anymore. However the CVE only addressed D-Link devices, it did not mention any of the other vendors affected; and the truth is, even if every single vendor put out a firmware update fixing this today, everyone would still be vulnerable, like, three years from now because no one updates firmware or even knows what it is half the time. So I expect this bug, even though it’s technically not an 0-day, to be quite useful for some time to come.