Hacked Dahua Cameras Drive Massive Mirai Cyber Attack

By Brian Karas, Published on Sep 27, 2016

Cyber attacks are accelerating and IP cameras are behind many of them.

Worse, last week, a 'massive' attack was carried out using numerous Dahua (and their OEMs) cameras. 

In this report we look at two recent attacks, the likelihood of similar future attacks and why IP video surveillance devices are increasingly at the core of these attacks.

CloudFlare ******** ******

************ *** ** *** largest ********* ******* *********** ******-**-******* (DDoS) *******.

* ********** ********** ********* that ******* **** **** in * ******* ******: 

********, ** ****** *********** ** IP ****** *** ***** pages **** ******* ** says ************. ***** *********** show * *****-******* ** in *** *******, ** well ** * ***** OEM [**** ** ****** available] *** * *****-**** UI ** *******:

***** **** **** ** be "****'* ****" ******* involved, ***** ***** **** been****** *-*** **************** **** *******, ** ******** ********* *******, ** *** ****** of ***** ******/****.

Akamai ******** ******

**** *** *** ****** major ****** ****** ** hacked ******* ** *** past ****.

***** ******* *** ** *** most ****-***** ************* ***********, and ** *** *** attacked *********:

**** ****** *** ** large **** *** **** / **** ********** ****** him ***:

******'* ***** ******** *******, Andy *****, ********** *** ******* ***** be ****** **** ****** cameras:

***** ***’* *** ************ that ** *** * network ** ******** ******* that ********* *** ******* of *******, ******* *** team ** ***** ********* the ******, ** ****, but **’* *** ** his **** ********. ** attack **** ********* ****** cameras ***** ****** **** tapped ******** ********* ** individuals ** ***** **********, he ****. “**’* ******** not * ****** *** office ******** **** * network ** *******, *** something **** ** ******* went ** **** *** and ****** * *** and ********* ** ** maybe * ***** ******,” he ****.

**** ****'* ******* *** ******* offline ** ** **** of ******** ******* ** NVRs ** **** ******, and ******** *** *** physical ******** ********.

Why *******/*** ******* *** ********

*** **** *** ** the ****** *** *** to ** ******** ** IP-enabled ******* *** ***'*/***'* being *********. **** ******** ** these ******* ********* ** the ********, *** * historical ************ ** ***** surveillance ************* ** ***** security, **** ****** **** targets *** *******. ****** in **** *****, **** the **** *******, *** ******* *** hackable **** ** *** installer *** *********** **** basic ****-********* **** ****** passwords.

****** ************* **** *** relatively ****** ******** ** the ******* ** ****** motivated *******, *** ** general **** *** ******* all ** *** ******* methods **** *** ** used, ******* ***** ******* easy *******.

*** ******* **** **** good ******* *** **** use ******* ***** *** be **** ****** ** notice ** ************ ****** right ****, ******** *** device ** ***** *** extended ******* ******* *** user ******** ** ****.

Profits ****** **** ********

*********** ** ****** ******* can ****** ********* ** dollars** *********** **** **** out, ********* *** ******* against ******* ** ******** for *****. **** ** pure ******, *** ********** of *** **** ******* sends * ******* ** the ******* **** *** attack ******, *** **** sits **** *** ******** a ***** (** **** likely, ********).

Camera-Based ******* ****** ** ********

**********, **'* **** ******** hacked ** ******** **** attacks, *** ** ** operating ******* **** ****** more ******, ******* **** turned ** ***** *********** devices **** *******. **** will ****** **** ** a ***** ** ******* being *********, *** **** patched ** ***** *************, that ***** **** ******* years ***** **** *** robust ****** ** ********* most ******* *******, ** customers ******* ******* **** direct ****-********** ** ******* and **** *** ** a ****** ******.

UPDATE: ***** ********

***** *** *********:

** ** ***** ***** has ****** ***** ** a ************* **** *** have ******** * ***** group ** ***** ** cameras. ** ***** ****** that **** ************* ******** the ******** ******* ** run ************ **** ***** compromising *** *******’ ******* capabilities. ** ***** **** appear **** **** ************* is ******* **** ** cameras **** *** ********* to *** ******** *** running ******** ******** (***-******* 2015).

