Own your own home - Home camera takeover by Michael Kubiaczyk

Blog post 16 January 2019, by Michael Kubiaczyk, principal security consultant at Secura
I recently purchased a home in the Netherlands, and one of the features that appealed to me the most was the set of cameras mounted near the front and back doors of the house. While my job typically focuses on technical security, usually that of websites, I find the physical security of my own home to be a very important topic as well! While speaking with the previous owner during one of our visits to the house before we bought it, he showed off a really nice feature of the system: he was able to pull up the camera feeds on his phone. Quite a nice feature, but also scary, since everyone has read about webcams which are just directly connected to the internet. Anybody could be watching!

Of course, when I moved in, the first thing I did was to disconnect the whole thing, since I didn't have time to figure it out. After settling in, I was able to investigate how this was all configured. I started where all cables start, in the electrical cabinet, where I could see a peculiar device with multiple network cables attached, mounted to the wall (outlined in red below):

electrical cabinet

It wasn't plugged into anything -- I didn't have any internet at first anyway -- but I could see that there were multiple cables coming in from around the house, and one cable hanging down to where it must have been connected previously. I grabbed my laptop and connected it directly to the cable coming from the device. Once connected, I could listen to whatever traffic was trying to go out that line, which I did with the tcpdump command.

tcpdump command 1

From this traffic, I could see two interesting addresses:

  1. 192.168.1.10 -- the address of the device.
  2. 192.168.1.254 -- the address of another device, which the first device is trying to find, and is asking on the network if anyone has seen it.

This is important information because when I just plugged the network cable into my laptop, my laptop wasn't assigned an IP address -- normally a DHCP server would issue one for me. In this case, my laptop is replacing the spot on the network where a DHCP server (or some other network infrastructure) would normally be. So, in order to connect to the target device (at 192.168.1.10), I need to have a route to it -- meaning that my own laptop needs an IP address which is reachable from that other device's IP address. I guessed that the next IP one over would work, and set my own IP address:

$ sudo ifconfig eth0 192.168.1.9 netmask 255.255.255.0 up

The netmask was an informed guess and is likely to work on most home networks (in the 192.168.x.y range). Once this was done, I was able to run ping 192.168.1.10 and received replies. Great! Now to see what is going on here.

Since we're now able to communicate with the target, we can check what services it has running on what ports. To do so, we run the tool nmap:

Since we're now able to communicate with the target, we can check what services it has running on what ports. To do so, we run the tool nmap: $ nmap --top-ports 1000 192.168.1.10

What this command does is it checks the target IP (192.168.1.10, the device) on each of the ports specified in the command, to see if there's anything running (and responding) on each port. In this case, I ran the command with --top-ports 1000 -- nmap contains a list of the most commonly seen ports, and for this command picked the top 1000 of those ports. You would expect a webserver to be running on ports 80 or 443, but some devices (like Synology network storage) use weird ports like 5000, so you can increase the number of ports scanned (or scan every possible port) but this will increase the time the scan takes.

In the response above, we see that ports 80 (HTTP -- meaning website), 554, 8000, and 9010 are in use by various services. Since my goal for now is just to access whatever administrative interface exists, I stick to the port 80 service, and don't bother much with the others. I load up the url http://192.168.1.10/ in a browser and see the following:

login http://192.168.1.10/

So it's a plain login page. I try logging in with some guesses (admin/admin, admin/hikvision, some guesses based on the previous owner's name) but no joy. Still, I made some progress, and now know that it's a Hikvision-brand recording device/switch that all the cameras are plugged into. Googling this brand shows that they take security fairly seriously -- there are no default passwords for the device, no way to reset it to blank. The only way to reset the password is to install a tech support tool, get the serial number of the device along with some other information, mail it to the tech support email, and wait for a response. So I install their support tool to get the required information, and fire off an email to tech support.

The site says this could take a few hours, but I'm not holding my breath, so in the meantime I poke around on the internet to see what information is available for this brand. I find that, for some older versions, there was a publicly-disclosed buffer overflow vulnerability, and someone wrote a password-reset tool that abuses this vulnerability to reset the password. Pretty neat, but sadly it doesn't work for me, as I seem to have a slightly newer version.

So, I disconnect my laptop from the outgoing port on the Hikvision NVR (Network Video Recorder) and instead plug it into one of the other ports, where the cameras are plugged in. Once again, I have no IP address initially, so I listen in to whatever traffic is flowing through the NVR:

tcpdump 2

On the inside of the NVR network, I can see the following devices trying to communicate:

  1. 192.168.254.1
  2. 192.168.254.4
  3. 192.168.254.6
  4. 192.168.254.7

So the inside of the NVR network is configured to use a network range like 192.168.254.0/24. Once again, I set my own IP address to match -- this time I pick 192.168.254.5 since it's in the middle, between some IPs that I know are in use. With that done I can ping the devices, so once again I run a scan to see what I can see:

IP Port Service
192.168.254.1 80 http
192.168.254.1   554 rtsp
192.168.254.1 8000 http-alt
192.168.254.1 9010 sdr
192.168.254.4 22 ssh
192.168.254.4 80 http

192.168.254.4    
554 rtsp
192.168.254.4       8000 http-alt
192.168.254.4 9010 sdr
192.168.254.4 49152 unknown

The results actually contain more devices since I have multiple cameras connected, but the remaining cameras show the same ports as 192.168.254.4 above, which are fairly similar to the ports exposed from the outside on the NVR device itself. I connect to the http interface on http://192.168.254.4/ however I see the same login page, and can't proceed through without the password. At this point, I'm a bit stuck, so I wait a while. For convenience, I connect the NVR directly to my home router, so that I can access it from my desktop without having to mess around with cables directly -- but I make sure that my firewall disables all outbound internet for 192.168.1.10. I don't want the camera footage being broadcast anywhere in the meantime.

Eventually I receive a response from tech support. Armed with the password-reset key, I am able to use their support tool to reset the passwords on my devices. At that point I can log in via the web interface, and I go through all the configuration pages to make sure there are no leftover user accounts, the "cloud integration" stuff is disabled, review all the storage settings. Since I don't plan to make this accessible online anytime soon, I leave my firewall blocking any outgoing traffic, and set up one of my own monitors at home to show the video feed.

My home is mine! I can now easily see when something's going on around my house, and can review any videos recorded due to the motion detection kicking in. And most importantly, I know that there's no way anybody else can access it.

@ Secura 2019
Webdesign Studio HB / webdevelopment Medusa