Hikvision Responds To Cracked Security Codes

Avatar
Brian Karas
•Published Aug 15, 2017 15:31 PM

Hikvision has responded to IPVM's report on Hikvision's security code being cracked, both with a 2 page update to dealers and communication directly with IPVM.

In this note, we examine Hikvision's response, evaluating the positive and negative elements of it.

Good

On the positive side, Hikvision:

  • Revamped the password reset procedure to a method that is more challenging to crack
  • Has been releasing new recorder firmware that makes an improved method available to users

Bad

On the negative side, problems remain:

  • Hikvision knew about the cracked codes for a long time but never notified dealers until after IPVM published
  • The new method still cannot be disabled
  • The new method still risks being cracked

Improved ******** ******** ** *********

******* *** ******** (*******) ******** *** generating ***** ***** *** *********** ****** the ******* ** ******* ******* ******, Hikvision **** *** *** ******* ** centrally ****** ****** *** *******, *** access ** **** ******** **********. **** should make ** ****** ** ** ** be ****** *** / ** *******

New ******** **** ******

********* ****** *** *** ******, ***** they ***** ** ** *** "**** key ******** ********" ** **** ******, though **** *** *** ******* ********* *******, such ** ** ** *** ***** on ****** ********** ** ********** ** a *********/******** ***** ********.

*** ******* ******** ** ******* ** before **** **** ***** ********* *******, sent ** ********* *******, * **** or **** ** ******** *** **** code/file ******** * ******** *****.

***** *** ******** ******* *** ***** on *** ******'* ******* **** *** serial ******, *** *** ****** ******* to ****** ** ** ***** **** of *** *********, ***** ** *** Hikvision ********* *** *******:

  • ****** ****** ******
  • ****** ****
  • ******* ***** ******** ** ***** ******** age
  • ****** ** *** ******** ** ****** number ******** ** ******

*** ***** *******, *** ******** ***** data, *** **** ** **** * random *****-******* ******, ***** ** **** sent ** ********* *******. ** ******* of **** ******, **** *** ** our **** *****, ** ***** *****:

(**** *** ****** ****** ** ********* in ********* ** *** *** ** the ******, ***** ***** ** ****** *** Hikvision ******* ** ****** ** *** unit ** ******** *** *******)

******** ***** **** ********* ******* ** our ***** ** *** *** ******** and ****** **** **********, "********" *** "d0111167" ***** ******** ** ****** ***** we ********.

*** ********* ******** **** ** **** for * ****, ***** ******** ***** were ****-*******. *******, ********* ****** **** the ***** *** **** *** **** 1 ***, ***** ******** ***** ***** be **** ** ********* ****** ** times *** * ***** ****. 

********* ** *********, *** ***** **** received **** ******* **** ** ******* if *** ****** *** ********, ** the ***** ******** ******* ***** *** device *********** ******.

No ******** ****** ******

** ******** ****** ** *** ****** is ****** ** ****** ******* *** password ***** ********* ******, ** *** the ******** **** ********* ** ********* to ***** *** ***** ********. ********* provides ************ *** ***** ******* ****, ******-**** ********** ******* ***** ********* **** * network. **** ***** ******* ********** ** anyone *** *** ****** *** *** the ******** ** ******** **.

Firmware ******* *********

********* ****** ******** *.*.** *** ***** (e.g., *.*.*, *.*.**) ******* *** *** password ***** *********.

*********'* ******** ******** ****** *** **** ******* ********* *** ********** recorders, ***** *********'* ***** ******* **** ******* ****** **** ***** ******* ******** *** **** of *** *********, ****** **** **** being ***** ***** ****'* ******. ****: Hikvision ***** ******* ******* ***** ******** customers ** *** *** ******** ******** as ***** *** ** ******** *********** ** the *** *****.

No *********

**** *** *** ******, *** *** ****** does *** ***** ********* **** ******** reset **********. **** ***** **** ****** who *** ******** * ******'* ****** number *** ******* ** ****** * password ***** ******* ** *********. ** they *** **** ** ******** ********* to ******** * ***** **** (***** is ****** ***** ***** ************ / validation ** *******), **** **** *** use **** **** ** **** **** the ******'* ***** *******.

Still *********

** *** ***, ***** ***** ****** an ********* ****** ********* **** *** take * ****** ** ********** *** run * *********** **** ******* ** a *** ****** ** **********, ***** can **** ** **** ** **** out ** *** ***** ******** ** the ******. ****, *** **** ** still **** ** ** *******, ******* to ******** ********, *** ****/** *** code ** *******, ***** ********* ****** in *** ***** ** ********** ** attack.