** *** ******* **** cameras **** **** ********, please ***** ***** **** firmware ** **** **** you *** ******* *** most ** ** **** firmware *********. *** ******* *** **** ******* firmware ****** ** **** ********* to **** **** ******** up ** **** ** all ** **** *******. Additionally, ** ********* **** forwarding ***** **** ******* actually ****. *** **** tips ** *** ** boost *** ************* ** your *******, ****** ******* the ************* **** ** our ******* [**** ** longer *********].

***** ** ********** *** investigation **** **** ************* and **** **** ** ensure **** **** ***** products **** *** ******, securely, *** ** ********. Dahua **** ******* *** updates ** ***, *******, if *** **** *** questions ** ********, ****** do *** ******** ** contact *** ************* **** at *************@******.*********.***.

**** ***** *** ******* **** their ********** *** ***** interested.

** **** ***** ***** ** clarify **** ******** ************* existed **** *** ********* in *** ******* **** firmware *******.

Comments (70)

To play devil's advocate, outside of random embarrassment, what will really drive video surveillance manufacturers to rectify this? Have we not seen enough evidence that manufacturers can have serious issues with near zero practical consequences? e.g., the still legion of vulnerable, not upgraded, Axis cameras out there...

I attended Black Hat this summer and one of the largest topics was the general ease someone with modest skills could infiltrate a network via IoT devices especially network cameras. The proliferation of IoT devices is almost making it almost too easy for hackers, if the vendors in our space ever catch up the targets will just shift to the next “smart” device.

I attended Black Hat this summer

1, thanks. How did you like it? Do you recommend it to other people in our industry?

I would not for someone new to the Cybersecurity market, it is radically different from something like ISC or ASIS.

It is mostly focused on the educational track rather than the show floor and can be fairly expensive to attend. If someone isn't already fairly well versed in this space they might be over their head at this event.

1, for you, how useful did you find the educational track?

Extremely, it is such a fast moving market in terms of the type of attacks and the products being released to defend against those it is about the only live venue to see the latest from both sides. If you are on the defense side there isn't anything like IPVM out there.

The other big show on the cyber side is the RSA Conference, I haven't been to it but I am planning on attending in 2017. From what I hear it is more like a ISC or ASIS with 30-40K attendees each year.

John, Black Hat is really for folks in the field/studying to be in the field (i.e., cybersecurity / information assurance). It is very informative and educational... not to mention a bit spooky to see what these guys can do. Happens every July (end of) in Las Vegas... lots of fun!

Happens every July (end of) in Las Vegas... lots of fun!

How much does it cost?

Do they take credit cards?

You can find the info here: https://www.blackhat.com/us-16/registration.html#pricing

Thanks, very simple. I just gave them my SS and they said they already had my credit card.

direct port-forwarding to cameras and NVRs can be a losing battle.

So what's the recommendation right now, no port forwarding and stick to VPN's for remote access?

It seems at this point; no camera manufacturer is secure. Are the cameras that have been hacked on a private network where the only point of access to the outside world is through the server where the VMS is running? Or are these cameras directly connected to the internet using default security credentials and default ports.

For us to understand how we can better secure our customers, I think it's important to understand how these attacks are happening and how the systems are setup. If no one is getting hacked using non-default credentials, then we need to know that too.

I realize this is a substantial question but the more I learn about the surveillance industry, and it's vulnerabilities, the more diligent I want to be.

I'm with John above, it would be very helpful to know more about how these devices are being compromised. Do they know if it's only devices with default UN/PW exposed to the internet via open ports? this is what the industry is usually suggesting but that still makes me wonder my next question.

Even with the UN/PW known, how are they changing or executing code on the cameras through the web interface? Assumption here is that any other port would be blocked, so how are they actually modifying the cameras to run the attacks later? Just because there is an open web interface shouldn't mean a 3rd party can modify the firmware. If they are actually going in and uploading new firmware, then maybe the manufacturers should only allow updates if connected locally. Or better yet, create a secure connection back to their servers to make sure firmware is legitimate. Gray market owners won't like that but then again, who knows where the gray market firmware is coming from.

Or could they be infecting PCs on the same local machine that can access more vulnerable ports on the devices to make changes like SSH?

I'd like to also add, how do we know if a camera has been compromised? does a simple firmware update fix it?

Assumption here is that any other port would be blocked, so how are they actually modifying the cameras to run the attacks later?

You can set ssh to run on port 80, disable http, reboot, login for a shell, add code, re-enable http, reboot.

During the attack the bot only needs outbound ports, which are not typically blocked.

