Vulnerabilities In Ip Alarm Signalling Protocols

[GalaxyGuy]

It's more than just asking about encryption. The devil is in the detail. Even though encryption is employed, the ARC receiving software and the transmitting device need to have unique keys in order that the ARC can verify the device before accepting the event for the account.  Many current 'secure' systems employ standard RSA&AES, but there is no identifying validaton of the transmitting device. Yes, this avoids eavesdropping, but does not stop the ARC being spoofed by encrypted events.

[cybergibbons]

Triple DES isn't bad really as long as your key is not too short.

One of the keying modes uses the same 56-bit key at each stage, to maintain backwards compatibility with DES. It's technically triple DES but no better.

It has known issues that make it less strong that ideal, but none of the attacks are yet practical. As computers become more powerful they will be possible, hence the move away from them.

Most practical cryptographic breaks aren't actually in the algorithm itself, but the implementation. A lot of things have fallen over due to leaking information in padding, and key exchange is frequently mishandled.

[cybergibbons]

GalaxyGuy - this was one of the things I mentioned in my post about encryption. Without a message authentication code, encryption is largely token.

[GalaxyGuy]

GalaxyGuy - this was one of the things I mentioned in my post about encryption. Without a message authentication code, encryption is largely token.

 

Sorry, I've still to read it

 

BTW, Honeywell employ 128 bit Private Key Advanced Encryption Standard (AES) for message data encryption and 1024 bit RSA (Public Key) for exchange of the AES private key on the Galaxy Ethernet implementation.  They don't employ message authentication, but their implementation of RSA is not standard, so any attacker would need to determine the algorithm to spoof events.

 

One other thing worth noting is that ARC's may employ blacklisting of any transmitting device that transmits to an unknown account. The sender would simply never know what was happening with the transmitted events, as they would be accepted. Wilco would never know this, as (for legal reasons) he didn't try spraying events across accounts at his ARC. If he had, then after the first invalid event, any subsequent events may have been binned. The ARC would then investigate the hacking.

[cybergibbons]

The blacklisting sounds like a great way of performing a DoS attack

[Joe Harris]

Blacklisting is perhaps not a good way to describe handling for such events at most ARCs.  They would normally instead be redirected to a default holding account for investigation.

[GalaxyGuy]

The blacklisting sounds like a great way of performing a DoS attack

 

 

Blacklisting is perhaps not a good way to describe handling for such events at most ARCs.  They would normally instead be redirected to a default holding account for investigation.

 

If they are accepted and flagged as non-normal reception and future reception is automatically blocked, then it sounds like a black listing. I would expect some anti-DDoS integration though.

[cybergibbons]

Honeywell are entirely unwelcoming to reports of vulnerabilities. What has been their take on issues with their protocol?

[matthew.brough]

Honeywell are entirely unwelcoming to reports of vulnerabilities. What has been their take on issues with their protocol?

To tell me to take a long walk off a short plank

[cybergibbons]

Yeah. I got told to walk off a short plank with the chains of a big lawsuit around my ankles. 

 

I'll take up the offer of signalling equipment once my plate is clear, I have a lot on at the moment.

[matthew.brough]

Yeah. I got told to walk off a short plank with the chains of a big lawsuit around my ankles. 

 

I'll take up the offer of signalling equipment once my plate is clear, I have a lot on at the moment.

Customer service at it's best

I'm not Honeywell fan. Their kit malfunctioning and their subsiquent lack of response to address it has cost us dearly in 2 big customers and a lawsuit that followed.

 

I thought you could publish this info as long as it was in journalistic interest

[cybergibbons]

I'm not sure I want to test it unfortunately. I do have someone willing to help with publishing stuff, I just need to make sure anything that is fact is presented as fact, and anything opinion is opinion....

[matthew.brough]

I'm not sure I want to test it unfortunately. I do have someone willing to help with publishing stuff, I just need to make sure anything that is fact is presented as fact, and anything opinion is opinion....

