Updating Hik OEM camera to Hik firmware

[Securame]

I am trying to update a Hikvision OEM camera (which is actually a Hikvision iDS-2CD6810F-IV/C, people count camera) with Hikvision's firmware, and I am unable to do so.

I am trying to use the same v5.4.80 firmware from Hikvisioneurope, IPC_E2_BV_EN_STD_5.4.80_181112.zip:

DOWNLOAD EU PORTAL

www.hikvisioneurope.com

But from the web interface, it just doesn't like it. (Failed to get the upgrading progress.) The web component is correctly installed, using IE, etc. I have updated many Hik products, so I have that covered.

Since it is an OEM, when I try to add it with a Hikvision NVR it throws me a "password error" on the NVR. I know this is normalo with this OEM products, if you try to use Hikvision's apps/programs, you get a password error, since their protocol is slightly different. I can add it to a Hikvision NVR as an ONVIF camera, but of course it loses its purpose, since then there are no people counting cappacities.

I do have a DS-2CD6825G0/C-IS in order from Hik, but I do not expect it to arrive before 2 weeks.

It used to also be possible to update it with TFTP, but I think that option is long gone. It is also not answering me on SSH, and I do not see any option to enable telnet/SSH on the web interface.

Does anyone have any ideas on what I could be trying next?
Thanks!

 

[alastairstevenson]

It used to also be possible to update it with TFTP, but I think that option is long gone.

Have you attempted the update this way?
There are usually fewer validation checks.

Does anyone have any ideas on what I could be trying next?

Generally the update process via the serial console (usually via the min-system) does less update validation than via the web GUI.
It may be checking and rejecting as a mismatch the OEM code between the Hikvision stock firmware and the camera hardware signature.
That may be worth a try - though there will some risk associated with doing so.

 

[tdb]

The TFTP tool listed is ancient, I couldn't get it to work and it turns out the instructions are wrong with newer cameras (or at least my variation lol). I literally just did this process to update a white box G1 camera and still have all my windows open so the following is based on that for the G1, but may point you in the right direction for your situation.

I ended up digging through the forum and finding a link to scottlamb's updated hikvision-tftpd which described how to search for the magic packet request from the camera, and of course provided a tftpd server and instructions of how to do the serving. Using the instructions I found the camera was actually using my network's ip range and getting the ip 192.168.1.64 rather than the 192.0.0.64 mentioned with the old tool, so setup the tftpd on 192.168.1.128 (which was the ip the magic packet request was looking for) and everything worked like a charm and the firmware transferred. After you upload the firmware leave the server running and in a minute or so it will give a message saying

Tue May 19 22:57:21 2020: received unexpected handshake bytes '53574b4807000000000000000000000000000000'

which is it reporting that the update is complete. When that happens it is still running in service level on the .64 address, so you have to power cycle it and it will boot up into the firmware that you uploaded. Because it is doing a factory wipe it wipes all activation and config so you have to use SADP to activate it again. I tested the process with the firmware from my oem first, and then with the hik firmware that was the same version. The hik firmware loaded the same way, and once rebooted gave me the expected branding. I then used the web interface to update to the latest firmware from the hik site with no issues.

 

[alastairstevenson]

When that happens it is still running in service level on the .64 address, so you have to power cycle it and it will boot up into the firmware that you uploaded.

Also - remember to shut down the tftp server / Python script before power cycling the camera, or the whole download / update process will repeat.

 

[Securame]

Thx @alastairstevenson and @tdb,

I have used the old TFTP Hikvision program for Windows, that's the one I have used for many years, and I think it doesn't work any more with the current hardware/firmwares. If they are now checking for a TFTP server on 192.168.1.128, that is a new to me, I will try it over there.

I had already seen the python TFTP server, but I guess I can not run that easily on any Windows machine. I will try to run it on a Synology, otherwise I might need to find a virtual machine.

 

[Securame]

Well, that did the trick!

Quite strange, but the update request came from 192.168.1.67 instead of 192.168.1.64. The first time the camera did not come back, so I thought for a moment I had killed it. Nothing was replying to pings on 192.168.1.64/192.0.0.64 or the original IP on the camera.

