My last on-topic post pontificated about the dangers and surprise of letting third parties into your house or codebase, where I discussed the addition of a TV DVR system to my home network. In this post, I'm going to go into some details about what I found on the network for the pure pleasure of it – no pontificating about anything, just the fun of sharing something I learned with some simple tools everyone has handy. Disclaimer: I am monitoring my home network and traffic across it and inferring stuff. I have no intention of reverse engineering or hacking the DVR system, nor do I have any particular beef with the provider. I will do my best to purge log snippets of identifying information. Second, it sure doesn't take much to get at some interesting info in this DVR system. I fired up nmap and identified the 3 DVR IP addresses out of the rest of my network. Below is the output from nmap specifically related to the DVR systems (NOTE: I used the output of a quick scan rather than a more in-depth scan that could identify more about each host in order to keep this quick and easy to read, but a more intense scan is a wise idea after you decide which targets to focus on):
Nmap scan report for XXX.XXX.XXX.103 Host is up (0.009s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 80/tcp open http 111/tcp open rpcbind MAC Address: XX:XX:XX:XX:XX:XX (Wistron NeWeb)
Nmap scan report for XXX.XXX.XXX.104 Host is up (0.010s latency). Not shown: 988 filtered ports PORT STATE SERVICE VERSION 6000/tcp closed X11 6001/tcp closed X11:1 6002/tcp closed X11:2 6003/tcp closed X11:3 6004/tcp closed X11:4 8080/tcp open http-proxy? 9000/tcp open http-proxy sslstrip 9001/tcp open tor-orport? 10000/tcp closed snet-sensor-mgmt 10010/tcp open rxapi? 49152/tcp open http-proxy sslstrip 49153/tcp closed unknown MAC Address: XX:XX:XX:XX:XX:XX (Wistron NeWeb) Device type: general purpose Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6 OS details: Linux 2.6.36 - 2.6.37, Linux 2.6.37 Uptime guess: 0.987 days (since Tue Sep 8 13:55:28 2015) Network Distance: 1 hop TCP Sequence Prediction: Difficulty=197 (Good luck!) IP ID Sequence Generation: All zeros
Nmap scan report for XXX.XXX.XXX.105 Host is up (0.011s latency). Not shown: 999 closed ports PORT STATE SERVICE VERSION 80/tcp open http MAC Address: XX:XX:XX:XX:XX:XX (Wistron NeWeb)
Having identified those three addresses, I noted that all had open HTTP ports. Well, in my mind at least, that's like a front door for me to knock on and see who's home. So, I fired up a browser and knocked! Note that I used my browser with Burp Suite as a proxy, so I could see headers and intercept traffic sent between my browser and the servers I am probing. There are many proxy tools out there other than Burp, including tools in the developer toolkits that some browsers ship with – the important thing is being able to inspect the HTTP headers, so pick a proxy tool of your choice and learn how to use it. The first IP address, XXX.XXX.XXX.103, gave me nothing – literally a 404 and no error text or anything. While I know from the 404 response that some sort of web server is there, I didn't get an easy answer and will have to come back to this and use some additional tools like netcat or curl to determine what this webserver is and what it is providing. The second IP, XXX.XXX.XXX.104, was more interesting – it has some ports open/closed we might want to inspect. I found it concerning to see the X11 ports there, but maybe they are running proprietary software using those ports. More immediately worth investigating were the http-proxy ports. The other ports look boringly related to network management and Windows Open Object Rexx service but I will inspect them later. Also, I noticed that on subsequent scans some other ports open that would then be closed next scan. I suppose by watching Etherape or Wireshark I could learn more about the traffic to and from this host but I am not ready to do that, yet. What I did learn by visiting port 8080 was this json looking object was returned:
{"status": {
"code": 403,
"commandResult": 1,
"msg": "Forbidden.",
"query": "/"
}}
Hmm, thats interesting, what looks like some sort of application behind port 8080 that might be an API of some sort that communicates using json. The html response headers verify this but don't give much more info. Visiting port 9000 returned a 400 and just the text “Invalid client.“ – no html or anything. Inspecting the response headers, I see a server name including the name of the vendor and a proprietary TV service... another item in my inventory of things to poke at later. Next, I visited port 49152 and got a 404 and no text. Another resource to follow up on, since it responded with HTML error code, I can assume there is a web server there. I moved on to the other ports starting with 9001 and immediately got a connection reset. Oh well, not a web application, so I moved on. Port 10010 also returned an immediate connection reset. That host was interesting to inspect, but now comes the real fun on IP address XXX.XXX.XXX.105. Browsing to the http server running on port 80 returned a super fun result. This IP address turned out to be the wireless router/video bridge for the system. And when you ask it “what's up?” it tells you in spades! The request returned the data in this source file. That is a dump of state for the wireless video bridge including process list, the output of dmesg, recent entries into the system log file, the fact that it is a Cisco product and what version of the firmware and hardware… all sorts of interesting data. And no password or anything protecting it – presumably to make it easy for support personnel to access. So, lets see what fun info the system just handed out. The first thing that caught my attention was in an early block labeled EPROM Manufacturer Data:
----EPROM Manufacturer Data----- MFG Data Version = 1 Model SKU = WVBR0-25 Model Region Code = US serial_number = H36EE4FE001393 HW MAC addr = XX:XX:XX:XX:XX:XX uuid = d319c9e1-2aaa-432e-be33-XXXXXXXXX WPS pin = 58783383 "58783383Ó(58783383) is a valid WPS PIN. HW Version = 48.J7602.SGF SW Version = 1.4.10.2 Manufacturing Date = 20140429
Yes, that sure looks like it is the WPS Pin for the wireless network the DVR system is using. That data is repeated later in the syscfg section and Wireless Settings, which I won't repeat here. One thing you can do with this is to use a tool like reaver-wps or bully to work out what the WPA passphrase is and gain access to the private network the DVR system is using. Remember this info was available on my personal network but the WPS is for attaching to the DVR system's Wireless Video Bridge, which is broadcasting its own SSID and is a separate network from mine. And my neighbors can all see this network when they browse open access points on their computers. Of course, they shouldn't be able to get on my home network to get this info but this info is not guarded in any way on my network, so the only defense is my wireless router and the strength of my passphrase choices. If it turns out that the video bridge is allowing WPS authentication, I will notify the vendor immediately that this is insecure and consider removing the system from my house. Digging through all of the other data in this file reveals a ton of info about the wireless video bridge:
- process list
- dmesg output
- 100 lines of /var/log/messages
- kernel and firmaware versions
- mac addresses
All of which is accessed by browsing to an open http port with no authentication. I haven't taken the step to try and gain access to the system as I am sure that violates some aspect of my EULA with the vendor, but with this info available a reasonably skilled person could gain access to the network and then potentially to the DVR hosts themselves (which are also clearly Linux-based devices). An end goal could be to steal the stored video content or reverse engineer the system to get free content from premium channels. As you can see, with a couple of readily available tools (nmap, Firefox, Burp Suite etc), I have gained a lot of information about this DVR system and its private network to give me a lever to gain access. Whether or not it is a valuable target is a separate discussion, but with this info you can begin inspecting your own network and identifying what the Internet of Things is adding to your environment. In my next post on this topic, I will address what happens when I turn on some settings in the main DVR to allow my Android device to act as a remote control, talk a bit about how I can control my DVR from anywhere if I log into the vendors website and discuss the issues that concern me about this. Title image courtesy of ShutterStock
