Dahua has acknowledged a series of cloud vulnerabilities that researcher Bashis discovered. Additionally, and separately, researcher Thomas Vogt found a separate vulnerability.
Dahua was hardcoding all of their major OEMs "cloud" DES/3DES keys in their executable that was being distributed. Just shameful. At least let the OEMs choose their own password and secure it themselves? I cannot think of a legitmate reason to do this.
This is the most insane thing to me. It's one thing if their cloud team has prioritized other things than updating the retired DES and 3DES hashing algorithms which is bad but understandable, but hardcoding the encryption keys in the executable for all their customers has never been and never will be acceptable in terms of security.
Dahua's cloud solution is used for Dahua branded equipment as well as 22 OEMs and has hardcoded cloud keys stored within an executable that was distributed to users and available for download via the web.
It would be bad if they only distributed the executable with the keys internally at Dahua, but it's a catastrophe that these executables have been out in the public with the encryption keys.
EDIT: It also surprises me that none of the OEMs has had a requirement that they want to use a encryption key that they have generated themselves rather than one that was supplied to them. I'd assume that someone who set up the system for the OEMs would have realized that this was kind of strange, or maybe Dahua set up the cloud instance for them?
I would assume as you mention, that Dahua simply set up the cloud for the OEMs. Or maybe they don't even use it but it is enabled in the firmware and thus they provisioned it.
The reason for the lack of security is that it is easy. That is why all of these companies go to an OEM.
Not really, OEM has their own Cloud keys and entry IP/FQDN to their Cloud. (My PoC has only exposed Dahua/IMOU IP/FQDN, I found OEM's IP/FQDN in same executable too, but didn't find it necessary to expose them in the PoC description, OEM cloud keys where enough)
When it comes to 3DES credential leaks via DVRIP and DHP2P, yes - they share same PSK.
Edit:
3DES and hardcoded PSK are within the NetSDK, so anything compiled with the Dahua NetSDK (clients/devices) share same PSK, pretty natural since one side needs to encrypt and other side need to decrypt - but the thing is that these credentials are sent to remote for requesting REALM/Random for DVRIP/DHP2P, and not only while login with 3DES.
I did an update on my Dahua Debug Console script with 3DES login as well, (however w/o credential leaks), but at least you can try that out if you want.
Dahua's time has come and gone. It was nice having cheap analog cameras back then, but now that we put them on our networks it is plain stupid to use them. No one ever got fired for NOT using Dahua.
Time to upgrade, and please check your new vendor thoroughly for security before you switch. Have a network security professional review the implementation before you go forward.
Name withheld for security reasons. Now how about Hik?
Update: This report has been updated to reflect that,despite it being 9 months since the press release, there is no progress to speak of with regards to the Dahua / Pepper relationship. Dahua has not responded to our request and Pepper responded stating:
After checking internally, we do not have updates on the IMOU devices to share at this time.
IPVM conducts reporting, tutorials and software funded by subscriber's payments enabling us to offer the most independent, accurate and in-depth information.
Comments (10)
Undisclosed Integrator #1
To confirm was the issue reported to Dahua before public disclosure? I don't understand why the cloud would be enabled by default !?
Create New Topic
Undisclosed Manufacturer #2
This is the most insane thing to me. It's one thing if their cloud team has prioritized other things than updating the retired DES and 3DES hashing algorithms which is bad but understandable, but hardcoding the encryption keys in the executable for all their customers has never been and never will be acceptable in terms of security.
It would be bad if they only distributed the executable with the keys internally at Dahua, but it's a catastrophe that these executables have been out in the public with the encryption keys.
EDIT: It also surprises me that none of the OEMs has had a requirement that they want to use a encryption key that they have generated themselves rather than one that was supplied to them. I'd assume that someone who set up the system for the OEMs would have realized that this was kind of strange, or maybe Dahua set up the cloud instance for them?
Create New Topic
Undisclosed Integrator #3
Dahua's time has come and gone. It was nice having cheap analog cameras back then, but now that we put them on our networks it is plain stupid to use them. No one ever got fired for NOT using Dahua.
Time to upgrade, and please check your new vendor thoroughly for security before you switch. Have a network security professional review the implementation before you go forward.
Name withheld for security reasons. Now how about Hik?
Create New Topic
John Scanlan
Update: This report has been updated to reflect that,despite it being 9 months since the press release, there is no progress to speak of with regards to the Dahua / Pepper relationship. Dahua has not responded to our request and Pepper responded stating:
Create New Topic
Jon Dillabaugh
05/15/20 03:22pm
The only people voting STRONG in the poll above are Dahua sales guys. Even their techs would vote WEAK. The honest sales guys said AVERAGE. 🤣
Create New Topic