Hikvision Default Password Hacking

Published Mar 03, 2015 05:00 AM

What was once just warnings and consumer concerns has exploded into a major problem for Hikvision.

A Chinese province's Hikvision devices have been hacked.

In this note, we examine what happened, what Hikvision says they are doing about this and what this means for the mega-manufacturer.

Update September 2015. Hikvision has suffered another major hack.

Hikvision ********** ******** ********

** **********, ********* *** ******* **** hit **** * ****** ** ******** concerns / ****** **** *** **** few *****. *** **** ******** *** Wired's ******* ** *********:******* **** ******** ****** **** **** WORST ******* ****** ****. ** ********, ***** *** ******* ******** ************* ***** ***** ** 2014. **** **** *********, ***** ********* historically *** *** ***** ***** ** change ******* *********, *** ***** ***** are ** **** ********* ******** *** there, ********* **** ****** ** ******* target *** **** *** ***** ************* hackers.

The ******* ******** ****

***** *** ********** ********, **** ** important **** ** **** **** ******** is ******* * ********** ************, ***** information ******** ** ********.

*** ******** *********, ** *** **** ***** ** China, **** ~** ******* ******.

** * ***** ******* **** ****** on *********'* ******* **** (********* ***********), ********* ****** **** ***** ******** were ****** ****** *** ******* ******** Internet ********* ******. ********* ****** **** this *** *** ** *** *** of **** ********* / ******* *********. We ****** ******* **** ** ** have ** ********** ** *** ******* government.

******* ** ********, *** **** **** government ***** ************ ********* *** ****** is * ***** *******. ******, **** is **** ***** ***** *** ******* government's ****** ******* ** ******** ******* products **** ***** ****** **** ** hacking / *******.

Hikvision's ********

** ********,********* *** ******** ******* ** ************ Products ********* **** ********.

** ********** ***** **** **** ******* done ** *** **** **** *** discloses * *** ******* ********* *** later **** ***** (*.*.*).

[[****: **** ******** *** **** ********.*** *** **** **** ** ** here.]]

*** ******* ** **** ******** ******* include:

  • ******* ****** ** *** ******* ******** (an ******* **** *** * *** risk *********)
  • ********* ****** ****** (****** ** *************** **********)
  • ******** ***** * ********* ***** ******** (helpful ** **** ***** ***** ********)

The ******

*********'* ***** ******* *.*% ** *** first *** ** ******* **** *** full ********** (******* *** ******** ****** Monday). ** *********** *****, **** ** not **** *** ** ***** ****, it ** * **** ** **** than $* ******* *** ** *****. On *** ****** ***, *** ***** price **** ********, ********** **** *** market **** *** **** **** ** a ***** ****.

******: **** **, ****: **** **** 3 ****** *****, *********'* ***** ***** is ** **** **** **% ***** the ******* ************, ******* **** *** market **** *** ****** **** ***** this.

***** ********* ** ********* ***** ** the ******* ********** *** *** **** connections, ** ***** **** **** **** be * ***** ***** *** ********* domestically. ** *** ***** ****, ** is ******* * ***** *** *** Hikvision *** ********* **** *** ***** discussed ****** ** *****.

** ***** ******* *** ******, ** think *** ****** **** ** **** severe. ***** ************* *********** **** ****************** ** ***** '********'. **** **** simply ******* **. ** *** ***** end ** *** ******, ***** ********* is **** ******** ****, ******* ** China, ** ******* **** **** *** care ******** ** *********** ******** ***** not ** ** * ******** ******** to *****. *******, ** ********* ***** to ****** **** *** *** *** high *** *******, ** ***** **** will ***** *********** **********, ****** ** easy *** ****** ** *******, "****, you *** *** ********* *** **** the ***** *** **** **** *** won't *** ******."

Hikvision *********** / ***** / ****

** *** *** * ********* **********, user ** ***, *** ****** **** carefully ****** **** ******** ******** *** absolutely ****** **** ********** ** ******** immediately.********* ******** ******** *** ********* ****.

