cybergibbons

So, if a PC on the same subnet could reconfigure the IP address/gateway, perform a denial-of-service attack, or even act as a man-in-the-middle, would that be considered a problem? It's far easier to compromise one of many PCs that a single embedded board, you see.

I'm just looking at changing some theoretical vulnerabilities into actual exploits on some IP signalling boards. Some of these would rely on the signalling board being accessible on the network from a PC (specifically, can the PC send broadcast traffic and the signalling board receive it). So when these boards are installed, how is the network connection normally provided? Is it just plugged into any available network port? Is a specific VLAN created (or any other segregation from the rest of the network)?

I'd like to get hold of one of these cards. Does anyone have one to sell?

Webway was good. Chris and Jim were very friendly and open, and pretty much everything I saw re-assured me that their product is as secure as it can be and, most importantly, if there was a problem it could be fixed by firmware upgrades. I was especially impressed by all the back-end work they do to make sure the system is secure - there is a lot more to it that just the SPT and encryption used. I'm going to go back for a period later in the year to examine the product in more depth.

It was a polite request, which I decided to comply with out of courtesy. http://cybergibbons.com/alarms-2/signalling-devices/csl-dualcom-post-removal/ I'm meeting with them next month to discuss the issues.

CSL have asked I remove this post. James or another mod - could you do so? Thanks.

I'm starting to get into these CSL board properly now, blah, blah, blah....

Ah, cool. Glad that it was informative.

Not an installer, just someone who plays with alarms. I don't see the point in going for a 1-way system anymore. Scantronic Ion is pretty poor, vulnerable to jamming (intentional or not) and replay attacks (read this PDF on the Abus Secvest http://sitsec.net/files/secvest_analysis.pdf, Cooper have verified the same protocol is used with Ion). I wrote about the differences between one and two way systems from a technical perspective a while ago: http://cybergibbons.com/alarms-2/alarm-technologies/it-swings-both-ways-especially-for-rf-comms/ The Pyronix Enforcer is pretty good I think, but I think I prefer the Texecom Richochet gear. I like that you can use Wintex (PC interface software) easily with Texecom. The design of the system, electronically, is much more compact and looks like it was done from the ground up, whereas the Pyronix gear looks a bit hodge-podge.

Some of the outputs are pre-set to mirror other signals in the alarm.

You've also got to factor in that firmware upgrades aren't going to just be the main panel now. Remote keypads, expanders, even wireless sensors need firmware upgrades.

1. It isn't currently, for your situation. I think arfur was mentioning something about devices on the same bus on Risco updating each other without interaction. Sounds pretty automatic in that situation. 2. We assume the auto update is secure. A fairly common vulnerability on routers is to lock down the firmware upgrade through the web UI but leave the TFTP route wide open, or as we have seen recently, with a convenient unchangeable admin account/backdoor method. 3. Yet, it is, but some are better than others. See issues with BT and O2 pushing out updates to their routers - they brick a proportion of them when users see their router not working properly, they kill the power halfway through the update. I'm not saying it should be totally avoided, just it does carry risks.

I've seen enough badly implemented update systems (not on alarms) that really can't handle an update that doesn't go quite right. That's the advantage of being onsite - often the update is done using an ISP header which allows you to recover even if things go wrong. The same is true for BIOS updates on a lot of PCs. Some PCs have dual BIOS flash which means if one doesn't work after an update, it can fallback to a backup.

Lots of reasons: 1. It's an opening that wasn't there before to the heart of the system. 2. Quite a lot of systems don't do any checksum or validation of the firmware 3. Firmware updates can and do fail - leaving you with a system that doesn't work.

I'd much rather have a system where I can update the firmware than one I can't, and as part of that, the manufacturer needs to be open to dealing with reports of problems. Online firmware updates are a bit scary. There's a lot that can go wrong, and it's a big opening for attacks.

The biggest problem by far is the small key compared to the code size, so I've kind of stopped looking into this one.

The same is true for encryption in some wireless systems. The receiver in the panel doesn't have the overhead to deal with a key per detector, so it just uses a single system wide key. That means all detectors, ever, use the same key...

