alastairstevenson
Staff member
I think you are right.
The '.800' suffix in the firmware version is typically what Hikvision are using to designate the (many) RCE-fixed versions of their firmware releases.
Updating Hik OEM camera to Hik firmware
- Thread starter Securame
- Start date
The '.800' suffix in the firmware version is typically what Hikvision are using to designate the (many) RCE-fixed versions of their firmware releases.
With the param '--check' the script will just try to verify if remote target are verified exploitable by writing and reading on remote.
With the param '--reboot' the script will just try reboot remote target with simple '$(reboot)' CMD injection, waiting 2 seconds and trying to access the target with a GET request, if no connection can be done - the script will assume remote are vulnerable, but not verified exploitable with read and write. (Still - $(reboot) shows it is exploitable as it really do CMD injection)
I would recommend to use both '--check' and '--reboot' arg in the test, if you just want to check if remote could be vulnerable/exploitable and really do not care if remote will reboot or not.
[As described in the PoC script]
Safe and unsafe vulnerability/verify check:
(will only use 'unsafe check' if not verified with 'safe check')
$./CVE-2021-36260.py --rhost 192.168.57.20 --rport 8080 --check --reboot
safe = '--check'
unsafe = '--reboot'
Above examples by @alastairstevenson,
1. '[-] Could not verify if vulnerable (Code: 500)' with only arg '--check' could still be vulnerable/exploitable with arg '--reboot'
1.1 - This check should be re-done with arg '--reboot' for verification
2. '[+] Remote is not vulnerable (Code: 200)' are not vulnerable nor exploitable, regardless using arg '--check' (no write and read) and/or '--reboot' (still answer on requests)
3. '[!] Remote is verified exploitable' with arg '--check' has successfully both written to remote and read back same from remote
4. '[!] Remote is vulnerable' with '--reboot' has successfully rebooted remote
Best, bashis
Last edited:
Thanks bashis. I tried with --reboot on the correct port (80) and it reported not vulnerable. I can sleep soundly again....hopefully for awhile.
Hi,
I see the following on an OEM camera which I am told is HikVision. How can I confirm it is HikVision and that firmware is upgradeable on it?
Reason for upgrade: I am trying to connect it to Avigilon Alta Aware (their new cloud system) and the camera keeps disconnecting so they tell me it is an ONVIF improper implementation issue and that upgrading it to HikVision firmware might fix it.
Thanks
I see the following on an OEM camera which I am told is HikVision. How can I confirm it is HikVision and that firmware is upgradeable on it?
Reason for upgrade: I am trying to connect it to Avigilon Alta Aware (their new cloud system) and the camera keeps disconnecting so they tell me it is an ONVIF improper implementation issue and that upgrading it to HikVision firmware might fix it.
Thanks
Hi,
Thanks for the reply.
- How do you know G5 is compatible?
- Please share the download link or full G5 model number so I can search for the firmware. I am new to HikVision.
- Can you please link to guide on how to upgrade this?
Much appreciated.
alastairstevenson
Staff member
In your System screenshot above, Hikvision introduced the 'Firmware Version Property' field due to endless confusion between model numbers and firmware sources.
Yours has G5 embedded in that field.
The Maintenance page of the camera web GUI is the safest way to do a firmware update in terms of validating the firmware being updated to - though there is always some risk of an adverse result.
A good source of G5 firmware here - I think 01 has the best chance of being a match, unless you know your camera is in one of the less common types further down :
Proceed at your own risk - updating an OEM model with native firmware does add to the uncertainty of a good result.
Thanks and much appreciated.
ONVIF implementation on my camera: CDNC328G2-XD/28W shows Version 23.06 which is from 2018. I want 2023 version of ONVIF so the motoroal avigilon tech can stop complaining about incompatibility.
1- Do you have a guide for upgrade so I give this a try?
2- Seller said my camera is same as: DS-2CD2383G2-IU but I think he is not very accurate as he tried to buzz me off. He also said I have the latest firmware but apparently not. Would DS-2CD2383G2-IU be in the same link you sent for firmware?
3- Based on the link you sent I see the following would be the logical way - do you concur?
Doesn't seem like my camera is:
solar
wildlife (camouflage?)
dual lense or people counting
fisheye
anti-explosion
These models not sure but probaby is not either:
HEOP or Smart hybrid
2xx7G2p or 3xx7g2p
That leaves me with:
01. (2xx3G2 2xx6G2(C) 2XX6G2H 2xx7G2(C) 2XX7G2H 3xx6G2(C) 3xx7G2(C) 1x83G0)
4- Is there a way to download current firmware from the camera and keep it as backup that if the camera BRICKS then I can restore it to its own crappy firmware?
Thanks.
alastairstevenson
Staff member
For the web GUI update - log in to the camera web GUI and go to the maintenance page.
Unzip the firmware file into a known folder on a PC local drive.
In the camera web GUI, browse to the file and click the update button.
The system will validate the offering and reject what's not a match, hopefully.
Cross your fingers ...
When applied to the camera, the firmware is split up, decoded, decrypted, the files spread around multiple locations.
So it no longer exists in its original form.
And unless you've hacked the camera, it's not realistic to gain internal access to preserve the status quo. Not impossible, but not that easy.
Unzip the firmware file into a known folder on a PC local drive.
In the camera web GUI, browse to the file and click the update button.
The system will validate the offering and reject what's not a match, hopefully.
Cross your fingers ...
When applied to the camera, the firmware is split up, decoded, decrypted, the files spread around multiple locations.
So it no longer exists in its original form.
And unless you've hacked the camera, it's not realistic to gain internal access to preserve the status quo. Not impossible, but not that easy.
alastairstevenson
Staff member
That's a different process, not via a browser access to the camera, it's a lower-level command-level type of access.
The browser access, if still available, has more validation checks and is safer.
Understood. I will try the browser method first and if it fails I will do tftp. Can you please send link for that guide too? OP posted that an older tftp process guide is no longer working and there is a github project to unbrick the camera which seems to have worked for him. In the readme of that github project I didn't see any mention of tftp server. Does the camera do a pxe boot or looks for a tftp server and one has to run a server on specific subnet for camera to get the files etc? A comprehensive guide would be appreciated.
I will have limited time on site and if browser firmware upgrade rejects I would like to have tftp server method ready as well.
alastairstevenson
Staff member
That sounds like Scott Lamb's Hikvision tftp updater Python-2-based clone.
It's useful when the firmware filesize is larger than 32MB - the Hikvision tftp updater doesn't handle files larger than than 32MB.
The camera sends a UDP probe packet using a specific port and address, and if it gets a response on another specific port and address considers it's a successful handshake to start accepting the file download via tftp.
The tftp updater historically listens on 192.0.0.128 for packets from 192.0.0.64 but in later manufactured devices the camera sends to 192.168.1.128 packets from 192.168.1.64
Be aware that 'forcing' firmware via the tftp updater method involves fewer validity checks, so more chance of a non-working end result if invalid firmware is applied.
Instructions and Hikvision tftp updater here :
TFTPServ
Hikvision IP Camera Emergency Firmware Recovery TFTP. Check this thread for info on how to use this tool to un-brick your Hikvision camera.
That sounds like Scott Lamb's Hikvision tftp updater Python-2-based clone.
It's useful when the firmware filesize is larger than 32MB - the Hikvision tftp updater doesn't handle files larger than than 32MB.
The camera sends a UDP probe packet using a specific port and address, and if it gets a response on another specific port and address considers it's a successful handshake to start accepting the file download via tftp.
The tftp updater historically listens on 192.0.0.128 for packets from 192.0.0.64 but in later manufactured devices the camera sends to 192.168.1.128 packets from 192.168.1.64
Be aware that 'forcing' firmware via the tftp updater method involves fewer validity checks, so more chance of a non-working end result if invalid firmware is applied.
Instructions and Hikvision tftp updater here :
TFTPServ
Hikvision IP Camera Emergency Firmware Recovery TFTP. Check this thread for info on how to use this tool to un-brick your Hikvision camera.www.ipcamtalk.com
Inside the 01 folder I found four other and tried two and I got "ugrade failed" from browswer upgrade process.
Is there a surer way to know which firmware this might be so I can force tftp to it?
Thanks,
alastairstevenson
Staff member
In theory, but rarely in practice in my experience, Hikvision could do OEM code matching in the firmware header against the camera OEM code and block updates on a mismatch. That's a possibility.
Hey I'm in a similar situation where I need to use Scott lambs tool.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.”
I'm a bit of a newbie to Linux and python.
Would you have a guide on how to setup the tool and uses it?
I've setup a virtual box debian environment and installed the packages. Just a bit unsure how to get the dav files in the folder via terminal and to execute the script.
Cheers