But on the second time I updated it with TFTP, when done I think it rebooted itself, it replied to ping for a moment on 192.168.1.67, and then came back to life unactive on 192.168.1.64. I did NOT have to power cycle it myself, it actually rebooted by itself (the first time it updated itself 2 times, since I still had not closed the TFTP server.

Thanks!

 

[tdb]

Maybe something else was already on the 64 ip? in any case the important thing is it worked . Knowing how to find the magic packet request makes everything a lot easier since obviously the ip can be different. A large part of my reason for commenting was to make sure that it will come up when I'm next looking to add a camera and can't remember what I did. My system is growing slowly as funding allows so it will always be "in process" lol

 

[Securame]

I always have IP 64 available for newly activated Hik devices, not the case. No idea why this model showed on 67, but the fact that it was actually looking for a TFTP server on 192.168.1.128 instead of 192.0.0.128 which is what I was expecting was what was making me fail.

 

[alastairstevenson]

I had already seen the python TFTP server

That's also been useful for those devices where the firmware filesize exceeds the 32MB limitation of the Hikvision tftp updater.

Quite strange, but the update request came from 192.168.1.67 instead of 192.168.1.64.

Could it be that the bootloader environment variables 'ipaddrs' and 'serverip' have been changed away from the original default?

I don't believe the Hikvision tftp updater is hard-coded to listen on 192.0.0.128 - it uses the IP address setting of the current interface.
But I'd need to hook up an older-model camera to verify that.

 

[tdb]

no it's not hard coded to listen, but without knowing how to see the magic packet it's hard to tell where to be. the issue with the hik tftp was apparently image file size or something? I just ditched it for a linux machine in my environment anyway.

 

[Securame]

Could it be that the bootloader environment variables 'ipaddrs' and 'serverip' have been changed away from the original default?

I was used to the cameras booting up for a moment on 192.0.0.64 and checking for a TFTP server on 192.0.0.128, before switching to their default IP 192.168.1.64.
I set up the TFTP server on 192.168.1.128, and the camera requested the update from 192.168.1.67.

no it's not hard coded to listen, but without knowing how to see the magic packet it's hard to tell where to be. the issue with the hik tftp was apparently image file size or something? I just ditched it for a linux machine in my environment anyway.

I didn't need to sniff for the magic packet, I just set up the TFTP server on 192.168.1.128. I will try to do so next time I have to update something

 

[CDAPete]

I have 2 of the OEM equivalent of Hikvision's 2DE4A425IW-DE. (25X Autodome POE PTZ 4MP IP). These are a great little auto-tracking PTZ but the OEM firmware is lacking a few of the features that the full Hik version has. The comments above give me hope that there may be a solution. I have Mac OS & Win10 PC (but no Linux or Raspberry Pi if that's needed). Does anyone have a comment or update on whether this is still worth proceeding with for these cameras... if you know and possibly a workflow that's a little more detailed than what appears at github for the less informed? Happy New Year.

 

[SEdawg]

Excuse the long rant; it's definitely on-topic and should be useful to someone.

I have a few OEM Hikvision cameras, model NP104-IR/4X, (equivalent to DS-2DE2A404IW-DE3), running on my home network since 2018. I happened upon the advisory of the latest Hikvision exploit/vulnerability last Friday while trying to add the cams to Home Assistant (Hikvision) and promptly freaked-out. It was then that I started down the path of understanding the difference between Hikvision v. OEM Hikvision. OEM is equivalent to SOL (Sh*t Outta Luck) when it comes to getting any information (let alone support) on the cams from Hikvision. They wouldn't even tell me if the sun was out, let alone if the firmware version I was running was indeed vulnerable. After exhausting all options, I decided it had to be. I wish a simple command/test would have accompanied the advisory, some harmless command I could run against the cams that would confirm they were vulnerable, but I guess that would help the bad guys down the road to exploiting the vulnerabilities. Of course, the real bad guys would already be well down the exploiting road just hearing the vulnerability exists, but I understand the principle in not wanting to give them any help.

