Dahua ESM: "No One Can Prove" Our Backdoor Is Intentional

JH
John Honovich
•Oct 02, 2017
IPVM

The Tyco specifier backdoor defense has been joined, this time by a Dahua enterprise sales manager:

A few counters:

  • The Dahua 8888888 account is definitely intentional.  Whether Dahua intentionally allowed remote access to that or was just incompetent, only Dahua knows. But putting in that 88888888 account was intentional and was dangerous.
  • The Hikvision ?auth=YWRtaW46MTEK magic string was hidden to the public but someone intentionally programmed that in.
  • Dahua's response to their devices ongoing hacks has been terrible. If I was a Dahua sales person, I would quit I would not want to draw attention to this.
  • These 'unintentional' mistakes are so basic that even if you believe they are unintentional, it raises very significant concerns about the competency of these organizations.

Instead of these excuses, prove that your companies can do better. Can you?

(6)
(1)
UD
Undisclosed Distributor #1
•Oct 02, 2017

Sales people should run these kinds of responses by someone more technically educated in matters such as this before making themselves and their company look foolish (or worse).  "we ALL should be calling the Equifax hack a backdoor as well" - does he not realize that a backdoor is a method of intrusion and not an act in itself?

(3)
U
Undisclosed #2
•Oct 02, 2017
IPVMU Certified

These 'unintentional' mistakes are so basic that even if you believe they are unintentional, it raises very significant concerns about the competency of these organizations.

Gross negligence.

Pre-meditated malfeasance. 

Pick one. At least one.

 

(8)
(1)
(4)
UI
Undisclosed Integrator #3
•Oct 06, 2017
In reply to Undisclosed #2

Exactly...can you??

(1)
(1)
U
Undisclosed #4
•Oct 06, 2017

More unqualified commentary.

I bet Mobotix is looking pretty good to Hunter these days.  Woops.

(4)
bm
bashis mcw
•Oct 06, 2017

Mr Hunter

Please explain

# -[ Most importantly ]-
#
# 1) Undocumented direct access to certain file structures, and used from some of Dahuas own .js to load 'WebCapConfig' and 'preLanguage'
# 2) Direct and indirect re-usage of hashes possible, however with MD5 hash 'security improvements' in Generation 3
# 3) Essential needs for successful login we simply request from remote device and process, no need to guess nor bruteforce anything
# 4) Abnormally wide range of products and firmware versions that share same reliable attack method, to be 'just an vulnerability'
# - True vulnerability over a wide range products and firmware versions have always some unexpected anomalies, which is expected

 

(1)
(2)
(2)
bm
bashis mcw
•Oct 06, 2017
In reply to bashis mcw

Let me explain how and why I became and still are convinced this is an intentional backdoor, and in Hollywood style.

When I found out how to download the clear text user database with login and hashed passwords, I was totally convinced it was simply a bug.

When I then was looking at the password hashes in Gen2 I noticed the well known 48bit hashes, remembered the .js scripts I've been thru earlier, so it was bit strange.

When I checked the same with an Gen3 I saw it was another type of hash, back to .js in that device and found the MD5 generator.

Was thinking "can I use these hashes to login?", started to do some quick and ugly coding for the 48bits, and oh yeah... damn, worked just fine O_o

A bit of research was needed to figure out how the random MD5 was working, used Burp Proxy to see how it looked like for an successful login.

Did manual stuff in Python to see how, with what and if I could generate same result, thinking this can't be like this, and when I did - I stopped all work - left everything on the screen, I could not believe what I've just achieved...

After an hour or two I tried to put that together in my quick and ugly code, with the requests and processing from and back to the device, worked nicely.

Anyhow, the point here is: Think now about a small plugin for your favourite browser (Chrome/Firefox/IE/whatever) that simply do;

1. Download the clear text user database

2. Extract username and hashes

3. Get all details needed to know the encryption type, random key and all needed stuff from remote device

4. Simply login with passing over the 48bit hash, or compute the random MD5 hash

5. Full admin access granted, the plugin don't even need to have a button.

I'm the only one who thinking intentional backdoor? Or Dahua maybe cannot do proper coding?

 