Failed ** ****** / ****

****** ********* *** ******* ***** **** the ******** ***** ********* ** ******** versions *** ****, ******* *** *********** online, **** *** *** **** ***** of ****, ** ******* *** ******* firmware ** ******* * ******** *****. Unfortunately, ********* *** * ******* ** **** communications ****** ******** ***************, **** ** in *** ***-******.*** *************, ********* ***** ** ******* ***** ****** only ***** ** *** **********, ** ******* *************. **** ************* ****** **************** **** ***** **** ******** ********* that ** **** ***** ** ******* on **.

Overall - ************ *** **** ******

** *** ******** ****, ********* *** taken ***** **** ** *** ********* side *** *** ************* **** ** address **** ***** *** ****** *** chances ********* *** ******** ** ***** password *****.

** *** ******** ****, ********* ****** have ********* **** ******* * **** time ***, ****** **** ******* *** it ** ** ******** ****** ***. Users ****** **** ** ***** * method ** ***-*** ** ****** ***** devices ********** ** ***** *****. ****, the *** ****** ** ***** ** risk ** ***** *******, *** *** still ** ********* ******* ********** ** authorization/ownership, ******* ***** ***** ** ********* equipment *********** **********.  

*********'* ****** ** ********** ** ***** security, *** ************* ** ********** *** enterprise ********, *** *** ** ***** seriously ***** ******** ***** **** ** non-destructive *******-***** ******** ****** ***** ** their ********.

Comments (22)
JH
John Honovich
•Aug 15, 2017
IPVM

Hikvision has a challenge here:

  • If they pro-actively notify the industry of their security vulnerabilities, Hikvision knows it will hurt their brand and expansion.
  • If they try to hide it, they can benefit if no one else reports on it. But if someone else reports on it, their reputation will be even more impacted as people find them untrustworthy and worry about what else is being hidden.

I think Hikvision is better off being pro-active and clear. Not only is it the right thing but it helps them build / repair trust.

How do you think Hikvision should handle these issues?

(7)
UM
Undisclosed Manufacturer #1
•Aug 16, 2017

A never ending saga showing that 'security' is not high on their agenda and comes a solid second or worse behind selling product, whether it's 'safe' or not. It's ridiculous that they do not respond to any vulnerabilities until such time they are disclosed by IPVM.

(9)
UI
Undisclosed Integrator #3
•Aug 16, 2017
In reply to Undisclosed Manufacturer #1

Yes I agree and after having taken business classes in Japan and learning about saving face, I think it might be worthwhile for IPVM to explore that concept in Chinese-related business/society:

http://www.china-mike.com/chinese-culture/understanding-chinese-mind/cult-of-face/

"In the US, you can admit and apologize for your shortcomings and gain respect for your honest efforts to learn from the past. Americans are generally forgiving if someone takes responsibility for their problems.

"For instance, during his Presidential run, George W. Bush spoke openly about overcoming his addiction to alcohol. This is something that no Chinese official would ever do it—it would be a devastating loss of face and almost impossible to recover from."

Please note: I am NOT defending Hikvision, but hopefully this can give some answers to why they might choose to or not to do something. They are doing business in America and they need to be privy to the social norms of that society both publicly and privately.

(3)
JH
John Honovich
•Aug 16, 2017
IPVM
In reply to Undisclosed Integrator #3

Sure, things are different in China.

Another example: China, Addicted to Bootleg Software, Reels From Ransomware Attack

And another: China’s Intellectual Property Theft Must Stop

And yet another: Chinese Government Spies on Churches With Video Surveillance

Net/net it is more than simply saving 'face', but a fundamental ethical conflict.

(1)
(1)
UI
Undisclosed Integrator #3
•Aug 16, 2017
In reply to John Honovich

