
In both cases, physical access to the room in which the DVR typically gets installed means DVR compromising is the least of your problems. It does not secure anything (despite the implication, a DVR is not a security system in classical sense, since it's not preventive).Ĭheap 4channel DVR like the one you describe - it's typical usage (from my 10 years in the industry as an integrator expereience) is:Ī) quad live view of 4 cameras around your houseī) looking at what your empleyees are doing. What is there really to exploit in a DVR? Oh God, when IT boffins try to look smart in PhySec :)
#DVROCX HOW TO#
With those two issues out of the way the only thing left is HOW to talk to our remote root shell that is waiting for us.luckily the device ships with netcat built into busybox, -e flag and all :) The device has a watchdog that polls the system to check if the "raysharpdvr" application is running and if it does not see it, it initiates a system reboot - very helpful. Lucky for us there are plenty of overflow bugs in this device that will lead to a crash :).

#DVROCX SERIAL#
The application does not actually provide a way to reboot the device using the web interface, there is a section that says 'reboot', but when it is triggered nothing happens and some debugging information displayed in the serial console saying the functionality is not implemented. The other issue is once we have reconfigured the device to run our command, it needs to be restarted before it will execute (its part of the init scripts). We can get around this issue by injecting a call to the dhcp client appliction ("udhcpc") - this will cause the device to use dhcp to get its network information bypassing the previous "ppp" config.

#DVROCX OFFLINE#
First in order to use this vector for command injection you must configure the device to use "ppp" - this will cause the device to go offline and we will not be able to interact with it further :(. "sprintf" with user input into a "system", that'll do it.
#DVROCX PASSWORD#
I created a small PoC in python that will pull the password from a vulnerable device: The next thing I saw was a bit shocking.when you access the application user accounts page the device sends the application all the information about the accounts stored on the device.

I imagine the activeX application that is used to connect to the device could be patched to just skip the login screen, but that seems like a lot of work, especially when there are much easier ways in. The first thing that I found with this lovely device is that the comms channel (9000) did not appear to do any authentication on requests made to it.Strike 1. The first item I looked at was the web application that is used to view the video streams remotely and configure the device. One of the ports that it will expose is for the web (activeX) application and the other is the actual comms channel the device uses (port 9000). Now for the real fun.looking at the device the default configuration is setup to auto-magically use the power of the dark lord satan (uPnP) to map a few ports on your router (if it supports uPnP). Telnet now works, but what fun is that when these devices don't normally expose telnet to the internet :).

Once the device is booted up in single user mode, the root password can be reset and the device can be rebooted.
