Tuesday, January 22, 2013

Swann Song - DVR Insecurity

"Swan song" is a metaphorical phrase for a final gesture, effort, or performance given just before death or retirement. This post serves as the "swan song" for a whole slew of DVR security systems. With that being said, I will refer to the lyrical master MC Hammer, lets turn this mutha' out.

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 opening the device up something grabbed my attention right away....

The highlighted header looked like a pretty good possibility for a serial port, time to break out the multi-meter and check. After a couple power cycles, the header was indeed a serial port :)

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:

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:

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 :)

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.

Neat write-up! We're looking to add these issues to OSVDB.org and wanted to clarify a few things.

1." 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?

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.

2) Yes - although I believe there are more issues to be found in these devices.

I'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.

I'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?

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.

Just 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.

Well, I bet that the OP is regretting what he said 3 years ago now! A massive flock of CCTV cameras is breaking the Internet.

Oh, as regards what you can do with the card number & PIN, pulled from the CCTV? Was that a joke? You can code up your own card, then go use it to withdraw or spend money! (So no, nothing serious at all) POS PoS devices are also on that same network you've compromised, too, btw. And likely the emails from the website, and possibly the database storing bulk credit cards. Need I go on?

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.

One 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.

I've got a customer who has, I think, been hit by this. I figured out it was hacked, but assumed it was a weak password. The new device, from Swann's new range, appears to have been re-pwned despite a strong (though somewhat short 8 characters) password. Inside of a week!

Thanks for the great article... proved useful for gaining access to the cmd prompt of my Night Owl Zeus DVR16B.My 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.

Oh, 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:

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.

Does anyone know if on telnet to the swann DVR does it allow for browsing the file system + recordings?If I take the drive out and plug it in an external SATA reader the drive is not recognizable by Windows so I was wondering if telnet allows the full viewing of the OS + data stored on the drive?

Further to Woodchuck's response, don't forget that it is a Linux box, so Windows won't understand the drive unless you add something to help it. Boot into Linux (use a thumbdrive or whatever) and it'll see the drive normally if you mount it.

I'd like to thank you for your insight and (very) blunt assessment of these DVRs. I own one, (but was lucky enough to have a "firmware" without the 1234-esque password).

Strangely enough, I used your instructions for a 100% white-hat purpose: To change the root password so I may shut the system down cleanly via telnet in the event of a power failure.

The not-so wonderful support folks at (company here) told me, in no uncertain terms, that telnet and SSH was not available and did not exist on their product (mind you, I was sending the question while staring at the login prompt in Putty...). All I wanted to do was shut it down. I didn't care about the method, be it Telnet, SSH, SOAP, etc...

Using your instructions, I was able to set a new root password, and can now have my UPS-equipped server issue all the halt/poweroff/restart commands I'd like, and don't have to worry about the drive safely being unmounted in the even of a power failure.

Now, I'm off to try to SSL Wrapper this thing to take care of the rest of its issues...

I'm not a computer expert or anything, but I have questions I hope someone here can answer. My friend has a Swann DVR system. I helped her install it. It worked fine at first, then things went south. Now when watching the playback, the video will randomly loop backwards at eerily convenient times. The playback footage has also begun to black out for 1-2 minute intervals, leaving large gaps of time unviewable. I thought the blackouts could be something up with the whole system, but it only happens to the cameras individually (and both of them do it) rather than both going down at once...so I don't think it's the camera itself, unless both are defective. After that went on for a while, the remote access to the DVR stopped working entirely. Someone had changed the port number the DVR uses which fucked with the remote access, and it definitely wasn't us. So, my question is thus: If someone were to gain access to the DVR (the people in question HAVE had physical access to the DVR box), would it be possible for them to actually modify the footage, or perhaps gain control of the cameras remotely to cause those blackouts? I just want to figure out if her system has possibly been compromised, because she is trying to gain proof of some fucked up shit with video footage and the playback is unreliable. One of the people who would be capable of doing this retired from the NSA after 20 years, so I have no doubt he would be able to pull it off if it's possible. Just unsure of what all could be done with the kind of access you describe here. Sorry this is sort of off topic, but I don't really know where else to find out what sort of manipulation is possible. Swann's tech support is pretty much useless. Thanks to anyone who can help.

