Dahua Backdoor Uncovered

Reactions:

Janet Fenner

[Note: Dahua Official Response]

The vulnerability was not intentional in any means. The moment this was brought to our attention we have been reactive in creating a solution that is being made public every step of the way. We have alerted our dealer/customer base this morning and will continue to do so. Our next step is not to be reactive but proactive in creating better processes to ensure that vulnerabilities cease to exist.

Reactions:

(1)

(9)

(1)

John Honovich

IPVM

In reply to Janet Fenner

Janet, I concur that Dahua's response has been professional and proactive. And it is a major step up from Dahua's very low standards.

But Bashis does raise some important questions, e.g.:

Why encrypt the password hash in browser's Javascript in the same format as stored in the device?

If this is just a mistake, it seems like an egregious one for a company that boasts 3,000 'engineers'.

In other words, either Dahua has some serious engineering problems or Dahua did it intentionally. Neither conclusion is reassuring, though I agree that malpractice is superior to maliciousness.

Reactions:

(8)

Undisclosed Distributor #2

In other words, they're not evil, they're just incompetent. Is this better?

Reactions:

(6)

John Honovich

IPVM

they're just incompetent. Is this better?

I suspect the spin will be everybody makes mistakes, nobody's perfect, this is just a one off mistake, etc., etc. It was one guy having a bad day, that type of thing.

So not great options but certainly better.

However, such 'mistakes' should not pass the QA process and cybersecurity testing process of a publicly traded company. So they will hire a name brand firm (remember Hik hired Rapid7) and they can use that as proof that things are fixed. But software / firmware continues to be developed so there is always risk on new issues / 'mistakes' arising and Dahua may need significant overall improvements in their internal engineering team.

A critical issue here is that these devices cannot be cloud upgraded. Web services have critical vulnerabilities discovered but they are easier to handle since a single patch fixes all. With millions of Dahua devices across the globe, many if not most will never be patched.

The next step then is cloud management / control (e.g., Hik-Connect). Of course then you need to trust that the cloud service does not get hacked or provides a backdoor to the Chinese government, etc. So yes, better to take a hit for incompetence than maliciousness.

Reactions:

(4)

Undisclosed Manufacturer #5

Fat-finger Typo Breaks The Internet :)

I suspect the spin will be everybody makes mistakes, nobody's perfect, this is just a one off mistake, etc., etc. It was one guy having a bad day, that type of thing.

So not great options but certainly better.

However, such 'mistakes' should not pass the QA process and cybersecurity testing process of a publicly traded company.

Even publicly traded super high tech companies, largely considered the best in their particular field, can royally screw the pooch on an epic scale from time to time.

Reactions:

(1)

John Honovich

In reply to Undisclosed Manufacturer #5

IPVM

Even publicly traded super high tech companies, largely considered the best in their particular field, can royally screw the pooch on an epic scale from time to time.

You should be their PR consultant. "Hey Dahua's just like Amazon!"

I know you know this, but for others, one thing that's different with the Dahua situation is that this vulnerability has existed for many years across multiple generations of Dahua's products. During all that time, it was never caught. Another reason why there is a debate over whether it was an error or placed by Dahua.

Reactions:

(4)

Undisclosed Distributor #2

I've found in 10 years of dealing with these manufacturers that the term "QA" is a mind-boggling concept to them. They continue to shove new changes and "features" out the door on a regular basis with no evidence of them being tested at all. I've become accustomed to the following process when reporting bugs in order to try to help correct a problem:

1. Report a problem

2 - 5. Be ignored completely and resubmit the problem.

6. They could not repeat said problem when testing with totally different equipment.

7. Request that they test with identical equipment and firmware revisions.

8. Receive response that problem has been identified, but they are no longer developing for that model and the problem has been fixed on this brand new shiny model that we should buy.

9. After tearing my hair out and banging a flat spot into my skull against the wall, nicely explain that you can't just abandon products 2 months into their life cycle when a multiple year warranty has been offered.

10. 2 months later receive a firmware update that resolves the issue, but creates 2 other problems in the process.

11. Repeat step 9 until the lovely embrace of unconsciousness takes me to a happy place.

Reactions:

(4)

(11)

Richard Lavin

Salas O'Brien • IPVMU Certified

"2 months later receive a firmware update that resolves the issue, but creates 2 other problems in the process."

(singing)

99 little bugs in the code

99 little bugs

take 1 down, patch it around

127 little bugs in the code

(A coder friend of mine taught me that little ditty.)

Reactions:

(3)

Undisclosed Manufacturer #18

Poking around a device suggests this could well be a mistake. It looks like it is down to a poorly configured http config and then using incorrect permissions on the folder where this information is held.

The old IoT problem of running everything as root, cluttering the device with files everywhere and forgetting to secure all of them correctly. Something which was probably implemented 5 years ago and no one thought to revisit it.

NB: I'm investigating this for fun it is not actually my job.

Reactions:

(1)

Andrew Tierney

The question isn't "why encrypt it in the same format?", it is "why encrypt it at all?"

Client side password hashing needs to end. It makes server side password hashing pointless.

http://cybergibbons.com/security-2/stop-doing-client-side-password-hashing/

Reactions:

(2)

Jonathan Lawry

Trecerdo, LLC

If this is just a mistake, it seems like an egregious one for a company that boasts 3,000 'engineers'.

The definition of "engineer" is very different in other parts of the world. In North America and Europe, an "engineer" is assumed to have a 4-year baccalaureate university degree in an engineering discipline. In many Asian countries, the term is much looser, and can mean that someone merely has some certificate from a vocational technical course. When I hear quantities of "engineers" cited for these companies, I take it with a huge chunk of sodium chloride.

Reactions:

(1)

Jon Dillabaugh

In reply to Jonathan Lawry

Pro Focus LLC

So close. NaCl would have been much more geeky!

Reactions:

(5)

Luis Carmona

In reply to Jonathan Lawry

Geutebruck USA • IPVMU Certified

It actually irks "real" engineers when IT systems engineers call themselves engineers.

Reactions:

(3)

Kyle Folger

IPVMU Certified

The same is true when an audio integrator or sound system operator is called an audio engineer without having a PE. This is really due to our understanding in the US of what an engineer is and not by the definition of the word. It's why it's easier to just avoid the use of the word unless there is a PE involved. I guess if you clarify by saying mixing engineer there wouldn't be as many assumptions.

Reactions:

(1)

Jonathan Lawry

Trecerdo, LLC

Don't look at me, man. I'm a physicist!

(I just realized that spending my life begging for grants wasn't as much fun as access control systems!)

Reactions:

(3)

Undisclosed #1

In reply to Jonathan Lawry

Reactions:

(2)

(7)

Larry Tracy

•Apr 05, 2017

Don't forget the hobbiest engineers!!

Reactions:

Undisclosed Manufacturer #18

Maybe I'm wrong in pointing out that most people in this thread haven't gotten the information from the source of the python script but the first frame of your GIF animation where you accidentally missed smearing the URL.

Thanks. Your mistake saved time looking around the firmware to figure this out :)

Reactions:

(1)

Brian Karas

In reply to Undisclosed Manufacturer #18

IPVM

Thanks for pointing that out. I fixed the image and deleted the one with the unsmeared frame from our server.

