Syndicate

You are here

Our routers need to remove the "internet" from the "internet of things" to stop DDOS

I frequently say that there is no "internet of things." That's a marketing phrase for now. You can't go buy a "thing" and plug it into the "internet of things." IoT is still interesting because underneath the name is a real revolution from the way that computing, sensing and communications are getting cheaper, smaller and using less power. New communications protocols are also doing interesting things.

We learned a lesson on Friday though, about why using the word "internet" is its own mistake. The internet -- one of the world's greatest inventions -- was created as a network of networks where anything could talk to anything, and it was useful for this to happen. Later, for various reasons, we moved to putting most devices behind NATs and firewalls to diminish this vision, but the core idea remains.

Attackers on Friday made use of growing collection of low cost IoT devices with low security to mount a DDOS attack on DYN's domain name servers, shutting off name lookup for some big sites. While not the only source of the attack, a lot of attention has come to certain Chinese brands of IP based security cameras and baby monitors. To make them easy to use, they are designed with very poor security, and as a result they can be hijacked and put into botnets to do DDOS -- recruiting a million vulnerable computers to all overload some internet site or service at once.

Most applications for small embedded systems -- the old and less catchy name of the "internet of things" -- aren't at all in line with the internet concept. They have no need or desire to be able to talk to the whole world the way your phone, laptop or web server do. They only need to talk to other local devices, and sometimes to cloud servers from their vendor. We are going to see billions of these devices connected to our networks in the coming years, perhaps hundreds of billions. They are going to be designed by thousands of vendors. They are going to be cheap and not that well made. They are not going to be secure, and little we can do will change that. Even efforts to make punishments for vendors of insecure devices won't change that.

So here's an alternative; a long term plan for our routers and gateways to take the internet out of IoT.

Our routers should understand that two different classes of devices will connect to them. The regular devices, like phones and laptops, should connect to the internet as we expect today. There should also be a way to know that the connecting devices does not want regular internet access, and not to give it. One way to do that is for the devices to know about this, and to convey how much access they need when they first connect. One proposal for this is my friend Eliot Lear's MUD proposal. Unfortunately, we can't count on devices to do this. We must limit stupid devices and old devices too.

I suggest that each gateway box have (at least) 2 ways of authenticating to it. This could mean two SSIDs for a wireless box (Such as bradhouse and bradhouseIoT) or two different passwords for the same SSID. Since simple IoT devices don't tend to have keyboards or UIs, they often associate with networks using one of the Wi-Fi Protected Setup protocols. As such, the box needs to have two different WPS buttons (or understand click and double-click on the button) for the different classes of devices.

When a device connects as a non-internet (ie. IoT) device, it will start out with full connectivity. But after some time, it will be restricted to only accessing local networks and the networks it tried to access (by name or IP ) during its early operation. That means the camera that asks its home host for software updates or cloud configuration can continue to talk to that host forever, but after a day or two it can't talk to other external hosts. It is much harder to use in a DDOS.

This presents some risks. Some devices might fail under these rules. If they do, the owner would have to go to the config for their gateway and add some customization, or reconnect the device to the full internet (with associated risks.) Devices would also be able to talk to addresses that tried to talk to them, or to addresses they were introduced to by one of the early addresses through an introduction protocol. For example, if you want your camera to be able to stream video directly to your phone, your phone would have to talk to the cloud server, which would then need a way to inform the gateway it is OK to talk to the phone. This can be troublesome through NAT, though there are existing protocols, like STUN, which might be adapted to this -- if the gateway sees a magic packet from the phone on just the right port, it could open up that path, for example.

Security holes

There are also a few attacks that are still possible under this regime. Several occur if the IoT device is able to change its ethernet MAC in software. Otherwise a compromised device will do that, and pretend to be a brand new device able to talk to anywhere. Or it might pretend to be a known and trusted device, though we could improve the encryption protocols we use to prevent that. We could constrain "new" devices on their volume of upstream requests, though that might break some things.

If an attacker is able to compromise the DNS service of the IoT's cloud server, they could point that domain at their target, and all the devices could then attack that target. For example, if the attacker can take over the cloudcamera.com domain service, it could point that at twitter, and all the cloud cameras would be allowed to attack twitter. This makes the attack more expensive, particularly if there are multiple brands of devices in the botnet.

Over time, it is hoped that makers of devices would become more aware of these problems. They would design their devices to not break under these constraints, or use a system like MUD. They would secure their domain servers or be ready to have them taken down in the event of attack. (Attacks that can be switched off at a single point are much less powerful.)

Open networks (like in coffee shops or friendly houses) can't be protected in this way. Let's hope not too many devices are on these networks.

Hopefully these attacks will also teach people about how firewalls and NAT do not protect very much. If you plug a lot of devices into your network and they are vulnerable, then the more general purpose devices like your laptop or phone are vulnerable like they were on the open internet. We should not forget that.

This also is not a quick solution. You need new firmware on all the gateways that have a lot of devices. But that's easier than securing all the devices.

Readers: What other behaviours by these IoT devices would get broken if they lose full net access after a few days? What other ways do you see that attackers could still build their DDOS botnets under this regime?

I may have learned something new. AFAIK the Mac address of a NIC is invariant and not subject to software change. But even if you did change it wouldn't a firewall based on disallowing connectivity for everything except a given set of MACs anyway and even those limited to a specific set of ports and/or protocols?

Why would most IOT devices even be on normal internet? That is a costly wifi radio connection for leaf devices to maintain for many proposed devices.

Devices can't be very useful in a botnet if they don't have a fairly general CPU and only have outgoing connections to phone home - not an ability to send HTML request to random addresses if any at all. I can see why people would want an internet webcam they can reach from work or wherever. But of what user would it be for the camera to send outgoing web requests? I am scratching my head over such a 'feature'.

If these devices are on home LANs then given that most home internet in the US has no static IP the home router seems implicated as the attack vector unless as you mention the device host itself was hacked.

Ah, I begin to see the light. ISP practice lack of home server means the device has to push up to its control hub for instructions. So maybe if that push up was compromised to instead push requests to some other attacked address?

Many ethernet controllers let you set the MAC in software. I don't know how common that is in IoT devices.

If a device can set its own MAC it can pretend to be a device which has full-internet access, or it can at the very least declare it to be a "new" device which temporarily is allowed access to a small set of devices in its "first" day, which would be the networks it wishes to DDOS.

If you actually use two auth methods (different passwords) that stops the device from pretending to be a blessed device. If you auth with properly done WPS you could prevent new macs from doing anything until they are associated with WPS.

The problem is lots of these devices run linux, almost all have general purpose CPUs. Surprisingly many devices on on external addresses, but even ones behind NAT and firewall are not safe. Those are not very good protection.