When I had my last house built, I wired it for a CCTV camera system. I ran siamese rg58 coaxial cable (the type with a separate pair for low voltage power) from a central location to all my camera locations since it’s a pain to do once a house is built. I bought a cheap
Dahua network-enabled DVR from one of what seems like hundreds of vendors who make them. When I finally brought the whole thing online, it worked well, but the “network-enabled” part of the DVR was super sketchy. For one thing, to view the cameras from a browser requires one run an unsigned ActiveX control in Internet Explorer. Never a good thing. Don’t get me wrong though. These things have a LOT of functionality for the money and they work very well. Unfortunately what I found was network security is but an afterthought.
Web Interface Login Page
eb Interface Logged In
My other options for viewing this thing are a fat client called PSS….
PSS Viewer
r a mobile app called iDMSS…
iDMSS Mobile App
Questionable network access aside, I thought being able to keep track of the homestead while I was out and about was quite handy. However, it took me a while to realize the sad reality of running a CCTV system in a house located in a very low-crime-rate, suburban area. That reality is that I never catch maleficence, or even mild shenanigans on tape. What I do capture is video of myself doing embarrassing things, like the time I was pulling my brand new Ducati out of the garage and dropped it or the half-dozen times I’ve walked out of my garage and hit my head on the garage lights.
Having Problems
Man Down
The Vulnerability
Anyway, after seeing vuln after vuln released on various DVRs, IPCams, baby monitors, and the like, I finally made time to take a look at the management and camera access traffic on my own DVR. What I found was nonexistent security, which wasn’t surprising. Dahua DVRs listen on TCP port 37777 by default. The various supported clients utilize a simple binary protocol over this port to manage and view the DVR. The bottom line, and this is fairly common with one-off binary protocols, is that these DVRs don’t really require authentication to manage and access. If you could port the ActiveX or PSS or iDMSS viewers to skip the login form, you could just access any Dahua DVR you want. Nothing mind blowing at all, but consider the following unauthorized requests:
Serial Number Request
Serial Number Response
Camera Channels Request
Camera Channels Response
Version Request
Version Response
DVR User Group Request
DVR User Group Response
DVR Users Request
DVR Users Response
Email Settings Request
Email Settings Response
DDNS Settings Request
DDNS Settings Response
NAS (FTP) Settings Request
NAS (FTP) Settings Response
Great so it’s pretty trivial to retrieve device settings. Clear text SMTP, DDNS, and FTP creds could be useful. The DVR user passwords are hashed so how could an attacker get their peep on? Can we just reset the password for a given DVR user? Yes we can.
Reset “admin” Password to “abc123” Request
Notice the 0x19 byte. This is just a simple checksum. 0x19 = 25 = and admin:Intel:abc123:abc123.length.
Well at least the device logs user activity by IP address. Can we clear the logs to cover our tracks? Absolutely.
Clear Logs Request
Logs Cleared
As I was researching this, I found some other disturbing things about Dahua DVRs. I found that the DVRs are shipped with telnet enabled and a static root password. Since the DVRs use a read-only file system, it’s not simple to change that password. What’s more, other folks had been researching Dahua DVRs at approximately the same time as I. They found issues like:
- The static root password I mentioned above
- Other backdoor accounts exist, including one with a revolving password that is a simple date hash.
- UPnP requests from untrusted addresses is supported and could be used to get publicly accessible telnet on a DVR.
- Passwords are limited to 6 chars.
- A weak 48-bit hash is utilized to protect DVR account passwords. (I’d like to know what this is so I can try cracking them)
Exploitation
I started writing a simple proof of concept script that dumps various configuration elements from the device. I started to notice other more minor issues like the fact that FTP, DDNS, and SMTP user credentials are stored and transmitted in clear text. So I decided to write a Metasploit scanning module for the issue I discovered. What I ended up with is a scanner module that does the following:
- Scans one or more addresses for a given port to identify Dahua DVRs
- Gets the firmware version
- Gets the serial number
- Gets the email settings (includes username, SMTP server, and cleartext creds)
- Gets the DDNS settings (includes the DDNS service, server, and cleartext creds)
- Gets the FTP (NAS) settings (again, cleartext creds)
- Gets the DVR users (username, group membership, and hashed passwords)
- Gets the user groups (group name, description, etc)
- Gets the channels (camera channel names, e.g. “bedroom” “cocina”)
- Stores any creds and services in the MSF “creds” or “services” database
And Optionally:
- Clear the logs
- Change a given user account’s password (unauthorized access)
You can see the “show options” output here:
Metasploit Module OptionsHere is the output of the module successfully running against a DVR:
Metasploit Module Exploitation Page 1
Metasploit Module Exploitation Page 2
Metasploit Module Credential Storage
Here’s my GIT repo: https://github.com/depthsecurity/dahua_dvr_auth_bypass.git
Just clone the repo (git clone https://github.com/depthsecurity/dahua_dvr_auth_bypass.git) and then move the .rb file to your modules directory (e.g. /root/.msf4/modules/auxiliary/scanner/misc/dahua_dvr_auth_bypass.rb)
If anyone wants to contribute to making this better / getting it included in the Metasploit repo, let me know. Some future options I’d like to add are:
- Check for telnet and utilize known default root password to gain telnet shell
- Issue UPNP request to open telnet to public access, then get telnet shell
- Check retrieved hashes for known default hash values (888888, 666666, admin, etc)
- Identify DVR password hash mechanism for cracking in JTR
- Stabalize across Dahua versions
Remediation
The best advice for now is to make sure these devices are not publicly accessible to the internet. Dahua initially stated they would work on fixing the issues but went radio silent afterwards.
Vulnerability Timeline
8/26/2013: Identified authorization flaw8/27/2013: Wrote proof of concept tool/scanner8/28/2013: Disclosed issue to Dahua8/30/2013: Received initial response from Dahua including request for more info8/30/2013: Responded to Dahua with requested info9/2/2013: Received confirmation that Dahua R&D is working to fix the issue10/2/2013: Requested status update from Dahua10/10/2013: Re-requested status update from Dahua after no response from 10/2/2013.11/13/2013: Publicly disclosed vulnerability on Bugtraq and presented at SecKCNovember meeting.