Dahua Suffers Second Major Vulnerability, Silent [Finally Acknowledges]

By: Brian Karas, Published on Jul 25, 2017

Less than 3 months ago, Dahua received DHS ICS-CERT's worst score of 10.0 for their backdoor.

Now, Dahua has received another 10.0 score for a new vulnerability. Despite that, Dahua has remained silent.

In this note, we examine the vulnerability, Dahua's poor handling of this, compared to competitors Axis and Hikvision, and the potential impact to Dahua.

[Update: After the publication of our report, Dahua has finally acknowledged the vulnerability]

Vulnerability ********

*****'* *** ********* ** vulnerable ** ***** ****** overflow, ********* ** ****, sponsored ** *** ** DHS. ************, *** ***** field *** *** ***** password, ** *** **** first **** *** *** when ********** ** *** camera, **** *** ******** input **** ******. **** can ** **** ** an ******** ** ****** excessively **** **** ** the ******** *****, *** trigger * ****** ******** in *** ****** **** that ********* *** *****.

****** ********* *** ** exploited ** ***** ** attacker ** ******* *** device, **** **** ******, or ********* ********** *** unit. ******* **** ************* exists ** *** ***** page ******, ** ************** is ******** ** ******* it, *** *** ****** with ****** ****** ** at **** ** *******.

*** ****** **** **** Dahua *** ******** ****** 2 ****** ***, ** the *** ** ***.

Models ********

***** ***** ** ****** that *** ******** *** that ***** *** ******** a ******** ***, *********:

*******, ** ** *** clear *** **** ***** models *** ********. *** example,***** **** **********, **** ****** *****, in ******* *******, **** North *******, **** ******* are ******* *** *** same *********** ********. ********, as *** ***** **** the ***** ********, ***** Dahua ****** **** ****** various *****, **** ***** models ***** ** ********.

No ********** / ** ******

***** *** **** ** official ********** *** ****** of **** **********, ***** is ******** ** ***** matters ** ** ******* below *** *****'* ***********.

**** *** ******* *** to ******** ******** ** Dahua *** *** ******** no **-***-****** ******** ***** this ****** *************

Fix **********

*** *** **** ************* report ******** * **** to ******** ** *****'* international **** **** ***** fix *** *************. *** that ****, *** **** of *****'* ************* ***** are ****, ********* *** errors:

******: ***** ** *****, the **** / ***** are *** ******. ******** firmware ** *** *** vulnerability **** [**** ** longer *********].

*****'* ***** ******* ******* is **********, *** *** no ********* ** **** vulnerability, *** **** ************* update ***** **** ***** 2017:

**** *** ******** ************* notices **** **********, ** it **** ****** ** models ******* ***** ***** far **** ****** ********.

Researcher **********

