Hacked Dahua Cameras Drive Massive Mirai Cyber Attack

Published Sep 27, 2016 11:43 AM

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

************ *** ** *** ******* ********* against *********** ******-**-******* (****) *******.

* ********** ********** ********* **** ******* were **** ** * ******* ******:

IPVM Image

********, ** ****** *********** ** ** camera *** ***** ***** **** ******* he **** ************. ***** *********** **** a *****-******* ** ** *** *******, as **** ** * ***** *** [link ** ****** *********] *** * Dahua-like ** ** *******:

IPVM Image

***** **** **** ** ** "****'* more" ******* ********, ***** ***** **** been****** *-*** *******,********* **** *******, ********** ********* *******, ** *** ****** ** ***** brands/OEMs.

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

**** *** *** ****** ***** ****** blamed ** ****** ******* ** *** past ****.

***** ******* *** ** *** **** ****-***** cybersecurity ***********, *** ** *** *** attacked *********:

IPVM Image

**** ****** *** ** ***** **** his **** / **** ********** ****** him ***:

IPVM Image

******'* ***** ******** *******, **** *****,********** *** ******* ***** ** ****** from ****** *******:

***** ***’* *** ************ **** ** was * ******* ** ******** ******* that ********* *** ******* ** *******, because *** **** ** ***** ********* the ******, ** ****, *** **’* one ** *** **** ********. ** attack **** ********* ****** ******* ***** likely **** ****** ******** ********* ** individuals ** ***** **********, ** ****. “It’s ******** *** * ****** *** office ******** **** * ******* ** cameras, *** ********* **** ** ******* went ** **** *** *** ****** a *** *** ********* ** ** maybe * ***** ******,” ** ****.

**** ****'* ******* *** ******* ******* by ** **** ** ******** ******* or **** ** **** ******, *** debasing *** *** ******** ******** ********.

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

*** **** *** ** *** ****** has *** ** ** ******** ** IP-enabled ******* *** ***'*/***'* ***** *********. With ******** ** ***** ******* ********* to *** ********, *** * ********** indifference ** ***** ************ ************* ** cyber ********, **** ****** **** ******* for *******. ****** ** **** *****, like ******* *******, *** ******* *** ******** **** if *** ********* *** *********** **** basic ****-********* **** ****** *********.

****** ************* **** *** ********** ****** exposure ** *** ******* ** ****** motivated *******, *** ** ******* **** not ******* *** ** *** ******* methods **** *** ** ****, ******* their ******* **** *******.

*** ******* **** **** **** ******* for **** *** ******* ***** *** be **** ****** ** ****** ** unresponsive ****** ***** ****, ******** *** device ** ***** *** ******** ******* without *** **** ******** ** ****.

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

*********** ** ****** ******* *** ****** thousands ** ********* *********** **** **** ***, ********* the ******* ******* ******* ** ******** for *****. **** ** **** ******, the ********** ** *** **** ******* sends * ******* ** *** ******* with *** ****** ******, *** **** sits **** *** ******** * ***** (or **** ******, ********).

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

**********, **'* **** ******** ****** ** initiate **** *******, *** ** ** operating ******* **** ****** **** ******, hackers **** ****** ** ***** *********** devices **** *******. **** **** ****** lead ** * ***** ** ******* being *********, *** **** ******* ** their *************, **** ***** **** ******* years ***** **** *** ****** ****** to ********* **** ******* *******, ** customers ******* ******* **** ****** ****-********** to ******* *** **** *** ** a ****** ******.

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

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

** ** ***** ***** *** ****** aware ** * ************* **** *** have ******** * ***** ***** ** Dahua ** *******. ** ***** ****** that **** ************* ******** *** ******** cameras ** *** ************ **** ***** compromising *** *******’ ******* ************. ** would **** ****** **** **** ************* is ******* **** ** ******* **** are ********* ** *** ******** *** running ******** ******** (***-******* ****).

** *** ******* **** ******* **** been ********, ****** ***** ***** **** firmware ** **** **** *** *** running *** **** ** ** **** firmware *********. *** ******* *** **** ******* ******** ****** ** **** ********* ** **** your ******** ** ** **** ** all ** **** *******. ************, ** recommend **** ********** ***** **** ******* actually ****. *** **** **** ** how ** ***** *** ************* ** your *******, ****** ******* *** ************* page ** *** ******* [**** ** longer *********].

***** ** ********** *** ************* **** this ************* *** **** **** ** ensure **** **** ***** ******** **** run ******, ********, *** ** ********. Dahua **** ******* *** ******* ** has, *******, ** *** **** *** questions ** ********, ****** ** *** hesitate ** ******* *** ************* **** at *************@******.*********.***.

**** ***** *** ******* **** ***** ********** for ***** **********.

** **** ***** ***** ** ******* what ******** ************* ******* **** *** addressed ** *** ******* **** ******** release.

Comments (70)
JH
John Honovich
Sep 27, 2016
IPVM

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

UD
Undisclosed Distributor #1
Sep 27, 2016

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.

(2)
(1)
JH
John Honovich
Sep 27, 2016
IPVM

I attended Black Hat this summer

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

UD
Undisclosed Distributor #1
Sep 27, 2016

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.

JH
John Honovich
Sep 27, 2016
IPVM

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

UD
Undisclosed Distributor #1
Sep 27, 2016

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.

