cybergibbons
-
Posts
498 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Events
Downloads
Gallery
Blogs
Posts posted by cybergibbons
-
-
No doubt it's serious
But nothing is being proven that it will fall over or could be compromised except on particular units
I'd say they staying quiet while they perform there own tests and find a way to patch it if it's at all true
They've had all of the detail since April 2015, and the bulk of it since June 2014. That's a very long time to apparently do nothing.
But nothing will be fool proof , all software and ip connections will have weaknesses
Exactly. To assume your system is free from problems is reckless. That's why having a system to update firmware is vital. It's probably their biggest failing in this whole thing.
CG this is right up your street should have given them heads up!
Yeah, this is terrible. I'm not sure if you've read the details on it, but this was negligence again. Literally 10 minutes looking at their site after the breach had been announced showed issues.
I report between 5 and 10 issues to various vendors each week. At least half of big sites have issues. It's scary - software "engineers" have no requirement to actually know what they are doing.
-
But surely there would be a record of failures where perhaps a bulgary or fire took place and perhaps no signalling was sent ,regardless of csl it would show up with the Maintainer no?
A fair number of installers have reported them not working though.
http://www.diynot.com/diy/threads/csl-dualcom-cs2300-r-vulnerabilities.447125/#post-3514570
That's not the first person who has said this. Looking at their protocol, maybe I missed something more obvious - if the unit sends an alarm, and then goes back to normal, all you need to do is stop that signal getting through. There is no sequence number at all, no end-to-end acknowledgement.
I don't think any historic failures are irrelevant, a lot can be learned from them surely?
Rob Evans, when he called me to ask me to take down the initial reverse engineering posts, specifically mentioned a case where a Dualcom unit had failed to send a panic alarm, and the shop owner had been injured. I wouldn't want that to happen if I released my research?
I think CSL may not be letting on how many failures they have.
-
But how many failures are known?
No idea - that's for CSL to answer. But they can't, because they don't have any way of detecting it.
-
55,000 views in a week, which isn't bad at all.
Still very surprised as CSL's lack of response - Twitter and Google are not looking bright for them.
-
This is where I reported the issue to Santosh, and he responded, eventually.
-
Thanks. That's interesting. I don't understand why it would take more than 10 minutes regardless of grade. I think the standard is a joke in this respect.
I spoke to my CSL rep yesterday who denied there site was hacked and also claimed any units tested were more than six years old and there units are completely secure.
As in, they denied this?
http://cybergibbons.com/alarms-2/customer-database-leak-on-csl-dualcoms-sim-registration-portal/
I have the emails from Santosh Chandorkar where we discussed it.
The units were old, but there is no evidence that the newer units don't suffer from the same issues.
the vpn bit from what i read is very last mile. Its not end to end.
Plus i believe alarm delivery and polling are different routes so polling imo does not prove path availability for alarm transmission.
ie some use the same path end to end to poll and deliver alarms.
As far as I can work out, the VPN is from the ARC to CSL. Certainly on the firmware I looked at there is no VPN functionality. The processors they use - the NEC 78K0R - are very small. They'd have to write the VPN software from the ground-up themselves. The way the latest firmware I have works, it just doesn't have room to do this.
The primary reason behind this is that the CS2300-R has been coded to deal with 4 different GRPS modems. The way this is done, it makes the code 4 times bigger in a lot of places. I'd estimate about 40% of the flash memory is taken up with this - there just is not room for a VPN client.
Possibly on later units, they have trimmed this out, allowing them to add functionality.
Difficult topic for me to be involved in tbh.
The levels of testing that can be done in respect of substitution and encryption are complex and I do believe that when we carried out certification to EN50136 this aspect was largely self declaration. Not ideal I would agree.
As a company our core specialty is (and always has been) secure communications. Ever since we entered the market with the first IP based ATS back in 2005 we have been under the microscope from all aspects of the industry. So 128AES, key exchange, substitution protection etc etc are what we eat sleep and breathe.
In a separate topic I mentioned that we have had the ATS independently pen tested on multiple occasions, we would not have been successful in internet signalling within the financial sector & corporate space without. This level of testing was (as it should be) intense and incredibly thorough, carried out under NDA as well because we were almost at the level where we were talking about the core of the encryption and substitution techniques we developed.
That's the thing then - where the standards are weak, you and your customers have demanded that pen testing takes up the slack.
-
yes
I missed this. Can you share it privately?
-
Yep. No but it's new.
Fancy dropping an email to CSL support asking for release notes or a changelog between 3.53 and 3.77?
-
I don't know why CSL haven't responded more robustly to it.
Fundamentally, what I have published doesn't say the system is ruined. Surprised they haven't defended themselves better.
-
3.77
Is that the number as reported when you turn the board on? Do you know when it was purchased?
-
Be interesting if that's just 100 affected units? Can't agree that its a round 600 units affected. That is imo bullsh1t
Is that grade 3 units, or gradeshift grade 4
Most end users won't know, care or give one as their insurer will come back on the maintainer.
I wonder what the insurers think on this.
As usual the insurers will ask for Dualcom plus
I can't see any difference between the different units - certainly the ones I have, the grade is just an option set in NVRAM.
What is "Dualcom plus" - seen that in insurance docs, but doesn't seem to line up with a product.
-
So 2013 firmware was in your report?
Firmware that was on a device installed 2013 - 2.5x. The latest on their site was 3.53 or 3.10 for UDL. This is the version number that flashes up as the board is booting.
I'd be interested to hear about other versions of the firmware though.
I have two DigiAirs now, so I am presently giving them a once over.
So as of April 2015 your findings are valid?
Unless CSL secretly deployed a later firmware version using programmers that no installers have, yes.
If one of you still have a valid login to the CSL installer area, you could check what the latest firmware version is. Maybe ask them what the latest version is for the Gradeshift as well...
-
How would one verify that?
Almost impossible as a third party. As of April 2015, the latest firmware they had available for download suffered from these issues. They don't provide any release notes or changelog, so really hard to tell.
-
CG how old was the unit you tested, CSL upgraded lots of ours earlier this year
Earliest 2009, latest 2013.
What did they upgrade them to?
-
The Guardian were going to run it, but then CSL claimed it was only 600 units. Not big enough.
-
Agreed
Stayed away from what technology?
Problem is, neither CSL or Intertek are going to openly say "The CSL CS2300 board testing to EN50136 had some parts self declared, including the encryption and substitution protection".
Testing the boards to the depth I tested them would cost between £10k and £20k. That's about one third of the cost of testing again. If you wanted the problems fixed, and needed in-depth advice, add another £5k at least.
I don't know if WebWayOne want to pass comment on the self declared aspects of standards testing?
Interestingly, since the research went live, two separate people have contacted me to talk about integrating the CSL protocol into panels. They were both shocked at how basic the protocol was, and how bad the documentation was.
I'm still finding it odd how little has been said by CSL. The post has far exceeded the traffic generated by Heatmiser vulnerabilities.
-
Agreed, but the trust is being tested as technology moves on and largely away from what installers have been used to for many years. There is now another 'breed' in the mix of security and these guys are, on occasions, failing at the first hurdle to make the hardware secure via inadequate software programming. Companies using independent certified security experts to give their equipment a seal of approval should be the only way forward now if trust is to be maintained.
Ask the question to Redcare, Emizon or WebWayOne - have you been pentested?
We already know what one of them will say.
-
I'm still really confused about CSL's product lines.
I looked at units that are marked CS2300-R. CSL claim there are only 600 of these in the field.
But then this box: http://www.ebay.co.uk/itm/272052537074?ru=http%3A%2F%2Fwww.ebay.co.uk%2Fsch%2Fi.html%3F_from%3DR40%26_sacat%3D0%26_nkw%3D272052537074%26_rdc%3D1
That is a G4 Gradeshift with a Worldsim - marked CS2300-R...
Surely there are more than 600 of these?
-
All things being equal yes, but this has to be different from now on in. It is only the beginning too where security is concerned if we go down the route of the ever popular automated equipment.
There has to be a chain of trust. I think it is wholly unreasonable to except an installer (or installation company) to evaluate each and every product they install. They need to trust either the test house, or the manufacturer.
As more and more devices get connected to the Internet, this will be more important. I've only briefly looked at Risco, Visonic, and Videofied Internet connected gear, and they all had serious issues. Some companies are getting security experts involved at the design stage now though.
-
id of thought that security on a security signalling device is pretty damn important
Me too.
This is the thing though - it keeps on getting back to "is it being exploited". I have no idea. Neither do CSL.
But fundamentally, the device doesn't comply with the standards it claims to.
How many of you know the PIN that secures the SMS functionality on Dualcoms in your estate?
-
Can't you loop the device somehow and prove it can be defeated , or are they fixed to point to a certain ip, why can't you mimic the ip and then try and defeat it, or you need the device to complete its data connection
Matrix stuff eh
I've done the following:
* Built a simulator of the Dualcom DC4 IP server. This means I can make a board believe that it is communicating with the real server when it isn't really.
* Built a GPRS modem simulator to show the same thing can happen on the GPRS side.
Unfortunately, it seems that Dualcom (and others, like Saxondale and Cubit), seem to think that GPRS is secure. It isn't.
im assuming they have moved on from the units you tested.
Why don't people ask them if they have moved on?
The hardware looks the same. The people are the same. CSL themselves have admitted that they can't update the firmware on any units at all.
The formula has worked for them. Why spend money on security when no one is looking?
Sorry I don't get it , CG has a card second hand , he can do what he wants as long as he doesn't connect to csl servers ?
I can do what I want to the SPT, but to prove there are real issues, you need to show that you can either create fake alarms or spoof normal polling. Not possible without connecting to their servers.
-
I am not in a position to verify if the above is right or wrong, I presume NSI will let us know in due course, does this apply to the latest units/firmware
Why not start asking CSL questions then? For whatever unit you use...
1. What encryption methods do your devices use?
2. How often do the keys get changed?
3. If there was a critical vulnerability and the firmware had to be updated, who pays the cost?
4. Have your systems been subject to a third-party pen-test?
-
Does anyone know if any Dualcoms have ever been compromised?
Problem is, if they haven't moved on from the CS2300-R, there is no way to detect when a unit has been compromised.
-
The problem in that respect is, where does the liability fall?
A lot of installers see that a product has been third-party tested, and you'll assume it's good. I'd wager that a lot of those installers don't realise that a large part of the standard is self-declared i.e. it's essentially worthless.
The insurers are similar. They've taken it on trust that the products comply with the standard.
Most end-users view the alarm and signalling as a grudge purchase. They don't care - unless they have a large estate of property they want to protect. That's why some of the bigger customers have had pen-tests done on systems.
After today though, it seems a number of insurers are going to start asking questions around signalling.
Csl Dualcom Cs2300-R Vulnerabilities
in Members Lounge (Public)
Posted
You have hit the nail on the head here.
I think what has happened is that Dycon is a small company, possibly 2-3 developers/engineers. They've used a esoteric processor - the NEC 78K0R. It's not easy to work with, there are scant tools, it's low in capacity, it's expensive, it's end-of-life. There's really little to recommend it, even 10 years ago. I suspect the are the kind of developer who has reached that stage in life where they don't want to (or can't) learn anything new. The DigiAir is fundamentally the same hardwear as the earliest boards I have - nothing is moving on.
I think these people have also assumed that the communications channel of GPRS is secure. This was true 15 years ago - only nation state attackers were capable of attacking it. Now for <£2000, you can build a viable fake cell site. They designed their protocol assuming the communications channel was secure.
When they had to expand to IP, they didn't have enough head-room to add a new protocol so stuck with the same thing.
Unfortunately I didn't record the call, but during the call in May 2014 when Rob Evans called me to ask me to take down the blog posts, the following (paraphrased) conversation happened:
RE: We have a case recently where a shop was robbed. The owner pressed the panic button and the signal didn't get to the ARC. The owner got hurt.
AT: Ok.
RE: If you release your research, this kind of thing could happen more often.
AT: So it's my fault for finding these issues, and not CSL's for developing the system?
RE: Well, we wouldn't want anything bad to happen if it is released.
Clear?