Dahua DVR Authentication Bypass - CVE-2013-6117

Posted by Jake Reynolds on November 13, 2013

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.

1.jpg#asset:362:urlWeb Interface Login Page2.jpg#asset:363:urleb Interface Logged In

My other options for viewing this thing are a fat client called PSS....

3.jpg#asset:364:urlPSS Viewer

r a mobile app called iDMSS...

4.jpg#asset:365:urliDMSS 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.

5.PNG#asset:366:urlHaving Problems6.PNG#asset:367:urlMan 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:

7.jpg#asset:368:urlSerial Number Request8.jpg#asset:369:urlSerial Number Response9.jpg#asset:370:urlCamera Channels Request10.jpg#asset:371:urlCamera Channels Response11.jpg#asset:372:urlVersion Request12.jpg#asset:373:urlVersion Response13.jpg#asset:374:urlDVR User Group Request14.jpg#asset:375:urlDVR User Group Response15.jpg#asset:376:urlDVR Users Request16.jpg#asset:377:urlDVR Users Response17.jpg#asset:378:urlEmail Settings Request18.jpg#asset:379:url
Email Settings Response19.jpg#asset:380:urlDDNS Settings Request20.jpg#asset:381:urlDDNS Settings Response23.jpg#asset:382:urlNAS (FTP) Settings Request 24.jpg#asset:383:urlNAS (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.

25.jpg#asset:384:urlReset "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.

26.jpg#asset:385:urlClear Logs Request27.jpg#asset:386:urlLogs 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)


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:

options.png#asset:387:urlMetasploit Module OptionsHere is the output of the module successfully running against a DVR:

exploit1.png#asset:388:urlMetasploit Module Exploitation Page 1exploit2.png#asset:389:urlMetasploit Module Exploitation Page 2 creds.png#asset:390:urlMetasploit 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


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.

Have Questions?
Get Answers