Dahua Says They Are Botnet Attack 'Victims'

By John Honovich, Published Oct 26, 2016, 11:43am EDT

'Victim' or 'accomplice'?

Dahua has issued a new press release, referring to their products as 'victims' of the massive botnet attacks hitting the Internet, emphasizing that Xiongmai devices were more heavily used and that publications have 'downgraded' their role in the attacks.

So, is Dahua a victim here?

Case *** ***** * ******

***** *** *** ******* the ******* *** ***** does *** *****, ****** or ********* ***** *** products *** ****** *******. ** that ***, *****'* ******** were ********** ****.

Case *** *** ***** * ******

***** ******** ******** **** two ***** ***** **** violate ******** **** ********* and ****** *** **** been *******. ***** **** admit ******** ******* ********* and *********. *** ***** it *** ****** ****** about ******** ****** ** be **** ** *******,*** ******* ***** **** Dahua *** ******* **** ***** (*** that ****** ***** *** be ******** ** **** Dahua *******). 

***** ***** **** **** of ***** ********* *** their ******** *** ****** viewing **** *** ********. Dahua ****** **** ** should **** ***** **** leaving ****** **** ****** a **** *** ***** many ********* **** **** their **-******* ******* ********* on *** ********.

Importance ** ********** *** ***** ****

** ***** ** * victim, ****, ** ****** of ****, **** ****** not **** *** ******** or ***** ****. *******, if ***** ***** ************* in *** ****** ** their ********, **** ***** face ***** ****.

** * ********* ******, since ******** **** *** sell ******** *************** *** do **** ******** ********** in *** ****, ***** would ** * **** more ********* ********** ****** given *****'* **** ******** position ******* ** '********' *******.

Debate ***** **************

**********, **** **** ** the *********** ******** ** responsibility. *******, *** ******* themselves *** *********** *** their *******.

*******, *** **** ***** have **** ********* *** is ** (*) *** buyer ** *** ******* that ****** **** ***** action? (*) *** *********** who *** ** *** systems? ** (*) *** manufacturers *** ******** ***** systems? ****** * **** could ** ****, ** some ******, *** ****. But ** ** *****, ultimately, *** **** ********* way ** **** ***** attacks ** *** *** video ************ ************* ** do ** **** ** possible ** ***** ** protections **** ***** ******* just **** ***** ******** enabled ******* **** **** doing *** **** *****.

Comments (26)

You had me at "telnet."

As in, "My insecure product uses Teletype Over Network Protocol defined in 1973."

Should go with out saying, as we're "Security" professionals, but telnet sends information in clear text... No one uses telnet anymore. The reason that has been explained to me for including telnet is that it's for "debugging" processes. Well a mass-production unit shouldn't have telnet!!!!!!