*** **** ******* ******* Ilya ***** [**** ** longer *********], ** ***** security ************ ************, *** **** ******** (no ****/*********** *****) **** the ********* ** *** vulnerability. ******** ************ ******* to ******* ********** ******* of *** *************.

Violates ******** *********

*** **********, **** ** how **** *** ********* have ******* ***************:

*********'* ******* ************** ***** ********** ***** most ****** *************, *** links ** ******** *******:

**** ******** ******* ** known ***************, *** ***** to ********, ** ************ ************:

**** ** ***** ******** to *****'* **** ** acknowledgement, **** ** ********, and ** *** **** of **** ***********, **** of **** ********** ********.

******

*** ******* ** **** Dahua ********* ** **** an ********* **** ***** record, **** **** ******* vulnerabilities *** **** ******* to ******** ****** *** inform ***** *********. ** that ***, ** ** not *** **** ********* Dahua **** *****, ** some *****, **** ** business ** ***** *** Dahua. *******, ** **** show *** ********* ** unwilling ***** ** ** acknowledge *************** **********, *** deliver ******** **** ********* can *****.

Vote / ****

******

****** **** ****: ***** USA *** ****** * press ******* [**** ** longer *********] ** *** website ************* *** *************, saying ** **** ******* 4 ** ***** ****** but **** * ******** upgrade ** *** *** available:

***** *** ******** ** dated **** *** **** and ****, **** *** not **** ** ***** website ***** *** ****. The ************* *** ****** publicly ** **** **** 18th *** *** **** report **** ***** *** notified ** *** **.

***** ** ***** ** document ** ****** ** the ***** ************* ******* press ******* ** ***** security *******.

Comments (34)

John Honovich

IPVM | 07/25/17 01:29pm

Dahua is the most obvious sign for industry people of the bubble that China is in.

This is a company that claims ~$2 billion in annual revenue, 10,000 or so employees but repeatedly fails to do even the basics right.

Dahua better hope the Chinese bubble economy keeps up because they simply lack the fundamental competency to compete without it.

Undisclosed Integrator #1

07/25/17 01:30pm

I think the product quality is good and the security poor as is any consistent security response.

I think the poll needs to be - what do you think of Dahua security and response?

Undisclosed Distributor #3

In reply to Undisclosed Integrator #1 | 07/25/17 02:16pm

Edited: "what do you think of the absence of Dahua security and response?".

Shannon Davis

TED Systems
07/25/17 01:40pm

Let's face it there are always going to be vulnerabilities found in IP cameras and IP devices. That is the nature of a computer which cameras are and too many people out there live to find these and cause irreparable harm. Ideally the vulnerabilities are discovered by the manufacturer or a white hat hacker who want to keep everything as safe as possible. The real question for the integrity of a manufacturer, and I don't care which one either, is how they handle the situation and how fast they handle the situation. Manufacturers need to face facts and admit when their is an issue and quickly and thoroughly take care of the issue. To me that is what separates mediocre want-to-be companies and really great companies, IP cameras or whatever IP device manufacturer. I think sometimes the reason some of these companies don't want to respond quickly and effectively is due to the fact they didn't discover the vulnerability themselves and don't want admit they didn't do more thorough testing and even then you will never find all vulnerabilities. Let's face we all make mistakes sometimes, it is how you own that mistake that makes you who you are.

John Honovich

IPVM | In reply to Shannon Davis | 07/25/17 01:45pm

Shannon, I agree with you about the importance of responding "quickly and thoroughly".

However, I also think that vulnerabilities should be evaluated based on how fundamental and easy they are to exploit. With Dahua, that is a big part of the issue. Their recent vulnerabilities tend to be basic issues that require little skill to exploit. That makes them more dangerous as well as points to more fundamental problems with Dahua's offering than vulnerabilities that are obscure or complex to take advantage of.

Brian Hampton

IPVMU Certified | In reply to John Honovich | 07/26/17 05:21pm

Little skill for an experienced exploiter. I attempted to learn about the previous backdoor and see what I could do to get in to some Dahua products I had but I was completely baffled at how I was supposed to do it. So while the threat still exists it isn't something that could be easily taken advantage of by some average internet user.

John Honovich

IPVM | In reply to Brian Hampton | 07/27/17 12:20am

I attempted to learn about the previous backdoor and see what I could do to get in to some Dahua products I had but I was completely baffled at how I was supposed to do it.

Brian, here is the script to use / exploit the Dahua backdoor. It's public on Github and it's quite straight forward to use. It's the same one we used to demonstrate on the Dahua backdoor test.

it isn't something that could be easily taken advantage of by some average internet user

The average developer, or even script kiddie, which there are clearly millions worldwide, could easily take advantage of it.

Randy Lines

In reply to Shannon Davis | 07/26/17 04:06pm

Great comments. Improper authentication on login is a very basic mistake in 2016 :(

rbl

Undisclosed Manufacturer #2

07/25/17 01:51pm

My only surprise when I read this article is that this is claimed as being only the SECOND Dahua exploit, when it feels like the fifth or sixth in the last year and a half.

Brian Karas

IPVM | In reply to Undisclosed Manufacturer #2 | 07/25/17 02:08pm

This is Dahua's second vulnerability with a 10.0 CERT score, and also the second one this year. The previous one, the Dahua Backdoor was potentially more damaging, as it was relatively easy to exploit, impacted a large number of devices, and also divulged sensitive data (passwords).

This listing contains additional Dahua vulnerabilities, which we will update in our Security Exploit Directory as well.

Undisclosed #4

IPVMU Certified | In reply to Brian Karas | 07/27/17 09:14am

...the input field for the login password, on the very first page you hit when connecting to the camera, does not validate input data length...

This is Dahua's second vulnerability with a 10.0 CERT score, and also the second one this year. The previous one, the Dahua Backdoor...

Then this one must be the Dahua Frontdoor...

John Honovich

IPVM | 07/25/17 04:00pm

Dahua's entire International site, including the firmware fix link, has been down at least 5 hours now.

The 404 code means the server is up but somehow it has been misconfigured or broken such that it cannot find / return any pages.

Eventually they will fix it but it is hard to comprehend how a publicly traded technology company could have such issues.

John Honovich

IPVM | In reply to John Honovich | 07/26/17 12:32am

Update: After (at least) 13 hours, the site / links are now active. Download firmware to fix the vulnerability here.

Undisclosed #4

IPVMU Certified | 07/25/17 04:25pm

Longse is looking better and better everyday ;)

Undisclosed Manufacturer #8

In reply to Undisclosed #4 | 07/27/17 03:36am

Longse. We're happy looking better for the security. Joy camera!

Undisclosed Manufacturer #8

In reply to Undisclosed Manufacturer #8 | 07/27/17 03:38am

Full disclosure - I'm not actually a Longse employee...

Robert Shih

Independent
07/25/17 06:29pm

So after binwalking the firmwares in question, if this is Sonia related this may be very isolated to that specific chipset series. I'll see what else I can dig up in my off time.

Also, IF this is Sonia related as the bulletin asserts, this is not within the web interface (which is located in a different subsection of the firmware)...

Undisclosed Integrator #5

In reply to Robert Shih | 07/25/17 10:21pm

Any more information from binwalking the firmware Robert?

Robert Shih

Independent
In reply to Undisclosed Integrator #5 | 07/25/17 10:26pm

Sonia is not in the recorders, only the IPCs that I've seen. Not a consistently sized file so it's not the same version across all of them.

Also, this firmware chipset only applies to wireless cams...which I've sold like 2-3 of in a whole year? Doesn't look like it'll affect too many existing dealers...at all

Undisclosed End User #6

07/26/17 05:32am

With the reusing of code between Challenge and Sonia, I would not be surprised if the flaw exist in both. I guess the only way to find out if this is the case, is to dig into details how to exploit and do tests, or keep an eye on published FW updates and try to figure from there. Guessing also that the researchers will provide more accurate vulnerability list in the future than Dahua itself.

John Honovich

IPVM | In reply to Undisclosed End User #6 | 07/26/17 11:21am

With the reusing of code between Challenge and Sonia

#6, thanks. Can you elaborate on what 'Challenge' and 'Sofia' are and how they relate / differ?

Undisclosed End User #6

In reply to John Honovich | 07/26/17 05:13pm

JH,

Challenge and Sonia is the two main binaries into Dahua's devices, where the difference is only (more or less) the naming of the binaries itself, depending what "chipset" they have been adapted and compiled for.

They both shares to handle all WebGUI, HTTP/HTTPS server, ONVIF, RTSP, debug console... etc, in short - it's one big binary that handle almost everything regarding networking services and hardware.

The interesting thing is, when they are using same source code and are compiled for different "chipset" or architecture (ARM/MIPS... or whatever), vulnerabilities found in one architecture/chipset are most likely to exist in the others as well (D'oh).

This is the case with the Dahua Backdoor, so therefore I would not be surprised that this flaw exist in both Challenge and Sonia, and if successfully exploited you will become root (as the Challenge/Sonia binaries runs as root).

However, there could be a difference on the used Auth for password - since the flaw lays there, and there exist three different 1) base64, 2) Dahua 48bit hash and 3) MD5, and it could affect only those FW versions who support "MD5", and that could narrow down the vulnerable devices.

Anyhow, some dumps from a IPC to show the "Sonia" binary.

~ # ps ax | grep sonia
229 root 619:25 /usr/bin/sonia AEWB
347 root 0:00 grep sonia
~ #

~ # netstat -anp | grep sonia
tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN 229/sonia
tcp 0 0 127.0.0.1:9989 0.0.0.0:* LISTEN 229/sonia
tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 229/sonia
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 229/sonia
tcp 0 0 :::554 :::* LISTEN 229/sonia
tcp 0 0 :::80 :::* LISTEN 229/sonia
tcp 0 0 :::37776 :::* LISTEN 229/sonia
tcp 0 0 :::37777 :::* LISTEN 229/sonia
tcp 0 0 :::443 :::* LISTEN 229/sonia
udp 0 0 0.0.0.0:33027 0.0.0.0:* 229/sonia
udp 0 0 0.0.0.0:53312 0.0.0.0:* 229/sonia
udp 0 0 239.255.255.250:1900 0.0.0.0:* 229/sonia
udp 0 0 0.0.0.0:3702 0.0.0.0:* 229/sonia
udp 0 0 0.0.0.0:37778 0.0.0.0:* 229/sonia
udp 0 0 0.0.0.0:37778 0.0.0.0:* 229/sonia
udp 0 0 192.168.5.21:37810 0.0.0.0:* 229/sonia
udp 0 0 239.255.255.251:37810 0.0.0.0:* 229/sonia
udp 0 0 0.0.0.0:37810 0.0.0.0:* 229/sonia
udp 0 0 192.168.5.21:5050 0.0.0.0:* 229/sonia
udp 0 0 255.255.255.255:5050 0.0.0.0:* 229/sonia
udp 0 0 0.0.0.0:5050 0.0.0.0:* 229/sonia
udp 0 0 0.0.0.0:5353 0.0.0.0:* 229/sonia
udp 0 0 255.255.255.255:48879 0.0.0.0:* 229/sonia
unix 3 [ ] DGRAM 592 229/sonia /var/tmp/wpa_supplicant-global
unix 2 [ ] DGRAM 11430 229/sonia /var/tmp/wpa_ctrl_229-1

John Honovich

IPVM | In reply to Undisclosed End User #6 | 07/26/17 05:52pm

Thanks! Very helpful.

Btw, somewhat related, on The Register someone commented:

Sonia (for dahua) and Sofia (for jufeng/xiongmai) is just the name of a binary blob that provides both the GUI and the web/proprietary interface to the dvr/NVR/ipc.

This fits your description of Sonia. Do you think there is a Sofia which is similar For Xiongmai? And any sense if they are sharing code or?

Undisclosed End User #6

In reply to John Honovich | 07/26/17 06:16pm

Very interesting, could very well be so that Challenge, Sonia and Sofia share same code.

And one of the comments there on "The Register" regarding Hikvision, yes - they also do have one binary that provides most services (named davinci), but my analysis of both Dahua Challenge/Sonia and Hikvision davinci, I have not found that davinci share same code as Challenge/Sonia - but Rapid7 did quite lots of stuff with Hikvision some time ago, so maybe once back in the time perhaps they did (speculating now, as I find the habit to use one big binary for services and Hardware similar - and also odd).

And here is output from a Hikvision IPC.

# # netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 169/dropbear
tcp 0 0 127.0.0.1:52698 0.0.0.0:* LISTEN 2465/dropbear
tcp 0 272 192.168.5.20:22 192.168.5.120:52896 ESTABLISHED 2465/dropbear
tcp 0 0 :::8000 :::* LISTEN 343/davinci
tcp 0 0 :::554 :::* LISTEN 343/davinci
tcp 0 0 :::80 :::* LISTEN 343/davinci
tcp 0 0 :::22 :::* LISTEN 169/dropbear
tcp 0 0 ::1:52698 :::* LISTEN 2465/dropbear
tcp 0 0 :::443 :::* LISTEN 343/davinci
udp 0 0 0.0.0.0:60212 0.0.0.0:* 343/davinci
udp 0 0 0.0.0.0:3702 0.0.0.0:* 343/davinci
udp 0 0 0.0.0.0:37020 0.0.0.0:* 343/davinci
udp 0 0 0.0.0.0:5353 0.0.0.0:* 343/davinci
udp 0 0 0.0.0.0:5353 0.0.0.0:* 343/davinci
udp 0 0 :::546 :::* 343/davinci
udp 0 0 :::3702 :::* 343/davinci
udp 0 0 :::34739 :::* 343/davinci
udp 0 0 :::5353 :::* 343/davinci
udp 0 0 :::48879 :::* 343/davinci
raw 83328 0 :::58 :::* 58 343/davinci

Kenny Johnson

07/26/17 01:20pm

if a camera does not have its HTTP port forwarded or open then it is safe from this vulnerability. Right?

Also, this just affects cameras right? Not NVRs.

Brian Karas

IPVM | In reply to Kenny Johnson | 07/26/17 01:45pm

if a camera does not have its HTTP port forwarded or open then it is safe from this vulnerability. Right?

Yes, if there is no remote access to the web interface on any port then you should be safe from this vulnerability being remotely executed.

Also, this just affects cameras right? Not NVRs.

Undisclosed Manufacturer #7

07/26/17 06:09pm

Note that having devices that have a known vulnerability on your network can still be an issue. If an attacker gains access from another source, then they can use this vulnerability to gain access to the video, make changes, etc.

Yes, it isn't as critical as when devices are directly remotely accessible, but you shouldn't just ignore it.

Heikki Peltomäki

07/27/17 12:02am

It's not uncommon at all to have security issues. But when you sit on two months old information and won't give a fair warning to your customers... Well that is just plain disrespecting. This just makes one wonder, what else has Dahua kept from its customers. After all, like said, this was their second 10 score vulnerability in a short period of time.

Even without a fix, just warning about the exploit might help customers make their systems more secure, at least giving them a chance.

Turning a blind eye on something unpleasant doesn't make it go away.

Not impressed.

John Honovich

IPVM | 07/27/17 12:08am

UPDATE: Dahua USA has issued a press release on its website acknowledging the vulnerability, saying it only impacts 4 of their models but that a firmware upgrade is not yet available:

While the document is dated both the 25th and 26th, this was not live on their website until the 26th.

There is still no document or notice on the Dahua International website press release or cyber security section.

Robert Shih

Independent
In reply to John Honovich | 07/27/17 06:57pm

I think that's just listing the existing released US branded models. The only reason the firmware isn't "available" is probably because they didn't compile an NTSC branded copy yet.

The models listed on the other resources are for their complete/international line and they have the PAL firmware (branded from the website and unbranded in my repository).

Brian Karas

IPVM | In reply to Robert Shih | 07/27/17 07:00pm

The only reason the firmware isn't "available" is probably because they didn't compile an NTSC branded copy yet.

Considering this vulnerability has now been public for 10 days, Dahua should have had the NTSC version available at the same time, or within a day, of the PAL version.

Undisclosed End User #6

In reply to Brian Karas | 07/27/17 07:08pm

WTF, they had time since May 2017, no?

Now it's July 2017... ridiculous!

Undisclosed Integrator #9

07/27/17 07:04pm

OK, so if there was a "patched" firmware released... how many people would be able to send techs to all of their client locations to apply the new firmware???

Would you charge the customer?

This would take us weeks...

Undisclosed End User #6

07/27/17 07:04pm

Sadly enough I cannot trust the official list of vulnerability series from Dahua, as I personally know for facts there was far more series vulnerability to the Dahua backdoor than Dahua officially reported.

Read this IPVM report for free.

This article is part of IPVM's 6,538 reports, 881 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.