The only way to really see that would have been to download the original .gif and examine the frames. Still, I apologize for missing that frame in the editor and leaving the URL in there.

Reactions:

Undisclosed Manufacturer #18

I spotted it briefly and went hunting for GIF editors to do exactly that.

Luckily I managed on the 7th attempt to hit the print screen button at the correct moment :)

Reactions:

Kyle Folger

IPVMU Certified

You may have deleted it from the page but not the Amazon server that hosts the file as the original .gif is still alive and well at the securitynewspaper.com link. I'm surprised that the links you upload to Amazon's server aren't secured links since I could download the file without being logged into IPVM. I realize that website could have simply downloaded the .gif and uploaded it again but I couldn't believe they just copied everything including your original links. You could lock the images to IPVM only as that would prevent a simple copy paste on other websites. Vimeo does that with videos so the links will only work when posted on the URL's you specify.

UM#18 - You don't need to take a screenshot at the exact time. You just need use a simple online service to explode each frame.

Reactions:

(2)

Jon Dillabaugh

Pro Focus LLC

In reply to Kyle Folger

Or simply edit it with MS Paint LOL

Reactions:

(1)

Undisclosed Manufacturer #18

HaHa ! The one time mspaint not handling anim GIFs would actually be helpful. Well done.

Reactions:

Brian Dombrowski

In reply to Kyle Folger

Nice ironic find of new back door to test the other back door. ;-) I wanted to try the file access out my SD49225T-HN. Now I can.

Reactions:

(1)

Undisclosed Integrator #3

In reply to Janet Fenner

Thank you for posting Janet. I find this to be a very brave action that I wish more manufacturers would replicate.

One key question is whether the Dahua OEMs have been notified and whether they will issue official statements so that non-Dahua labelled product users are made aware they will need to update their firmware.

Reactions:

(3)

(1)

John Honovich

In reply to Undisclosed Integrator #3

IPVM

One key question is whether the Dahua OEMs have been notified

I have talked to many of the Dahua OEMs. Overall they tell me either limited or no communication yet from Dahua. I am not surprised about that since Dahua is still scrambling to respond themselves.

I do think the OEMs will need to make a statement at some point. I have not pressed them right now since they are still trying to get information themselves. It is going to depend which models they OEM, whether they use the same firmware (most do I think, but not all), etc.

Reactions:

(3)

Robert Shih

Independent

We got our "official Dahua response" letter last night.

Reactions:

Undisclosed Integrator #4

What are the conditions to vulnerability? simply connected to the net? does it have to be port forwarded? I see it works regardless of credentials... what else?

Reactions:

Undisclosed End User #6

In reply to Undisclosed Integrator #4

Simply connected to network, port forward would be taken care of by UPnP (if inside Firewall) and UPnP not disabled.

Thats it.

So, i would advice, disconnect!

Reactions:

(1)

Brian Karas

In reply to Undisclosed Integrator #4

IPVM

Any device that has the web interface remotely accessible is vulnerable. That would generally mean port forwarded (either manually or via UPnP). And, of course, any device in a DMZ or directly connected would be vulnerable as well.

Right now this is a proof of concept, showing what is possible, attacks built on top of this could assume default/normal ports only, or could try many ports. So, do not assume that using a random port for web access would make you any less vulnerable.

Reactions:

(1)

Jon Dillabaugh

Pro Focus LLC

So if the device is still using the default port scheme (http port 80), then port 80 must be forwarded? Will this work on the mobile port 37777? Has that been ruled out?

Reactions:

Brian Karas

IPVM

Nothing has been ruled out yet. This attack is built on Dahua using a very insecure method to manage credentials and handle logins. It would not be unreasonable to assume that any port/service that allowed remote access/authentication is either susceptible to the same attack, or to a very similar derivative.

Reactions:

(1)

(2)

Kyle Folger

IPVMU Certified

I'm not surprised considering just a few years ago the Dahua products were limited to 6 alphanumeric characters. Dahua makes decent products as far as design and functionality but they have a lot to work to do on the software side. I wish these companies would spend money on having all devices checked by a reputable third party software security firm before shipping.

Reactions:

(5)

Undisclosed Distributor #2

In reply to Kyle Folger

I agree with you Kyle, but this goes against every "business practice" that they operate by because it would add additional costs which they consider unacceptable.

I recommend that we stop associating these products with the "security" industry and just call them "remote monitoring devices". The laughable concept of them offering "security" products that themselves are insecure is making this market even more difficult to survive in.

Reactions:

(3)

Jon Dillabaugh

Pro Focus LLC

While we rarely expose http on any device, we do have some mobile ports exposed on various installs. It would be nice to know if we need to close those in the meantime.

Reactions:

(1)

Brian Karas

IPVM

I asked Dahua for a comment on the mobile service specifically.

Reactions:

Robert Shih

Independent

On hard testing, I found that the web port (default 80) was the only port open for this attack. This means this attack does NOT affect the built-in firmware upgrade daemon that listens in at port 3800.

Reactions:

(1)

Brian Karas

IPVM

Robert - can you elaborate on how/what you tested? Did you use the script that bashis originally published, or something else?

Reactions:

Robert Shih

Independent

I attempted hard access of the named files within the directory structure using the available ports. TCP Port 37777 timed out whereas the other open ports actively refused the connection. This is reflected in a browser and in the script as well. I'd have to test with other known files in the directory, but overall, the two files that are most crucial seem to only be accessible with the web port right now.

Reactions:

Greg Masters

Robert:

I have examined the .py script. It would appear that port 80 is indeed specified at line 338 but what is to prevent one from changing the port to something else (if you know which http port the camera uses). Another case for changing all default ports...if you **must** forward ports.

I am concerned about my installs and better get to work testing. Thanks for your help here.

Reactions:

(1)

Greg Masters

On initial testing you better add the SD6C series of PTZ to the list.

Also the SD59 series.