(1)
(1)
Avatar
Jon Dillabaugh
•Oct 06, 2017
Pro Focus LLC

If you ask me, I am leaning towards complete and utter lack of professionalism as the cause, instead of the intentional backdoor. Dahua has a long track record of sloppy, mismanaged, crappy products. That said, your not buying a Rolls Royce when you buy Dahua. You’re buying a Jiangnan. 

(1)
bm
bashis mcw
•Oct 06, 2017
In reply to Jon Dillabaugh

Jon, that's worse than intentional backdoor, as that means they cannot do proper coding. 

I've been too nice...

 

(1)
(1)
U
Undisclosed #2
•Oct 06, 2017
IPVMU Certified
In reply to bashis mcw

Jon, that's worse than intentional backdoor, as that means they cannot do proper coding.

Only to a technical person like yourself :)

But if the choices are

  1. Can't be trusted to do proper coding 
  2. Can't be trusted period

#1 can be remedied, but what can you do with #2?

(1)
UD
Undisclosed Distributor #1
•Oct 06, 2017
In reply to bashis mcw

Yep, always seems to come back to the question: "Are they evil or just completely incompetent?" and which is worse?

 

(1)
bm
bashis mcw
•Oct 06, 2017
In reply to Undisclosed Distributor #1

Incompetent is defiantly the worse, as you can't even rely they *could* code an intentional unauthorised way in. AKA backdoor.

Hikvision scores +1 (again) 

 

(1)
(3)
U
Undisclosed #2
•Oct 06, 2017
IPVMU Certified
In reply to bashis mcw

bashis, you reputation concerning the art of the hack is nonpareil.

However, if I may ask, have you ever been an actual, day to day, in the trenches, working for hire, programmer?

 

U
Undisclosed #2
•Oct 07, 2017
IPVMU Certified
In reply to Undisclosed #2

However, if I may ask, have you ever been an actual, day to day, in the trenches, working for hire, programmer?

So maybe you have and maybe you haven't, but if you haven't consider this:

Its easy for such a hacker to imagine that they are engaging in a blow for blow duel with the engineer(s) who wrote the software under consideration.  Every piece of code is viewed by the hacker as if the engineer was writing it specifically to thwart the hacker.

Why wouldn't the hacker see thru such a lens?  After all, his day consists of nothing but looking for vulnerabilities in commercial code.  Don't software engineers spend their day thinking of nothing but how to outwit the hacker?

Unfortunately no, they have other concerns as well.  For instance they also have to:

  1. Write code that does something of value
  2. Write code that is modular and integrates
  3. Write code that is extendable and maintainable
  4. Write code that performs adaquately even with limited resources.

A working program that can be hacked is a liability.  But a non-working program that can't be hacked is useless.

Programmers create backdoors and other scaffolding in pursuit of program excellence, not necessarily with malicious intent.  

Yes, they need to do way better at security; chances are they haven't been incented to yet.  Hackers provide the incentive.

These are the Golden Days of camera hacking for sure.  Enjoy them while they last!

(1)
bm
bashis mcw
•Oct 08, 2017
In reply to Undisclosed #2

Yes, I have been in that trench, and I know the drill to "deliver".

Bug's will always be there, one way or another, but leave the R&D code out for production, and most of the Hikvision and Dahua problem would (and will not) not be any issue.

Frankly speaking about the "Golden Days", sure - I learn from it, but for sure it would been better for everybody without them.

 

U
Undisclosed #2
•Oct 08, 2017
IPVMU Certified
In reply to bashis mcw

Thanks for the response.

Frankly speaking about the "Golden Days", sure - I learn from it, but for sure it would been better for everybody without them.

That's a true and somber statement.

But, since you're being frank, tell me, when you are looking for a vulnerability and then Voila! a huge one appears, are you not happy to find it?

 

 

 

bm
bashis mcw
•Oct 08, 2017
In reply to Undisclosed #2

Looking for and finding vulnerabilities is one thing, and with that coming the challenge to try find out something "useful", but finding R&D code/backdoor/...whatever you want to call it, no I am not happy at all to find it - I would been so much better without it.

Nevertheless, it was important find, and needed to be reported, and why I reported in the way I did is well documented into my PoC. 