This is assuming that port 22 is forwarded to the camera to begin with, or you have control of another local host. It also assumes that outbound traffic from the camera isn't regulated.

These are very simple things to prevent, as long as the integrator chooses to do them.

This is assuming that port 22 is forwarded to the camera to begin with, or you have control of another local host.

No, it doesn't. I am saying you change the port that ssh is enabled on to be 80 (or whatever port the camera is using for http).

Which is already open, or how did we get to the gui?

Outbound ports, especially ones for DNS and NTP, are often left open because of the difficulty/expense of setting up local time servers.

I know you always setup dual NIC card VMS servers running local time services with professional firewalling, but many do not.

This is a good reason why certain features in the web GUIs should only be accessible locally and not remotely which should be set in the firmware itself. The two main things that come to mind are the firmware update option and any shell access. This at least makes it more difficult for cameras connected to the internet to be infected.

So what's the recommendation right now, no port forwarding and stick to VPN's for remote access?

In a perfect world, maybe yes. From a practical standpoint you likely realize that is hard to implement.

A general recommendation for the purposes of securing any network of devices is to first minimize your attack surface. This means reduce, as much as possible, the number of devices that can be remotely accessed without requiring something like a VPN or higher-level service that restricts anonymous access.

For a network of cameras you can reduce your attack surface by installing an NVR (or similar device) that provides access to multiple cameras through a unified interface and login credential. This alone will not make your network "secure", but if it does get compromised you have reduced the compute power available to the attacker (this is assuming the attacker wants to use the device for a DDoS or similar purpose), and you have also reduced the amount of post-hack cleanup you have to do (rebuild/reinstall one device instead of 16).

Secondly, this NVR(like) device should ideally come with some sort of certification from its manufacturer that shows it has undergone some amount of basic PEN testing and can withstand common known attacks. This is not a guarantee that it is unhackable forever, but it shows that at least for now it should be able to withstand casual to moderate attack efforts.

If the device is not certified (and at this stage, most will probably NOT be certified) you can take some time on your own with common pen testing tools and see if a particular brand or model of NVR passes more tests than others. You may be able to find something that with moderate configuration can be more secure than average.

At this stage you are probably in the top 10 percentile of secured devices, meaning that your network is going to be harder to penetrate than many others. Because this is a game of numbers/volume, the attackers looking to exploit devices will try to script as much of this as possible. If your components do not look "interesting" or weak from a casual scan, you stand a decent chance they are passed over entirely.

You can probably take a giant lead forward from there by installing a firewall that can block/blacklist large blocks of IPs, potentially by subscribing to a IP blocklist provider. At a minimum you can probably block out IP ranges from incoming connections that do not correlate to your local region. This is on the premise that your users are likely to be relatively close to home when accessing devices remotely.

For users that travel, you may need to reduce the blocklist to just foreign subnets (Russia, China, etc. (unless of course you are in Russia...)), or require the use of a VPN when the user is "remote". This makes it more convenient to casually check on things most of the time, and then fire up the VPN when you're truly remote.

A step beyond all that is a firewall that can automatically detect and block port scans, or potentially even a device like a web application firewall, which can scan traffic at a lower level and look for common exploit attempts. This is probably overall for non-enterprise applications though.

That's a start, let me know if there are more questions.

Brian, great points and I completely agree (Aim to make it as difficult or unattractive as possible for an attacker.)

Our cameras reside on a infrastructure that is pre-approved by our Network Engineers. The NVR’s sit in-between the cameras and the Network Switch. The Network is only accessible by VPN and our company employs a constant training / retraining program to educate the weakest link (end user).

We know we can’t stop all attackers however we are trying very hard to keep from being an attractive target.

Thanks for the feedback/info, sounds like you have things pretty well locked down.

When you are required to port forward to a device behind your firewall, you're by definition providing public access to said device and in the process transforming it into a publicly accessible internet server. This commitment requires responsibility on your part both in the initial secure configuration and ongoing maintenance, monitoring and care. At MultiSight something like 10% error rates of API requests due to probing by malicious sites was not uncommon. In summary, hang a device off the public internet and (congratulations!) you've become the administrator of a public site with all the implications thereof.