Yes, but according to who's ethics? You would think that theft, spying, and lying would be accepted world-wide as wrong no matter the situation, but that's simply not the case. Unfortunately for companies that are unwilling to change according to the region they do business in, they will be hurt by such acts and I know Hikvision's unwillingness to do so IS hurting them now (as seen by US agencies getting rid of all Hikvision equipment as you reported on).

 

Keep up the good reporting John, we deserve to know what really goes on!

(1)
JH
John Honovich
•Aug 16, 2017
IPVM
In reply to Undisclosed Integrator #3

Yes, but according to who's ethics?

Side stepping the philosophical debate, as you note, Hikvision wants to be in business in the West where Enlightenment ethics are well established. They can 'accommodate' us or risk the problems they are having. As a practical matter, the West overall has been soft on the PRC for so long that we have emboldened the PRC to act as they do.

(4)
UI
Undisclosed Integrator #3
•Aug 16, 2017
In reply to John Honovich

I have agreed from the beginning.

Avatar
Mick Brown
•Aug 16, 2017

Not surprised

 

UI
Undisclosed Integrator #2
•Aug 16, 2017

I know that every device has way of resetting the admin password. It's just not readily published on the internet like Hikvision.

I've done it on Burglar Alarm Panel such as DSC and Elk. Hivivision is always on the chopping block since, well let's admit it, they are the biggest video surveillance by volume...

On a side note, TVT, who is major OEM supplier, has one master password that will reset their entire line of recorders. It's a fact since I've done it myself. I am not going to share it though for the sake of cyber security. I really hope that TVT patches this as soon as possible. It's just matter of time before this gets leaked, or maybe it already has? LOL

Avatar
Brian Karas
•Aug 16, 2017
IPVM

I know that every device has way of resetting the admin password. It's just not readily published on the internet like Hikvision.

This is not necessarily true, and more importantly, it matters HOW the reset is performed. For example, Milestone Husky, and Genetec SV appliances have no way to reset their passwords, according to statements from both companies. Mobotix requires the unit to be shipped back to the factory. You can argue if this is too extreme or not, but it does ensure that the unit can not be simply reset across the network.

Other devices have a physical button that needs to be pressed, often while the device is rebooted, requiring physical access to the unit, instead of just network access, as is the case with Hikvision.

Regarding TVT, we plan to investigate that and will report on what we find. Given the way TVT OEMs to a broad range of brands (see: Interview With Researcher Who Cracked Security Of 70+ DVR Brands), it would be a widespread vulnerability if a static password could be used to reset all of those devices.

(1)
(1)
MC
Marty Calhoun
•Aug 16, 2017
IPVMU Certified

"according to statements from both companies" Take that with a grain of salt!

(1)
(1)
(1)
(1)
U
Undisclosed #4
•Aug 16, 2017
IPVMU Certified
In reply to Marty Calhoun

Pass the salt, please...

Hikvision claims the new method, which they refer to as the "GUID key password recovery" is more secure...

(2)
(3)
Avatar
Brian Karas
•Aug 16, 2017
IPVM
In reply to Marty Calhoun

Take that with a grain of salt!

 

Why? Do you know of a way to reset the admin passwords on those devices? Do you know of a history of reported security issues with those companies? (not just here, but on public disclosure lists such as CERT, etc.)

 

(1)
U
Undisclosed #5
•Aug 16, 2017

If "9963844e" and "d0111167" are examples of reset codes, then it seems like it might be an 8-character hexadecimal number or a 32bit pass code. That is still 4.2 billion possible combinations (fewer if their algorithm has collisions). I wonder how secure the cameras are against a brute force attack?

Hikvision should implement one or both of the following if they haven't done so already

  • Limit password reset capability to a short time frame after the last reboot, thus greatly limiting the exposure to brute force attacks. This would break their current implementation though as it relies on up-time.

  • Require a reboot (or a very long wait) if too many unsuccessful attempts are made. They already lock cameras if too many normal login attempts are made, so maybe they do this already.

There's still the issue of there being an algorithm to generate the code. I think it's a great service to be able to offer the ability to restore access to an NVR/DVR without losing data, but I think this should absolutely require physical access to the unit. And for IP cameras I would prefer that a factory reset via physical button on the camera be the only method to restore access.