In searching I found the latest firmware for my OEM camera, NP104-IR_4X_5.6.12_190807(.)dav; that would still be vulnerable to my understanding, but I decided to give it a try. All the cautions and warnings about flashing OEM cams with Hik firmware had me fearing flashing the cams with anything directly from Hik, but I also downloaded two firmware files that seemed like they would work with the DS-2DE2A404IW-DE3 models. I dusted off the Internet Explorer browser and logged into the cam GUI and attempted to upgrade the firmware through the Maintenance page. None of the .dav files would flash. Every upload attempt resulted in a "failed to get the upgrading process" error. A day of trials and tweaks resulted in nothing. I decided I had no choice but to risk bricking a cam (or turning it into a Chinese GUI) by going down the TFTP route.

I tried the Hikvision TFTP server, had no luck (wouldn't complete the upload), so I gave the GitHub - scottlamb/hikvision-tftpd: Unbrick a Hikvision device (NVR or camera) via TFTP script a try. Put the script on one of my Raspberry Pi 3+, issued the listed commands in the Terminal, restarted my cam and it worked like a charm! Well, I did have to run it/restart the cam several times when any of the uploads stalled, but it worked! I owe Scott Lamb a few beverages...

All three .dav files uploaded and the GUI never went Chinese, but there was a definite difference in picture quality/functionality. The latest firmware for the NP104-IR/4X (5.6.12_190807) flashed fast (file is only 23MB) and picture quality/functionality didn't change. The .dav file I downloaded from the international Hik site was the latest version I could find, 5.7.1_211015, it was nearly double in size (46MB). It uploaded and the GUI was the same, but the picture from the cam was crazy; almost had a Matrix-like effect with cascading pixels/blocks and the IR lights also didn't seem to work. I then flashed the .dav I downloaded from us.hikvision DS-2DE2A404IW-DE3 product page (5.6.800_210628); it was the largest of the files (48MB). That installed correctly and seems to have given me the same/better picture quality as the 5.6.12_190807 firmware. I haven't kicked the tires all the way around with it yet, but I think this is as good as it gets for now.

Here's the disconcerting thing with the installed firmware, when I check the System Settings, it reports I'm running V5.6.12 build 190807 firmware (not 5.6.800_210628). I re-flashed multiple times, it never changed. I can only guess it's one of two things:
1) the 5.6.12_190807 firmware somehow locked the cam, so (even though it seems the firmware upgrade process worked) no subsequent firmware can install
2) the Hikvision programmer(s) neglected to change the version in the .dav file, so it's reporting the wrong version
....wait a minute, a third option just occurred to me:
3) they just copied/doubled the code in the 5.6.12_190807 firmware to make it look like they were taking action and released that (probably not, but maybe)
The Hikvision disclosure page (Security Notification - Command Injection Vulnerability in Some Hikvision products) is confusing on whether or not (whatever) the firmware I'm running is vulnerable. On the positive side, the row for the DS-2DExxxx cams states "Versions before (not include) V5.5.0 build xxxxxx " are vulnerable. That would be good, except that in the paragraph above the table it states "Your device firmware is affected by this security vulnerability (CVE-2021-36260) if its version dated earlier than 210628. " 190807 being before 210628, I can only conclude after all of this, I am still running vulnerable firmware

If anybody has any tips on my situation or tests I can run to see if I'm still exploitable, I'd welcome them. I don't expose the cameras directly to the internet, but the VMS I use (Zoneminder) is accessable outside the LAN. I think that affords me some level of security against the exploit, but I still hate the idea of running two compromisable (that'll be an acceptable word to Webster's sooner or later) devices on my network.

“And I only am escaped alone to tell thee.”

 

[alastairstevenson]

when I check the System Settings, it reports I'm running V5.6.12 build 190807 firmware (not 5.6.800_210628)

That's a bit odd!
Not something I've seen, or heard mention of.
It sounds like one or more of the updates only held a subset of all the files.

The latest firmware for the NP104-IR/4X (5.6.12_190807) flashed fast (file is only 23MB) and picture quality/functionality didn't change. The .dav file I downloaded from the international Hik site was the latest version I could find, 5.7.1_211015, it was nearly double in size (46MB).

That's odd too, the firmware sizes generally stay about the same or get larger with each new version.
But I've not really explored how the firmware update process handles the OEM code that's coded into the camera bootpara data - it seems just to be ignored.

I wish a simple command/test would have accompanied the advisory, some harmless command I could run against the cams that would confirm they were vulnerable, but I guess that would help the bad guys down the road to exploiting the vulnerabilities.

