Hikvision Default Password Hacking

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.

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".

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?

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.

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!

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.

...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".

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.

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...