IoT security

Tue Feb 7 13:13:03 UTC 2017

" any IoT device must _by default_ emit a UDP packet to an
anycast address reserved for the purpose which identifies the device
model and software build. "

Any semi-competent attacker will simply alter the way the network stack on
the device works to make it _not_ look like an IoT device for the purposes
of this check, rendering it moot.

"If the IoT
device receives the fail message, it must try to report the problem to
its owner and remove its default route so that it can only communicate
on the local lan."

If the vendor isn't thinking about security already, as evidenced by the
current issues with these devices, how are they to be convinced to add code
to make said device do something exceptionally specific?

I believe it's important to remember that network endpoints will never be
sure fully secure. They will never be fully in compliance with $standard .
They will never always follow best practices. This is not to say we should
do nothing (obligatory 'Perfect is the enemy of good' comment) but it's
something to think about when discussing possibilities.

On Tue, Feb 7, 2017 at 6:56 AM, William Herrin <bill at herrin.us> wrote:

> On Tue, Feb 7, 2017 at 5:26 AM, Rich Kulawiec <rsk at gsp.org> wrote:
> > On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote:
> >> What about some kind of requirement or convention that upon boot and
> >> successful attachment to the network (and maybe once a month
> >> thereafter), any IoT device must _by default_ emit a UDP packet to an
> >> anycast address reserved for the purpose which identifies the device
> >> model and software build.
> >
> > I can think of at least four reasons why this idea must be killed
> > immediately and permanently.  This is off the top of my head *before*
> > coffee, so I strongly suspect there are more.
> >
> > 1. An attacker who takes control of an IoT device can change the contents
> > of that packet, cause it to be emitted, suppress it from being emitted,
> etc.
>
> Hi Rich,
>
> Immaterial. The point is to catch vulnerable devices before they're
> hacked. That can't always happen (even with customers and vendors
> engaged in best practice patching), but it need only happen often
> enough to limit the size of the resulting botnets.
>
>
> > 2. This will allow ISPs to build a database of which customers have
> > which IOT devices.  This is an appalling invasion of privacy.
>
> As I envision it, it's an opt-out system. Anyone who cares and knows
> enough to secure their network can turn it off for their devices. No
> permission or action from the ISP required to turn it off. In fact,
> you need only block packets to the well-known anycast address to
> disable it for all devices on your network.
>
>
> > 3. This will allow ISPs to build a database of which customers have
> > which IOT devices.  This will create one-stop shopping for attackers.
>
> Possible, though an ISP which retains the data opens itself to a class
> action lawsuit if it can't keep control of it.
>
> Nevertheless, let's not oversell the privacy implications: most of the
> IoT devices we're talking about phone home anyway. They're tied to
> this or that cloud service rather than accepting local access. An ISP
> can't learn as much information by watching who they phone home to
> (deep packet inspection), but they can learn an awful lot.
>
>
> > 4. It won't take long for this to be used as a DDoS vector.
>
> If the ISP can't keep control of its security head-end then sure, at
> least until the ISP regains control.
>
>
> Regardless, I encourage you to suggest alternate solutions which don't
> run afoul of the problems you mention. The problem isn't going away.
> Entirely cutting off customers doesn't work because there are too many
> impacted customers and ISPs don't have the resources or the will to do
> so. Demanding that trash vendors not produce trash won't get it done
> either. When you eliminate responsible device hardening, cutting
> customer connections and the kill switch, what's left?
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>