It's already happening for those that knowingly or not expose their IP cameras to the internet.
One example :

Mirai-based Botnet - Moobot Targets Hikvision Vulnerability | FortiGuard Labs

FortiGuard Labs analyzes how an attacker can leverage CVE-2021-36260 to create targets for Moobot which is a DDoS botnet based on Mirai. In this blog we explain how an attacker delivers this payloa…

www.fortinet.com

There is a proof-of-concept that was created by researcher @bashis that you could run on your pi to assess the possible vulnerabilities in the cameras.
The --check option is harmless enough.

PoC/CVE-2021-36260.py at master · mcw0/PoC

Issues has been disabled for these PoC's, as they are simply PoC, Public Domain and unsupported. - mcw0/PoC

github.com

 

[SEdawg]

Thank you for the quick comments Alastair, especially the link to the PoC github. I downloaded the py code and ran all the tests against the cameras (pinging each first to be sure they were responding).
All commands failed with "Cannot establish connection to 192.168.1.64" except:

./CVE-2021-36260.py --rhost 192.168.1.64 --rport 8080 --reboot

which reported the remote is vulnerable.

I'm hoping this means my cams are not vulnerable, excepting a command to restart itself (which doesn't seem like a big attack vector unless an attacker establishes a TFTP server on my LAN). Would you agree?

 

[alastairstevenson]

All commands failed with "Cannot establish connection to 192.168.1.64" except:

Dumb question for which apologies -
Is that definitely one of the camera IP addresses and is the pi on the same IP address range?
That error message usually suggests a network connectivity problem.

 

[alastairstevenson]

Just a thought - have you customised the web GUI port away from 80?

 

[SEdawg]

Dumb question for which apologies -
Is that definitely one of the camera IP addresses and is the pi on the same IP address range?
That error message usually suggests a network connectivity problem.

Not dumb at all, I miss the crucial little details all the time. I'm on the same range, I can ping other devices and the cameras do respond to the pings. I haven't changed any ports that I can recall, the GUI lists ports as:
HTTP: 80
RTSP: 554
HTTPS: 443
Server Port: 8000
Enhanced SDK: 8443

The suggested py commands all use port 8080. Just to be sure, I tried the commands on port 80 and port 8000. Nothing worked on 80 (error 200), but 8000 had the exact same results as 8080 (only the reboot command was reported to be vulnerable).

 

[alastairstevenson]

The suggested py commands all use port 8080.

The tests should be performed against the actual web HTTP GUI - that's the path down which the vulnerability can be exploited.
The tests are not totally definitive - there are firmwares where the vulnerability can't be verified.
But in many cases, the result is clear.

Here is a worked example of a selection of cameras of various models and firmware versions.

alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.112 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.112:80"
[i] ETag: "e69-258-601f845c"
[!] Remote is verified exploitable
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.111 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.111:80"
[i] ETag: "468-258-5e6f4e77"
[-] Could not verify if vulnerable (Code: 500)
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.107 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.107:80"
[i] ETag: "468-258-5e6f4e77"
[-] Could not verify if vulnerable (Code: 500)
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.106 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.106:80"
[i] ETag: "39b-1e0-5784b16e"
[+] Remote is not vulnerable (Code: 200)
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.105 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.105:80"
[i] ETag: "8f6-1e0-587ec5e1"
[-] Could not verify if vulnerable (Code: 500)
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.104 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.104:80"
[i] ETag: "31a3-258-5fe206d5"
[!] Remote is verified exploitable
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.103 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.103:80"
[i] ETag: "468-258-5e6f4e77"
[-] Could not verify if vulnerable (Code: 500)
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.102 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.102:80"
[i] ETag: "2a2-258-5e8c6abf"
[-] Could not verify if vulnerable (Code: 500)
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.101 --rport 80 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.101:80"
[i] ETag: "383-1e0-5784b16e"
[+] Remote is not vulnerable (Code: 200)
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $

And here are the respective models and firmware versions :

 

[SEdawg]

Ah, so I guess checking against port 80 was indeed what I should have done. Running all checks against 80 return remote is not exploitable (Code 200), save the simple reboot command. I'm thinking/hoping I'm safe, at this point.

Thank you for all your assistance!