Image
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
