This week, it’s been revealed that a massive botnet made up substantially of hacked IoT devices was responsible for attacking a top tier service provider, and taking a whole collection of major websites down for a long period of time.
https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/
What’s particularly shocking though, is that these devices weren’t what you’d normally consider “hacked” – as in, they weren’t taken over by exploiting a bug that stops an otherwise good design from keeping bad guys out. They were taken over by a simple program that had a simple list of known user/password combinations, and all it had to do was attempt to login to the right devices as a known hard-coded user with administrative privileges, install itself, and go from there. These devices had security that was entirely broken by design. Or lack of design.
Linux is becoming bigger and bigger in the embedded devices world. As processing power gets cheaper and faster, it becomes very handy to be able to take a working operating system, and all the services and capabilities it gives you for free. Drop it onto your hardware, then build your product on top of that.
Linux gives an intelligent embedded product an awful lot for free. The problem is, it gives far too much.
Think, for a minute, about what kinds of features a simple IP security camera might have. You’d expect it would have some means of identifying the product on a local network (ZeroConf/bonjour, uPnP, etc) and a simple web server linked to the internal application settings that could authenticate a special kind of web user, then serve pages of settings, and receive settings changes back, then have those settings change the behaviour of the product as required.
You wouldn’t expect it should have the ability to allow an SSH session as a system level user with administrative privileges from anywhere that can reach it.
The reason there are so many IP cameras and similar in the world with this kind of feature, is that Linux by default has this feature enabled. It’s not that someone thought that it’d be great for all their products to accept user logins on system user accounts that can do anything to the system at all (actually it’s great for the development phase, it lets you run and debug code on the target while you develop and compile on a normal computer) But nobody thought to turn it off before releasing a product that sold millions of units.
People were focusing on what the product needed to do, but not focusing on what it needed to not do.
This is enough of a problem in products that don’t run a general purpose OS. You can have all sorts of bad things happening to an embedded product if nobody thought about what it might do under unusual circumstances. But on a full blown general purpose OS, failing to consider the behaviour from this perspective is crazy. Because a full blown general purpose OS allows so much more than your average embedded product needs to or should be able to do.
And so, now we have a rampaging army of IP security cameras taking down twitter. Or anything else the botnet’s owners decide to target.
If something good can come of this, it’ll be a discussion about what kind of security consumers should expect from digital networked electronics. It’s not OK to sell you a product that burns your house down, or sell you a product that ruins your phone or TV reception. It should be just as not OK to sell a product that allows theft of a person’s personal data (and really, if you have a remotely operated computer on your home network controlled by hackers, Twitter breaking for a day is the least of your problems)
I hope that people will come together and start to implement industry level standards based on protecting privacy and enabling security for internet connected hardware. And that tools can be made available to test anything to these standards, so that bad manufacturers are quickly identified and stopped before they can put a million more unprotected future attack bots on the internet.
We need to catch this problem before governments step in, and end up legislating a whole new tier of globally inconsistent, unwieldy, and expensive legislative compliance requirements – drafted by entrenched companies who will use the exercise as a means to stifle competition rather than protect people from bad products.
Well written article with a strong conclusion.
thanks Bruce! The frustrating thing is, it’s all very possible to do right. I’ve been involved in a few projects now where we built a linux device, but always had the intention from the very start go back and pull out all the services and capabilities that weren’t needed… (the other special issue with embedded linux is making sure you have a means to patch actual bugs in the OS and networking stack as they are discovered.. but just doing this first also means you’ll have less ongoing bugs being critical issues as cutting down the number of interfaces your product has greatly shrinks the attack surface that’s available to exploit any future bugs too)