I can understand that, especially with the deep pockets some of these companies have (which is what I think they rely on to mask some of their 'issues'. If it was me personally I'd do it but can understand why many wouldn't.

[Joe Harris]

Honeywell are entirely unwelcoming to reports of vulnerabilities. What has been their take on issues with their protocol?

 

Their take is that they are right and everyone else is wrong.  At least initially it is - they only change their mind when they realise that nobody is buying product.

[Joe Harris]

You would have thought by now that Honeywell were used to handling vulnerabilities

 

To date they have been lucky as vulnerabilities have been disclosed ethically to them.  Though in some cases they had over 3 months from disclosure to publishing and yet still haven't fixed the issue over 6 months later.

[matthew.brough]

You would have thought by now that Honeywell were used to handling vulnerabilities

 

To date they have been lucky as vulnerabilities have been disclosed ethically to them.  Though in some cases they had over 3 months from disclosure to publishing and yet still haven't fixed the issue over 6 months later.

You think they will ever bother? My issue list didn't get resolved in 2 years, not even the critical ones.

[Joe Harris]

We were given a workaround followed by more unsuitable workarounds.   It is only fair for me to point out that they did finally realise and fixed an issue we flagged properly within the firmware rather than through a workaround.

[matthew.brough]

We were given a workaround followed by more unsuitable workarounds.   It is only fair for me to point out that they did finally realise and fixed an issue we flagged properly within the firmware rather than through a workaround.

Lucky you . . .

[jimcarter]

We are happy to discuss our encryption and substitution protection with interested parties and have been independently tested not only by the BRE/LPCB, but also customers own IT and external penetration test houses. This has enabled us to sell our systems into banks and retailers. As encryption is part of our software protocol we see no reason not to offer this level of protection to any connection.

 

 

Just picking up on what Chris has said here. The 3rd party penetration testing we carried out has been under non-disclosure and included sensitive information on how the system operates. They attempted attacks on both the SPT and the MCT, all unsuccessful. To truly meet Grade 4 levels of alarm transmission both substitution and encryption protection is mandatory on ALL communication paths. You cannot claim to meet Grade 4 if you do not adhere to these requirements and these are questions that should be asked of the the ATS provider. As Chris mentions, once these techniques are in place they may as well be deployed across all grades if system, it makes no sense not to. 

[cybergibbons]

Jim,

 

Two things I pick up from that:

1. "sensitive information on how the system operates" is under NDA. If that information was disclosed, would it have material impact on the security of the system? I've seen NDAs breached before, and you've always got to think about what happens if you piss off an employee.

 

2. "once these techniques are in place they may as well be deployed across all grades if system, it makes no sense not to" - this is a brilliant attitude to have. I really don't think product differentiation should be the reasoning behind a grade 2 product being worse than a grade 4.

[matthew.brough]

Jim,

 

Two things I pick up from that:

1. "sensitive information on how the system operates" is under NDA. If that information was disclosed, would it have material impact on the security of the system? I've seen NDAs breached before, and you've always got to think about what happens if you piss off an employee.

 

2. "once these techniques are in place they may as well be deployed across all grades if system, it makes no sense not to" - this is a brilliant attitude to have. I really don't think product differentiation should be the reasoning behind a grade 2 product being worse than a grade 4.

We have a NDA with Webway and to be fair, they are quite forthcoming with information when asked.

[jimcarter]

Agreed (cybergibbons) and this is the same for say any employee working within our own development department and Im sure we are not alone here. Yes you have to be very cautious with disclosing information but when getting involved in meaningful pen-testing you have to be working with companies that are both reputable and trust worthy. The financial institution we worked with on this particular project was insisting on a very demanding test and employed the company to carry out the tests. Part of their criteria was to attach the system from within and focused not only on our systems but their own. 

[cybergibbons]

It all sounds like good stuff. Getting proper pen testing done is a really important step. SIA-HS would have been ripped apart in less than a day by an intern at most decent pen testing places.

And yes, WebWayOne has a lot of useful and confidence inspiring stuff open to me without an NDA. 

[jimcarter]

Yes it's a useful from two points, it validates what the test houses such as BRE have done and helps us have great confidence in what we do. We can't use the test results on a commercial basis or openly publish the reports but at least we can talk about and outline what we have done.

[james.wilson]

Jim, its good to see openess from a manufacturer, thanks for doing that here. Id like to see cyberg have a proper look at your stuff to give an independant view on the kit?

 

 

Jim,

 

Two things I pick up from that:

1. "sensitive information on how the system operates" is under NDA. If that information was disclosed, would it have material impact on the security of the system? I've seen NDAs breached before, and you've always got to think about what happens if you piss off an employee.

 

2. "once these techniques are in place they may as well be deployed across all grades if system, it makes no sense not to" - this is a brilliant attitude to have. I really don't think product differentiation should be the reasoning behind a grade 2 product being worse than a grade 4.

CG on point 2. I do. There is a cost saving demand in the marketplace. You cannot compete offering a g4 product for g2 money. The standards demand minimum requirements at set grades. You cannot enforce a buyer (customer) should pay for something they feel they dont need. That is the whole point of risk assesment and advising what is best for them at their risk. ie do you have a 50k cash rated safe to put your piggy bank in at night? You dont need to but are you saying you should?