(Obviously, we're assuming a lot about the vulnerabilities being exploited here--that the devices were configured on the public internet via port forwarding or otherwise)

Your advice, Brian, is great. But should it be necessary? It's not if you're running a type of IoT device that doesn't follow this same architectural model for remote access.

Many devices--what I would characterize as "true" IoT devices--connect outbound from behind a NAT and establish a connection to a cloud-based service where they then poll for commands or retain an open two way connection for ongoing communication. The end-user interacts with the device with this cloud-based service as an intermediary. No firewall holes required. Assuming the service provider maintains a secure environment, there is little if any attack surface area at the device on the end-user customer's network.

This is how most of the devices I'd label as IoT work today. The practice of putting the device behind a firewall then poking holes in the firewall is an anachronism. I understand why it's often most practical, given the needs of low latency high bandwidth video streaming and the state of the offerings from existing manufacturers. But alternatives to the latter exist and should become more common in the future.

The issue is twofold; manufacturers have to do better closing vulnerabilities quickly and installers need to secure the networks that these devices run on.

installers need to secure the networks that these devices run on

What does this mean? How do we know what little steps we can take that really work vs hiring a true IT security professional?

My first response would be if you are installing any devices on an IP network, you should be IT savvy.

That said, a properly configured, professional firewall will block a majority of the issues. Nothing is 100%, in liu of not connecting the system to the Internet. But you can restrict which hosts have access to the camera network. You can also restrict the outbound traffic from the camera network as well.

You can also restrict the outbound traffic from the camera network as well.

True, blocking traffic to remote/foreign networks could be beneficial, though in theory if your device is trying to communicate OUT to an undesirable network that likely means that someone undesirable has already gotten IN. Exceptions here would be reflector attacks, but that outbound traffic could be targeted to more local networks (local being a datacenter in your same geographic area) and may not have hit a restriction filter anyway).

Overall, blocking outbound traffic will have the same challenges as blocking inbound traffic, you have to find the right set of networks to block that increases securing without decreasing the ability for the customer to easily use the system.

So are we working on the assumption that these cameras weren't compromised BEFORE install? That they weren't installed with tampered firmware? We know for sure that they were tampered with post install?


For the time being I think that is a safe assumption, they were not hacked at the factory or installed in a tampered state.

That is certainly a potential scenario, but I think if you are really worried about your cameras arriving with corrupted firmware you need to find a different vendor.

Wow, this is bad news.

In thinking more about these problems, one thing manufacturers could do is offer a kind of port-knocking-as-a-service.

Port knocking is a stealth way to enable remote access by sending a set of packet requests that "knock" on a firewall. If the requests follow the right sequence, the firewall opens a port. Kind of like a "secret knock".

The layout would roughly be:

Camera system is setup so that it is whitelisted to only allow traffic from a remote IP, which is an IP address associated with a cloud server the manufacturer controls.

The corresponding app has the login details/info per usual, but is configured to first send a request to the cloud server the manufacturer maintains. That request effectively says: my current IP is x.x.x.x and I want to access the device known as "Home NVR" with "username/password". If the info checks out, the manufacturer cloud server sends info to the on-site NVR (via its white-listed IP) that says "allow an incoming connection from x.x.x.x on port y" (the port y part is dynamically assigned). After that command, the cloud server sends a response to the app that says "ok, go ahead and connect on port y".

The other component here would be that the NVR would auto-expire this access request after some amount of time and/or inactivity.

With this you would have a dynamically managed IP whitelist, without needing to expose your NVR directly to the "raw" internet. It would solve the majority of remote attacks/exploits, with very little overhead on the cloud server since you are not routing all video through the cloud, just an initial connection request.

Camera system is setup so that it is whitelisted to only allow traffic from a remote IP, which is an IP address associated with a cloud server the manufacturer controls.

This IP would be well-known, and therefore spoofed, no?

Yes, you could restrict using a higher layer thru certificates and SSL, but then would you even need the IP restriction?

I would envision it as an HTTPS connection (for simplistic encryption) between the cloud server and the onsite device. It would be a simple data exchange, but still two-way (not just a direct "open this port for x.x.x.x"), and over TCP. This would pretty much eliminate the option to spoof the IP of the cloud server and send an incoming connection configuration request.

There are multiple ways this idea could be implemented, and it might not require a whitelisted IP (and the general risks/issues for the manufacturer in being so tightly tied to that IP). However by doing a whitelisted IP for the initial incoming traffic you make the NVR device nearly transparent to all casual port sniffing.

