Jump to content
Security Installer Community

Recommended Posts

Posted

This also interests me from an installer POV too.

I wanted to split this out to keep the other thread on topic.

Do you find a large number of DVR's provide an attack route on to the network?

Basic or Enterprise kit? Any models you can use as an example?

Do you feel it's up to the manufactures to design them better or the installers to have them VLAN'd? etc...

 

I've done a number of pen-tests of small to medium sized businesses where the DVR has been my entry point. I've just written a whitepaper for a client who should be releasing it in the new year that explains in detail why they are so bad.

 

The primary problem is port-forwarding. If you open up the network so you can connect to the DVR, your entire network is reliant on the security of the DVR.

 

Then the DVRs themselves have terrible security. Many of them have backdoor accounts, many run custom protocols with no authentication, many of them have other vulnerabilities. You can get root on them very quickly.

 

Even if they aren't port forwarded to the Internet, a lot of them are vulnerable to attacks from desktop browsers - a carefully crafted link sent to someone in the shop can gain us control of the DVR if it isn't partition.

 

Many of the Swann DVRs suffer from this issue:

http://console-cowboys.blogspot.co.uk/2013/01/swann-song-dvr-insecurity.html

 

Despite it being found years ago, new DVRs suffer from the same issue. I've found similar problems in Dahua (who make about 50% of the cheap Chinese DVRs), Evigilo, Dedicated Micros, Pelco. I've tried reporting some of these, and the vendors are totally unresponsive. Unlike the signalling issues though, these place networks are real and immediate risk, so I'm not releasing them.

 

To fix it, it needs a bit of both. The manufacturers need to get better, but security is about layers. If you VLAN the DVR from the rest of the network, then you make most of these attacks much harder.

I have a blog, some of which is about alarm security and reverse engineering:
http://cybergibbons.com/

 

 

 

Posted

Unlike the signalling issues though, these place networks are real and immediate risk, so I'm not releasing them.

That's fair comment.

To fix it, it needs a bit of both. The manufacturers need to get better, but security is about layers. If you VLAN the DVR from the rest of the network, then you make most of these attacks much harder.

From and installer POV we expect the DVR to be secure.

I can understand why many are not, look at shellshock for example, These CVE's will never be updated in older DVR units.

I wouldn't be surprised if most DVR's sold today are running outdated linux kernels or suffer from known exploits.

The issue is as you say, the run of the mill engineer is bearly capable of punching some holes in the firewall and installing the client. This is where the manufacturers should step up IMO.

After all you say about layers, you can put the DVR on a VLAN to protect the site but what about the private images stored on the DVR?

Ultimately the installer would be responsible if anything did happen.

Posted

What evil **** can I do with ftp & a dm?

being a simple alarm monkey I guess I can do better than just changing files until it bricks ?

Mr th2.jpg Veritas God

Posted

question?

Those that do port forward to an insecure device.

If that device is used to gain access or rip a client off, who is liable?

The client for allowing access to their router, the manufacturer for weak security or the installer for bypassing the security of the so called 'firewall'?

securitywarehouse Security Supplies from Security Warehouse

Trade Members please contact us for your TSI vetted trade discount.

Posted

That's fair comment.

From and installer POV we expect the DVR to be secure.

I can understand why many are not, look at shellshock for example, These CVE's will never be updated in older DVR units.

I wouldn't be surprised if most DVR's sold today are running outdated linux kernels or suffer from known exploits.

The issue is as you say, the run of the mill engineer is bearly capable of punching some holes in the firewall and installing the client. This is where the manufacturers should step up IMO.

After all you say about layers, you can put the DVR on a VLAN to protect the site but what about the private images stored on the DVR?

Ultimately the installer would be responsible if anything did happen.

 

I think manufacturers should be obliged to produce secure devices and provide firmware updates for 3-5 years.

 

Let's not be unreasonable - I'm not expecting a DVR to be totally resistant to attack. But the mistakes that are being made are basic and easily avoidable. Above all, you know that they are not driven by security - once the DVR is out of the door, they have made their money.

What evil **** can I do with ftp & a dm?

being a simple alarm monkey I guess I can do better than just changing files until it bricks ?

 

DM?

question?

Those that do port forward to an insecure device.

If that device is used to gain access or rip a client off, who is liable?

The client for allowing access to their router, the manufacturer for weak security or the installer for bypassing the security of the so called 'firewall'?

 

Personally, if I were you, I would have a disclaimer listing the risks for port-forwarding to a device inside the network. There are alternatives, but they are less convenient and they cost more.

I have a blog, some of which is about alarm security and reverse engineering:
http://cybergibbons.com/

 

 

 

Posted

And just to give you an idea of costs and time - it would probably take about 5 days of work for me to say "This DVR with this given firmware in this configuration is secure enough to be on your network" with any level of confidence.

 

That's clearly not feasible - an installer can't pay be 5 days of consultancy each time he wants a DVR checked out.

 

It has to fall to the vendor.


Currently, I would recommend:

1. VLAN to isolate all security devices from the rest of the network.

2. VPN into the network to access the DVR (this is the convenience bit) rather than rely on port-forwarding.

3. Careful outbound firewalling of the network to attempt to limit damage should someone get in.

 

The problem that still remains is oversight - if the DVR does get owned, how does anyone tell?

I have a blog, some of which is about alarm security and reverse engineering:
http://cybergibbons.com/

 

 

 

Posted

And just to give you an idea of costs and time - it would probably take about 5 days of work for me to say "This DVR with this given firmware in this configuration is secure enough to be on your network" with any level of confidence.

 

That's clearly not feasible - an installer can't pay be 5 days of consultancy each time he wants a DVR checked out.

 

It has to fall to the vendor.

Currently, I would recommend:

1. VLAN to isolate all security devices from the rest of the network.

2. VPN into the network to access the DVR (this is the convenience bit) rather than rely on port-forwarding.

3. Careful outbound firewalling of the network to attempt to limit damage should someone get in.

 

The problem that still remains is oversight - if the DVR does get owned, how does anyone tell?

So points1 and 2 may be hard to do in some circumstances, point 3 I already do, point 4 (and I know you havent numbered it) is there a way of setting up intruder detection and email warning if a windows PC is owned ?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.