Spitballing IoT Security

Tue Oct 25 08:10:31 UTC 2016

In message <FD166608-2C42-415D-B6F7-FD6921263E09 at puck.nether.net>, 
Jared Mauch <jared at puck.nether.net> wrote:

>Top posting to provide some clarity:

That's funny.  Personally, I have always felt that top posting -destroys-
clarity.  But as Chaplin Tapman said in Catch-22 "I'm not here to judge
you."

>1) Many IoT devices are connected via some cloud service, think Nest

Yea.  And?

Are you saying that there is no way to make that connection happen
without a kernel that's going to allow unlimited outbound bandwidth
to entirely arbitrary targets?

>2) Many IoT devices have cloud management, think of Ruckus, UBNT UniFi
>etc that phone out to a site via DHCP option or otherwise.

I admit that I -was not- thinking about such things when I posted my
trivial proposal, in large part because I'd never heard of either before
now.  But that's OK.  I've just googled them and I don't think either type
of device really negates my simple proposal.

Via the simple expedient of redefining the scope of the problem being
addressed, I would still like to claim that what I proposed may have some
merit, but only for "real" IoT devices.  I will now define what I'd like
to call "real IoT" devices as "stuff that isn't either general purpose
computers *or* stuff like routers."

The Ruckus thing and that UBNT UniFi thing appear to me to fall more
into the class of devices I'd prefer to call "routers", i.e. stuff
whose job it is to move quite a lot of packets, on a routine basis,
in the outbound (Internet) direction.

(Yes, I'm cheating by definining and/or re-defining my terms, on-the-fly,
to exclude stuff that I don't want to be bothered thinking about right
now.  But maybe that isn't such a bad thing, or even such an intellectually
dishonest thing as it may at first appear.  It's best not to bite off more
than you can chew, and I think it might be useful to solve the problem
for a big swath of common "IoT" devices that either are now, or that will
soon be on the Internet, even if I can't offer you a solution for, you
know, poverty and world hunger at the same time.)

>3) Many IoT devices are something like a set top box, these need access
>to a CDN or similar to get the content for the users.

I thought a bit about that since I posted, and here's my response...

Yeabut traffic for -those- things is goona be 99.99% inbound.  My Roku
needs to connect out to get stuff, and maybe it is even is doing that
via TCP.  (I really don't know, cuz I never even thought about it before.)
But even if my Roku is sucking down content via TCP connections which
*it* initiated (i.e. "outbound" TCP connections) if there were a low
fixed, maximum -outbound- bandwidth rate limit implemented for this thing,
directly in its kernel, I believe that it could still do everything it
is supposed to do with no problem.

So fuggetabout what I said about totally disallowing outbound TCP.  For
many IoT devices, actually and totally disallowing outbound TCP connections
might be workable... and for those, it would be a prudent and useful
kernel-enforced limitation...,but for many others, like my Roku, maybe
not.  But neither your refrigerator nor my Roku really ever has any need
to be sending multi megabits per second outbound.  They just don't.  I'm
-not- suggesting that we put all these things on a diet and give them only
9600 baud to work with.  I'm just saying that if they ever hit more than,
say, .2 Mbps outbound, in total, over any short period of time, then I
think their kernels would be doing the world a favor if they displayed
some sort of an error code (where feasible) and if they then started
just dropping outbound packets on the floor until things settle down
and the -requested- outbound bandwidth drops back below the hard limit.

(Of course, all traffic to internal interfaces, local loopback, and
RFC1918 addresses should be utterly exempt from the cap.)

>4) Many IoT consumers don't read NANOG, so they also won't
> set up a firewall other
>   than to know it is a service impairing tool that must be disabled for
>their devices to work.

Well, yea, there's that, but also, with IPv6, as I understand the plan,
every single device, no matter how lowly or absurd, is gonna get itself
plugged right straight into the neural backbone of the entire planet.
None of this NAT router or firewall stuff anymore!  That's so last
millenium.  So there's not gonna be nothin' in our bright bright future
for Luci and Desi to either enable or disable anymore, even if they
wanted to.

But here it seems that you're agreeing with me, and even making the case
for me.  The device itself should be fail-safe.  It shouldn't need outside
help in order to avoid bursting into flames and endangering innocents
like a 1970's Ford Pinto.

>5) There are few/no new lessons here compared to the default install of
>Redhat 3.0.3
>   from the late-1990s.  I recall it by default installed INN a usenet
>news server.

