Hikvision Honeypot Hackathon

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
We get quite a lot of posts about port forwarding - and quite a lot of good advice in response about the risks, and pointers to more secure remote access methods.
And we still get posts related to the Hikvision backdoor vulnerability, where camera passwords are mysteriously lost, or cameras disappear from the network.
So I thought it might be interesting to relieve a bit of the lockdown boredom and see how well a Hikvision camera survives being accessible from the internet.
The short answer - it doesn't.

I set up port forwarding and exposed to the internet a DS-2CD2432F-IW cube camera, running the backdoor-vulnerable 5.4.0 firmware, using wireshark to record the traffic.
There was no shortage of probes - though there were actually very few that were Hikvision-specific.
The majority of probes were against the high ports - with only a few against SSH, telnet and HTTP/80
I'd guessed that ports probed might be targeting known weaknesses in the very many types of devices that allow inbound access from the internet.
But there did seem to be quite a spread. Maybe graphing them would show a picture.

Here is a summary of the types of probes, simplistically just using the wireshark built-in stats to get the proportions of packets.

9655 packets over five and a half hours, about 30 packets per minute.
60/40 split UDP / TCP.
7939 probe sources.
Just 3 probe sources made up 30% of the total - Alibaba Germany, Alibaba CA, Alisoft CN. Weird.
1.1% of the probes were against telnet/23
Just 0.5% of the probes were HTTP/80 with most just doing a "GET /" as opposed to something more interesting.
And 0.2% of the probes were SSH

0.5% of the probes were TCP/8000 and about half resulted in an HTTP GET, so were aimed at alternate web access.
The rest pushed a few bytes at the camera, but were presumably not part of the Hikvision API as the camera didn't respond back.

OK, so far, so normal. At 30 packets per minute unsolicited, it really underlines the risks of using port forwarding to remotely access your cameras.
And the predominance of the high ports in use also underlines that using high ports doesn't really provide much protection.

So what next?
I shut down wireshark and left the camera on overnight.
Next morning, the camera was still normally accessible. I started up wireshark again.
After a short while, the captured packet rate shot right up.
The camera had been hit!

Immediately after a TCP 3-way handshake to port 80, there was a PUT using the Hikvision backdoor to change the admin password to asdf1234
This was used to log in to the camera web GUI.
Then a couple of snapshots were retrieved, and a long series of SDK and ISAPI commands issued to profile the camera and assess capabilities.
Judging from the rapid rate of these, the interaction was automated / scripted.
There was no attempt to start a video stream.
The final activity was to issue a PUT /ISAPI/System/factoryReset?mode=full HTTP/1.1 command and leave it with a pending reboot.
A normal user would have been left with an admin password problem, and an inaccessible camera after being rebooted.

So, after just under 24 hours, a Hikvision camera subject to port forwarding was probed by nearly 8000 sources, and hacked.
I'm not at all surprised.
Hopefully this experiment may open up a few eyes as to the genuine risks associated with port forwarding for remote access.
Easy to do and convenient that it is, it's certainly not cyber-safe.
 

Bink

Getting the hang of it
Joined
May 25, 2017
Messages
76
Reaction score
28
Thanks for the detail; might be more interesting to see what happens with current firmware over an extended period of time.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I wish! That's a lovely looking pot.
Unfortunately I'm out of honey, and forbidden to go to the shops.
 

Mike A.

Known around here
Joined
May 6, 2017
Messages
3,825
Reaction score
6,377
Yeah, it doesn't take long for things to be found these days. Every IP is continually probed 24x7 across most all ports. Trying to hide things on high or otherwise obscure ports is long done.

From just a few minutes now (DPT=Destination Port):