***** * **** ** **** *********, it ** ***** ** ** ********* hard ** ******* *** *** ******* your ********* ** ** ******. *** Hikvision ******** ******** ****** * **** ago (*** *** ********) **** **** very ***** / ****** ***************. ** is **** *** ** ** **** if *** ******** ***** ***** ******** risk, *** ** ** ******* **** the ***** ******** *** ************* **** prone.

****

Comments (46)
UM
Undisclosed Manufacturer #1
Mar 03, 2015

"this is even worse given the Chinese government's recent efforts to restrict foreign products that might expose them to hacking / attacks"

Well if that is not the pot calling the kettle black!

(2)
(1)
SM
Steve Mitchell
Mar 03, 2015

Given that most VMS/DVRs run on Windows or an embedded linux, the risk of OS level vulnerabilities will always be present.

There's also another dynamic at play--the manufacturer is focused on the functionality of the software running atop the OS, and can easily take their eye off the ball when it comes to regular assessments of the OS they're distributing along with their products.

Integrators can scan a DVR/VMS for vulnerabilities and should consider patching any obvious issues (either themselves or via the manufacturer) part of the configuration/installation process. Unfortunately, regular audits and patch cycles are a necessary evil as new vulnerabilities are found.

As customers, look at this as a quality issue, as these are essentially unpatched bugs that the manufacture has not planned for. If that means Hikvision gets a black eye, then so be it.

(2)
Avatar
Ethan Ace
Mar 03, 2015

I cannot for the life of me understand why telnet is enabled by default. When's the last time someone telnetted a camera? Hikvision isn't the only one guilty of this, either. Dahua and Bosch definitely do as well. It's amazing how many open ports you can find on some gear.

(3)
Avatar
Tony Darland
Mar 03, 2015
IPVMU Certified

Is Telnet comm using a command line?

Avatar
Ari Erenthal
Mar 03, 2015
Chesapeake & Midlantic

Not forcing the installer to change the default password in 2015 borders on malpractice. Shame on every security manufacturer that still won't enable this most basic step.

(3)
(6)
Avatar
Luis Carmona
Mar 03, 2015
Geutebruck USA • IPVMU Certified

"Shame on manufacaturer not making me do what I should know to already do."

Sorry, don't agree there.

(7)
Avatar
Ethan Ace
Mar 03, 2015

I think in commercial environments, installers should know better. For a lot of home and small DIY installs, people absolutely don't know better.

If techs already know they should change passwords, there's no drawback to a manufacturer forcing them, right? Plus it reduces the chance of them not being changed.

(2)
SM
Steve Mitchell
Mar 03, 2015

Apparently the default password was an issue here.

And, yes, it's a good policy that should be enforced.

I wonder in this case what the scale of the deployment was, however. Hundreds or thousands of DVRs? If so, there could be deeper issues at play than just "changing the default password" as password management in general of a deployment of that scale could be a serious issue. Change the default password to 'abc123.' Now socially engineer somebody to get the password, and bingo--same effect. It could even be the case that the default password was left in place to make the system more managable. Irresponsible, yes. But pragmatic if there was not a person or group chartered with administration that would have taken responsibility for password management as well.