Once you've got a decent connection and the root account, you can make it play the Suoer Mario theme. That the password is changed is your clue. (IP cameras can also be trivially hacked too, so possible they're mining Bitcoin or something, though Swann aren't normally IP cameras, but connected via coax & 12V dc cables)

If you continue looking at the raysharp_dvr binary, you will also find a few hardcoded passwords -- ROOT:topsecret (not kidding), rsroot:rs5678. The firmware (unpackable using firmware mod kit) also contains a couple of hashes for the root accounts, one of which is DES and resolves to root:helpme, the other is MD5 (not in dictionary, varies by DVR).

I am deciding whether i should return this DVR or rewrite its firmware. The current firmware appears like it was written by a bunch of monkeys. Also ActiveX-only, really? Too bad because hardware seems to be solid (it is built around HiSilicon's HI35zxx ARM CPU)

The video stream is initiated by connecting to port 9000 and sending it 16 bytes. All the bytes appear to be zero (00) except for bytes 5 and 13. 5 is always the same 0x47 and Byte 13 is the one that selects which camera to stream. For camera number one byte 13 = 0xA4. I wrote a perl script that will listen on a port and when a client connects it will connect to the dvr, send the 16 bytes and start streaming the output to the connected client. I am unable to get vlc to connect. I wrote another script to dump the output from the stream to a file and tried to play it with vlc and it would not play. I marked it as avi and tried to play with windows media player and it did sort of play and I could see the top 1/10th of the screen. I'll need to keep playing with it. If anyone else has any info on how to play it please post.

Not sure if the manufacturer fixed this specific vulnerability, but I noticed a firmware update hidden away on their website:

http://swann.com/downloads/New_FTP/Name/

I updated my DVR8-4000 to the latest release available, then tried the python script. I had to mod the script to use my port, instead of the default 9000. The result is "No reply, not vuln." I only wish I had tried this on the original firmware before upgrading. If anyone tries the script, then updates firmware, I'd be curious to hear the before/after result.

Oh boy. Just poking around, I telneted into the router and logged in as root with no password. Good grief. Trying to change the password to something, anything, I get "passwd: An error occurred updating the password file." Any ideas why it's doing that?

If I vi /etc/passwd, and try to save a password that way, I get a message that the file system is read-only. Any ideas on how to get a root password now? Sorry to newb up the thread. I'm a bit of a linux rookie.

Some time ago I was looking for ways how to connect to my Swann DVR over internet and skip their ActiveX component. This search got me to this page and somehow inspired to dig deeper, as I wasn't able to anything from the net. Next stop was http://www.securityfocus.com/archive/1/534830/100/800/threaded. Apparently most of cheap end DVRs are coming from the same place and have same software within. Take away from previous article for me was that network traffic what is happening between ActiveX component and DVR is not encrypted. From my school days I remembered that there is a way to look into TCP traffic going out from your computer. I got myself Wireshark and spent couple of hours reading how TCP works. Basically you just need to get tour Wiresark going and see what kind of a traffic is going from ActiveX component to DVR and what comes back. It appears that there is plain h.264 video stream coming for every channel and you can save/stream/watch it really easily. It takes just connecting to your DVR media port (9000) and sending one TCP packet per channel to initiate the stream. In Wireshark look for the package with length 561 (or 3rd packet in TCP stream flow for every camera). Copy binary format of this packet payload and that is your key in. Simple linux command that worked for me is below (this ugly looking part after echo command is the place where you want to put the payload data you copied before)

This script will keep writing pure h.264 stream into the file. In case you want to have some remote viewing application built on top you probably want to create some named pipe and send stuff there. Then take ffmpeg, convert the stream into something else and do what ever you need to do with it.

So in short, there is a way to skip ActiveX component for your Swann DVR but entire thing is one big security hole. Just close down all the DVR ports in your firewall if you have something to hide;)

Security is must to save your lives and very important things which are connected with you. We are dealing in various instruments which help to save casualties in daily life. Lets take a look for the Cctv full kit, Cctv suppliers Manchester , 8 channel cctv security system, HD cctv camera or Hikvision ptz , Hikvision DVR, Hikvision NVR and Cctv for sale.

Wonderful blog post on cctv cameras. Many times cctv cameras can be life saving and it is very important that everyone has installed them in their premises. We are cctv camera dealers in chennai and this post was very useful for us.