# -[ My Full Disclosure Policy ]-
#
# Normal vulnerabilites: I collect enough information about my findings and trying to notify the vendor to have coordinated disclosure
# Backdoors: If/when they are intended, the vendors wants to hide/keep them (of course), what would you suggest? Notify the vendor or Full Disclosure?
# Proof of claim: Screenshots or some Youtube video would not proof anything, so the claim couldn't be posted without real hard cold facts
# - Professionals within the CCTV industry needed to know, and the only place I knew were many of them, was at IPVM, and therefore the first post was made there.

U
Undisclosed #6
•Oct 08, 2017
In reply to bashis mcw

Vulnerabilities in devices that are supposed to make things safe are very worthy of serious scrutiny, and I applaud your efforts, bashis. It can certainly be a struggle to deal with companies and painful to know of all the sensitive risks in their devices while not having anyone else to tell about them. Fortunately some people care and many of them are here.

bm
bashis mcw
•Oct 08, 2017
In reply to Undisclosed #6

Normally it's not big hassle to talk with companies, I could give several names who actually doing a very good job when it comes this kind of reporting of security vulnerabilities.

Sometimes it is a very big hassle, some offering "rewards with NDA", some is quite offensive, some without any response until last minute or beyond offered time limit of Full Disclosure, or some without any response at all.

I believe this has something to do with their matureness when it comes to this kind of subjects, some is mature for it and some are not.

More Full Disclosure coming up. 

U
Undisclosed #2
•Oct 08, 2017
IPVMU Certified
In reply to bashis mcw

Sometimes it is a very big hassle, some offering "rewards with NDA"...

I know you are unmotivated by such tactics, but for many researchers "rewards with NDA" is what they are interested in, assuming the "rewards" are sufficient, am I right?

More Full Disclosure coming up.

Responsible or Zero-Day?  New vendor?

UM
Undisclosed Manufacturer #5
•Oct 06, 2017
In reply to Undisclosed Distributor #1

I met a bunch of Chinese developers during the last years. During our work, they often ask me silly questions on how to do basic tasks. After a while I was sick of answering questions, then I said "PLEASE, Google your question and click the first link! Damn!"... then I realized that he has no access to google... that was enlightening for me to understand why they do so many stupid mistakes.

These poor guys have no real/legal access to up to date informations. While the rest of the world can easily ask google to find some state of the art source fragments, ideas, discussions or open source projects, these Chinese guys are cut off alot of information, because the information is not indexed by Chinese search engines. 

Additionally most Chinese developers I learned to know, do not know Englisch language. They rely on translations... so if an information was not translated, then it does not exist.

Since these trips I believe to understand why these stupid things happen. So to make it short: They don't know it better, their skills are often many years behind the state of the art.

It's quite frightening if you ask them to encrypt a certain information and then they proudly come up with BASE64... /facepalm

(2)
(3)
U
Undisclosed #2
•Oct 06, 2017
IPVMU Certified
In reply to Undisclosed Manufacturer #5

Google your question and click the first link! 

btw, you can save a step by using the "I'm Feeling Lucky" button :)

(1)
(2)
UM
Undisclosed Manufacturer #5
•Oct 06, 2017
In reply to Undisclosed #2

Hehe, thanks for the hint, but I use the address bar of my browsers in 99% of my searches, then I need the additional click :)

Imagine the amount of time that 10K Hikvision developers could save this way... 1 click sums up in this case!

 

Back to topic:

I know that using VPN connections to bypass governmental restrictions is quite common in China, but the developers I learned to know just use it in special situations, not for their everydays work. Often just the supervisor has a VPN account, so the guys have to ask him if they can use it... this is a big barrier. 

(2)
Avatar
Campbell Chang
•Oct 09, 2017
In reply to Undisclosed Distributor #1

This has Hanlon's Razor written all over it.

Never attribute to malice that which is adequately explained by stupidity.

(1)
UI
Undisclosed Integrator #7
•Oct 09, 2017

Just more proof how incompetent not only the people at Tyco are, but Dahua as well.

I say incompetent only in an effort to obey Hanlon's razor, which states, "Never attribute to malice that which is adequately explained by stupidity."

(1)
(3)
New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions