Re: Spitballing IoT Security

[Jared Mauch <jared () puck nether net>]

Top posting to provide some clarity:

1) Many IoT devices are connected via some cloud service, think Nest (for example)
2) Many IoT devices have cloud management, think of Ruckus, UBNT UniFi, etc that
   phone out to a site via DHCP option or otherwise.
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.
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.
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.
   As a usenet operator, this baffled me as they had insufficient memory, storage
   etc to do this task, and left security surface quite wide.

   We must promote secure by default.  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.
6) Devices need to prompt for updates.

   Apple has sorted this nicely, people are prompted for supported upgrades, disjoint
   from carriers and other issues.  Contrast this with other ecosystems where upgrades
   require extra steps or have a non-OEM partner involved (eg: Cell Carrier, Cable Co).

   These devices get less frequent updates, ostensibly for testing but also leave known
   issues exposed for months or years.
7) Malware can damage systems making them require extra steps to recover them.  Whitehats
   may know some mitigation techniques, but can’t protect you either.  Some people have
   taken a more aggressive approach, eg: https://gitlab.com/rav7teif/linux.wifatch

   They will block others from infecting your device until it’s rebooted.

- Jared

> On Oct 24, 2016, at 4:24 PM, Ronald F. Guilmette <rfg () tristatelogic com> wrote:
>
>
> In message <e364fcea-7105-b3b9-63a9-7d22ab83516c () nuclearfallout net>, 
> John Weekes <jw () nuclearfallout net> wrote:
>
> > On 10/23/2016 4:19 PM, Ronald F. Guilmette wrote:
> jw>>> ... The ISPs behind those IP addresses have
> jw>>> received notifications via email...
> rfg>> Just curious... How well is that working out?
> > For the IoT botnets, most of the emails are ignored or rejected, because 
> > most go to providers who either quietly bitbucket them or flat-out 
> > reject all abuse emails. Most emails sent to mainland China, for 
> > instance, are in that category (Hong Kong ISPs are somewhat better)...
>
> So, given the apparently impracticality of trying to clean up all of these
> kinds of messes via the good old-fashioned tedious and laborious method
> of emailing the relevant providers and then just sort-of vaguely hoping
> that they will -do something- responsible with it, I am just sitting here
> trying to dream up some sort of generalized long-term fix for -all- of
> these IoT DDoS type problems.
>
> Maybe there just plain isn't any such thing as a general solution to the
> problem, because it may perhaps be just technically too complex.  But I hope
> no one will begrudge me if I yearn for some sort of Grand Unified Field
> Theory of IoT security.
>
> So, I have a thought... probably worth what you paid for it... and I'm just
> brave enough to throw it out on the table and then everybody can pile on
> and tell me what an idiot I am, for this or that perfectly sound technical
> reason.  (I'll say up front that I don't even pretend to understand many
> of the protocols in use these days, in particular UPnP, and to be frank,
> I'd never even heard of SSDP until yesterday.  So I can't and won't begrudge
> anybody who tells me that I have my head up... ummm... in the clouds.)
>
> So anyway, here are the assumptions/assertions, perhaps wrong, which are my
> starting point:
>
>    1)  I am not persuaded that IoT devices have a compelling need to them-
>        selves initiate outbound TCP sessions, ever.  (If I'm wrong about
>        this, then I'm sure people here will tell me.)
>
>    2)  Likewise, I am not persuaded that IoT devices have an absolute and
>        compelling need to do very much in the way of UDP.  Yes, I would
>        like my smart XYZ device to always know what time it is, so, you
>        know, a modest amount of NTP traffic is reasonable and to be expected.
>        Other than that however, I don't see a compelling need.  If you want
>        to either control or get data out of your IoT device, you can make
>        an inbound TCP connection to it.
>
>        (Somebody will probably say "Oh, no.  We need to stream real-time
>        video out of some of these things, and for that we absolutely have
>        to send the stuff via outbound high-bandwidth UDP." but I am not
>        persuaded that this is either absolutely necessary or even Good,
>        i.e. from the point of view of the legitimate security concerns of
>        the owner of the device.)
>
> So, based on the above perhaps flawed assumptions, here is my idea.  It is
> composed of two simple parts:
>
>   1)  First, I will successfully complete my campaign to be elected King
>       of the World.  (Given the current poltical climate, worldwide, this
>       should not be a problem, because I lie a lot.)
>
>   2) Second, once elected I will decree that in future all new IoT devices,
>      and also all updates to firmware for existing IoT devices will have,
>      BUILT IN TO THE KERNEL, code/logic which (a) prevents all outbound TCP
>      session initiation and which also (b) strictly rate-limits all other
>      protocols to some modest value.
>
> Remember, we're going to have a few billion of these devices online in the
> coming years.  If even and modest subset of these can ever be tricked by an
> attacker into spewing non-rate-controlled traffic towards an attacker-
> selected target, then we're gonna have a problem.
>
>
> Regards,
> rfg