
Xfinity's Security System Flaws Open Homes to Thieves - alistairSH
http://www.wired.com/2016/01/xfinitys-security-system-flaws-open-homes-to-thieves/
======
jerf
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.

~~~
lost_my_pwd
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.

------
StavrosK
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/](https://stringphone.readthedocs.org/en/latest/)

~~~
adrianN
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.

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

~~~
kefka
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/2015/10/17/so-you-wanna-iot-a-howto-on-
internet-of-things-1-of-many/)

[https://crankylinuxuser.net/2016/01/05/so-you-wanna-iot-a-
ho...](https://crankylinuxuser.net/2016/01/05/so-you-wanna-iot-a-howto-on-
internet-of-things-2-of/)

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?

~~~
throwaway7767
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.

~~~
kefka
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.

:)

------
5h
Troll headline.

The flaw results in false positives.

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

~~~
lost_my_pwd
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.