An IoT is -not- a general purpose computer.  In the latter case, it is
assumed that the owner will "pop the hood" when it comes to the software
configuration.  In the former case it is assumed that the owner -won't-
be doing that, or will have only a very minimalist ability to do so.
(CAUTION!  Risk of electrical shock!  There are NO user-servicable
components in this box.)

>   We must promote secure by default.

I love it when people agree with me.

>This means some sort of secondary authentication
>   such as a sticker on the device with default password or requiring
>the entering of
>   a serial number or basic setup information to work.

Well, yea. That would be nice too.  Force the user to set a unique password.
How novel!  Swell idea.  Marvelous.  I'm all for it.  And we know that
will work, absolutely 100%, until it doesn't, until the day when some
pimply-faced teenager in Minsk figures out how to engineer a maliciously
crafted JPEG, then uploads it to his Picassa album, and then gets his pal
to spam out 50 million spams encouraging Joe Wankers everywhere to view
the latest nude photos of Jennifer Lawrence on their Rokus, whereupon
we'll all be right back where we were on Friday.

>6) Devices need to prompt for updates.

See above.  That would be nice too.  I'm not persuaded that it will
actually solve the problem though.

(Think about this too:  If the software minions hired by the manufacturer
to code up the original firmware were careless enough to have created a
serious security flaw in the -original- firmware, what makes you think
that they are suddenly going to develop superior coding skills and that,
thus, any update released by the company will be any more secure than the
original flawed version?  And that's even assuming that the same guys who
coded up the original firmware are tasked to do maintenance fixes, which
is most companies, they're not.  The original coders all get moved over
to the latest project in development, and the company hires one or two
19 year old H1-Bs just off the boat to handle all software maintenance
on the "old" products.  So nine times out of ten, the guys tasked with
fixing the security problem(s) in the "old" products are even more inept
dumbasses than the ones who coded up the original security flaws in the
first place.  How many securty fixes have had to have -their own- subsequent
security fixes applied?  Plenty.)

>   Apple has sorted this nicely, people are prompted for supported
>upgrades...

Umm, I'm getting the book off my shelf that purports to tell me how
to disagree without being diagreeable.  But I can't seem to find it
so I'll just say what I mean:  Rubbish!  "Apple has sorted this nicely"???
You must be joking!

I've got an iPhone 3GS.  I went into the local Apple store more than
a year ago and asked them how I could get the bloody thing to read and
display PDF files.  They were very polite, and tried hard to avoid
snickering directly in front of me.  And they were, of course, only
too happy to show me a brand new iPhone 6 while telling me how little
it would probably cost in conjunction with "my plan".  (Hint:  I don't
have a plan.  I have GoPhone dollars, which don't cost me anything if I
don't use them, which, in general, I don't.  And if Apple really thinks
that I'm going to shell out several hundred real bucks for a piece of
electronics that might accidentally end up in the washing machine or
simply get ripped off they got another thing coming.)

So, it turns out that Apple can't (or rather won't) give me any version
of any of the last -3- major releases of IOS for my phone, because they
quite rightly have figured out that it is not in their economic interest
to do so.  So I now own the Apple equivalent of Windows XP.  No security
fixes, no nothing.

So when you say "Apple has sorted this nicely', you'll just have to forgive
me if I take issue with that.

More to the point however, this illustrates part of the overall problem.
Manufacturers and vendors sell stuff to you with the expectation (and hope?)
that it's all gonna end up in a landfill someplace within 5 years.  They
certainly don't plan on releasing any security updates past those five
years, and that's even assuming that the company itself lasts that long.
(Many don't.)

So, six years from today we'll all wake up one morning, turn on CNN, and
find out that a maliciously crafted packet sent to 35 million vacation pet
feeders has just resulted in the disapperaance from the Internet of the
entire continent of South America.  So Wolf Blitzer or Brian Krebs will
pick up the phone to call the manufacturer to ask if they're going to be
releasing a security update for this massive problem, only to find out
that the phone number is dead and the company declared bankruptcy three
years earlier.

This is not a happy ending.

If all of the *&^%$# damn stupid vacation pet feeders had originally shipped
with outbound rate limits hard-coded in the kernel, maybe this could have
been avoided.

>7) Malware can damage systems making them require extra steps to recover
>them.  Whitehats
>   may know some mitigation techniques, but can't protect you

I do so love to end on a note of agreement.

I reiterate, fail-safe by design, and outbound rate limits for all IoT
things to which such limits can be sensibly applied without damaging or
materially degrading functionality... which is to say most of them.

Regards,
rfg