DPT=42125
DPT=2404
DPT=1986
DPT=64032
DPT=3017
DPT=32132
DPT=5555
DPT=1433
DPT=5219
DPT=3410
DPT=60653
DPT=137
DPT=42170
DPT=31822
DPT=21694
DPT=27815
DPT=34276
DPT=3399
DPT=2077
DPT=9039
DPT=44459
DPT=1388
DPT=23
DPT=9807
DPT=5090
DPT=5432
DPT=30379
DPT=27822
DPT=886
DPT=29782
DPT=46458
DPT=54499
DPT=41135
DPT=23
DPT=2356
DPT=443
DPT=38851
DPT=43413
DPT=50076
DPT=5068
DPT=137
DPT=80
DPT=123
DPT=2027
DPT=20131
DPT=25292
DPT=2923
DPT=5052
DPT=9331
DPT=26921
DPT=5555
DPT=14323
DPT=81
DPT=20002
DPT=27530
DPT=23879
DPT=3769
DPT=3389
DPT=45719
DPT=2078
DPT=16107
DPT=2902
DPT=7385
DPT=57630
DPT=54629
DPT=38729
DPT=2913
DPT=57548
DPT=4008
DPT=5038
DPT=40666
DPT=8080
DPT=3381
DPT=2371
DPT=43966
DPT=30585
DPT=60462
DPT=21693
DPT=41466
DPT=12447
DPT=12302
DPT=5364
DPT=443
DPT=42739
DPT=7443
DPT=1080
DPT=5900
DPT=3107
DPT=31820
DPT=61900
DPT=1060
DPT=3481
DPT=3481
DPT=4579
DPT=4579
DPT=30512
DPT=1866
DPT=57296
DPT=2210
DPT=22
DPT=9363
I run a full-time monitor on my gateway just to see what's coming at me. You see some interesting things at times. e.g., Sequential, coordinated probing by multiple hosts working as 'teams' to avoid detection for such probes. A flood of probes to specific ports when some new zero-day comes up. How they'll converge on a port when there's some indication that there's something vulnerable there. Everyone should take a look at their router logs from time to time if for no other reason than to prove to themselves that it's an absolutely terrible idea to leave any typical consumer device open to the Internet.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I might just do that, in case there are any new Hikvision exploits being tried.
OK, so I thought I'd take up the suggestion of some forum members and expose newer Hikvision firmware to the internet.
I took a G1 camera (DS-2CD2135FWD-I) and updated it to the current IPC_G1_EN_STD_5.6.4_191224 firmware.
As Hikvision have added back the SSH enable to the web GUI, I used that, to increase the attack surface.
Presumably Hikvision believe that their psh shell is secure enough for exposure, behind the SSH access.
This camera survived the experience, unlike the other one.

After exposing the camera for 24 hours and logging the network traffic, here are some observations.
This is not a rigorous analysis down to fine detail, looking for evidence of potential new exploits for example, more of a broad-brush numbers summary from wireshark.
There might be some new exploits hidden in the capture, I'll be having a browse around to try to spot any oddities.

Over 24 hours, the number of unsolicited packets handled by the camera was 46,598, that's over 30 per per minute.
There were thousands of attempts to gain access to the camera, in addition to the routine scans that catalog the internet.
Many of those attempts were specific to Hikvision.
The scale and variety of the activity again really underlines the fact that being out on the internet is fraught with risk for a device that's not had cyber hardening as a design priority.
Don't succumb to the attraction of port forwarding! Take the time and put in the effort to install a VPN solution for remote access.

Some numbers :
TCP/UDP split 55%/45%
Top ports(qty) for TCP packets 80(4,448), 22(517), 445(349), 1433(336), 23(285)
The vast majority of probes were against the high ports, both for TCP and UDP.
5 sources made up 30% of all probes.
Their origin appeared to be Alibaba Germany, Alibaba CA, Alisoft CN, Lanet Ukraine.

There were 5 probes specifically targeting the Hikvision backdoor vulnerability.
Any of these would have resulted in a hacked camera if it had been vulnerable to that exploit.
Just 93 probes targeting port 8000, though none seemed to be Hikvision-specific.
One probe was from the polaris botnet against port 80

Interestingly the main way of brute-forcing a Hikvision-specific login was using the ISAPI interface, presumably faster than the webform.
GET /ISAPI/Security/userCheck HTTP/1.1
There were very many login names and passwords tried. Fortunately, the 'illegal login block' seemed an effective barrier.
And there were lots of GET and POST HTTP requests against a big variety of paths.
One source blasted though nearly 2000 in an automated way.
About 50 probes accessed the normal Hikvision login path, so Hikvision-specific.
 

Bink

Getting the hang of it
Joined
May 25, 2017
Messages
76
Reaction score
28
Thanks for taking the time to do this and the resultant write-up. While exposing these Chinese-made devices (no xenophobia here, but security is really not a priority to many of these manufacturers) is poor practice, I always take the added measure of session rate limiting, and blocking offenders, anything that’s exposed. This slows down these attacks, and conserves the resources they consume, and most back off once they determine they’re being rate limited.
 