Thanks. With a) it seems that the main issue is that customers could reset the panel when the ARC doesn't want them to. b) I suspect exactly the same algorithm is used in the panel as in the program. I think the algorithm was written for whatever 8-bit processor was used in those days. Might as well show the algorithm used, the only bit of it that needs to be secrete is the vector at the top which I have changed. I don't know if you know any programming or python, but it's really simple. # Taken from the data in the exe vector = [3,3,5,5,8,1,3,9,8,0,5,9,3,9,4,1,1,0,9,4,3,0,2,2,8,4,3,2,8,4,9,4,1,3,3,3,3,8,5,3,0,2,4,3,2,1,8,9,0,5,4,3,9,5,8,3,9,9,1,0,0,9,9,3,3,8,2, 1,4,9,1,4,9,2,9,0,9,5,3,9,5,3,3,5,9,1,0,2,9,3,2,1,2,9,8,0,4,9,4,2,3,9,4,0,1,8,5,3,3,9,9,1,0,5,9,3,8,9,4,8,4,2,3,1,0,3,9,4,8,2,0,4,3,3, 1,0,5,2,8,3,3,5,2,8,3,2,9,5,2,1,2,4,4,3,0,4,2,3,4,1,8,2,9,1,0,5,1,8,2,4,3,5,1,0,3,8,5,3,2,1,1,3,9,3,2,3,5,8,3,9,0,3,2,3,5,3,8,4,0,3,9, 1,9,3,0,2,9,3,8,1,4,2,8,4,0,1,9,1,0,1,2,1,3,5,3,3,9,0,2,1,4,1,2,3,4,3,4,9,5,3,5,9,3,1,3,9,4,0,3,2,3,3,4,4,2,1] def generate_reset(quote, version): i = 0 tens = 0 reset = [] while i <= 4 : j = 0 result = 0 while j <= 4: offset = (version + tens + quote[j]) % 256 result = result + vector[offset] tens = tens + 10 j = j + 1 reset.append(result%10) i = i + 1 return reset print(generate_reset(quote = [0,0,0,0,2], version=131)) Notice that there is no multiplication, division, or anything fancy. The % symbol means "modulus" which most people know as "remainder". So "% 256" means "divide by 256 and give me the remainder". You normally get this for free in a microcontroller - an 8-bit number is limited to 256 values, so it just wraps round anyway. Panel firmware would contain it - in fact, now that I know certain panels have it, I can find the long string of characters called "vector" in some of them. The problem with panel firmware is that it is very hard for me to work out what is data and what is code. In x86 exes, there are normally a lot more hints available to me. I can also easily run an x86 exe and step through the running code to see how it works. With a microcontroller in an alarm, I can't easily do this.

Tunstall are someone who Menvier took over who Cooper took over? If you can point me towards a program to generate them...

Precisely Joe. This is just an easy target to show that.

It's all part of learning. Nothing lost for a few hours work.

So I wonder what drove the standard to require that and where the 5-digit Technistore code fits in to this? There must have been some reason behind it being 5-digit - it's rarely seen as a code length. It's a combination of the long code and short key. The key allows 256 distinct mappings between the quote code and reset code. That means that 12345 quote can only map to at most 256 of the 100,000 possible output values. 999,744 of the outputs are not possible - our keyspace has been reduced hugely. Notice I say "at most 256". It is possible for 12345 to map to 98765 using one or more keys. In fact, 12345 could map to 98765 using all 256 keys, but then we wouldn't need to find out they key at all. So if you tell me the reset code and I know the quote code, it is highly likely that I can just guess the key. For a very limited number of quote/reset pairs, I get 2 possible keys (in fact, there are two combinations with 4). So more than 99% of the time, I just need a single quote/reset pair to work out the key. So normally I get something like: 12345/74643 - only possible key is 123 (99.25% of the time) Sometimes I get this: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 98747/37265 - one possible key 232 (about 99.25% of the time) It would be really unlikely to get this: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 91737/72764 - two possible keys 078 and 154 (about .75% of the time) (we know the key is 154 as it is the only common one) Vanishly small chance of this happening: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 73748/38377 - two possible keys 232 and 154 (about .75% of the time) 98747/37265 - one possible key 232 (about 99.25% of the time) I've just tested these by running every single possible combination of key and input code against the algorithm. Not in any detail - have started looking at Texecom. Not aware of Tunstall.

Thanks Matt. You've raised something interesting there. With the 00-99 mapping system, you'd need to get all 100 pairs to be sure of the mapping. With Technistore, you need one pair to know the mapping.