Point being, large scale deployments (I'm assuming its very large) like this are really large scale IT deployments, and need to be managed as such. Security is part of any large scale IT deployment. The customer/integrator should expect "secure" products, but also has a continuous and ongoing responsibility in governing the security of their network.

Shoddy product? Maybe. Shoddy deployment/management, definitely.

(2)
(2)
JH
John Honovich
Mar 03, 2015
IPVM

Steve, that's a good point about deployment/management.

One thing I am really curious about is how did anyone from the outside even get access to those recorders / cameras? You would think that all of those devices would be behind firewalls / security devices that would stop any attempts from even getting to the recorders / cameras, no?

(1)
SM
Steve Mitchell
Mar 03, 2015

I would wager this is all on a "converged" network, and as such the network was also vulnerable to the same mismanagement that led to the password issue.

Correct me if I'm wrong but I imagine these huge Chinese municipal projects really being customer driven--that is, the province itself was responsible for the implementation and operation and doesn't necessarily depend on any single 'integrator' (other than likely subcontractors who would install gear).

This is why I'm inclined to point the finger mostly at the IT management since it would be they who failed to adequately assess and enforce solid IT security controls on the network and attached devices.

I suspect a lot of integrators on IPVM come at their customers with value add in mind where they support and help manage the (often isolated) security network. But very large projects tend to have a lot more customer involvement in day-to-day management of the converged infrastructure, even if there's an integrator to which they outsource some of those responsibilities.

(2)
(1)
JH
John Honovich
Mar 03, 2015
IPVM

I don't know how this system was set up or managed.

I know some Chinese government systems are actually integrated by the manufacturer (like Hikvision, e.g., Hikvision's Expansion into System Integration Examined) but I have no idea about Jiangsu specifically.

JH
John Honovich
Mar 03, 2015
IPVM

Related: The upcoming ONVIF Q profile aims to make this standard: New ONVIF Profile Q Aims To Change Discovery and Default Passwords

(3)
Avatar
Ari Erenthal
Mar 03, 2015
Chesapeake & Midlantic

But it has been shown again and again and again that DIYers and trunkslammers either don't know or don't bother doing it. And who loses? The end users.

Let me ask you this: what is the downside to forcing default password change? Why wouldn't any manufacturers do it?

Avatar
Ethan Ace
Mar 03, 2015

Related: We had more discussion about this here: IP Camera Passwords - Axis, Dahua, Samsung

People generally felt password creation should be forced, but simple passwords allowed.

(1)
U
Undisclosed #2
Mar 03, 2015
IPVMU Certified

...what is the downside to forcing default password change?

You have to do it to every camera.

On a 16 piece Costco kit, this extra labor increases a 'slammers fully burdened cost significantly.

(2)
U
Undisclosed #4
Mar 03, 2015

Why wouldn't any manufacturers do it?

Support costs. People calling up asking how to reset cameras, how to login, how to recover passwords.

Delays in helping people "To fix that issue, you should just adjust setting X on your camera". "Oh, you forgot the admin password?..."

(2)
(1)
JH
John Honovich
Mar 03, 2015
IPVM

D, that's a good point about support costs / complexity.

Related: Dahua And Hikvision Master Password Backdoor

Avatar
Meghan Uhl
Mar 05, 2015

I agree with both Ari & Luis - it is unfortunate that in our litigious, and sometimes mind boggling "stupid people", society that manufacturers have to put warnings on thing like on an electric hair dryer "do not use in the bathtub" or the one for radiator belts that warns "do not attempt to replace belt with motor running" HOWEVER, there is a reason these exist and I'm sure there are "stupid integrators" out there who don't do what they "should know to do already" and the customer is left vulnerable. The black eye ends up on the manufacturer (deserved or not) so they should put the warnings on the label & if they can force something in the programming, all the better.

(1)
Avatar
Luis Carmona
Mar 05, 2015
Geutebruck USA • IPVMU Certified

Thanks, Meghan. And I'm not against manufacturers having a prompt to recommend or forcing change of the default password, my issue was with calling it malpractice. At some point an integrator has to take responsibility. And as for the novice end user installing cameras themselves, well, an end user who installs his own smoke detector should also be expected to take responsibility for knowing what they are doing if they are going to do it themselves instead of having a professioanl do it. So the same should be for changing the default password on a camera they install, especially if the camera will be exposed to a common user network and/or the Internet.

But none of this absolves manufacturers from taking proper to make a good faith effort to effect some sort of security for their cameras, meaning no unchagebale backdoor login, which always somehow becomes publlic, no poorly written interface that allows someone to bypass the login altogether, and what's especially galling, is when a security flaw is exposed, it takes months, sometimes years, to get fixed. But them, isn't it up to dealers/integrators, to stay informed about the products they sell and install and find out if there are at least any known problems that have not been resolved yet?

Lot's of questions, lot's of ways of looking at it.

Avatar
Ari Erenthal
Mar 05, 2015
Chesapeake & Midlantic

Well, who is the customer? Who does the manufacturer have to look out for?

if the customer is the integrator, then I agree with the manyfacturers' decision to not force default password change. After all, it can be inconvenient for the integrator to have to change every password, and it probably isn't necessary in a closed network in any case.

If, however, the end user is the customer, well, then it becomes the manufacturer's responsibility to protect the end user against a lazy or incompetent integrator.

I am strongly opposed to the notion that the integrator is the customer, and that the manufacturer's only responsibility is to the integrator. Without the end user, the integrator is nothing, and without the integrator, the manufacturer is nothing. The end user's needs is the reason for the security industry to exist. Therefore, failure to protect the end user from a bad integrator is, yes, malpractice. It shouldn't be possible to install the product insecurely when secure installation is so easy, and so basic a step in other industries.

(1)
U
Undisclosed #2
Mar 05, 2015
IPVMU Certified

If, however, the end user is the customer, well, then it becomes the manufacturer's responsibility to protect the end user against a lazy or incompetent integrator.

Every home router that I've purchased comes with a default username /password. Half of them do not get changed. Because usually there is no integrator involved in installation to change the password and protect the end-user. This is more serious than the camera vulnerability and still what is being done?

Maybe the manufacturer needs to protect the end-user against themselves, too.

UM
Undisclosed Manufacturer #1
Mar 03, 2015

Anyone who wants a "code secure" system will have most likely have to employ a third party to independently verify the integrity of the programming code being used.

As one may infer from these posts...

Hacking D-Link, Cisco And IQinVision - Black Hat Video

What Checks Do Manufacturers Perform To Check Their Program Code?

... I don't think manufactures themselves will invest much into the security of their own products, instead only taking extra measures it if it is worth their while after you (end user or dealer) have already paid someone on your own to do penetration testing and you make it a condition of the sale that the manufacturer fixes it. So it's most likely not going to happen unless there are 100's of thousand or millions of dollars at stake.

If you ask the manufacturer how secure their equipment is, you're probably always going to get a song and dance about they take thorough testing and take extreme measures, but hey, "We make no guarantees and are not liable for any losses due to unknown vulnerabilities".

(1)
U
Undisclosed #2
Mar 03, 2015
IPVMU Certified

Ironically, in this case Hikvision seems to be using the default password issue to their advantage.

As John pointed out there is/was a "real" buffer overflow issue that may have been involved in the attack. But as undisclosed C indicates here, Hikvision is/was trying to characterize the attack as mainly being related to the password vulnerability.

Because then it's not their fault as much, since they advise changing your password for security reasons. And because most cameras in the wild are still vulnerable to this vector, they can claim its everyone's problem.

UM
Undisclosed Manufacturer #3
Mar 03, 2015

I don't understand the reason that Hikvision did not take proactive actions previously since the issue was there several years ago.

Besides blaming users for not changing default password, is this buffer overflow vulnerability avoidable?

JH
John Honovich
Mar 03, 2015
IPVM

I am not sure what Hikvision did specifically for the province. However, they have responded with new versions after each issue, including the buffer overflow.

One challenge for all traditional manufacturers is that they do not typically control or have access to their products after they are sold. In this regard, they are different than SaaS / web based services which are easier to respond to security flaws since a single push can patch all affected users.

A flaw found in Hikvision or any other large surveillance manufacturer might have unpatched devices for many years to come as certain users either don't know about it or aren't sufficiently motivated to act.

Avatar
Ray Bernard
Mar 03, 2015

I have never encountered a sufficiently secure video system, either in a project or for a deployment for which I've been given a tour. There are both practice (including service access) and product vulnerabilities. Often an nmap or Nessus scan will take some network cameras offline, making it a real pain to power cycle them if they are not on PoE.

Integrators use system and device "master" passwords for themselves accross their entire customer base, so that a field tech won't have to deal with customer-specific passwords. Customers who learn about it always demand they have customer-specific passwords. But most never learn about it. Many integrators use LogMeIn or its equivalent, without the customers havng knowledge of it, an audit trail of access, or control over locking down the access in the case of an attack that warrants it.

Because the industry security practices are so poor, I don't think this will have as big an impact as it should have, except for marketers, who will have a field day trying to assert their products are more secure. Some improvements will occur, of course, but probably nowhere near what should happen.

(5)
(2)
JH
John Honovich
Mar 03, 2015
IPVM

Ray, good feedback.

I agree that security practices are generally poor. It seems there is not a lot of interest. For example, this is the first article/post/topic on IPVM related to information security that has ever generated heavy interest. Maybe this is a watershed moment or maybe it will it fade away, part of this certainly depends on how many other big manufacturers have issues like this again.

LM
Luke Maslen
Mar 03, 2015
IPVMU Certified

Hi John, would IPVM consider an article on how to disable Telnet access on various brands of cameras, NVR's and DVR's? I've failed to find the word telnet in the PDF manuals for Dahua and Samsung cameras and video recorders. I always change the default passwords but I can't figure out how to disable telnet access. A "how to" article would be a great help. Thank you!

HO
Hans Olsen
Mar 04, 2015

If doing an article, then please widen it to more than just telnet. There are several convenience features in different brand cameras which are nice to have but not really needed for most usage that add to the security risks.

For example, some brands have dyn-dns or similar functionality where the camera or NVR can register with the manufacturer and get a manufacturer dns name that can be used for accessing the device. It can be more or less easy to figure out how the manufacturer constructs the dns names and then just enumerate or scan though them to find devices that are open for attack.

Some also have UPnP port mapping functionality, such that the device by it self can open up ports through simpler routers and expose the device to an outside network. If you don't need this, then turn it off and limit access to just the VMS/NVR (or better a proxy in front of the VMS/NVR). Also, don't port map using standard ports which would be an attackers first guess.

And then there is of cause UPnP/SSDP and Bonjour discovery protocols which allows the device to announce it self on the network. Which makes it easy for you to find the device, but it also makes it easy for everyone else on the network as well.

That's just on the top of my mind and there is probably a lot more.

If Carlton Purvis is still with IPVM (I miss his articles) then perhaps a series of articles focusing on security from different perspectives (trunkslammer, IT professional, security expert etc) showing what people are actully doing and what they should be doing when looking at the whole system and not just individual devices would be interesting.

(3)
JH
John Honovich
Mar 04, 2015
IPVM

With 120 votes, integrators and manufacturers are opposed in their perception of how this will impact Hikvision.

For manufacturers, 40% believe the impact will be significantly bad while only 19% think it will be insignificant.

By contrast, for integrators, only 16% believe the impact will be significant whereas 42% think it will be insignificant.

(1)
SM
Steve Mitchell
Mar 04, 2015

Irony is product quality actually does keep us manufacturers up at night. Whereas I assume integrators get burned by defects often enough, while still seeing their manufacturers succeed, that they assume nobody (but them) cares.

(2)
JH
John Honovich
Mar 04, 2015
IPVM

That's one interpretation.

I'd offer: "Integrators get burned by defects often enough, while being able to get by, that they just don't think it is going to matter."

There are many different integrators and different integrator perspectives, but I think that thought process is behind the general trend of poll responses.

JH
John Honovich
Mar 04, 2015
IPVM

Update: Hikvision stock was up slightly today, indicating that investors are not that concerned about the long term ramifications of this.

U
Undisclosed #2
Mar 04, 2015
IPVMU Certified

...we think this will cause significant resistance, making it easy for rivals to declare, "Sure, you can buy Hikvision for half the price but..."

Rivals will shorten this to simply "Hackvision".

(6)
VK
Vasiles Kiosses
Mar 05, 2015

There is a lot targetting one manufacturer but they all need a good kick up the you know what. I have not seen one camera manufacturer that truly embraces IT security practices. May I suggest IPVM add to their testing cycle for products, basic security tests and build up a table of who does what and how well. The contents should include:

- enforced first time root password change on power up

- Password strength

- protocol control Telnet, FTP etc (ability to turn it on or off or modify port)

- Vulnerability scanning (Nessus provides simple tool for scanning)

On the flipside, the VMS vendors need to get with it as well. Maybe its changed now but in the past some products would only connect to the cameras on the default root account. VMS product is just another user of the device. Root accounts should be for emergency use only.

(1)
UI
Undisclosed Integrator #5
Mar 05, 2015
Just about every IP camera is a mini Linux computer... The idea that they're secure is a farse, don't confuse headlines (or lack thereof) as a reason to make changes... In my opinion none of these cameras are secure. They're unencrypted video streams for gosh sakes! Lets not fool ourselves here lol .... I mean bank encryption gets hacked ALL THE TIME, do you really think a hacker with skills can't hack your dinky IP camera? I wouldn't be surprised if a competitor in China hacked into the cameras to hurt their credibility. All IP cameras should be insulated whenever possible... public networks, main internal networks are all vulnerable... If you’re not putting something between you and your ip cameras then you’re in for trouble. I never put IP cameras on the main networks unless I absolutely have too. The idea of continually upgrading camera firmware to protect against attack is a unnecessary expense.. So do yourselves a favor, don’t treat any IP camera as if it is “secure” in any way.
(2)
(1)
(1)
JH
John Honovich
Mar 05, 2015
IPVM

E, good feedback and perspective.

Your conclusion:

"So do yourselves a favor, don’t treat any IP camera as if it is “secure” in any way."

But some organizations do have to run it on their 'main' network, right? I agree with you of the benefits of segregating cameras but sometimes it is not a practical option. And to that end, many users need cameras that are as secure as possible, no?

And I am not saying manufacturer A is good and B is bad, but that some users really need to have cameras to be as secure as they possibly can be.

(1)
UI
Undisclosed Integrator #5
Mar 05, 2015

John I completely agree.. However I've sat down with many IT administrators and they've all asked me the same question.. "Can you secure your system"... My answer/solution has always been, yes if we use a segregated network for the IP cameras. In my opinion its an unfortunate reality but no OEM can tell you with a straight face that their cameras are truly secure. There is a reason that almost all IP Camera OEMs don't advertise how secure their cameras are... its because they're not secure...

JH
John Honovich
Mar 05, 2015
IPVM

"There is a reason that almost all IP Camera OEMs don't advertise how secure their cameras are... its because they're not secure..."

Literally laugh out loud...

On that point, Trendnet was punished by the US government for calling their cameras 'SecureView' and then getting repeatedly hacked. So, yes, marketing people, probably best to avoid such claims!

What I am trying to emphasize is that the security (or lack thereof) across IP cameras ranges - some are really bad and some are not as bad :) To that end, it's important to figure out which ones pose the least risk, no?

(1)
UI
Undisclosed Integrator #5
Mar 05, 2015

Absolutely

SM
Steve Mitchell
Mar 05, 2015

Just because an IP camera runs Linux that makes it insecure? Is it more or less secure than the organization's other Linux machines like their email server, etc.?

The devices on any network that have the greatest risk footprint are the general purpose PCs and servers. These are more powerful, run fully configured commodity operating systems, must provide some command-line access and interactive user interfaces, and run on commodity hardware platforms. They typically run many more services than an embedded system, any one of which can/will eventually have new exploits revealed. What's more, they're easier to exploit through social engineering attacks (ie, posing as a contractor who needs a password, or dropping an infected USB key in the parking lot).

Many IP cameras may not be 'secure' as typically configured. However, given their nature, they have the opportunity to be one of the most secure devices on the network. They need not support interactive command-line or UI use at all. They need only run the OS level services necessary to do their jobs, and the few protocols they do implement can be carefully protected.

The various security accreditation programs out there for DoD, NIST, etc., call out specific requirements for controls that must be in place for Windows, Linux servers, etc., and fewer for various embedded devices like IP phones, IP cameras, video conferencing devices, etc. Controls are necessary, but these embedded devices are not as complex and thus not as vulnerable as your PCs and probably your VMS/DVRs.

Are some vendor's cameras more secure than others. Probably. Are they all insecure? Probably not when compared the risk posed by other devices on the network.

UI
Undisclosed Integrator #5
Mar 17, 2015

I agree with you Steve, except my point was that having 30+ mini linux computers on your network that run 24/7 are more vulerable to silent attacks then say a computer server... My reasoning is pretty simple.. Someone hacks into a ip camera on a customer's network and no one may ever notice... Someone hacks into a main server or NAS and starts deleting files... someone will notice very quickly... So my point is that if you have large installations of autonomus machines (ie ip cameras) the ability for someone to hack in unnoticed is extremely high vs a desktop computer or server. We all know Linux is in general a more secure solution than say a windows unit.

SM
Steve Mitchell
Mar 17, 2015

There are two sides to the formula with which we assess risk: How vulnerable in the device to compromise, and how much damage could be caused to the rest of your enterprise if that device is compromised. Cameras, as single purpose embedded devices, tend to be lower risk in both categories for the reasons I cite. Whereas servers are higher risk.

I'll never make excuses for a glaring security hole in a camera. Or discount both the manufacturer's responsibility and the customer's responsiblity for ensuring their safety.

But broad statements that cameras are "insecure" aren't true--they need to be evaluated like any other device on the network. And while they require scrutiny I'm actually less concerned with their risk than I am my servers.

Avatar
Ray Bernard
Mar 17, 2015

Steve, you are so right in saying that you have to look at the risk picture.

A lot depends upon the kind of data that a camera collects and any detection functions that the camera performs. If someone can log in to the camera and turn off motion detection or other aalytics or alarm reporting, that could have a significant impact if, for example, the camera is being used for perimeter intrusion detection or motion is used to trigger recording. If edge recording is in use, turning off recording or stealing video could have consequences. But it all depends upon how critical the camera's functions are, and what is on the video.

Cash register video--if credit card information is readable--certaily warrants high protection. But that would most likely be server-based recording, not edge recording, an example of the point you made about servers.

As you say, it's not just the vulnerabilities that matter.

[Start Soapbox]

The risk factors include the attacker profile. An integrator's disgruntled employee who quits on the expectation of being hired by a customer, and who then is turned down by the customer, is a situation that should immediately prompt password changes for all compromisable systems and devices. This is a nightmare scenario for an integrator who uses "universal passwords" accross its full customer base.

I was doing a site walk a few weeks ago and our group passed by an equipment room where one of the video field technicians was loudly (noisy equipment room) telling another tech the "company password" it uses for ALL video servers, not just this customer's servers. YIKES! This is a pet peeve of mine because it is so common.

[End Soapbox]

One growing trend is to make maximum worthwhile use of network camera intelligence. As applications running on cameras become increasingly important to security operations, so will the security of the cameras themselves.

Avatar
Ethan Ace
Jun 03, 2015

After some delay, Hikvision has released 5.3.0 firmware. We have a full test of it here.

MI
Matt Ion
Dec 14, 2015

Well the HIK NVRs and cameras we've been getting the last month or two have the new forced-password measure enabled. Only one problem with it: there doesn't appear to be a way now to change the IP on initial setup via the SADP tool, as that requires the correct admin password.

So it seems to only way to do it now is to change your computer's IP to the same subnet as the camera's default (usually 192.0.0.64 although I've seen a few variations on that - at least SADP is still good for something), so you can log into the camera and give it a suitably complex password, at which point you can just change the IP from the camera's own admin interface.

Of course, a major problem with that is that you can only bring one camera up at a time, as they're not set for DHCP and thus all start up with the same factory-default IP.

The last couple of Dahua DVRs I've put in have added this "feature" as well...