UI
Undisclosed Integrator #7
•Aug 16, 2017
In reply to Undisclosed #5

Why brute force? The "Magic_Number" is already out in the wild for their old password reset tools. If you can hit the LAN of the IP Camera then you can own it. 


http://sergei.nz/files/reset_hikvision_password.py
(1)
Avatar
Brian Karas
•Aug 16, 2017
IPVM
In reply to Undisclosed Integrator #7

There was always more to it than just the 'Magic Number', the magic number was factored with other data from the device, and then the output converted to type-able ASCII characters.

The new method clearly uses a different overall approach, even the output is very different. They could be using the same 'Magic Number' (and I suspect they are not), but enough other elements are different that existing code/methods/numbers provide little help.

 

(1)
UI
Undisclosed Integrator #7
•Aug 16, 2017
In reply to Brian Karas

I was under the misconception that U5 was talking about the old code. My Apologies.

As for the new password reset method it is still the same BS in my option. It is just more security though obscurity and sooner or later someone will leak the new algorithm and we will be right back to square one. 

(1)
Avatar
Brian Karas
•Aug 16, 2017
IPVM
In reply to Undisclosed Integrator #7

It is just more security though obscurity

Based on past performance from Hikvision, I would tend to agree with you. That is why I think they really need to offer up some proof (see my comment above) to show they have solved the crackability problem, not just a statement that it is now different.

Avatar
Brian Karas
•Aug 16, 2017
IPVM
In reply to Undisclosed #5

To clarify, the examples used were actual values from reset requests we performed. There was a third one I didn't publish, but it followed the same format. All 3 of them had a single lower-case letter at one end of the code, and then the balance made up of 7 digits.

There are obviously a lot of unknowns about the new method, though some answers may be easy to determine with some simple testing.

I thought about various brute-force attacks. One big question is determining first if the password reset request 'flips a bit' that makes the unit ready to accept a reset code, or if a proper code was randomly guessed would the unit accept it?

If the unit would accept a request code without any 'priming', it makes it a lot more susceptible to a distributed bot-net attack. Think of a spin on Mirai that is fed a list of Hikvision IP's, and each device picks a random code and random IP, and tries them. Even with timeouts, reboots, etc, this would likely stumble on a fair number of devices over time. That feedback could then also be potentially used to crack the algorithm.

In the current scenario, where Hikvision chooses not to disclose details on what exactly makes the password reset approach trustable, I think that having this capability, with no ability to disable it, hurts them. It is too easy for people to outline practical scenarios that could lead to another wide-spread exploit, and thus decide that Hikvision's products are not suitable for their applications.

Similarly a substantial bug-bounty could also instill confidence. Offer $10,000 to anyone that can crack the new algorithm as a show of faith.

UI
Undisclosed Integrator #6
•Aug 16, 2017

@ Brian. Dahua's NVR58XX series can integrate with Milestone and Genetec. Also, some of the HIKVision DVRs/NVRs can be added to Milestone through ONVIF. So if there are remote sites using DAHUA or HIKVision that are not connected to any external network (or Internet), but which are linked to a Central Command Centre running Milestone or Genetec, is there a Security concern?

(1)
Avatar
Brian Karas
•Aug 16, 2017
IPVM
In reply to Undisclosed Integrator #6

So if there are remote sites using DAHUA or HIKVision that are not connected to any external network (or Internet), but which are linked to a Central Command Centre running Milestone or Genetec, is there a Security concern?

Yes, there is still a security concern. If someone can get the admin password reset and take over a recorder, then they have high-level access to a core component on the security network. From that you can potentially extract other information (IP addresses of servers, other passwords, etc.) and use that to attack other components of the network.

For deployments like you describe, (remote sites, use of higher-level VMSes), the organizations tend to be larger, and risk of internal attacks (rogue employees) also increases. Your security threat is different than a small single-recorder site directly connected to the internet, but a still a threat.

(2)
(2)
UI
Undisclosed Integrator #8
•Aug 17, 2017

I sense a Hik-Blog post condemning "The Blogger" in the near future.

(2)