Anybody else see this published?
https://community.rapid7.com/community/infosec/blog/2016/01/05/r7-2015-23-comcast-xfinity-home-security-system-insecure-fail-open/
It’s labeled as an Xfinity Home Security problem, but upon further reading it may be a problem for all Zigbee device. Thoughts?
If I’m understanding this correctly, their vulnerability is that if you jam the 2.4GHz signal then a sensor won’t be able to communicate to the controller. It’s not so much a ZigBee problem, but one thing that’s in development that should help is a framework for device health so that we proactively notify you if a device hasn’t communicated in awhile. Either way, a lot of these devices are “sleepy” and only wake up occasionally on their own. A device like a door sensor may only wake up once every few hours, so we’d need to not see a device for a number of hours in some cases before we alert the user that there’s a potential issue.
It’s a known issue, but already discussed…
dang, thought i did a through search! Somebody can lock this thread.
Nah… Nobody commented on the “response” I posted to that old Topic; so I think some extra visibility isn’t a bad thing. Thanks for sharing the news…
I work in the human machine interface world data integrity is one of the most important parts of the job. At least knowing when it’s broken that is.
T[quote=“Tyler, post:2, topic:34746, full:true”]
If I’m understanding this correctly, their vulnerability is that if you jam the 2.4GHz signal then a sensor won’t be able to communicate to the controller. It’s not so much a ZigBee problem, but one thing that’s in development that should help is a framework for device health so that we proactively notify you if a device hasn’t communicated in awhile. Either way, a lot of these devices are “sleepy” and only wake up occasionally on their own. A device like a door sensor may only wake up once every few hours, so we’d need to not see a device for a number of hours in some cases before we alert the user that there’s a potential issue.
[/quote]
There is a better way to handle this, if ST intends to make a real security system - and judging by their service options via Scout and now ADT (but not necessarily by how the product works, yet) - then there should be a better method to detect zigbee/zwave network failures or interference. Something active, say a plug in beacon that the hub must be able to communicate with and if that fails due to interference = ALARM.
Patent Pending - Method to determine interference (jamming) with a wireless security system
If it is radio jamming then any device in that general area would be affected. So the correct way to monitor batter type devices for jamming would be to put a powered device in the general area and force a refresh of that device on a frequent basis. If you can’t communicate to it then there is something wrong with the network and you could chose your action.
I hope the “device health” solution will “see” sleepy device reporting. I have some devices that don’t have any events in the 7 day history and other than catching a sleepy event in live logging I wouldn’t know if they were alive.
Would a user settable threshold work? If ST can’t communicate with X% of devices and the LAN connection is good, send alert and/or send off siren.
Sort of. But as mentioned, Zigbee devices can be sleepy by design. So, yes that would work better than nothing but’s it’s far from ideal for all scenarios.
To be properly robust, it really needs to be an always on, AC Powered /Battery Backup purpose built Beacon that constantly communicates on Zigbee, Zwave and other relevant protocols with the hub and when packets are lost at a certain rate, an alarm can be triggered.