Confirmed (-((((

Reactions:

(2)

John Honovich

IPVM

On initial testing you better add the SD6C series of PTZ to the list.

Also the SD59 series.

Thanks for those details, Greg.

We know the list is going to be much longer and we have asked Dahua for an update on when the list will be updated / finalized. We will certainly post updates as we receive.

Reactions:

Andrew Tierney

The vulnerability downloads a file over HTTP - it will only work on a port running HTTP.

Reactions:

Brian Karas

IPVM

I received a response from Dahua, they say the mobile client service is not affected by this.

Reactions:

Christian Laforte

If I were Dahua or Hikvision right now, I'd discretely offer Bashis a lucrative consulting gig.

Whether he would accept or not is a different matter. ;-)

Reactions:

(5)

Luis Carmona

In reply to Christian Laforte

Geutebruck USA • IPVMU Certified

I bet they offered him a camera.

Reactions:

(1)

(6)

Undisclosed #11

In reply to Christian Laforte

Christian, agreed- I would like to see is more of this open dialog from Dahua, (white) hats off to Janet once again for her direct approach on this latest matter.

In examining other industries, I find manufacturer's like Tesla, who embrace and monetarily reward the efforts of hackers like Bashis, far better reinforce peace of mind and commitment amid their customer base by openly discussing their software/firmware shortcomings and faults, lessening the blow and opening the door to an almost sympathetic collaboration. This open collaboration is how brand commitment is conceived, and manufacturers set apart from the rest.

Reactions:

(2)

Undisclosed Integrator #7

Being relatively new to the group, I was wondering how to determine what company(S) OEMs for Verint and Speco cameras.

Reactions:

Undisclosed #8

http://www.bbc.com/news/technology-39193008

That what I call breaking news

Wikileaks 'reveals CIA hacking tools'

http://www.mirror.co.uk/news/world-news/year-zero-series-wikileaks-cia-9981832

and you can Google lot more

Reactions:

(2)

Undisclosed Integrator #9

This kind of security issue is what makes buying OEM in general hard for me because these bugs and issues pop up and then have to go through so many different communication chains to actually get to the end product out in the field. It's great to hear Janet Fenner respond but she only represents the US Dahua market, what about Dahua China and the hundreds of OEMs around the world selling these products? Dahua USA won't have much of an impact on those devices.

This kind of stuff just makes me want to leave the industry too because as these vulnerabilities are continually found across all brands, as an integrator, that means time I have to spend manually updating firmware. In a lot of cases that means truck roles too if there is no onsite server I can access.

I wonder if manufacturers were forced to pay integrators to update manufacture's mistakes if they would think twice about security quality control?

Reactions:

(5)

(3)

Undisclosed Distributor #2

In reply to Undisclosed Integrator #9

One thing to consider is that the manufacturers want to totally eliminate the integrator completely. They would love nothing more than to sell direct to the consumer and run and hide while counting their money and letting the poor souls who get roped into doing the physical installation suffer tremendous amounts of drama and poor pay.

Reactions:

(1)

(3)

Brian Karas

IPVM

I don't think manufacturers want to "eliminate" integrators, as there are still a lot of end users that want/need someone to do the installation work for them. I do think many manufacturers would like to sell

I do think many manufacturers would like to sell direct to end users that are capable of doing their own work without getting pitchforks from the integrators though.

Reactions:

(1)

Undisclosed Distributor #17

Almost 9 months before Dahua opened in USA the Dahua USA CEO Tim Wang told me face to face that the re-sellers & installers are a dying market. They said they intend to remove the "layers", and they've been executing this strategy like clockwork.

Reactions:

(3)

John Honovich

In reply to Undisclosed Distributor #17

IPVM

they've been executing this strategy like clockwork.

I can believe Dahua's goal is to do this.

But let's be fair to Dahua. Nothing Dahua does operates like clockwork. The best metaphor for Dahua's operations is a drunk driver.

Dahua is only dangerous because they are willing to waste a lot of money, not because they have the talent or organization to accomplish their ambitions sustainably.

Reactions:

(4)

(2)

Andrew Tierney

In reply to Undisclosed Integrator #9

This is why secure, automatic firmware updates are the thing that needs to be done.

Without this in place, mistakes the vendor makes end up costing their customers money. This isn't a good dynamic.

Reactions:

(2)

(1)

Undisclosed Manufacturer #10

But how many integrators that sell in the low end would actually spend the time to go back and fix them? Not unless it's billable hours. Would actually be a great revenue generator. Sell and install a system with 1 year or less warranty (I've seen 90 days not be that uncommon), wait until that warranty runs out, then make a call saying "Hey, we need to update your firmware. Yeah, sorry about that, but you know we're not the manufacturer, we just install 'em." Recurring yearly/quarterly revenue.

Reactions:

Andrew Tierney

In reply to Undisclosed Manufacturer #10

Yes, that's why they need to be automated.

My router updates firmware and updates without me noticing. Why should DVRs be any different?

Reactions:

(2)

Undisclosed #11

Agreed wholeheartedly, Andrew, however, this is where a dual kernel OS becomes paramount-- imagine the chaos that would ensue were a firmware update to come through and reboot the system in the middle of an incident. Reminds me of a major metropolitan police department I worked with recently who yanked all of my competitor's gear because the watchdog was rebooting periodically, usually in the middle of an interrogation.

Reactions:

(2)

Andrew Tierney

It needs more than the kernel. The whole operating system needs mirroring. Nearly all modern microprocessors and bootloaders can deal with this though.

Reactions:

Eddie Perry

No automatic firmware updates would be a bad idea.

I have had firmware that delete settings, brick cameras, and all sorts of other weird things happen.

Updates should be done manually especially when you talking about flashing firmware to embedded Linux devices. god forbid you have a power blip while updating. need to be done on site or have end user/owner over see or initiate the update.

Reactions:

(4)

(1)

Luis Carmona

Geutebruck USA • IPVMU Certified

In reply to Eddie Perry

Cheaper the device, the more likely something will go wrong. Yes, I've seen high end cameras brick, too. But going more back to my IT days, that was the general rule of thumb.

Would be nice if there was something like an "update server" that could push updates at schedule times using basic "stages" rules, like 1/5 cameras this day, 1/5 of cameras that day, etc.

Reactions:

Andrew Tierney

A couple of vendors I work with use similar patterns.

One allows customers to put themselves into alpha, beta and stable. Alpha get updates immediately after QA. Beta after a few days of alpha. Production a week or so after. Any individual device can be updated immediately if needed.

The device holds several copies of firmware and if the upgrade fails, it will fall back. If the new version is unstable e.g. reboots 3 times in under 10 minutes, it will fall back.

I can't think of when they have bricked devices.

Another vendor simply trickles the update out. I seem to remember it being based on the last 2 bytes of the MD5 of the MAC address 0000->FFFF or similar. Starts slow and ramps up.

Reactions:

Andrew Tierney

In reply to Eddie Perry

Yes, that's because the vendors you have experience with are not competent at automating firmware updates.

If a vendor's firmware update deletes settings, it's a sign of serious incompetence. Settings should be entirely segregated from the OS.

Again, if a firmware update can brick a device, it's because they have not engineered it to not brick when it updates.

And if a firmware update can fail due to a power blip? Again, engineering incompetence.

Reactions:

(5)

Undisclosed Distributor #2

I think their incompetence has been very well established with these issues. The question now continues to be "at what point do the problems caused by their incompetence finally outweigh the desire to sell their cheap products?".

Reactions:

(4)

Andrew Tierney

When people stop buying the cheap products because of security concerns, or they are prevented from selling them by regulation.

I can't see either happening.

Reactions:

(2)

Robert Shih

Independent

In reply to Eddie Perry

Well, it could be manual execution with the ability to search a firmware server for the latest updates.

Reactions:

(2)

Andrew Tierney

Yes. Always allow for opt-out if desired, but strongly encourage users to automate.

Reactions:

Undisclosed Integrator #12

What's the old saying?

"Never attribute to malice that which is adequately explained by stupidity." - Hanlon's razor

However it seems like Dahua has made this mistake a few times before...

Reactions:

(2)

Undisclosed #1

how did bashis come across this backdoor in the first place? Did he/she specifically target this manufacturer to see 'what he/she could find'? (we need more of this)

Is he/she a researcher who specializes in security industry cyber security? (we need more of these)

I see bashis has published vulnerabilities in other security hardware.

For the record:

I would just like to let bashis know that what he/she is doing is a great service to the entire security industry.

Reactions:

(3)

Greg Masters

Unfortunately this backdoor script, while good, is not necessary. The real vulnerability is the **very simple and short*** url you need to download the camera account configs without any authentication. I really don't want to post in a public forum but its this simple:

Like: http://<ip><port>/veryshorttext/filename

The url you need is inside the script.

Then it is simple to extract all the usernames and passwords. All is in plaintext except passwords are hashed and can be reverse-hashed.

Repeat, running the script is not needed. This is just too simple. To test for this vulnerability all you need is an internet connection and a web browser, no knowledge of linux or python is needed. Obviously if your cameras are not on the internet...good idea but not always possible, you are not vulnerable.

I have asked Dahua and the distributor I purchased from for help with new firmware. A software developer I work with says because the source code for the SOC (Amberella) is proprietary it would be difficult to write new firmware without it.

The only fix until new firmware is made available would be to take the cameras off the internet or run image/video capture on a local server or DVR, and ssh/sftp into the local server to access the images. VPN access on the local server for camera configs. This can be automated and we are working on that option now.

Dahua, please step up and get us patched firmware!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Reactions:

(1)

John Honovich

IPVM

The real vulnerability is the **very simple and short*** url you need to download the camera account configs without any authentication

Greg, that is exactly what we described in the post above:

The affected Dahua devices allow a configuration file containing usernames and passwords (among other info) to be downloaded without authentication. The URL is not published and not easily determined from the standard web interface, making it effectively hidden. However, once known, it is simple for anyone to do. [Note: for security reasons, we are not sharing the exact URL.]

You say:

To test for this vulnerability all you need is an internet connection and a web browser, no knowledge of linux or python is needed.

Yes, you can but we are not going to give out the URL because that URL would help others exploit it.

Dahua, please step up and get us patched firmware!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I know they are working on it and taking this seriously. I don't when exactly the full list of models and firmware fixes will be published.

Reactions:

Undisclosed Integrator #12

Hey Greg, is this "very short and simple URL" part of their documented API? Because if this is what I think it is Bashis deserves a cookie and Dahua deserves a swift kick...

Reactions:

Greg Masters

In reply to Undisclosed Integrator #12

Undisclosed:

The url, AFAIK, is not documented. I looked in the http API docs and in the Network SDK information published. Its easy to find in the .py script, but running the script is NOT needed to test if you are vulnerable. I have a hunch most of their cameras are affected. I support two bullet types and three PTZ models, none are on Dahua's published list as of today and all are affected.

If you can find a published mention of this, that would be nice to know (for us) and really bad form for Dahua.

I agree with Bashis, this is too simple to be a mistake. I think it was intentional. My thoughts are not really important but we have 1000's invested with Dahua cameras and they better release a patch soon.

Reactions:

Greg Masters

I am replying to my own post.....I do not mean any disrespect for Dahua. Software vulns are part of the business, but this is so basic to see without any effort its hard to believe (for me) it was an accident. Maybe not sanctioned by Dahua, or by "official" design, but it is there.

I apologize if my comment implied any disrespect for Dahua. I think their products are excellent.

Thanks for listening

Reactions:

(1)

Robert Shih

Independent

I am right now working on pushing Dahua to develop and release the most updated firmware they can for this. Please, message/email me a list of your most urgently needed models and I'll try and help you as well if your own distributor is slow in getting you firmware.

Reactions:

(1)

Andrew Tierney

In isolation, allowing unauthenticated access to the hashed passwords doesn't allow access to the device. It's because the device the accepts the hashes that the vulnerability becomes serious. This is because it hashes the passwords in JavaScript in the browser. There is no such thing as "reverse hashing". You can only brute-force a hash.

Reactions:

(1)

Greg Masters

I stand corrected. "Reverse" is a poor choice in words. Hashes can be brute-forced if the algorithm is strong......but my source tells me these hashes aren't secure.

Nonetheless I may examine your suggestion if there is even a need to do this, if as you say the browser sends a hashed password which the device would accept. Thank you for your correction.

Reactions:

Undisclosed Integrator #12

Just at a glance it does not look like it requires authentication to use the GET/SET command via Dahua's API...

If this is the case once I know the IP Address of a running Dahua Device I should be able to run a script to GET any information I would want, or SET any values I would care to, for the camera.

GET http://<ip>/cgi-bin/config/...

SET http://<ip>/cgi-bin/configManager.cgi?action=setConfig&<...>[&...]

This is just my 2-cents from looking over the API for half an hour. I have a background in computer science, but not Network/Cyber Security.

URL for the API I am reading:

ftp://ftp.wintel.fi/drivers/dahua/SDK-HTTP_ohjelmointi/DAHUA_IPC_HTTP_API_V1.00x.pdf

Reactions:

Robert Shih

In reply to Undisclosed Integrator #12

Independent

That's an extremely old copy of that.

This link should be a little more up to date.

Edit: Yay, editing posts! Updated link.

Reactions:

(1)

Undisclosed Integrator #12

Thanks Robert. I am glad I was read old documentation.

Reactions:

Greg Masters

Robert:

Your link to the ftp server is good however the files here:

ftp://ftp.asm.cz/Dahua/kamerove_systemy/_SDK&API/HTTP%20API/HTTP_API_zaheslovane.zip

are password protected. The other files there extract OK.

Can you verify please?

Thanks

Reactions:

Robert Shih

Independent

Oh, did a bit of homework and found a new one: Booyah!

Edit: Additional homework revealing that most of those commands are not working.

Edit 2: Oh shit, learned how to still edit my posts after the normal time window for editing has closed. So yeah, commands work.

Reactions:

Robert Shih

Independent

Nevermind, they work. Forgot I killed my PoE switch before clocking out yesterday.

Reactions:

Greg Masters

That is the same documentation I was looking at. I thought http commands sent through configManager **did** require auth. Such as disabling telnet on some of the newer cameras, adding users, reboot, etc. I'll look again. I have not given much thought that these commands could work without auth.

But this backdoor is simpler than that. I have tested on SD6C, SD63, SD59, SD5200 bullet, 4200 dome, 3220 dome, SD6A series, all accept the URL.

Reactions:

(2)

Undisclosed Integrator #12

I am now even more curious about what you are talking about, but I think I need to research Bashis's code some more to figure it out. Hopefully I just misread the API... =_=

Reactions:

Undisclosed End User #13

Does IPVM bother to check CVE filings? I found Dahua has one filed for this on Feb 27th:
http://www.cvedetails.com/cve/CVE-2017-6342/

Also, the big "backdoor" claim seems a little on the reckless side, as that conjectures this was intentional. (Maybe it's click bait for new subs?)

I suggest IPVM learns more about CVE. There are vulnerabilities in a lot of products. And some very highly used ones have very high frequencies of them. Would you say Microsoft windows has "backdoors" or "security vulnerabilities"?

Reactions:

(1)

(4)

(1)

John Honovich

In reply to Undisclosed End User #13

IPVM

#13 thanks for sharing but that has nothing to do with this issue. Quoting from CVE-2017-6342:

An issue was discovered on Dahua DHI-HCVR7216A-S3 devices with NVR Firmware 3.210.0001.10 2016-06-06, Camera Firmware 2.400.0000.28.R 2016-03-29, and SmartPSS Software 1.16.1 2017-01-19. When SmartPSS Software is launched, while on the login screen, the software in the background automatically logs in as admin. This allows sniffing sensitive information identified in CVE-2017-6341 without prior knowledge of the password.

This, remote unauthorized admin access via the web, is completely different and much more severe.

Reactions:

(1)

Undisclosed #1

Note that the link to CVE-2017-6342 you provided contains these vulnerability details:

If you check that 2013 vulnerability (on that same site) it shows this:

So if, CVE-2017-6342 is a different vulnerability than this new one reported by bashis (as you point out), how is this 4 year old CVE-2013-6117 different from the bashis-reported vulnerability?

Based on that 2013 CVE, suspicious types might conclude that Dahua has long been aware of vulnerabilities that allow access to 'sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777."

Reactions:

(1)

Undisclosed #1

In reply to Undisclosed #1

This story was written by the guy who stumbled upon the 2013 vulnerability after he bought some cameras for his house and began to investigate these devices to better understand how they worked:

Dahua DVR Authentication Bypass - CVE-2013-6117

Reactions:

(1)

John Honovich

In reply to Undisclosed End User #13

IPVM

Also, the big "backdoor" claim seems a little on the reckless side, as that conjectures this was intentional.

The researcher himself believes this is a backdoor and that is explained in the post.

Considering you have confused one issue for another and you missed the researcher's own statement about believing it to be a backdoor, did you just skip the post and go straight to the comments?

Reactions:

(2)

Undisclosed Integrator #14

Does anyone know if ICRealtime NVR's or cameras are affected?

Reactions:

Undisclosed Integrator #3

In reply to Undisclosed Integrator #14

Unknown at this point unless someone can test it. It is entirely possible they write their own firmware or add some other secret sauce beyond slapping their picture on the GUI. I would contact ICRealtime to find out. I would get it in writing.

Reactions:

Undisclosed Manufacturer #15

I'm getting more and more angry, frustrated, and totally dis-heartened with the 'so what' attitude to these repeated warnings over the Dahua & Hikvision issues from parts of our industry.

Guys who have entered the market place in the last few years, due to the new low prices making it possible for them, where as before it was beyond them.

They are making hay while the sun shines, completely turning a blind eye to the risks and warning being given by IPVM, others sources, and the market as a whole - and when the times comes they'll throw there hands up in the air say 'not my problem' and go back to non-security electrical applications leaving their customer-base in the lurch and the market is a much worse place than when they joined it.

Hikvision and Dahua are bad for our market FACT for economic, political, and security reasons. I make no mention of UNV as they haven't had these published issues. So this isn't an attack on the Chinese brands before anyone accuses it of being so.

Reactions:

(3)

(1)

Undisclosed Integrator #3

In reply to Undisclosed Manufacturer #15

While I agree, let me get this out of the way: This email is almost instantly going to be invalidated because you are an Undisclosed Manufacturer, except not stated as eloquently.

Reactions:

(2)

Undisclosed Distributor #2

In reply to Undisclosed Manufacturer #15

I agree with you 1000%. Even when you try to advocate a better form of security or better security practices, for example getting rid of P2P, you are immediately shouted out of the building because "customers want easy" or "with P2P I can do 10 installs a day instead of only 5 when I have to set up port forwarding and DDNS". I'll say it again, these products in no way contribute to the true "security" industry, they are remote monitoring devices that are being offered by manufacturers that are either incapable or unwilling to step up and make the necessary changes to offer versions that embrace real security.

I welcome all rebuttals to this statement, I'd like to hear why you would consider me wrong.

Reactions:

Undisclosed #8

Can you explain please

what is wrong with P2P in your opinion?

Thanks

Reactions:

(1)

Undisclosed Distributor #2

This is my own tin-foil hat opinion. When I think of something being secure, I know how it has been set up and how it can be accessed. With P2P, you are passing your security off to the entity that is running the service and trusting that they are trustworthy. I have seen or heard of no disclosure as to content of the communications between the DVR/NVR/IP Camera and the P2P server. When the devices "phone home" in this manner to check in to see if there are connections waiting for them, I just don't trust that they may be checking to see if there are other instructions that they should execute. You are counting on the "trustworthiness" and "professionalism" of the managers of the services who are brokering these connections for you. I don't consider trusting others to do it for me as a security measure.

I have done some sample packet captures and found that there were packets going to IP addresses in mainland China, hmmm red flag for me there (slight pun intended). I've worked with a few of the manufacturers and inquired about being able to host and manage our own P2P service using their software, but they insisted that they would only do this if we rented the web space and granted them full root level access to the server to run it which I would rather cut my right arm off then allow this on a server that I had a part in managing. Also, when using a web access, these P2P servers want your client to log in and then the broker the connection between the host and the client, the traffic is at some point being managed by the service provider and who's to say that they aren't capturing all of these nice little treasures to keep for a rainy day.

Not necessarily falling so much into the security breach category, but you are also providing a living, breathing, verified e-mail address and other contact information to a company that at any time may become your direct competitor, and trust me they will not hesitate for one second to use it when they decide to market directly to those that they know have bought these "security" devices.

Using P2P is, strictly in my opinion, a cop-out where security is concerned, but I've pretty much given up on trying to advocate a better, more secure way of doing things like this, people just want quick and cheap. When the hammer falls, and it inevitably will, P2P will not end well for anyone.

Stepping down off the soap box, feel free to pick this apart at your leisure, but I stand firm in my views.

Reactions:

(1)

Undisclosed #11

SMH.

Reactions:

(1)

Undisclosed Distributor #17

Are you smacking your head because you're one of these untrustworthy MFGs? Why wouldn't you explain your reaction further? Smack your head a little harder next time or don't bother posting.

Reactions:

Undisclosed #8

Thank you for detail answer/opinion

I have different ? for you

Before client(phone) for example connect to Server(NVR/DVR)

using P2P what is the status of the ports(local router) on Server side

are they Open or Close in your opinion?

thanks

Reactions:

Undisclosed Distributor #2

I'm not sure that I'm clear on the nature of your question. Are you asking the status of ports on the NVR/DVR installation site? P2P allows you to not have to open any external ports to internal devices on a local network, because in the end, it is your locally installed NVR/DVR that initiates an outgoing connection (through the P2P "broker") to the client that requests the connection. Hope I understood that correctly.

Reactions:

(2)

(1)

Undisclosed #8

Thanks again

I was asking those ??? just for my own curiosity

if I understand P2P properly.

But, also create another question

if Ports are being closed all the time

then P2P kind of more secure?

Agree?

Reactions:

Undisclosed #8

Actually JH should create new discussion P2P ver Port forwarding

Reactions:

Jon Dillabaugh

Pro Focus LLC

The questions that need asked of your P2P provider are:

1) Is it encrypted end to end?

2) Can you trust the P2P provider to keep your account safe?

3) Can you host your own P2P server? Will they sell/lease you the software?

4) Does the handoff maintain an encrypted tunnel?

Reactions:

Undisclosed #8

Jon, do you know any companies using encrypted end to end P2P?

Reactions:

Jon Dillabaugh

Pro Focus LLC

Hikvision

Reactions:

(1)

Brian Dombrowski

Is anyone using or considering using VPN for their control/management plane of remote cameras and DVRs? OpenVPN is free open-source. I have remote Raspberry Pi VPN clients that tunnel to my OpenVPN cloud server. Zero port forwarding. They should just put openVPN clients into this gear.

Reactions:

(1)

Jon Dillabaugh

In reply to Brian Dombrowski

Pro Focus LLC

My issue here is that I manage many clients systems. If I have one VPN network, they will all be shared. For this reason, the VPN would only be used for my purposes, maintenance. While that would be fine, going forward P2P offers similar security, the same access, and I don't have to share the accounts between clients.

Reactions:

(1)

Undisclosed Distributor #2

In reply to Brian Dombrowski

I like your thinking and agree with you, this would definitely be a way to go. Thinking about the nature of connections, I believe a VPN would break P2P functionality. With the P2P service putting the client with the host, I don't think that VPNs can operate properly in the 3 party mode like that.

Reactions:

Brian Dombrowski

Lumping replies here.

1) I wouldn't use any proprietary P2P at all with a VPN. With VPN, it's like you're doing this all on your own private network. (i.e. image like your doing in all at home on your own LAN.)

