cybergibbons

Part of the issue here is you don't need to port forward for the device to be at risk. Another part is that it isn't just this DVR, so many of them have issues. This site explains how similar attacks have been happening against routers: http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html It's quite advanced, but it is actually happening. And it's not teenagers you are going to need to worry about, it's organised crime from other parts of the world. As an aside, which DVR brands do you all trust? I've got budget to buy higher end gear and want to have a crack at something good.

It's a lot easier to find this out now than engineer codes. The thing with engineer codes is that they are a built-in part of the system, known and accepted by many. The problems in the DVR aren't exactly in the manual.

It's been viewed by tens of thousands already, so the cat is out of the bag. The solution has a few aspects: 1. Don't trust very cheap gear, especially if it has no firmware updates. 2. Make sure you change passwords from defaults. 3. Don't port forward to the device from the open internet 4. If remote access is required, use a VPN. 5. Segregate it from the rest of your network on a VLAN or subnet. 6. Block outbound traffic so it can't create a reverse shell. 7. If it has HTTPS, enable it.

So, if you port-forward, it's obvious - Shodan will find the unit, and because it has a distinctive HTTP header, can be found. We can see 44k of them by this means. But if I add the following HTML to a web page: <IMG SRC="http://192.168.1.201/shell?[commandfor reverse shell]">, and you visit that site, the DVR will connect back to me, so I can control it. That's just for one IP. so I'd use JavaScript and essentially check all likely internal IPs. This is because it is lacking cross-site request forgery protection. It's not a lack of functionality or spec really, unless they write "No backdoors! No hardcoded passwords!". Even some fairly expensive DVRs have some issues: http://www.theregister.co.uk/2016/02/18/blank_519070_the_pin_to_enter_to_pwn_80k_online_security_cams/ Hikvision have had problems in the past: https://community.rapid7.com/community/metasploit/blog/2014/11/19/r7-2014-18-hikvision-dvr-devices--multiple-vulnerabilities They were responsive when I spoke to them about issues with IP cameras though.

I'd be very surprised if this wasn't being used already. It took less than a few hours to find the issue, and we've certainly seen attacks of this type carried out against home and business routers.

They should. It's essentially the same as letting someone come into your business and plug in a computer to the network.

If you are very strict about it, then it can be safe. When you are on the VPN connecting to the DVR, you must not browse any other sites, otherwise the attack could be carried out against it. All outbound access from the DVR needs to be blocked.

There's absolutely no requirement to use a password on this. I can make it connect back to my server and control it just by entering a URL on it. Or I could get you to visit a site with the URL on it.

I looked at a cheap DVR and found some really quite serious issues. If you port-forward to this, an attacker - and not a skilled one - can take complete control of the device and do what they want on your network. https://www.pentestpartners.com/blog/pwning-cctv-cameras/ I wouldn't trust any DVR to be honest. Expect more like this in the near future.

Well, that bit is meaningless. "Military Grade" means nothing, to start with. This is military grade, according the vendor: http://cybergibbons.com/alarms-2/reversing-an-anti-code/ This page is protected by encryption of the highest standard: https://www.google.co.uk/ Would that mean you could trust your data with them? You need to know how the data at rest is being encrypted, and how authentication is handled. They aren't open about it. Look at the Amazon reviews or kickstarter page for it.

Avoid like the plague.

Technically, it's not a VLAN, but essentially it is the same idea. It's another network that is firewalled off. Normally that functionality lets the trusted network access the guest network, so putting security devices on there could be wise. Good idea.

The point of a VLAN is to make it like there are physically separate networks running. You then use the routing/firewall to allow certain traffic between the two. They add a lot of security if you set the firewall up correctly, and make a lot of attacks a lot harder. You can make it so that a PC on the general VLAN can access a DVR on the the security VLAN. But the DVR wouldn't be able to access the rest of the network, so damage would be limited. Even if you allow all traffic between two VLANS, it makes an attackers life harder as a number of attacks assume the DVR is on the same local network segment.

Yes, it would need doing once per model at least.

Yeah, they have a lot more functionality that should keep them secure, but they suffer from the same kind of issues (all running as root, vulnerable services, services you can't turn off etc) as the cheaper cams. One manufacturer put such strong legal threats out to a researcher that he pulled research and a talk - he won't say who it is though.

Done.

I've not looked at Axis DVRs. IP cameras are not the worst but no better than Hikvision.

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 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. DM? 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'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'll reply this evening.

It would be good if we could keep this on-topic if possible. My personal feeling is that the risk here is not to individual properties unless they are very high value. I don't know what does the signalling when you get up to the highest values - most of the really at risk places have 24/7 guarding. Possibly some CNI stuff - certainly big substations are unmanned, but then they already have SCADA links in place and I would imagine alarm stuff goes over the same channels. That said, I think we need to start thinking about attackers that aren't Billy Burglar. As PeterJames said, technical attacks on alarms by burglars are not yet happening. I can think of other attacks though: Sending huge numbers of spoofed alarms, causing ARCs to be inundated and guarding services and police to be unable to respond. A great distraction whilst you do something like the Hatton Garden job. Bricking hundreds of alarms using UDL (because the UDL protocols behind signalling devices have poor security as well) Using a signalling device in a botnet to perform DDoS attacks or send email Using a signalling device as a pivot to attack a network The last one is the one that really interests me. I've used DVRs to pivot into networks on pen-tests several times now. They are generally not secure and once I am on them, I can use them to attack the rest of the network. No one suspects these little devices of being malicious. Installers don't know networks so can't firewall or partition them. IT won't touch them because they are installer by a third party. The current Dualcom boards can't be used as a pivot because they are physically incapable of it. I guess that is a saving grace. I think we also need to look at the standards in more depth. The Dualcom boards I looked at are certified to be compliant, but there is no way that a competent third-party would certify them. What did CSL tell Intertek? Who messed up here? The standard demands the encryption - it's planned for a technical attack. Just to add - the installers here have generally been welcoming and positive about the work. But an installer who spends their time on a forum is probably one of the more involved and knowledgeable - it's the rest of them that need convincing!

Who knows. As you all told me, who cares about the RF side. Look at the signalling side. I started and it's not good. Risco, Visonic, CSL and Videofied have all attempted to go further than SIA etc. and they have made massive errors. What I don't get is how badly broken it is. These are not subtle issues - the Videofied work took me less than 3 hours from start to finish. I spent more time trying to contact them and writing the blog post than actually doing the work. I gave up on the UK side and tried the French and US contacts, still nothing. It took CERT to get them talking.

I believe so.

As per the subject, I found multiple serious vulnerabilities in RSI Videofied's protocol: http://cybergibbons.com/alarms-2/multiple-serious-vulnerabilities-in-rsi-videofieds-alarm-protocol/ This means it is trivially easy to spoof alarms from other panels. RSI Videofied have not been communicative. Supposedly they have deployed a fix, but I have not been shown what this fix is. They have had 4.5 months to respond so far. I would strongly recommend if you use their panels to ask what they are doing to fix this.