Xfinity's Security System Flaws Open Homes to Thieves | Hacker News Reader

Xfinity's Security System Flaws Open Homes to Thieves

wired.com

32 pointsalistairSH17 comments

This system really can't help but fail open. The researcher handwaves in this direction, 'because “you don’t want these to alert and go off every time you turn on the microwave,” Beardsley notes', but either it fails open or trips an alarm; practically speaking there is no middle ground. Changing the color of a light in a different room in the middle of the night is as good as a no-op.

I'd submit that what this really proves isn't that the Comcast system needs this or that tweak... what it proves is that this sort of security can't be done wirelessly. Wireless equipment can not help but assume that if it can't hear from its sensors, the situation must be OK, and they can not help but be jammable with hardware that really isn't that sophisticated.

The solution to both problems is a decently-shielded wire. It is impractical for a thief to jam, and continuous active communication that trips in a fraction of a second if severed from the hub is trivial and reliable.

I like WiFi as much as the next guy, but it seems to me a lot of people badly overestimate what wireless is capable of sometimes.

One presumes that if your system is set to disarmed, as it would likely be if you're using your microwave, this could be ignored, but in Armed - Away mode, differently.

The system I have is wireless and despite being in a 3000+ sf home with many potential sources of interference, I have not had any communication issues. When a perimeter sensor, one that guards against intrusion, drops communication, the system will take action dependendin on whether the system is armed or not. If someone is home using the microware, the alarm is typically not armed; not that the microwave has ever caused an issue anyway.

I don't see why this is not the behavior for xFinity's system as well.

You are also missing the point that there is no indicator of communication failure, no log, etc.

In my fire alarm when the batteries are going dead there is a chirp that lets me know of a pending failure. The Xfinity alarm system could do that as well.

Instead the alarm system is worse than useless.

I can buy a box that always has a green light on it which is exactly what this "alarm" system is doing when there is an extreme failure.

Not exactly the same, but I'm very worried about security and data privacy when it comes to home devices. A third party knowing what photos I publish on the web is one thing, but a third party actively being able to control my thermostat, kitchen or being able to see what's happening in my home at any time, unknown to me, is what really scares me.

Regarding the security aspect, I wrote a secure communications library[1] as a proof of concept in Python, with the aim to make it much easier to write authentication and encryption into an app. About privacy, though, we need to make sure that the only devices that run in your house give you access to the code and the ability to verify what's running on the device.

Otherwise, we can stop worrying about whether we're in Brave New World, where people were numbed by all the entertainment, or 1984, where people were under an all-seeing tyrant, and be sure that we're in both those things, numbed by all the entertainment which incidentally required that we voluntarily sign away all control to the all-seeing eye in exchange.

[1]: https://stringphone.readthedocs.org/en/latest/

If I had smart devices in my home, I wouldn't allow them to communicate to the Internet directly. I think the common approach is to set up some bastion computer that only allows SSH login and make the other devices only visible to this computer and not the Internet at large.

Most manufacturers (e.g. Nest) insist on the devices talking to their servers, in order to maintain lock-in.

Oh yes. I talk greatly about that on my blog, crankylinuxuser.net

All in all, there are open standards in which IoT devices could communicate: MQTT(mosquitto), CoAP(Californium), AMQP(rabbitMQ) to name a few. Yet, none of the major vendors will touch these technology stacks, precisely because of lock-in to their special-snowflake database servers.

There are solutions, of which only 1 is palatable.

1. Don't buy. (Dumb house, but at least you control it.)

2. Only buy company offerings that support the above standards. (Good luck.)

3. Build it yourself.

I'm going down the path of "Do it yourself." I already have a gateway controller acquiring data from sensors and sending data to things like wirelessly connected Neopixels (ws2811 strands). The radio I'm using is a mesh network chip called nRF24L01+ and the Arduino library is MySensors. Things just work, and work well. I have data dumping into a MQTT Mosquitto instance and processing logic resides in Node-Red.

The other part of the Corporate "We hold your data" policy is the main reason they give: so you can control your devices from anywhere. Sounds great. Our solutions are to use things like No-IP.org , but you end up with a max 4 device limit. Not to mention, they also have a draconian ToS. So what else can you use? TOR. ..?

