Dahua NVR – Multiple Exposures (CVE-2017-6341 CVE-2017-6342 CVE-2017-6343)

Introduction

Responsible Disclosure Timeline.

  • 2016-10-10: Sent to both the Australian Importer and Dahua, everything mentioned here plus more. The Importer was also called to discuss the issues.
  • 2016-10-17 (approx): Followed up verbally with the importer a couple weeks later (phone).
  • 2016-11-14: Contacted both the Importer and Dahua for an update.
  • Apart from when I rang the Importer directly, no one has responded.
  • 2017-02-24: Public Disclosure.
  • 2017-02-26: CVE’s Assigned
  • 2017-03-02: Sent all CVE’s (plus CVE-2017-6432) to Dahua
  • 2017-03-08: Dahua Responded stating all three CVE identified here will be resolved in July 2017.
  • 2017-03-11: Content redacted by request from Dahua until all issues are resolved
  • 2018-05-23: That which Dahua will fix, they have fixed.  There have been no active communications from Dahua for over 6 months so content is once again public.
  • 2018-05-23: github pages broke, I’ll fix it up one day.  nullku7.github.io/stuff is this documents original and official home.

Relevant CVE’s

CVE-2017-6341
CVE-2017-6342
CVE-2017-6343

Changes since First Reporting on 2016-10-10

The camera’s now force a password to be set, which to be honest, does nothing!

Older CVE’s worth noting

CVE-2013-6117 is still worth reading to understand the port 37777 service.
While it’s vulnerabilities are no longer directly exploitable, the protocol is unchanged for the most part.
Dahua DVR Authentication Bypass – CVE-2013-6117

The Hardware

  • NVR Model: DHI-HCVR7216A-S3
  • NVR Firmware: 3.210.0001.10 build: 2016-6-6
  • Camera Firmware: 2.400.0000.28.R build 2016-3-29
  • SmartPSS Software (v 1.16.1 Build Date 2017-01-19)

Camera Names

The first interesting thing when loading the webpage is a cap.js file.
While this gives us nothing yet, we shall take log of what it has.

var talkTypes='2&1&4&';
var devType='DHI-HCVR7216A-S3';

var userInfo='This is user info!';
var streamCap=19;
var channelNames='Shop&&Shop&&Warehouse&&Entry Gate&&<<<redacted>>>';
var rtspport = 554;
var ClientType = 0;
var capTcpPort = 37777;
var radius = false;

So we know the names of the camera’s, but not much more yet.

The entire DVR/NVR interface is already loaded on the login screen

Obtaining Camera Passwords

CVE-2017-6341

As it turns out, the Web Page, Mobile Application, and Desktop Application are all nice enough to transfer all camera details in clear text.

The following TCP Stream contains ALL camera’s, their IP’s, and Username/Password.
What happens is the software requests all the camera configurations, and this is included in the response.

These are the camera’s that Dahua now Force a password change on! This is a huge risk as the camera’s are usually isolated via the NVR from the main network, meaning accessing them required using the NVR as a pivot. Due to most installers sharing a common password for the entire system, the chance the admin password for the NVR would be revealed would be very high. Screen Shot 2017-02-24 at 10.26.33 am.png

As can be seen from this Captured TCP Stream, the client software requests all of the camera channels, and the NVR responds with this.

We have the the Requested DisChn.
This alligns with with the Cammera Channels from cap.js.

So we now have.

  • Camera Name
  • Camera IP
  • Camera Username
  • Camera Password
  • Camera Type

New Users

Whenever a new user (of any level permission) is added, the username and password is transmitted in clear text

Screen Shot 2017-02-24 at 10.39.14 am.png

This packet a6 00 00 00 17 00 00 00 06 is surprisingly identical to that identified in cve-2013-6117 If that’s the case, 17 is a checksum 06 is what I seen on a new user, while 0a is identified in the above cve for changing passwords.

23 char = 0x17 … looks good.

CVE-2013-6117 – Reset Password method has Changed

Upon further investigation of CVE-2013-6117, the entire protocol is identical. This results in another exposure, the ability to capture reset passwords, not only the new one, but the old as well.
This is worth noting that either “Intel” was a hard coded option for the last password, or was the researchers last password.

As can be seen in the metasploit module and Depth Security’s blog “Intel” was hardcoded https://github.com/depthsecurity/dahua_dvr_auth_bypass/blob/master/dahua_dvr_auth_bypass.rb#L169
Screen Shot 2017-02-26 at 10.16.54 am.png
“Intel” must be the old password.
username:oldpass:newpass:newpass

Injecting a new user

So testing the known CVE-2013-6117, as well as writing my own, does not work. The NVR closes the port the moment the packet is sent, it must be blocking the connection.