If the info checks out, the manufacturer cloud server sends info to the on-site NVR (via its white-listed IP) that says "allow an incoming connection from x.x.x.x on port y" (the port y part is dynamically assigned). After that command, the cloud server sends a response to the app that says "ok, go ahead and connect on port y".

How does the NVR open the router's firewall on a arbitrary port selected dynamically to allow the connection?

The NVR is running its own firewall (iptables).

The router is configured with a port-forwarding range, say 20000-21000 to forward through to the NVR. The NVR is setup to pick a port in that range.

Though with the dynamic whitelists, the dynamic port might not be required or adding all that much additional security.

The NVR is running its own firewall...

Thanks. I didn't understand the interaction between the firewalls at first.

Also, I'm not understanding how the knocking is implemented. Are you saying that the cloud server dynamically creates a knock sequence of ports that it transmits to client and server?

In traditional port-knocking the client sends a series of "knocks" (essentially packets to a pre-determined sequence of ports) and then the server opens up a defined port for a specific service, like SSH.

In my proposal the client sends a knock of sorts to a 3rd party cloud server. That server verifies the "knock" and then sends a message to the NVR to open up a port and accept an incoming connection from the remote IP of the verified client.

It's port-knocking with a middle-man.

Ok, now I am understanding better. Just a couple questions:

How does the client know what the sequence is to port knock with?

How would it be kept secret?

Moreover...doesn't that still necessitate that there be an open port for listening to the cloud/authentication server?

Wouldn't someone on the inside be able to capture the authentication packets and duplicate that for themselves?

If we're considering threats, we need to think about inside jobs to be thorough.

I can forward this idea up to my Dahua rep. It seems she has some pull with the R&D department. Especially, if I was able to kiss up to her enough to get her to reopen firmware development on a cam that was released back in 2012 to try and cure an RTSP security flaw. Let's see who can guess the other member I am referring to before he speaks up to say hi to me :D

Let's see who can guess the other member I am referring to before he speaks up to say hi to me :D

Hi Robert!

Is it me?

Um...I only recall one customer I needed to do all of that for and he's not an undisclosed on here, lol.

That and he got me my free month here.

But if you buy from me over @ SavvyTech, then hi there! :D

he's not an undisclosed on here...

Actually, he's not sure himself.

Well done! You solved the mystery. I'm guessing you deduced that from his original firmware complaints or the fact that he introduced me here shows up somehow?

This level of admiration is kind of creepy TBH....

That he figured it out?

Or that I'm grateful for the account?

You want creepy? I was fangasming over Honovich giving props over email for my first post here. Even I had to tell myself to calm down there.

No, U3 may be the same person who keeps tabs on me frequently and has links to my posts on deck. I'm unsure what I've done to endear him/her to me.

U3 may be the same person who keeps tabs on me frequently and has links to my posts on deck...

Oh come on, you love it, you big ol' ham!

Hey Robert, regarding that firmware I'm curious about something.

Back here, Jon says that the OEM tech said to use only the NTSC version not the PAL version.

If used with IP cameras and the HDMI output though, what wouldn't have worked?

The cameras don't have an HDMI output.... Not sure if that was what you are meaning here. Or if you meant the output of the NVR/VMS?

The cameras don't have an HDMI output.... Not sure if that was what you are meaning here. Or if you meant the output of the NVR/VMS?

I'm just trying to find an acceptable solution for the many Dahuan devices which have PAL firmware available but no NTSC version.

If the trade-off for not having your camera hacked into is a reduction of the max frame rate from 30 to 25, many might feel it worth it.

He already fixed not being able to load the firmware by using port 3800 for the firmware recovery method.

If you have the branded cam or you don't mind your OEM product sporting the logo in the firmware then you can use this: https://www.odrive.com/s/1c536a0d-c072-4742-8f13-2389c5a3bd83-579fc195

That's if you have the same model/series as John.

Edit: You know what, you said many. Just give me all of your freaking model numbers so I can cross reference.

Still matters. The outbound stream will be whatever framerate PAL or NTSC dictates it to be.

The outbound stream will be whatever framerate PAL or NTSC dictates it to be.

Seriously, Robert?

Doesn't the user "dictate" the frame rate?

Do you mean max framerate? What was Jon's framerate?

So 25fps would be the limit for PAL and 30fps for NTSC.

Are there any other limitations of the PAL firmware when used with IP cameras in a system with HDMI (non-ntsc analog outputs)?

