Unauthenticated Remote Code Execution (RCE) vulnerability in Hikvision IP camera/NVR firmware (CVE-2021-36260)

Would be interesting to know why, but I guess you comment out "remote.send(query_args='cat N>webLib/N')" ?
(I put the whole 'already pwn' check there to not have multiple same entry in (my) /etc/passwd)
Unsure , kept asking me for a password. bypassed the already pawned check.
 
FYI FWIW that I tried the script and it worked great once I installed the required software/modules on my CentOS box - thanks for the quick confirmation test!
 
I have heard that Hikvision has a website to test if your camera is vulnerable. Just needs the serial number and provides the new firmware
 
I suspect that you have a network connectivity issue with the target.
I use a non-routable IP. That said, substituting your commandline for my own situation, here is one result, which defaults to port 80.
So, all is good.


% Python3.9 ~/Desktop/hikvision.py --rhost 192.168.254.4 --check
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.254.4:80"
ETag: "c9b-1e0-5b8fa31f"
[-] Could not verify if vulnerable (Code: 500)
 
@bashis I'm wondering if you've worked up any ability to leverage the 'reboot' Language tag exploit to gain a root shell.
Code:
tar: can't open '/dav/.tar.gz': No such file or directory
[01-01 00:00:50][pid:0][HW_IF][ERROR]load language fail!
[01-01 00:00:50][pid:0][PSIA][ERR[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3499>:######## info.si_signo = 15
[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3500>:######## info.si_errno = 0
[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3501>:######## info.si_code  = 0 ()
[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3502>:######## info.si_addr  = 0x1
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot

I have a couple of fairly dumb Annke I51DF cameras I'm playing with, hoping to 'smarten' them up, just for fun.
They do seem to have a good hard shell around them, secure boot, signing etc etc.
 
I use a non-routable IP. That said, substituting your commandline for my own situation, here is one result, which defaults to port 80.
So, all is good.
So - and apologies for the dumb question - are you trying to test cameras connected to NVR PoE ports when the PC is on the same LAN as the NVR LAN interface?
Or have you hooked up the PC to an unused NVR PoE port and set the PC IP address to be in the range 192.168.254.x ?

You should probably also try the 'reboot' option of the PoC - that result is not definitive.
 
So - and apologies for the dumb question - are you trying to test cameras connected to NVR PoE ports when the PC is on the same LAN as the NVR LAN interface?

I don't think that is a dumb question. I can always use helpful suggestions. The way your question is worded, the answer is 'yes'.

I'm on a 192.168.x.x network and my NVR has an IP on that same network segment. The NVR is configured to use a non-routable IP for the cameras. The NVR is configured with no internet access and also a firewall rule to block traffic in and out on WAN interface.

To my best understanding they are not visible from the outside however anyone on my LAN can access them.
 
Ok, so to properly run the PoC against the cameras, the PC needs to be connected to an NVR PoE port, and have an IP address in the range 192.168.254.x
 
Have few Annke I61DR Cubes running V5.4.5 build 170123 , looks like they are not affected by this when search the Hik link above .

I'm guessing as these cameras are quite old there is no updated firmware released for them ?
 
Ok, so to properly run the PoC against the cameras, the PC needs to be connected to an NVR PoE port, and have an IP address in the range 192.168.254.x
Hmmmm. You mean the PC ethernet cable connected to NVR and assigned an ip in camera’s range? Probably be easier to change one camera to LAN IP on NVR segment and test it with PC. Would that work? All cameras are same model/firmware. Anyway, cameras are 2142FWD and I’m fairly certain they are not compromised. The Hikvision site does not accept the serial as subject to upgrade.
 
Have few Annke I61DR Cubes running V5.4.5 build 170123
Do you know if they are OEMd R0 series Hikvision cubes?
If so - there is a mysterious firmware update here, in the same version and build date format as the vulnerable devices in other series :

@bashis PoC comes up with this for a DS-2CD2432-IW on that same version of firmware :
Code:
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.105  --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.105  --reboot
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.105:80" with "reboot"
[+] Remote is not vulnerable
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $
 
Do you know if they are OEMd R0 series Hikvision cubes?
If so - there is a mysterious firmware update here, in the same version and build date format as the vulnerable devices in other series :

@bashis PoC comes up with this for a DS-2CD2432-IW on that same version of firmware :
Code:
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $ ./Hikvision_CVE-2021-36260_RCE_POC.py --rhost 192.168.1.105  --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.105  --reboot
[*] Hikvision CVE-2021-36260
[*] PoC by bashis <mcw noemail eu> (2021)
[*] Checking remote "192.168.1.105:80" with "reboot"
[+] Remote is not vulnerable
alastair@PC-I5 ~/coding_stuff/bashis_disclosures $


This was the old thread on them. They were Annke clones from what I remember
 
@bashis I'm wondering if you've worked up any ability to leverage the 'reboot' Language tag exploit to gain a root shell.
Code:
tar: can't open '/dav/.tar.gz': No such file or directory
[01-01 00:00:50][pid:0][HW_IF][ERROR]load language fail!
[01-01 00:00:50][pid:0][PSIA][ERR[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3499>:######## info.si_signo = 15
[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3500>:######## info.si_errno = 0
[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3501>:######## info.si_code  = 0 ()
[DSP][ERR]<1000524>[DSP]<sigsegv_handler><3502>:######## info.si_addr  = 0x1
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot

I have a couple of fairly dumb Annke I51DF cameras I'm playing with, hoping to 'smarten' them up, just for fun.
They do seem to have a good hard shell around them, secure boot, signing etc etc.
No, I don't have any cam like that to work with, but would be fun task. I would assume everything are R/O except '/tmp', would make a shell script there for execute and see what could be done. Limited input are known, and needs to be worked out as blind.
 
  • Like
Reactions: alastairstevenson