FWIW Telnet is just a 'service' that is run on a computer (in this case cameras and NVR's and the like). You can send any text across that service, encrypted or not. Where the problem is here is that the login details are both hard fixed, unalterable, and send in plaintext.

The nature of the equipment we typically use as security professionals is built on a legacy of independent and separated communications lines. IP based communications are pretty much the exact opposite of this (for most intents and purposes). The upshot of this is that if given the firmware of a connected device, it can be pulled apart, quote easily understood, and then exploits can be found. Most of the equipment we see uses an embedded Linux Kernel. Where do we draw the line with responsibility if there is a flaw in the Kernel itself? Or one of the protocols used? Or a dodgy SSL certificate or web server?

Pointing the finger directly is not so easy. Could the embedded OS of most every device, regardless of manufacturer, be improved? I would think the answer is a resounding yes. This is a recurring theme and will continue to be. Is it IT security? Is it 'real-world' security? Both?

Let me give you a simple example: A network connected camera under the eves at the front of a building. Someone could dislodge the camera and they would have access to a network cable and potentially the rest of the network. Someone attacks the camera with a virus..... now they have access to your network and a swiss army knife to do with it what they please. Now lets shut down the regular video feed from the camera and display a static image..... nothing to see here..... Oh look, there's an NVR, perhaps I can store my movie collection on that, or some corporate files for later retrieval, or a password sniffer for the staffs logins. I think you get the idea.

This is as with most everything we do a risk management exercise. There has been too much tendency to just 'throw a product at it' without understanding the impact of that decision. I do not believe it is fair to expect any one product to be completely hardened against all attack vectors, especially with the products we work with and the applications we use them for. There needs to be a defence in depth approach. I am yet to see this well implemented in the field. This is not an IT security problem although it overlaps in this area. Likewise it is not a real-world security problem but it overlaps here too. It is a hybrid problem and requires a hybrid solution.

At this time I would suggest that no single IT person or 'real world' security person has a fully working methodology for solving this. It is something that needs considerable thought and planning and is unique to each site and circumstance. This leads us all the way back to risk management (and mitigation) - the core of what our industry is here to do. Right now we cant do it to the levels required without reducing the interconnected nature of the equipment and going back to basics.

Just my 2c

Let me give you a simple example: A network connected camera under the eves at the front of a building. Someone could dislodge the camera and they would have access to a network cable and potentially the rest of the network

How does this relate to whether Dahua is or not a victim in the botnet attacks?

I certainly grant the scenario you describe is possible but that is a physical intrusion into the premises of the building, which is completely different from what happened in the issue we are examining here.

It is certainly related. What I am illustrating is several things:

1/ Dahua can be seen as a victim here due to the nature of the attack

2/ Dahua can be seen here as a facilitator of the attack

3/ Assigning blame is not so straight forward due to the nature of the equipment involved and the operational conditions they are subject to. There are multiple attack vectors that can be exploited - where can you reasonably draw the line?

My point is that the content of the discussions so far is a drastic oversimplification of the situation. Can you sue Microsoft because you have had a virus? Or and Anti-Virus manufacturer? Or the Hardware manufacturer that made the computer? Or the retailer? Or the IT guy that manages a network? The hacker / attacker who made the virus? What about the ignorance of the installer for putting an insecure device into the wild? There's a whole cavalcade of things going on here.

Is Dahua a victim? Sure. Are they also a facilitator? Sure. Is the firmware manufacturer also a victim here? Not so clear. Are they a facilitator? Sure. The people who installed the gear in an insecure way, are they victims? No. Facilitators? Yes. The end user?.... And on it goes.

You cant just say firmware = bad therefore manufacturer is at fault. Thats just ignorant. This is a much larger scenario and these devices are just parts of a much larger environment that do not operate on their own. Where's the due diligence of everyone else in this chain of disasters?

There are multiple attack vectors that can be exploited - where can you reasonably draw the line?

Andrew, you can easily draw the line with your physical intrusion example. This is clearly not a fault of any manufacturer, whether it be Dahua, Hikvision, Axis, Arecont, whomever.

If someone comes into your facility and physically unplugs a camera and then connects to your network, that has nothing to do with the camera. That is an issue of your network and installation. Regardless of how the camera was designed, the camera cannot prevent attacks to a network it is physically disconnected to.

I certainly agree, as I said in the body of the post, that responsibility for the botnet attack can be reasonably shared between users, integrators (if employed) and manufacturers but the physical example you cite is not relevant.

I think we're going to have to agree to disagree on this one. To me, substitution of a device on the network with anything other than the intended device is a risk. To me, mitigating that needs to be done both in the device and with the network structure - again leading to that hybrid risk model.

This would be solved by implementing 802.1x in the network. (and I agree with John that this scenario you outlined is purely a network security issue, not device related) Then a device is unable to access the network at all before they are authenticated. If someone were to replace a device, even if you spoof the MAC-address, you will not be able to connect.

I do realize that implementing 802.1x is not a trivial task for non-IT personnel and it do add more configuration time of each and every device.

Alternatively, one can simply implement better physical security for the network, only using dome cameras and placing the cameras so high that the camera is not easily accessible. It is a much lower level of security compared to 802.1x, but for a smaller customer, or a fully separated network (virtual or physical), this might be satisfactory.

As soon as un-security minded people develop security products there is going to be a bad day for someone.

The victim I see is the users which had problems, it's the company which had an attack, for this case was DYN

In the eye of some legal minds, I would say Dahua and others aided and abetted.

They have no excuse for having pathetic security minds. At no time did they say anything, like o yes those old DVRs you know are as safe as a chocolate fireguard.

Whilst anyone can argue we are a victim, so let's see how much this cost them? anything! A few we are sorry emails. Have they sent to press to express shame, and sadness of their own lack of historic skills. No they take stance like Xiongmai taking the high ground of it's the customers fault, that's just crap and the world knows it. What an embarrassment of a company they are.

Having plain text on any network camera these monkey develop is beyond a joke, everyone should just send back and get a refund and find a decent trustworthy product.

Product should turn on and first ask to set password, make it secure, or tricky. This is where a quality manufacturer will make you do the right thing, it's starts with the device, it's should be bullet proof.

I would suggest developers people take a look at how Apple have tackled the IoT devices for their homekit, this stuff has major certificate handling before it will even answer from anything.

Bottom line it clear for Chinese products, it's 50% finished, time to sell it! you find problem we fix it. and sorry for the problem, and big sorry for big problem.

We all wait to hopefully see the list of devices used in these botnets, name and Shame has to be only way for things to be fixed.

As the group involved now have told the world, it would seem it's just a practice run for something bigger! remove these devices and these attacks don't register.

We can only hope something positive comes from this, as a industry the buck starts with the hardware vendors. Now lets see the first email spam with the Botnet free certified claim!

Forget FCC / CE / UL that's pointless, we need something that's not going to bring the internet and the freedom it gives the world to it's knees.

I go back to my point that a proper firewall would have prevented this attack 100% of the time.

This does NOT let Dahua off the hook, but the integrator should protect the clients' networks regardless.

The buck doesn't stop there either. End users should know what their networked devices are capable of, and if they aren't savvy enough to determine that on their own, hire a third party who is.

Lastly, there is some blame to be placed at the feet of the ISPs who allow this traffic that should be easily discovered and dropped. They could decommission the modem/NIC corresponding with said traffic instantly, which would prevent such attacks.

Going back to square one, Dahua is who made these insecure devices, so their feet should be the first to feel the flames. Every one else, get in line accordingly.

Telnet is a protocol that is available on many well know network devices today (and has been for decades). Since the protocol is not secure, it's not normally enabled by manufactures as a default setting. This is an industry best practice.

SSH (Secure Shell) provide the same level of access to the device as Telnet, but uses keys to encrypt traffic over the network. SSH is preferred over Telnet as a best practice.

802.1x is a protocol that authenticates the device to the network switch. This stops unauthorized devices from accessing the network (i.e. unplug a camera & plug-in a laptop). This protocol is not commonly deployed today, but is an available option on most network devices and switches.

Many network devices today have a default user name and password. This is commonly done to be installer-friendly. It's an industry best practice for the installer to change these settings.

All networks attached to the Internet should be protected by a properly configured firewall (for example: VPN for Remote Access only and robust traffic in / traffic out rules). This best practice should be owned by the end user or their IT management firm, and strongly recommended by the installer.

All that being said, how many physical security devices today are installed with the majority of default settings, and connected to the internet without a properly configured firewall.

As an industry, it's in all of our best interests to harden our systems and networks to reduce these types of attacks. We are in the security business, and these events give the entire industry a black eye. The last thing we need is for end users to believe our devices and installation methods are not secure enough to put on their enterprise class networks.

As we strengthen our IT security posture; the cyber terrorists will just likely switch to targeting Internet-of-Things (IoT) devices such as televisions, thermostats, and refrigerators. That industry will need to get serious about security as well, since they are more consumer oriented, and are capable of having far more devices on-line.

If you want to see around the world what these attacks are then check this site link below, it's impressive, and also sad to see this going on 24x7.

Some people need secure their computers & devices, to assume of course they don't know this is happening. A firewall on router maybe not blocking outbound connections, when it's already on your network!

Also these Bots are cleaver and send small packets, could be hard to detect, unless you know what to look for!

Check this.


Yes Dahua is culpable, but so is Acti, Axis, Panasonic, and Mobotix - all brands that I use. We need the manufacturers to change their defaults and mandate a first time password change. Not too much to ask.

Meanwhile there are millions of cameras that you and I have installed that are vulnerable to attack. The problem will not go away until we clean up our existing inventory. I believe this was just a test run. We will see it again.

On the defensive front, I wonder if routers all over the world could filter outgoing DoS attacks, or refuse to retransmit them? The IoT becomes a serious threat if bad actors get control of this new frontier.

We need the manufacturers to change their defaults and mandate a first time password change.

Roger, the big issue here is open telnet access. Even if you exposed an IP camera with a default password, if they had closed telnet, the hacker would not have been able to use the cameras in a botnet attack. All they would have been able to do is watch video, change camera configurations, etc., far less dangerous than taking out significant parts of the Internet.

All they would have been able to do is watch video, change camera configurations...

Though they could just enable telnet (or ssh) then, no?

Little good that would do without the corresponding firewall port being open and forwarded to the IP of the device.

Wether or not the service is running is really a local issue. It would be very rare that telnet would be NAT'ed to the device to begin with, so remote access to these devices should be blocked by the firewall.

The one scenario where this is a real issue is where you had a poor firewall integration by allowing the device to be in the DMZ. Only an irresponsible or unprofessional tech would DMZ the entire device.

Little good that would do without the corresponding firewall port being open and forwarded to the IP of the device.

Disagree. Telnet runs just as well on port 80 as port 23.

So, since one port must be open already, changing telnet to run on that port instead of http gives you root sh access.

Disagree. Port 80 doesn't need to be open for Dahua systems. You only need 37777 by default settings. Is it your assertion that Telnet also listens on port 37777? Are there any other ports that Dahua devices listen to for Telnet access? Where is this documented?

Is it your assertion that Dahua forces telnet to be run on only port 23?

I would say yes. Unless I see documentation stating that the port can be changed, then that is my working assumption.

And BTWs, that is the UPNP page, which has no effect on which port is going to be used by a given service. That is only to automatically make your firewall less secure, which is strongly frowned upon.

If you want to look at the Network > Connection page, that is where you will find the ports that the GUI allows you to change. In addition to this, you may be able to make other changes via Telnet/SDK.

You said

Little good that would do without the corresponding firewall port being open and forwarded to the IP of the device.


That is only to automatically make your firewall less secure, which is strongly frowned upon.

So a lotta bad could be done by a hacker enabling UPNP, no?

That would have to be allowed by the firewall. No decent firewall has UPNP support and the ones that do support it, have it disabled by default.

No decent firewall has UPNP support and the ones that do have it disabled.

Nice hand-waving. Who said people using crappy cams are using Jon D.'s approved decent routers? Besides that,

By default, NETGEAR home routers have UPnP enabled...

I'm not sure about Dahua, mine don't even run telnet at all. But I am 100% positive that on Axis cams i can enable ssh and put it in whatever port that is open thru the firewall.

do you have one, i can show you?

You, convienently left out the very next line:

"By default, NETGEAR home routers have UPnP enabled, while the business routers have it disabled."

You think that there is anywhere near the number of business routers as home routers?

Ask your neighbors...

In China a large number of devices connect to the internet using PPoE. because China Mobile, China Telecom both use this as an account service authentication.

That you can use on multiple devices, all having PPoE.

So you can say it's quite indeed possible many devices are not even with a router. exposing NVR / DVR / IPC to a lot of nasty stuff!

When you are talking going back several years of many devices used for businesses, could amount to a lot of in-secure units about!

Router which I have come across in China from internet operators are very poor quality, cheap and very basic units, lacking a great deal security.

Newer offering are somewhat better, but the internet installers recommended to use TP-Link naturally as a home grown product, and also because the internet installation they get working for you.

However even TP-Link models sold in domestic market are cheaper models than the international exported variations. So only having one language, and no English version for firmware updates.

This could be why a lot of easy to find devices used as BotNet are located in China.

Most history if not all DVRs for old, which are still a lot, would use the local network offing little in way of security.

NOTICE: This comment has been moved to its own discussion: China Install Security Problems

Read this IPVM report for free.

This article is part of IPVM's 6,743 reports, 909 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
Loading Related Reports