SamM

Pulling my weight
Joined
Mar 29, 2020
Messages
245
Reaction score
109
Location
SA
Thank you for doing this test, It is most helpful that you took the time to document the results. Glad to know that other exploits are not being used at this time although I believe that any CN product will still have them, given their historic surveillance issues. Give a shout out if you need any help for future tests on any other exploits.
 

SamM

Pulling my weight
Joined
Mar 29, 2020
Messages
245
Reaction score
109
Location
SA
Thank you for doing this test, It is most helpful that you took the time to document the results. Glad to know that other exploits are not being used at this time although I believe that any CN product will still have them, given their historic surveillance issues. Give a shout out if you need any help for future tests on any other exploits.
Also, Can you give permission to use the contents of your reports?
 

mat200

IPCT Contributor
Joined
Jan 17, 2017
Messages
13,649
Reaction score
22,741
We get quite a lot of posts about port forwarding - and quite a lot of good advice in response about the risks, and pointers to more secure remote access methods.
And we still get posts related to the Hikvision backdoor vulnerability, where camera passwords are mysteriously lost, or cameras disappear from the network.
So I thought it might be interesting to relieve a bit of the lockdown boredom and see how well a Hikvision camera survives being accessible from the internet.
The short answer - it doesn't.

I set up port forwarding and exposed to the internet a DS-2CD2432F-IW cube camera, running the backdoor-vulnerable 5.4.0 firmware, using wireshark to record the traffic.
There was no shortage of probes - though there were actually very few that were Hikvision-specific.
The majority of probes were against the high ports - with only a few against SSH, telnet and HTTP/80
I'd guessed that ports probed might be targeting known weaknesses in the very many types of devices that allow inbound access from the internet.
But there did seem to be quite a spread. Maybe graphing them would show a picture.

Here is a summary of the types of probes, simplistically just using the wireshark built-in stats to get the proportions of packets.

9655 packets over five and a half hours, about 30 packets per minute.
60/40 split UDP / TCP.
7939 probe sources.
Just 3 probe sources made up 30% of the total - Alibaba Germany, Alibaba CA, Alisoft CN. Weird.
1.1% of the probes were against telnet/23
Just 0.5% of the probes were HTTP/80 with most just doing a "GET /" as opposed to something more interesting.
And 0.2% of the probes were SSH

0.5% of the probes were TCP/8000 and about half resulted in an HTTP GET, so were aimed at alternate web access.
The rest pushed a few bytes at the camera, but were presumably not part of the Hikvision API as the camera didn't respond back.

OK, so far, so normal. At 30 packets per minute unsolicited, it really underlines the risks of using port forwarding to remotely access your cameras.
And the predominance of the high ports in use also underlines that using high ports doesn't really provide much protection.

So what next?
I shut down wireshark and left the camera on overnight.
Next morning, the camera was still normally accessible. I started up wireshark again.
After a short while, the captured packet rate shot right up.
The camera had been hit!

Immediately after a TCP 3-way handshake to port 80, there was a PUT using the Hikvision backdoor to change the admin password to asdf1234
This was used to log in to the camera web GUI.
Then a couple of snapshots were retrieved, and a long series of SDK and ISAPI commands issued to profile the camera and assess capabilities.
Judging from the rapid rate of these, the interaction was automated / scripted.
There was no attempt to start a video stream.
The final activity was to issue a PUT /ISAPI/System/factoryReset?mode=full HTTP/1.1 command and leave it with a pending reboot.
A normal user would have been left with an admin password problem, and an inaccessible camera after being rebooted.

So, after just under 24 hours, a Hikvision camera subject to port forwarding was probed by nearly 8000 sources, and hacked.
I'm not at all surprised.
Hopefully this experiment may open up a few eyes as to the genuine risks associated with port forwarding for remote access.
Easy to do and convenient that it is, it's certainly not cyber-safe.
Thanks, really enjoyed the write up.

btw - a good resource for folks:

btw 2 - enjoyed and wanted to share this with folks:
Black Hat 2013 - Exploiting Network Surveillance Cameras Like a Hollywood Hacker
 

Flintstone61

Known around here
Joined
Feb 4, 2020
Messages
6,587
Reaction score
10,894
Location
Minnesota USA
Is Andy's firmware a step up from the other Amazon/Dahua items as far as phoning home code? After watching that video, I guess 2013 in Camera time is a long time ago....
 
Top