2) If you have multiple client systems, you can handle that on one VPN server still, but you have to create policy for it. This is just a handy example where say these three separate types of users in the example are just three different clients. You cannot use this exactly as is but it shows how policy works in OpenVPN to make separate subnets.
https://openvpn.net/index.php/open-source/documentation/howto.html#policy

Reactions:

Undisclosed #11

I understand the paranoia, don't disagree with it, however, these are Amazon servers being used in the P2P service.

Reactions:

Undisclosed Distributor #2

But who is running/administering the applications running on the servers? Who is watching the traffic that goes out the side-door of the P2P server application to see where it goes to from there? I've personally seen this P2P server setup be sold as a "turn-key solution" and installed for a re-seller as a "courtesy" on a rented AWS service only to be hacked into due to negligence of the P2P provider and used as an agent for an attack on a mainland china site costing the re-seller thousands of dollars of bandwidth overage fees.

I don't dispute the reliability of the server platform that they are hosted on, I don't trust those running it to a point that I would sell this to a client as a "secure" solution.

Reactions:

(2)

Undisclosed Distributor #17

We rented some Amazon AWS servers from Dahua for DDNS & P2P. A month later Amazon sent us a nasty cease and desist letter, because our server was participating in DDOS attacks. The bandwidth cost was well over $1,000/mo, normally that server was $100/mo.