Yes, max frames per second.

Other differences, should they exist, are probably minute and negligible. For a more precise answer, I'll have to wait till Dahua is back from vacation. I'll grill them for specifics when that happens.

Just for my own mental frame of reference, this concept is also used by Wake-On-LAN, correct? I think in the WOL realm they are called "magic packets".

When we installed Dahua's DDNS service on our Amazon web server it was compromised and cost us thousands of dollars in bandwidth because it sent out DDOS attacks...

DNS servers in particular are common for DDoS attacks. Due to the way the DNS protocol works you really do not even need to exploit the server to use it for reflection or amplification attacks.

What was the interest/benefit in installing their DDNS service? Did it allow you to brand it as your own or offer some other benefit over other DDNS options?

Only branding, and we never even used it with our customers. We let it run for 1 month to test and within that month we got hit with the DDoS.

Were you a unwilling partner in the attack or the target of the attack?

Unwilling partner, the DDNS software we installed on the EC2 AWS server was compromised, and they used that server as a source for at least part of the DDoS that was going on.

Is there an article on IPVM that goes over the specifics of basic best practice for securing our systems?

Also is it my understanding that embedded NVRs like Hikvision with cameras directly connected are harder to hack than systems run over the network?

Most of our systems are 16 channel or less and cameras plugged directly into the POE ports on the NVR and the only network access we have is plugged into the router for internet access. What kind of vulnerability does this setup have?

We have an analysis of the Axis cyber hardening guide which is a good starting point.

Dahua has responded:

As of today Dahua has become aware of a vulnerability that may have affected a small group of Dahua IP cameras. It would appear that this vulnerability exploits the affected cameras to run unauthorized code after compromising the cameras’ network capabilities. It would also appear that this vulnerability is limited only to cameras that are connected to the internet and running outdated firmware (pre-January 2015).

If you believe your cameras have been affected, please first check your firmware to make sure you are running the most up to date firmware available. You can find the most current firmware here It is very important to keep your firmware up to date on all of your devices. Additionally, we recommend only forwarding ports your devices actually need. For more tips on how to boost the cybersecurity of your network, please consult the Cybersecurity page of our website.

Dahua is continuing its investigation into this vulnerability and will work to ensure that your Dahua products will run safely, securely, and as intended. Dahua will provide any updates it has, however, if you have any questions or concerns, please do not hesitate to contact our cybersecurity team at cybersecurity@global.dahuatech.com.

Here is the PDF version with their letterhead for those interested.

I've asked Dahua to clarify what specific vulnerability existed that was addressed in the January 2015 firmware release.

If you have questions, feel free to ask and we will relay to Dahua.

I would like to know if they plan on upgrading older models that are vulnerable. We are having trouble getting new firmware for models sold in 2015.

In my personal anecdotal experience; probably not Jon. Sometimes if we would push them hard we could get a firmware fix on old stuff, but most of the time it's just "move on to the next product."

Though, this is an unprecedented situation that they've found themselves in, so perhaps it would warrant a firmware upgrade from them. Does Dahua have cloud-upgrade yet? What a miserable job it would be to update over 145k compromised cameras manually...

I'm very interested to see how they control the damage of this.

What a miserable job it would be to update over 145k compromised cameras...

Somebody's got to do it...

U3, take a bow I suppose - Should I Hack 10,000 Dahua Cameras?

It looks like Dahua may be able to claim being part of a record-breaking event.

These recent DDoS attacks are hitting peaks of over 1Tbps, significantly higher than previous DDoS events that were several hundred Gbps.

What a claim to fame!

At least we're not Hikvision (aka Chinese gov)!!!

Don't know if this has already been mentioned in this thread or elseware on the site.

Here's a list of the cameras this particular malware (called "Mirai") targets. Along with a nod to IPVM, btw.


Mobile broadband devices from Sierra Wireless were also infected with Mirai.

I know these products are popular with some integrators for remote sites, hopefully nobody deployed Dahua cameras behind a Sierra Wireless gateway.

Read this IPVM report for free.

This article is part of IPVM's 6,604 reports, 890 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now

Related Reports

