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.

***** ******* *** ************ and ** ******* *** behind **** ** ****.

*****, **** ****, * '*******' attack *** ******* *** using numerous ***** (*** ***** OEMs) *******. 

** **** ****** ** look ** *** ****** attacks, *** ********** ** similar ****** ******* *** why ** ***** ************ devices *** ************ ** the **** ** ***** attacks.


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

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

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

********, ** ****** *********** ** IP ****** *** ***** pages **** ******* ** says ************. ***** *********** show * *****-******* ** in *** *******, ** well ** ****** ****** * *****-**** ** in *******:

***** **** **** ** 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 *******, ************* *** ************* **** of *** *******.

***** ** ********** *** 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?

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...

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.

Login to read this IPVM report.
Why do I need to log in?
IPVM conducts unique testing and research funded by member's payments enabling us to offer the most independent, accurate and in-depth information.

Related Reports on Hacking

Dahua Wiretapping Vulnerability on Aug 02, 2019
IPVM has validated, with testing, and from Dahua, that many Dahua cameras have a wiretapping vulnerability. Even if the camera's audio has been...
LifeSafety Power NetLink Vulnerabilities And Problematic Response on May 20, 2019
'Power supplies' are not devices that many think about when considering vulnerabilities but as more and more devices go 'online', the risks for...
Register Now - Fall 2019 IP Networking Course on May 02, 2019
Register for the Fall 2019 IP Networking Course. For early registration save $50 off the course's normal $299 price. This is the only networking...
Locking Down Network Connections Guide on Apr 23, 2019
Accidents and inside attacks are risks when network connections are not locked down. Security and video surveillance systems should be protected...
Silicon Valley Cybersecurity Insurance Startup Coalition Profile on Mar 20, 2019
Many industry people believe cybersecurity insurance is not worth it, as the voting and debate in our Cybersecurity Insurance For Security...
Hikvision Favorability Results 2019 on Mar 18, 2019
Hikvision favorability results declined significantly in IPVM's 2019 study of 200+ integrators. While in 2017 Hikvision's favorability was...
Bosch VDOO 2018 Vulnerability on Dec 20, 2018
Security research firm VDOO has discovered a critical vulnerability in Bosch IP cameras. Inside, we cover the available details of this new...
Genetec UL Cybersecurity Certificate (2900-2-3) Examined on Dec 19, 2018
Proving a company is cybersecure has become a major concern for security companies. But how trustworthy are these certificates? Earlier in 2018, a...
No GDPR Penalties For UK Swann 'Spying Hack' on Nov 20, 2018
The UK’s data protection agency has closed its investigation into Infinova-owned Swann Security UK, the ICO confirmed to IPVM, deciding to take “no...
HID: Stop Selling Cracked 125 kHz Credentials on Nov 05, 2018
HID should stop selling cracked 125 kHz access control credentials, that have been long cracked and can easily be copied by cheap cloners sold on...

Most Recent Industry Reports

TMA Apologizes to Amazon / Ring on Aug 23, 2019
Not only is Amazon / Ring making major incursions into the residential security market, the organization representing the biggest incumbents, The...
China Dahua Replaces Their Software With US Pepper on Aug 22, 2019
What does a US government banned company do to improve its security positioning in the US? Well, Dahua is unveiling a novel solution, partnering...
Security Integrators Outlook On Remaining Integrators In 2025 on Aug 22, 2019
The industry has changed substantially in the last decade, with the rise of IP cameras and the race to the bottom. Indeed, more changes may be...
First GDPR Facial Recognition Fine For Sweden School on Aug 22, 2019
A school in Sweden has been fined $20,000 for using facial recognition to keep attendance in what is Sweden's first GDPR fine. Notably, the fine is...
Anyvision Facial Recognition Tested on Aug 21, 2019
Anyvision is aiming for $1 billion in revenue by 2022, backed by $74 million in funding. But does their performance live up to the hype they have...
JCI Sues Wyze on Aug 21, 2019
The mega manufacturer / integrator JCI has sued the fast-growing $20 camera Seattle startup Wyze. Inside this note: Share the court...
Dahua 4K Camera Shootout on Aug 20, 2019
Dahua's new Pro Series 4K N85CL5Z claims to "deliver superior images in all lighting and environmental conditions", but how does this compare to...
ZK Teco Atlas Access Control Tested on Aug 20, 2019
Who needs access specialists? China-based ZKTeco claims its newest access panel 'makes it very easy for anyone to learn and install access control...
Uniview Beats Intel In Trademark Lawsuit on Aug 19, 2019
Uniview has won a long-running trademark lawsuit brought by Intel, with Beijing's highest court reversing an earlier Intel win, centered on...
Suprema Biometric Mass Leak Examined on Aug 19, 2019
While Suprema is rarely discussed even within the physical security market, the South Korean biometrics manufacturer made global news this past...

The world's leading video surveillance information source, IPVM provides the best reporting, testing and training for 10,000+ members globally. Dedicated to independent and objective information, we uniquely refuse any and all advertisements, sponsorship and consulting from manufacturers.

About | FAQ | Contact