The server's location itself doesn't mean anything, it's the access & administration of the server that means something.The P2P feature is a software application, it is programming and code, physical location means nothing, except maybe latency.

Reactions:

(2)

Undisclosed Distributor #16

It's seems biased that a simular article on Hikvision would be public, and yet this article is not.

On topic, I hope manufacturers will start taking some of the good advice given in this thread so far. If an alarmpanel is installed without changing the code we blame the installer. If a CCTV installation is done with standard passwords I think it says a lot about the installer...

Reactions:

(1)

John Honovich

In reply to Undisclosed Distributor #16

IPVM

It's seems biased that a simular article on Hikvision would be public, and yet this article is not.

Dear Hikvision distributor, portions that are related to test results are typically member's only, e.g., Hikvision Discontinued 'Migration' Tested and the portion of the above report that was member's only. That is because tests take much more resources / money.

Indeed, with this report, the first 7 paragraphs / effective 1st page was free, so we still gave a lot free, just not the test results:

And think about it, is the title 'Dahua Backdoor Uncovered' really something positive for Dahua?

Reactions:

(1)

(3)

Orlando Ayala

Looks like these guys took care of giving away the test results for you.

{IPVM REDACTED}

Reactions:

(2)

John Honovich

In reply to Orlando Ayala

IPVM

Orlando, what they have done is copyright infringement and we will be filing a takedown request immediately. Thanks for letting me know.

Reactions:

(1)

(2)

Undisclosed Distributor #17

They didn't even remove your watermark!

Reactions:

(1)

Undisclosed Manufacturer #18

In reply to Undisclosed Distributor #17

They didn't even link to their own hosted GIF files. They hot linked them.

The trick back in the day was to then change said image for goatse.cx (NSFW).

That might get them to react.

Reactions:

Undisclosed Distributor #16

For sure it's not at all positive for them.

But a simular article on Hik was published publically:
https://ipvm.com/reports/hik-default-hack

The picture in the top is even the same.

So, why is one public and one private?

Reactions:

(1)

John Honovich

In reply to Undisclosed Distributor #16

IPVM

So, why is one public and one private?

I explained this in my first comment.

portions that are related to test results are typically member's only, e.g., Hikvision Discontinued 'Migration' Tested and the portion of the above report that was member's only.

The Hikvision default devices post did not have any testing. It was simply us reporting comments made in a discussion. The Dahua portion that was paywalled was our test results.

And by the way, last night we published a public report: OEMs, Dump Dahua.

I understand why as a Hikvision distributor you would not like our Hikvision coverage but suggesting that we are biased for Dahua is silly.

Reactions:

(1)

Brian Karas

IPVM

Has anyone downloaded new firmware and upgraded their devices yet? If so, please contact me, we would like to check some of the differences between unpatched and patched devices.

Reactions:

Greg Masters

•Mar 17, 2017

Hello I received a new f.w. for the "adreia" series PTZ. I have been told....not certain...that covers the SD6C220S and the DH-SD59220S cameras. Robert is pretty busy now. I have the file installed on a client's SD6C220S only and it appears to be no longer vulnerable.

Does the "S" imply Adreia series?

Reactions:

(1)

Greg Masters

Brian:

If I can get my hands on new fw I'm happy to test. I messaged Robert....our two most vulnerable cameras are a SD-6C and SD-59 PTZ. Hopefully he can get firmware which is not vulnerable. As of now nothing has been released (you probably have better info than me) for these cameras.

Reactions:

Robert Shih

Independent

I'll bug them tonight when their time zone rolls around. I only wish I had the superpower to wring someone's neck over TCP/IP.

Reactions:

(2)

Brian Karas

IPVM

We have also heard a report that Dahua's intercoms may be affected.

If anyone has a VTO2000A (or possibly other Dahua IP intercoms) installed we would recommend you consider them to have the same risk as Dahua cameras or recorders right now.

Reactions:

Robert Shih

•Mar 11, 2017

Independent

I'll tell my Cali office to set some up and test them. They haven't arrived in Houston yet.

Reactions:

Orlando Ayala

Just received a phone call from a Dahua representative. She asked what products I had deployed in order to streamline my update process. She seemed genuinely concerned and was very helpful when I pressed her on some specific questions. Between this and the 3 emails I have received since Monday I have to say I feel like they are moving quickly and with a purpose to alleviate this enormous problem.

That in no way absolves them from what is apparently egregious incompetence or bad will. But I've always been one to respect those that own their mistakes and bad judgement.

On an interesting side note, she mentioned the possibility of reimbursement for billable hours or even sending out Dahua techs to apply updates for us(not happening even if true). She also mentioned that Dahua OEM is a separate entity from Dahua N.A. and those updates should be acquired from the OEM directly.

Reactions:

(1)

(2)

Undisclosed Manufacturer #15

I just saw a supposed 'Security Professional' comment on LinkedIn "what a load of rubbish, fake news"

It's been acknowledged by Dahua mate!

Funnily enough; he's a Dahua sub-distributor so there's no conflict of interest or anything

Shameful. Zero credibility.

Reactions:

(2)

(1)

Brian Dombrowski

