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 ********
*****'* *** ********* ** ********** ** stack ****** ********, ********* ** ****, ********* ** the ** ***. ************, *** ***** field *** *** ***** ********, ** the **** ***** **** *** *** when ********** ** *** ******, **** not ******** ***** **** ******. **** can ** **** ** ** ******** to ****** *********** **** **** ** the ******** *****, *** ******* * buffer ******** ** *** ****** **** that ********* *** *****.
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.
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).
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)...
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.
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.
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).
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.
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.
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???
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.