What? The essence is that you install TOR on your machine, and edit the /etc/tor/torrc and turn on a hidden service to SSH and HTTPS. Reconfigure Node-Red to use self-signed certs and enable authentication. Now you have access to the GUI to create flows as well as webpages within the flow. I have a nice discussion how to do everything from hardware on up here:

https://crankylinuxuser.net/2015/10/17/so-you-wanna-iot-a-ho...

https://crankylinuxuser.net/2016/01/05/so-you-wanna-iot-a-ho...

But in a nutshell, TOR isn't just for anonymizing, secure internet. It's also great for punching holes in firewalls and NATs and stuff to provide a service anyone can get to. Just be smart about it, secure the open ports down, and keep your onion site hidden as well.

I've been railed against before for my unpopular opinions regarding this topic. But things are only going to get worse with every company who decides to reinvent the wheel, so they can have your data. And not to mention pilfering your data, does the idea of "No Internet, no House automation" sound like a good idea?

All good points (though to me, option 1 is more preferable to option 3 :)

I'd like to point out, if you're not aware already, that tor additionally supports authentication for hidden services on the network layer. You can put a "HidServAuth" line in your torrc, which will then create a key line you must place into your clients torrc. Only clients with the key can connect to the hidden service. You could use that either in place of or in addition to bespoke web app auth and SSL. That way you also prevent people enumerating tor hidden services from knowing what's running behind your service.

Oh, of course option 1 is the most palatable, until everyone gets their shit together regarding standards.

No, I know I'm going down the "Here ye be dragons" path of making my own IoT infrastructure. It's been one hell of a wild ride, seeing this and that offering, and how they fall flat on 'If internet is down, you have a doorstop'. I show people at the hackerspace and other tech groups, and they really see value in it.

I'll certainly have to look into the HidServAuth option. However, I've been watching to see if Ca.Cert is going to get off their collective asses and revoke the "Only EV2 certs can be provided for .onion addresses" rule. My biggest problem with certs on .onion is that they fail to work. Ideally, I want a LetsEncrypt cert on all of my services (Node-Red, Mosquitto via MQTTSSL, email). And just be done with it.

I'm certainly trying an orthogonal way of setting up IoT vs the Corporate way of remote data centers and oppressive data handling techniques.

I favour (1) myself, being happy to walk across the house and press a button whenever I'm excessively hot or cold, but I like your idea about putting the house as a Tor hidden service. Are these "enumerable" or scannable? (like people scan the IPv4 range looking for targets)

At the most unidea circumstances, you can scan the whole space of "{16 alphanumeric characters}.onion" at a space of 36^16 or around 7x10^24 addresses. That's not feasible.

The other attack I've seen is turning on HSDir flag in /etc/tor/torrc and then logging all hidden service descriptors you receive. This method is obviously passive, but it does get the job done according to : http://donncha.is/2013/05/trawling-tor-hidden-services/

Admittedly, I'm relying on my hash.onion for a security via obscurity. And I'm OK with that. Because behind that obscurity is key based ssh and a Node-red configured with https and authentication. Obscurity can be an effective part of overall security, as it lowers the surface area of attack.

The problem is, I don't have time to work on the DIY angle. I'm using INSTEON, which is closed/proprietary from a hardware sense, but has a documented API that's relatively simple to program for, and there are many available programs to control it.

I applaud your position though. I find the popularity of Wi-Fi/Cloud-connected IoT devices to be a trend doomed to disaster.

I agree this is key. I am using an INSTEON system, which doesn't use Wi-Fi or Bluetooth, and it's got an interface to my PC. Any control of any module of my house, therefore, goes through my PC.

Troll headline.

The flaw results in false positives.

If jamming frequencies caused all the locks to disengage, that would "Open homes to thieves".

Jamming disables the alarm sensors for (up to) hours, allowing thieves to break in undetected.

I'd argue that this should be called a 'false negative' rather than a 'false positive', but in any event it's certainly a security risk.

I think you may have misunderstood. On my home security system, communication interruptions to a sensor are treated as a "bad" condition and alerts are sent with a comm warning. The system fails open.

With the xFinity system, it fails closed, meaning that when a sensor loses connection, the system assumes everything is OK until it hears from the sensor again. An alarm/alert only occurs if a sensor affirmatively indicates a "bad" condition.

Reply on news.ycombinator.com