At this stage, it appears each TCP Connect needs to authenticate, then the binary protocol should work exactly as it used to. This means that the authentication bypass methods should no longer work.

Anyone who wants to assist in solving this, please feel free to contact me. I will spend more time on this as time allows.

Auto Login despite NO login

CVE-2017-6342

When launching SmartPSS Software (v 1.16.1 Build Date 2017-01-19)
It logs into the NVR before any user interaction with the software.
Upon logging in, the above camera information is divulged, as well as the Admin Hash.
This alone may be enough information to gain access, if not, we need to go deeper.

Additional Information for clarification – 2017-02-27

The software launches to the ‘login’ screen.
While on this screen, the software logs into the Port 37777 service as admin. As soon as it logs in, in the background, it pulls the camera configurations, which includes above camera usernames and passwords.

Hashes

CVE-2017-6343

Below is the hash captured when the software is launched.

Screen Shot 2017-02-24 at 2.37.47 pm.png

This hash alone is not that useful, but everything needed to make it useful is presented just before.

Screen Shot 2017-02-24 at 2.39.58 pm.png

So with this we have

  • Account Name: admin
  • Realm: Login to 2FO3611PAEG9265
  • Random: 1331847305
  • Account Hash: B43EA4316B4B391FD34B6A85E687B628E3FE7A9CBF8405F1452EF497E53899E3

The method of calculating this hash is unknown for Port 37777 Binary Protocol.
It appears to be SHA256, which is not a known Dahua Hash, and it not present in the web interface JavaScript.

For the Web it is simply this

part 1: MD5(username:realm:password)
part 2: MD5(username:random:part1)

Older Dahua had an infamous 48bit algorithm, this is not used on these NVR

Looking at source code, it seems at some point they only did a base64encode, this also does not work on these NVR

This is a great improvement over the past, but unfortunately, you can still sign in using the MD5 hash via the web interface.

Below is the JS which creates the Hash for the web interface, none of these appear to be valid.

function getAuthByType(a, b, c, d, e, f) {
switch (d) {
case "Basic":
return Base64.encode(a + ":" + b);
case "OldDigest":
return superEncipherment(b);
case "Default":
if (c)
return hex_md5(a + ":" + e + ":" + b);
var g = hex_md5(a + ":" + e + ":" + b);
return hex_md5(a + ":" + f + ":" + g);
default:
return b
}
}
function superEncipherment(a) {
for (var b = "", c = [], d = hex_md5(a), e = [], f = 0; 16 > f && f < d.length / 2; f++) e[f] = parseInt(d.slice(2 * f, 2 * f + 2), 16); for (var f = 0; 7 >= f; f++)
c[f] = (e[2 * f] + e[2 * f + 1]) % 62,
c[f] += c[f] >= 0 && c[f] <= 9 ? 48 : c[f] >= 10 && c[f] <= 35 ? 55 : 61,
b += String.fromCharCode(c[f]);
return b
}

Continuing Research

I will be continuing this research very slowly.
I unfortunately don’t have the time to finish this now, but I also feel it is very important this vulnerability is publicised now, since Dahua have decided to ignore the risks and take no action to rectify it over the past 4 months!

Credits

Andrew Frahn (null ku7) and others where mentioned

3 thoughts on “Dahua NVR – Multiple Exposures (CVE-2017-6341 CVE-2017-6342 CVE-2017-6343)

  1. Hello, and thank you for that very interesting info. I am working on this subject lately, and you are the only one that mentions the SHA256-lookinh hash. I could verify with SmartPSS and my own Dahua device, that credentials are sent in clear-text, but I am also looking for a way to manually generate the final SHA256 hash, to understand how it’s being generated. Any luck on this?

    Like

  2. The password hash taken from above:
    B43EA4316B4B391FD34B6A85E687B628E3FE7A9CBF8405F1452EF497E53899E3

    Break point:
    B43EA4316B4B391FD34B6A85E687B628 E3FE7A9CBF8405F1452EF497E53899E3

    The first part of this can be generated with the javascript above. Top function “var g” method.
    Deobfustecated the var names here to match what you have :
    function getAuthByType(user, password, truthvar, auth_type, realm, random)

    Over 37777 direct not with JS/RPC2 method, the NVR/DVR/Cam sends out a response to your login message telling the format that it wants to see the password presented in. A while ago you only needed the first part. Now on newer firwmare you need the second part too.

    Given we only know the realm, random, user and password at login via 37777 from what we are told by the NVR, it’s logical that he second part is just a different method of creating a hash of that data.
    It changes at each login so must include the random information as part of the hash.
    Still working on that one…

    Nom

    Like

Leave a Reply to KonKar Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s