Much has been written about how DDoS attack on Dyn was made possible by a security hole present in various internet of Things (ioT) devices. The lingering question is: how do we prevent this from happening again?
This is tough to answer. First, I don’t have any idea whether or not my webcam participated in this attack. Chances are you don’t know if yours did, either.
Second, there’s no reasonable way for me to go in and secure my webcam so that it’s unable to participate in this type of attack in the future. The security hole used by the exploit is baked into the core functionality of the embedded operating system that my webcam’s manufacturer sourced from China. There’s a good chance that even the company who made my webcam was completely unaware that this security hole existed.
We Can’t Rely On Users … or HomeKit
Even if we could fix this one security hole on every affected device – and it’s important to note that we cannot – what about the similar holes that exist in your printer, DVR, doorbell or thermostat? The reality is these exploitable devices are going to exist in the homes of enough general consumers that we need to assume everyone’s house is compromised and will remain that way for a good, long time. Apple’s very-secure HomeKit protocol makes it extremely difficult to hack HomeKit data, but doesn’t stop these devices from being exploitable in other ways.
Every Router, a Speed Bump for DDOS Botnet Attacks
For this, I look to router manufacturers. The problem with a DDoS attack is that it’s really difficult for the servers being attacked to separate good traffic from bad. Routers, however, have a lot more information about the device initiating the request.
Any decent home router these days uses Quality of Service (QoS) algorithms to manage traffic (ahem, Apple, you need to catch up here). That means your router is (or should be) examining every single packet coming in and out of your home, making sure it properly prioritizes the important ones to ensure a smooth internet experience for you.
Router manufacturers could enhance their QoS algorithms to look for devices like webcams that start performing requests atypical for that type of device. For most routers this truly could be a simple firmware update. Today’s routers (including Apple’s) have CPUs that are fast enough to process this type of on-the-fly analysis if the right firmware is installed.
Additionally, router manufacturers like NETGEAR, eero and others have QoS and parental control databases that auto-update to account for new devices and services. Those database updates could also include the addresses of servers being attacked. As soon as Dyn saw they were being targeted, they could have asked router manufacturers to add their addresses to the database and push out an update.
Just Slow Them Down Until It’s Not Fun Anymore
The point isn’t to completely stop these types of attacks – that would be nice, just reasonably impossible – rather to limit the impact of any such attack. If a large-enough percentage of consumers were using routers that automatically limited this type of activity, a lot of the benefit for attackers would be lost.
Yes, there’s definitely a cat-and-mouse scenario here where attackers will work to circumvent these in-router blocks, but I think it would be a very good start. Right now the mouse is blind and immobile and the cat is having a field day.
Router manufacturers, the ball is in your court, but we’re all here to support the process.
Indeed. The beauty of the Internet is – unsurprisingly – its Achilles heel. Daren Kitchen suggested an interesting idea (Daily Tech News Show, ep 2884): distributed DNS. Something using the blockchain and bittorrent tech.
But I guess that requires “redoing” basic piping of the Internet which cannot be easy. What do you guys think about that?
I don’t pretend to be a security expert, but a simplified version of how this might work. When the device connects to the router the router determines it is a XYZ Inc device (via MAC Address, etc) and therefore could know which IP addresses to whitelist for devices by that manufacturer. Any traffic sent to a non white listed address would be considered suspect.
I know there are nuances to this, but I’m thumb typing and don’t want to make this too long.
Where did I state that? I’ve done a lot of research into HomeKit. HomeKit ensures that HomeKit transmissions are encrypted in a very secure way (so much so that many ioT CPUs can’t handle it), but that’s it. Unfortunately, Apple doesn’t have the leverage to force companies to adopt only HomeKit. Most manufacturers are building for other, more popular (and, by default, more open) platforms first and then adding HomeKit as a secondary feature.
Again, HomeKit is very secure within its own ecosystem, but devices can and are built to support multiple platforms simultaneously. Any security holes inherent in those platforms remain open.
For sure. That’s why a router is perfectly suited to sniff out these types of things. It’s not about the bandwidth at all, it’s about the type and frequency of the requests. If your webcam suddenly starts doing a multitude of requests to the same, non-local, DNS server, well, then that could raise a flag. Corporate firewalls do this kind of thing all the time. It would be quite possible to build that filtering/sniffing functionality into many existing home routers, too.
That’s definitely something that will help. The thing is that, as @Alphaman stated, most of that is already happening by default with NAT. The problem is that many devices intentionally open incoming ports so that their services are available from the outside world. Webcams are a target specifically because of this. NAS devices, too. Closing off ports would limit their functionality, and that’s why we need another solution.
HomeKit could be that solution, but only if that’s the lone protocol a device supports. I think we’re a long ways off from that being a reality, if ever.
This is a good discussion. Thanks for poking and prodding at this, guys. With all the chatter about the recent DDoS attacks there hasn’t been enough of the “and how do we prevent this in the future?” dialog. I’m glad we’re having it here.
Dave,
The trick with a DDoS is to leverage a small amount of data into a huge amount of replies. Or, to paraphrase Patton, “No zombie ever won a war by dying for his cause, but by making the server die for his.” A zombie sends a tiny little request, perhaps as small as a single packet, but for a LARGE amount of data. The zombie can send thousands of such requests, and barely move the bandwidth needle. The server, OTOH, tries to reply with potentially hundreds of Kbytes or even megabytes of data in response to that one packet request. That is what kills the servers and clogs the networks.
A bandwidth filter on the zombie won’t see the response, either, because often the reply is sent someplace completely different. That’s the ugly beauty of the zombie army…
Cheers,
Aaron
Are you sure? You stated that you were unsure of the requirements of HomeKit approval but then state that it WILL NOT keep you safe! Might not keep you safe, or will not ensure your total safety, might be better ways but I’m willing to bet as part of HomeKit certification, Apple requires certain privileges be locked down which would have stopped this attack.
I understand that NOTHING is unhackable, but with so much low hanging fruit I would go out on a lim and say that HomeKit devices are far more hardened for security, and until you get confirmation of vulnerabilities, you might want to tone down your statements..
Also, I agree with the other reader that locking down incoming ports is a far better way to protect against these attacks.
That’s why we need all routers to be a part of this (or at least a large-enough percentage of them). If the protection is Distributed, then we can stop these things.
Interesting idea, but the issue with a DDoS is the first D — distributed. Any one device doesn’t have to contribute much to the deluge for it to become part of the flood, and throttling it using QoS won’t really accomplish much different than what the attacked site can already handle.
The real thing that a home router can do that it’s already doing, is prevent the backdoors in these devices from talking to the Internet. When a compromised device is placed directly on the Internet, it puts us all at risk. But, if the ports that make up the backdoor are blocked (in this case, ports 22/SSH and 23/telnet), the black-hats simply can’t get to them, and they are denied that zombie.
Want to check to see if your device was part of the zombie army? Try to telnet or ssh to your device from outside your network. This will only be allowed if you have that device defined as your DMZ host or if you have mapped either of the 2 ports above to your external IP address. If your router’s firewall has those ports blocked, or if your device simply doesn’t have those ports open (use Network Utility on your Mac to do a port scan of your webcam for 22 to 23), you’re not part of the problem. (For the curious reader, you can find the list of usernames and passwords used at https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/).
In the future, you should also consider blocking any other ports to those devices or using a non-standard port mapping to get to them (I’m looking at you, port 80.) But don’t presume that this is sufficient (quick, how many people use port 8080 to map http traffic? Yeah, I thought so… That’s an easy enough test for any script kiddie to try.) Even better? Only buy devices that have regular firmware updates from vendors that care about the security of their products. Not some mass-produced Chinese back-doored el-cheapo device.
Now, if only Apple made webcams…