UI
Undisclosed Integrator #6
Sep 27, 2016

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!

(1)
U
Undisclosed #3
Sep 28, 2016
IPVMU Certified

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

How much does it cost?

Do they take credit cards?

(1)
UI
Undisclosed Integrator #6
Sep 28, 2016

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

U
Undisclosed #3
Sep 28, 2016
IPVMU Certified

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

(1)
(6)
Avatar
John Bazyk
Sep 27, 2016
Command Corporation • IPVMU Certified

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.

(6)
(1)
UI
Undisclosed Integrator #2
Sep 27, 2016

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?

U
Undisclosed #3
Sep 27, 2016
IPVMU Certified

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.

(2)
Avatar
Jon Dillabaugh
Sep 27, 2016
Pro Focus LLC

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.

(1)
U
Undisclosed #3
Sep 27, 2016
IPVMU Certified

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.

(1)
UI
Undisclosed Integrator #2
Sep 27, 2016

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.

Avatar
Brian Karas
Sep 27, 2016
IPVM

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.

(3)
(3)
JL
John Lineweaver
Sep 27, 2016

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.

(1)
Avatar
Brian Karas
Sep 27, 2016
IPVM

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

SM
Steve Mitchell
Sep 28, 2016

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.

(1)
Avatar
Jon Dillabaugh
Sep 27, 2016
Pro Focus LLC

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

UI
Undisclosed Integrator #2
Sep 27, 2016

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?

Avatar
Jon Dillabaugh
Sep 27, 2016
Pro Focus LLC

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.

Avatar
Brian Karas
Sep 27, 2016
IPVM

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.

Avatar
Jon Dillabaugh
Sep 27, 2016
Pro Focus LLC

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?

Avatar
Brian Karas
Sep 27, 2016
IPVM

Yes.

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.

U
Undisclosed #4
Sep 27, 2016

Wow, this is bad news.

Avatar
Brian Karas
Sep 27, 2016
IPVM

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.

(1)
(1)
U
Undisclosed #3
Sep 27, 2016
IPVMU Certified

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?

Avatar
Brian Karas
Sep 27, 2016
IPVM

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.

U
Undisclosed #3
Sep 27, 2016
IPVMU Certified

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?

Avatar
Brian Karas
Sep 27, 2016
IPVM

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.

U
Undisclosed #3
Sep 27, 2016
IPVMU Certified

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?

Avatar
Brian Karas
Sep 27, 2016
IPVM

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.

U
Undisclosed #3
Sep 28, 2016
IPVMU Certified

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?

U
Undisclosed #8
Sep 28, 2016

(1)
RS
Robert Shih
Oct 05, 2016
Independent

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.

RS
Robert Shih
Sep 30, 2016
Independent

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

(2)
U
Undisclosed #3
Oct 04, 2016
IPVMU Certified

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?

RS
Robert Shih
Oct 04, 2016
Independent

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

U
Undisclosed #3
Oct 04, 2016
IPVMU Certified

he's not an undisclosed on here...

Actually, he's not sure himself.

RS
Robert Shih
Oct 04, 2016
Independent

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?

Avatar
Jon Dillabaugh
Oct 04, 2016
Pro Focus LLC

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

RS
Robert Shih
Oct 04, 2016
Independent

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.

Avatar
Jon Dillabaugh
Oct 04, 2016
Pro Focus LLC

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.

U
Undisclosed #3
Oct 05, 2016
IPVMU Certified

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!

U
Undisclosed #3
Oct 05, 2016
IPVMU Certified

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?

Avatar
Jon Dillabaugh
Oct 05, 2016
Pro Focus LLC

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?

U
Undisclosed #3
Oct 06, 2016
IPVMU Certified

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.

RS
Robert Shih
Oct 06, 2016
Independent

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.

RS
Robert Shih
Oct 05, 2016
Independent

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

U
Undisclosed #3
Oct 05, 2016
IPVMU Certified

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

RS
Robert Shih
Oct 05, 2016
Independent

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.

Avatar
Hal Bennick
Oct 04, 2016
Trafficware, a CUBIC Company

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

UD
Undisclosed Distributor #5
Sep 27, 2016

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

Avatar
Brian Karas
Sep 27, 2016
IPVM

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?

UD
Undisclosed Distributor #5
Sep 27, 2016

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.

U
Undisclosed #3
Sep 27, 2016
IPVMU Certified

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

UD
Undisclosed Distributor #5
Sep 28, 2016

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.

UI
Undisclosed Integrator #7
Sep 28, 2016

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?

JH
John Honovich
Sep 28, 2016
IPVM

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

JH
John Honovich
Sep 28, 2016
IPVM

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.

Avatar
Jon Dillabaugh
Sep 28, 2016
Pro Focus LLC

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.

UD
Undisclosed Distributor #5
Sep 29, 2016

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.

U
Undisclosed #3
Sep 29, 2016
IPVMU Certified

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

Somebody's got to do it...

JH
John Honovich
Sep 29, 2016
IPVM

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

Avatar
Brian Karas
Sep 29, 2016
IPVM

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.

(1)
Avatar
Jon Dillabaugh
Sep 29, 2016
Pro Focus LLC

What a claim to fame!

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

(1)
SM
Steve Mitchell
Oct 05, 2016

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.

https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/

(1)
Avatar
Brian Karas
Oct 18, 2016
IPVM

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.