Not intending to derail this thread by any means, but Dahua does have a handy distraction today with the wikileaks news about this stuff being used by the CIA. Also on Today show this morning as shown here. Love my 2005 Honda still.
http://www.today.com/video/could-your-car-be-hacked-by-cybercriminals-an-eye-opening-demonstration-893790787889

Reactions:

Jon Dillabaugh

In reply to Brian Dombrowski

Pro Focus LLC

Those dumps were two days ago, one day after this report was published. I wonder if all the people here who bash the Chinese for their use of cyber spying will denounce the same from the GOAT (C.I.A.)?

Reactions:

(2)

(1)

Undisclosed #1

Reactions:

(9)

Undisclosed End User #6

Dahua @ Web Interface Remote Access

You really want this?

Then no "backdoors" will needed to implement by the manufacture, you giving them direct access to your devices...

Reactions:

Brian Karas

IPVM

Good point. People are concerned about backdoors, yet they trust P2P, which is essentially giving the manufacturer the same degree of access.

If you do not trust a manufacturer, you probably should not have the devices accessible over the public internet, P2P or port-forwarded, it is all the same.

Reactions:

(1)

Undisclosed End User #6

If you don't care about the access - enable this junk, if you do care about the access - do not enable this junk!

As I said, you are giving away your credentials to the manufacture (and who else?).

It's so obvious, that it should not even being needed to be questioned from my side.

Reactions:

John Honovich

IPVM

P2P, which is essentially giving the manufacturer the same degree of access

Well, P2P is giving the manufacturer / provider the key to your front door...

Reactions:

(1)

Undisclosed End User #6

•Mar 11, 2017

Exactly

Reactions:

Undisclosed End User #6

•Mar 11, 2017

Trying to recall where, but can't remember where I read that Dahua customers with P2P enabled had already been "patched/non vulnerable" only because they using P2P...

Eh, okay? What does P2P stands for? Isn't that Peer-2-Peer? And, how can these devices already been "patched" ?

Reactions:

Undisclosed Distributor #2

So, after only a week this story is off of the front page and "out of sight out of mind" for the majority of people. I acknowledge the stories about Flir and Honeywell issuing statements, but is there any follow-up being done with dahua for updates? These manufacturers are notorious for just ignoring problems and hoping they will go away and for the most part they get their wish. How serious does it have to be for their to be a real effort to hold their feet to the fire to get a resolution?

Reactions:

(1)

John Honovich

IPVM

is there any follow-up being done with dahua for updates?

Yes, repeatedly.

And, as you mentioned, we just released the Honeywell report 4 hours ago, so obviously we have not forgotten about this.

The main thing we keep asking for is the complete list. The public list is still at 11 devices (the same from 8 days ago) but it is obviously way way higher than that. The question is how we should cover it next. The best solution is to just release the list.

Btw, Dahua can play dumb or try to ignore for now but, since the vulnerability is so straightforward to exploit (more dangerous than previous default password attacks since this requires no authentication) their devices are going to get hacked and when it does they face the risk of another major hacking incident.

Net/net, we are absolutely going to continue to cover this on multiple angles.

Reactions:

Jon Dillabaugh

Pro Focus LLC

The issue I have is that I don't necessarily know what the part number of the affected units I have are. They were OEM and purchased before Dahua USA opened shop.

You also have Dahua USA with different part numbers than China. Which model number, if I could figure out what I have, do they want?

One big cluster f%#$ and the worst part is, we saw this coming. I just dealt with getting updates for the RTSP issue late last year, and now we are on the witch hunt again trying to track down what should be simple firmware updates.

NOTICE: This comment has been moved to its own discussion: One Big Cluster f%#$ And The Worst Part Is, We Saw This Coming

Reactions:

(1)

Undisclosed #1

"So, after only a week this story is off of the front page and "out of sight out of mind" for the majority of people."

That sounds like you are inferring that IPVM is somehow 'burying' the story.

In reality, IPVM is publishing so many new pieces since the addition of some of their new employees that ALL stories from the front page get pushed back 'out of sight' as time itself marches along.

fyi, the main page stories also show up on the Discussions page - and any new update to the thread moves it right back up to the top, i.e. no longer 'out of sight'.

Reactions:

Undisclosed Distributor #2

In reply to Undisclosed #1

I never meant to infer that IPVM was not doing a fantastic job in their coverage and know they would provide updates if they become available. What I'm hoping to read is first hand response from dahua themselves. They seem to climb into their hole when things like this occur (Mirai botnet, anyone?) and just hide until it blows over and then act like it never happened. This is mostly about the OEM side which dahua USA seems to claim is an entirely different company. The PR persons first comment in this thread showed some promise in that something was actually acknowledged, but for all we know she may have been canned for that.

I would just like us to, as an industry, continue to hold them accountable until an actual fix is produced. I'd like to really see them sweating at ISC West when they can't offer any answers except "Hey, look at this new shiny product coming out that won't do that at all".

Reactions:

Robert Shih

•Mar 15, 2017

Independent

Actually we're getting firmware already to fix this and I've tested the results. So far so good, but we need more models.

Reactions:

(1)

Undisclosed Distributor #2

•Mar 15, 2017

Interesting, are they issuing firmware for OEM'd versions of their products or for dahua USA versions?

Reactions:

Robert Shih

•Mar 16, 2017

Independent

Honestly, the only difference is UI branding. They're completely interchangeable.

Reactions:

Undisclosed End User #6

•Mar 18, 2017

Another interesting report can be read here - Dahua Cameras Unauthorized Access Vulnerability Technical Analysis and Solution

Reactions:

Undisclosed Distributor #2

Has there been any further updates from dahua about this? Are they still following up with their OEM vendors? Do they have a website of some sort to which people who have purchased their products can be sent for updates?

Reactions:

Undisclosed End User #6

http://us.dahuasecurity.com/en/us/Security-Bulletin_030617.php

Don't feel so no..

10 Updates listed here

55 Updates listed here (on the "new" Firmware link)

http://www.dahuasecurity.com/download_111.html

Reactions:

(1)

Greg Masters

I have said before I think their hardware is quite good. I cannot explain nor figure out why their support is , well, complicated.

They have developed firmware fixes for a lot of cameras which are not on their dahuasecurity web page or press release. I can speak from personal experience. We have a number of cameras deployed with "Adreia" series cameras, and Dahua has provided a fix. Verified to close the backdoor.

Suggest you contact Robert Shih n this forum, he has been very helpful.

Reactions:

(1)

Undisclosed End User #6

If they have fixes available, why not inform about them or even push them online... make no sense!

Time to make own archive and publish? (Well, think that would break the "law"?)

Reactions:

TOSHIAKI TANAKA

All,

The followings are my understanding regarding this article. Can someone correct me if there is anything wrong:

1. Hashed value of the admin account password can NOT be simply decrypted, but sometimes the original password can be gained by attempting to compute many possible passwords which could match the hash value.

2. Firmware update is necessary for affected models of Dahua camers. If this firmware update cannot be done remotely, we have to visit all the sites where affected cameras (1 million devices in total!) are installed for local firmware update.
Can someone tell me if the firmware update can be done remotely or not?

Any kind of comments are welcomed.

Regards,

Reactions:

Undisclosed End User #6

