cybergibbons
-
Posts
498 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Events
Downloads
Gallery
Blogs
Posts posted by cybergibbons
-
-
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.
-
This should be in trade only in my opinion. Yeah it might be splattered all over the web but site rules don't allow default engineer codes let alone back doors to DVRs....? I agree the issue should be raised but not in public view.
And anyway, from an installation point of view, what's the solution?
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.
-
I suppose any device that has port forwarding could be used in this way. It's a bit over my head but are you saying even if not port forwarded the device can be used?
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.
Yeah I agree with a few of the posts, low end of the market wont care less, and chances are will never know about all this unless it hits main stream media, which I cant see happening.
Saying all that, you say cheaper DVR's... what's a buyer to look for to avoid this in the "expensive" DVR's....? Is there something in the spec we should be looking for that makes it less vulnerable?
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:
CG your point is the DVR makes an open way to get to the rest of the network which for some can be disastrous , what about any DVRs being used in data sensitive companies , looks asthough any using hikvision here , what are they like in terms of security
Hikvision have had problems in the past:
They were responsive when I spoke to them about issues with IP cameras though.
-
it not quite a real world issue (yet)
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.
-
No one cares anyway
They should. It's essentially the same as letting someone come into your business and plug in a computer to the network.
-
Not even if its on a vpn or vlan?
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.
-
Even if secure passwords are setup?
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.
-
So this bit isn't true
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:
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.
-
Newer models of routers have guest networks on the wifi, mine doesnt allow me to see my servers when I log into the guest wifi so I guess this is a easy way of setting up a vlan or am I wrong
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.
-
If there all fitted to the same standard and specification, surely this would only need doing once for each model/firmware?
Again I would expect the manufacturer to have had this done externally.
I also agree with PJ about 1 and 2 being hard to implement on some networks.
Point 3 should be done as standard for anyone with knowledge of setting up firewalls, however, someone with a network background would understand this in more depth than an alarm monkey.
Yes, it would need doing once per model at least.
-
Sorry, I meant the cams
Surprised at that as they seem to offer a lot of seemingly esoteric security / IPsec options.
Not that that makes them more secure by default, I know.
And I've never used Hik IP so can't compare.
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.
-
cyber,
clear some pm's as there something i wanna send you...
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?
-
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.
-
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'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!
-
How much other gear is insecure?
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.
-
Oh dear does Matt know?
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.
Cheap Dvr Leaves Your Network Vulnerable To Attack
in Members Lounge (Public)
Posted
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.