[AusNOG] What are we going to do about IoT (in)security?

[Vijay Sivaraman]

Agree that today’s CPE routers have poor security, and most have UPnP
enabled by default that lets any entity inside punch a hole through the
firewall.

Thanks to SSDP/UPnP, it’s relatively easy for an iPhone malware once
inside your home to scout for IoT devices and expose them to Internet
attacks: "Smart-Phones Attacking Smart-Homes"
(http://www2.ee.unsw.edu.au/~vijay/pubs/conf/16wisec.pdf)

And while it’s at it, it can also expose your household IoT devices as
reflectors for DDoS attacks: “Quantifying the Reflective DDoS A‚ttack
Capability of Household IoT Devices”
(http://www2.ee.unsw.edu.au/~vijay/pubs/conf/17wisec.pdf).

Vijay



On 13/6/17, 2:53 pm, "AusNOG on behalf of Jake Anderson"
<ausnog-bounces at lists.ausnog.net on behalf of yahoo at vapourforge.com> wrote:

>I think the answer is to divorce the internet toothbrush from security
>totally.
>Short of throwing internet toothbrush vendors from other countries in
>jail via black helicopters there is no way you can make them care about
>security.
>They have made the sale, closed the business and started up another one
>before the shipping container has landed.
>
>I think the answer is going to be having the CPE device/modem/router be
>the "gateway" to the home devices.
>The gateway vendor can make a name for themselves as a durable vendor of
>security.
>
>For getting IoT stuff to work the device registers itself with the
>gateway, says what it has and what it can do, then the gateway provides
>the access to/from the public internet for that.
>Critically, no packet from the internet should hit the IoT device
>without being transformed by the gateway.
>IE the gateway will serve up the web page for the toothbrush, then send
>API calls to the toothbrush.
>
>I envisage some kind of discovery protocol that runs when the device is
>plugged in, to register with the gateway, the customers smart phone then
>goes "ping" asking them to accept the device.
>The device gives the gateway some kind of device description "I'm a
>camera, or an air conditioner" something like USB HID/mass storage spec.
>Device gives the gateway a static HTML set with branded images and
>whatever for the gateway to use with magic <?'s> to trigger the actions
>in it's spec so the customer gets a pretty UI when they visit
>"myplace.myisp.net.au"
>(Bonus points for ISP's doing DNS)
>
>The gateway vendor can then provide durable security and updates to
>their devices and protect all the customers toothbrushes.
>It'd also help to some extent stop the requirement for the toothbrush
>vendor to run a server to provide access for end users to devices in
>their home networks. So in 5 years time you can still access your Air
>Conditioner even though the vendor wants you to buy a new one and so
>have shut down the server your AC uses.
>
>
>On 12/06/17 10:31, Mark Delany wrote:
>> It seems that this is a disaster just waiting to happen.
>>
>> If network appliance companies can't get security right, the chances of
>> white-goods manufacturers doing so has got to be even less likely.
>>E.g., the
>> latest model of my electric toothbrush has bluetooth connectivity so
>> Internet access is surely just a step away. Does a toothbrush
>>manufacturer
>> attract top-notch security programmers (yet alone think they need
>>them)? I
>> doubt it.
>>
>> A natural choke point is the residential router/modem. Has any work been
>> done to define the capabilities or profile of such a choke point that
>>might
>> inherently protect IOT devices?
>>
>> Without thinking too hard, I envision a residential router might create
>>a
>> number of local networks that are constrained in certain ways such as no
>> inbound connections, no outbound connections, no cross-device
>>connections,
>> filtered list of external destinations, that sort of thing.
>>
>> Such constraints might be implemented as separate VLANs or wifi
>>networks or
>> both, managed in a user-friendly manner. Something that most modern
>> residential routers could implement today.
>>
>> When a new device is added to the network, the router portal could be
>>used
>> to allow it access and place it in the appropriate VLAN. Address-space
>> management might also work - such as link-local address allocation.
>>Heck, an
>> IoT device might identify itself in some way and the router could
>> automatically spin up the appropriate VLAN and firewall rules without
>>any
>> human intervention.
>>
>>
>> Beyond constraints, there are also service needs. My new AV receiver
>>likes
>> to contact their manufacturer's HQ for an NTP service. That could
>>readily be
>> offered locally rather than opening up wider access. One imagines some
>>sort
>> of local service discovery might work here, such as Bonjour. Again
>>something
>> that most modern routers could implement today with ease.
>>
>> Serendipitously, NBNCo has a list of approved VDSL modems. One wonders
>> whether that could be extended to a list of modems that support an IoT
>> security profile?
>>
>> Sorry about the ramble, but improving IoT security seems like a
>> multi-faceted problem that we can't afford to ignore. Does anyone
>>disagree?
>>
>>
>> Mark.
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>_______________________________________________
>AusNOG mailing list
>AusNOG at lists.ausnog.net
>http://lists.ausnog.net/mailman/listinfo/ausnog