In reply to TOSHIAKI TANAKA

>1. Hashed value of the admin account password can NOT be simply decrypted, but >sometimes the original password can be gained by attempting to compute many >possible passwords which could match the hash value.

Correct, cannot be decrypted. But, can be brute forced or hash compared, how long time for brute forcing / hash comparing depends of the originally used password.

>2. Firmware update is necessary for affected models of Dahua camers. If this >firmware update cannot be done remotely, we have to visit all the sites where >affected cameras (1 million devices in total!) are installed for local firmware update.
>Can someone tell me if the firmware update can be done remotely or not?

To my knowledge, they should be remotely updatable, but others may correct me if I'm wrong for some possible devices.

However, this backdoor don't need to have any brute forced, hash compared or known password, all that is needed is to use the downloaded login name and password hash (without knowing the password) to login.

Reactions:

TOSHIAKI TANAKA

•Mar 29, 2017

In reply to TOSHIAKI TANAKA

Thank you very much for your comments!

I wish to know more on your explanation "all that is needed is to use the downloaded login name and password hash (without knowing the password) to login."

I thought that the admin password hash (would-be encrypted password) extracted from the config file, then the above hash value should be analyzed by brute force or rainbow table, whatever. If you are lucky, you will get the original password.
This was my assumption in accordance with the following description in the article.

Backdoor Demo

The proof-of-concept code released by Bashis automated the process of downloading the config file, extracting the admin password hash, and then using that to compute the real password that could be used to login to the device.

Reactions:

Brian Karas

•Mar 29, 2017

IPVM

Toshiaki -

I edited that text to make it more clear:

The proof-of-concept code released by Bashis automated the process of downloading the config file, extracting the admin password hash, and then using that to compute the string the device would expect from a client sending a valid password that could be used to login.

Here is basically what happens (UE6 can probably provide more technical details):

Javascript that is part of the login page on the camera/DVR performs an MD5 hash of the password the user enters, and then combines this with the user name, and a random value that the camera sent as part of a cookie.

The client then passes that to the camera as a login token, which the camera inspects to see if the value of that token matches what it would expect from that client.

Because the camera is storing the hashed password value, and also exposing that to any person/script that calls the right URL, it is relatively easy to pass that hash back to the camera with the username and a random string to create the same token the camera would expect from a real user who typed in the right password.

Reactions:

TOSHIAKI TANAKA

•Mar 30, 2017

Brian,

Thank you very much for your insightful explanation! I finally understood the mechanism of backdoor. (Neither brute force nor rainbow table is necessary)

Many Thanks,

T Tanaka

Reactions:

Greg Masters

In reply to TOSHIAKI TANAKA

If you can access the web UI, then, yes the firmware can be remotely updated. Doing so does not remove the user accounts or change network settings. DISCLAIMER: I have done so on a limited number of models (three) cameras, 14 in all. I do not recommend remote f.w. updates, but it has worked for me. Im my case it was a three hour drive to visit the site, if the remote upgrade failed. So we took the chance.

The hashed passwords can be used as-is to log in...but not directly.

While the hash cannot be easily decrypted, there are methods (rainbow tables, brute force) to get the creds. But in this case, it is not necessary.

It appears the new patch may affect mobile apps like IP Cam viewer, and others, from using http, even with authentication.

Reactions:

(1)

TOSHIAKI TANAKA

•Mar 29, 2017

Greg,

Thanks for your response.

Please allow me to ask you the same question to User #6 as above.

I wish to know more on your explanation "The hashed passwords can be used as-is to log in...but not directly."

Backdoor Demo

Reactions:

Greg Masters

SIDE-EFFECT of firmware patch: It appears the patch affects the user cred file (you know what it is) in a malformed way, if you look at your user account page you will see a new user "null" added. While we tried deleting it, that was unsuccessful. Also another user management app which I am told uses Dahua's protocols was unsuccessful.

I don't think (am unsure, actually) this is a risk but it is uncomfortable. Since telnet is disabled (and can't be reenabled with the http API url) we can't directly edit the account file. Serial access might work but its too much of a hassle and requires physical access to the camera....my curiosity might get the better of me on this.

ANYONE know how to "delete" this "user"? Is this any risk to leaving as-is?

This is confirmed on "S" series PTZ.

remove nulluser

NOTICE: This comment has been moved to its own discussion: Dahua Backdoor Patch Creates A New User "Null"

Reactions:

Undisclosed End User #6

Sure, it's probably script bug while messing with the user database... (most probably old default admin account that they tried to wipe out)

Can you edit the user? Set password at least?

Most probably the login name that contains nothing (aka empty login name), and the GUI shows "null", could even be so that the password is the same. So, it could be no login and password.

If you can set password on that account you should be fine, think it would be bad if you could not..

Reactions:

Greg Masters

Hello, modifying that "user" is unsuccessful. I had tried to set a password, or at least remove from admin group, besides deleting the "user".

At least user: "blank" pass: "blank" does not appear to work.

Thanks for your comments

Reactions:

Undisclosed End User #6

http://www.dahuasecurity.com/firmware_111.html

Think you should report it to cybersecurity@dahuatech.com soonest

Reactions:

Undisclosed End User #6

•Mar 31, 2017

FYI,

Listing 131 "new" firmwares available for download, I have no idea if this is connected to the recent backdoor or not (since they still using old/weird date stamps, whatever...), but i guess it's good for you to know that this list has increased from 55 to 131 the last two days.

Mostly covers: IPC/NVR/XVR/HCVR/SD/TPC

Reactions:

Greg Masters

•Apr 01, 2017

User #6, that is true, they (Dahua) do not appear to be changing filenames in the early patched releases. It would be easier if they did. I believe...but can't prove...all of the ones added on that page have been patched.

Dahua, if you are here, it would be better from a customer service standpoint to update the filenames. How is a customer to test their installs without knowing if the firmware is patched...or using the exploit code/url themselves to test? On their own or on a client's network, with permission, please. I can say for sure the five or six models we have received new f.w. for are not vulnerable only because of direct testing on them.

Without this certainty your some of your customers/integrators are left behind in a field of gray.........

Reactions:

John Honovich

•Apr 01, 2017

IPVM

In reply to Undisclosed Manufacturer #19

Dahua, if you are here, it would be better from a customer service standpoint to update the filenames

We made this point to Dahua weeks ago. I am sure many others have done the same. Why they don't update the filenames is unclear.

How is a customer to test their installs without knowing if the firmware is patched...or using the exploit code/url themselves to test?

Dahua has told us they recommend customers to call in to technical support and that support will personally help each customer.

To your underlying point, I agree it would be easier for most if they made it easy to self-serve with clear public information.

Reactions:

Undisclosed Manufacturer #19

•Apr 09, 2017

Has Bashis re-released the proof of concept script?

"The researcher plans to re-release it on April 5th."

Reactions:

John Honovich

•Apr 09, 2017

IPVM

#19, The researcher has decided not to re-release it due to the large number of devices at risk and that third parties have already validated it. However, knowledge of how to exploit the backdoor is growing and impacted devices should certainly be upgraded / patched.

I've updated the original post to reflect that. We also discussed that in this report - 1 Million Dahua Devices Exposed To Backdoor

Reactions:

Undisclosed #20

•Apr 09, 2017

IPVMU Certified