Six Flags' FDA Violating Outdoor Dahua Fever Cameras on Oct 26, 2020
As Six Flags scrambled to reopen parks amid plummeting revenues caused by the...
Faulty Hikvision Cali Colombia Fever Camera Implementation on Jul 20, 2020
The mayor of one of Colombia's largest cities has promoted a faulty Hikvision...
Ubiquiti Access Control Tested on Oct 21, 2020
Ubiquiti has become one of the most widely used wireless and switch providers...
Axis Exports To China Police Criticized By Amnesty International on Sep 21, 2020
Axis Communications and other EU surveillance providers are under fire from...
False: Verkada: "If You Want To Remote View Your Cameras You Need To Punch Holes In Your Firewall" on Jul 31, 2020
Verkada falsely declared to “3,000+ customers”, “300 school districts”, and...
Infinova, March Networks and Swann H1 2020 Financials Examined on Sep 02, 2020
While Dahua and Hikvision, helped by fever camera sales, are recovering from...
Dangerous Hikvision Fever Screening Marketing In Africa on Sep 15, 2020
A multi-national African Hikvision distributor is marketing dangerously...
Hikvision Global News Reports Directory on Aug 13, 2020
Hikvision has received the most global news reporting of any video...
Uniview Deep Learning Camera Tested on Jul 14, 2020
Uniview's intrusion analytics have performed poorly in our shootouts. Now,...
Anixter Runs Fake Coronavirus Marketing Using Shutterstock Watermarked Images on Jul 24, 2020
Coronavirus faked marketing is regrettably commonplace right now but Anixter...
Dahua Buenos Aires Bus Screening Violates IEC Standards and Dahua's Own Instructions on Jun 30, 2020
Dahua has promoted Buenos Aires bus deployments as "solutions that facilitate...
Dahua, Hikvision, ZKTeco Face Mask Detection Shootout on Jun 19, 2020
Temperature tablets with face mask detection are one of the hottest trends in...
US Passes Uyghur Human Rights Law Condemning Mass Surveillance on Jun 18, 2020
The US government has passed the Uyghur Human Rights Policy Act of 2020,...
Verkada 2020 Cameras Image Quality Test on Oct 06, 2020
Verkada's first-generation cameras suffered from numerous video quality...
Verkada Falsely Claims "First Native Cloud-based Access Control and Video Security Solution" on Jun 18, 2020
Verkada's false claims continue, this time to be the first native cloud-based...

Recent Reports

Motorola Solutions Total Revenue Down, Video Revenue Up on Oct 30, 2020
Motorola Solutions' total revenue is down, but video (both fixed and...
Recruiters Show 2020 On-Demand Recordings on Oct 30, 2020
Recordings from the 12 recruiter presentations are now available...
Consultants Show 2020 On-Demand Recording on Oct 29, 2020
Recordings from the consultant show are available on-demand at the end of...
Hikvision AcuSense G2 Camera Test on Oct 29, 2020
Hikvision has released their next generation of AcuSense analytic cameras...
Biggest Problems Selling Access Control 2020 on Oct 29, 2020
Access control can cause integrators big headaches. What practical issues do...
Taiwan Geovision AI Analytics and NDAA Examined on Oct 29, 2020
Taiwan manufacturer Geovision's revenue has been falling for years. However,...
Bedside Cough and Sneeze Detector (Sound Intelligence and CLB) on Oct 28, 2020
Coronavirus has increased interest in detecting symptoms such as fever and...
Fever Tablet Thermal Sensors Examined (Melexis) on Oct 28, 2020
Fever tablet suppliers heavily rely on the accuracy and specs of...
Verkada Fires 3 on Oct 28, 2020
Verkada has fired three employees over an incident where female colleagues...
Eagle Eye Networks Raises $40 Million on Oct 27, 2020
Eagle Eye has raised $40 million aiming to "reinvent video...
Hikvision Q3 2020 Global Revenue Rises, US Revenue Falls on Oct 27, 2020
While Hikvision's global revenue rises driven by domestic recovery, its US...
VICE Investigates Verkada's Harassing "RawVerkadawgz" on Oct 26, 2020
This month, IPVM investigated Verkada's sexism, discrimination, and cultural...
Six Flags' FDA Violating Outdoor Dahua Fever Cameras on Oct 26, 2020
As Six Flags scrambled to reopen parks amid plummeting revenues caused by the...
ISC Brasil Digital Experience 2020 Report on Oct 23, 2020
ISC Brasil 2020 rebranded itself to ISC Digital Experience and, like its...
Top Video Surveillance Service Call Problems 2020 on Oct 23, 2020
3 primary and 4 secondary issues stood out as causing the most problems when...