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)

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.

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?

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

 

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.

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.

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.

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.

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

rbl

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.

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.

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

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.

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

Longse is looking better and better everyday ;)

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

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

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

Any more information from binwalking the firmware Robert? 

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

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.

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?

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

 

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?

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

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.

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.

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.

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.

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.

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

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.

 

WTF, they had time since May 2017, no?

Now it's July 2017... ridiculous! 

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

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.

Already a member? Login here | Join now

Related Reports

Dahua Critical Cloud Vulnerabilities on May 12, 2020
Dahua has acknowledged a series of cloud vulnerabilities that researcher...
Dahua Taunts Australian Government, Continues To Sell Illegal Fever Cameras on Aug 10, 2020
Dahua is effectively taunting the Australian government by continuing to sell...
Dahua USA Admits Thermal Solutions "Qualify As Medical Devices" on Jul 02, 2020
Dahua USA has issued a press release admitting a controversial point in the...
Australia Dahua Faked Advertisement, Government Warns of 'Criminal Offense' for Not Registering As Medical Device on Jun 25, 2020
A full-page advertisement in a national Australia newspaper for Dahua's...
Dahua Loses Australian Medical Device Approval on Aug 04, 2020
Dahua has cancelled its medical device registration after "discussions" with...
Wrong Dahua Australia Medical Device Approved on Jul 20, 2020
Dahua's body temperature system is now in Australia's medical device...
US Surgeon General Unwittingly Showcases Sanctioned Dahua Temperature System on Jul 28, 2020
The US' top public health spokesperson, the Surgeon General, posted a photo...
Panasonic i-PRO Hid Huawei, Does Damage Control on Aug 21, 2020
Panasonic i-PRO hid their usage of Huawei from the public, continues to...
Dahua, Hikvision, ZKTeco Face Mask Detection Shootout on Jun 19, 2020
Temperature tablets with face mask detection are one of the hottest trends in...
Access Visitor Management Systems Guide on Jul 22, 2020
"Who are you, and why are you here?" Facilities that implement Visitor...
Forced Door Alarms For Access Control Tutorial on Aug 17, 2020
One of the most important access control alarms is also often ignored....
Dartmouth College Deploys K3 Temperature Screening on Sep 29, 2020
While Dartmouth College has a $6+ billion endowment, the College has bought...
Bottom: Integrators Start To Stand Vs Coronavirus on Apr 20, 2020
Good news - IPVM integrator statistics show that while coronavirus has hit...
The Insecure Verkada Access Control System on Jun 25, 2020
While Verkada touts the security of its system and that how their new door...
Fever Cameras Are Medical Devices, Per The FDA, Dahua, Feevr, Hikvision, InVid Contrary Claims Are False on May 28, 2020
Fever cameras are medical devices, despite what euphemisms various sellers...

Recent Reports

New Products Show Fall 2020 continues tomorrow with Genetec, Milestone, Avigilon, Microsoft and more! on Sep 29, 2020
IPVM's sixth online show continues tomorrow and will feature New Products...
Avigilon / Motorola VS Virtual ISC West on Sep 29, 2020
ISC West has historically been so dominant that no player would think of...
Dartmouth College Deploys K3 Temperature Screening on Sep 29, 2020
While Dartmouth College has a $6+ billion endowment, the College has bought...
Hanwha AI Object Detection Tested on Sep 28, 2020
Hanwha has added detection and classification of people, cars, clothing...
Favorite Access Control Manufacturers 2020 on Sep 28, 2020
200+ Integrators told IPVM "What is your favorite access control management...
OnTech Smart Services Partners With Google and Amazon To Compete With Integrators on Sep 25, 2020
A pain point for many homeowners to use consumer security and surveillance is...
The Future of Metalens For Video Surveillance Cameras - MIT / UMass / Immervision on Sep 25, 2020
Panoramic cameras using 'fisheye' lens have become commonplace in video...
Hikvision Sues Over Brazilian Airport Loss on Sep 24, 2020
Hikvision was excluded from a Brazilian airport project because it is owned...
China General Chamber of Commerce Calls Out US Politics on Sep 24, 2020
While US-China relations are at an all-time low, optimism about relations...
Verkada Disruptive Embedded Live Help on Sep 24, 2020
Call up your integrator? Have someone come by the next day? Verkada is...
IP Networking Course Fall 2020 - Last Chance - Register Now on Sep 23, 2020
Today is the last chance to register for the only IP networking course...
Drain Wire For Access Control Reader Tutorial on Sep 23, 2020
An easy-to-miss cabling specification plays a key role in access control, yet...
Norway Council of Ethics Finds Hikvision Human Rights Abuses "Ongoing" on Sep 23, 2020
Hikvision's involvement in "serious human rights abuse" in Xinjiang is...
IPVM Camera Calculator User Manual / Guide on Sep 23, 2020
Learn how to use the IPVM Camera Calculator (updated for Version 3.1). The...