Secure Boot Could Eliminate Botnets - But Manufacturers Ignore It

I'm not sure but I don't think the latest attack could be prevented this way. The problem was that Mirai gained access to the cameras using default username and passwords.

Itamar -

Mirai (and generally any other botnet) does two things to take over a device:

1. Gain root or admin-level access to a device (this could be using a shell, like Mirai did, or through web UI exploitation)
2. Download/install the actual malware that can be used to enable remote botnet control, and to add capabilities that the device might not have by default (like the ability to create/control raw sockets)

You can make a device much more secure simply by changing default credentials, and doing other things to limit network access, but there are still risks.

Secure boot/SOE handles the second half of the above, it prevents unauthorized software from executing. So even if someone gained access to your device, they could not load and run botnet software.

Mirai could not work if EITHER of the above two security issues were addressed.

Point #1 is mostly in the hands of the user/installer to address, manufacturers can only do so much in the sense of enforcing strong passwords, and doing this comes with trade offs in increased support costs, etc.

Point #2 though is under the control of the manufacturer, they can implement a secure operating environment that helps protect devices that are poorly configured. It also helps to protect against other exploits that may be found, hackers might find a way to gain shell access, but if the cannot do very much with that shell, it makes the device less valuable and the hack less risky to their customers (though they would still have a duty to fix the discovered exploit).

#1 - most of the OS's and applications are just being pirated and copied by so many manufacturers that they just don't know how to safely alter them.

#2 - "though sometimes for a slight additional cost compared to lower-end chips" this shoots it down immediately.  These companies are doing everything they can to save every penny, they refuse to do anything that will increase the cost at all.

For multiple reasons, I would not expect manufacturers that are solely focused on cost to do much with secure boot. No matter how you choose to approach it, security is expensive (relative to doing nothing or bare minimums). But I think there are other manufacturers, not targeting the budget buyers, who do their own firmware and OS modifications and have the resources to implement this, and sell/market it in a way that justifies the expense.

In multiple places I have seen feedback that people think cyber security issues are going to continue to be a big concern in 2017. A manufacturer that implemented secure boot, and had a decent bug bounty program (inviting people to discover and report weaknesses) could gain a significant edge by promoting themselves as the "most secure" platform, justifying a higher price and differentiating themselves from others.

#2, would secure boot have stopped the Axis critical vulnerability?

Rootkits run at the BIOS level and can hide their presence in some ways, which makes it easy for them to re-infect the target in case someone removes the malware or factory defaults the unit (which probably isn't deep enough to touch/clean the BIOS).

BIOS is for PCs, do you mean bootloader?  

The vast majority of botnet clients do not require that level of infection, and I imagine it's very hard to accomplish a rootkit level infection on an IoT device without physical access. Unless of course the BIOS supports kicking off updates from the OS.

Installing a rootkit is simple once you get in as root, with local access or remote access.

maybe I'm just being pedantic, but the opening just seems flippant.

 

First, I appreciate the feedback.  The opening was to meant to mirror what I think is a common question that people might have upon learning about secure operating environment options, "if it's possible, why aren't manufacturers doing it?" The answer, of course is because it is not just as simple as turning something on, but that does not mean it should not be considered an option to combating cyber security issues.

The purpose of this post was to call more attention to alternate ways to secure devices, and that the task does not need to fall solely to the user or integrator.

Yes, there is effort involved in making devices more secure, and today manufacturers are putting minimal effort into true device security. Secure boot and secure environments already exist, to various degrees, in the PC world. SElinux, as one example, would provide far greater security than what we have now for the internals of most systems.

The userspace problem is somewhat easier to address in embedded devices, where you generally do not have to deal with actual users installing additional software applications. This may complicate things for ACAP, or other cameras that support 3rd party apps, but those are a very very small part of the broader installation base.

Nitpicking aside, do there exist today any OSes that will run only signed code at every level?

The capability exists, but this is where it gets harder to make comparisons between things like Apple's code-signing requirements (for example), and embedded devices. It is possible for a user to turn off signed-code requirements in desktop OSes, because there are just too many apps and use-cases out there. But an embedded camera could be set to only run manufacturer-signed code, if the full stack (Secure boot, secure kernel, etc.) was all implemented.

...but merely signing something does not also encrypt it, which is the point I was making.

My point was only that if you do encrypt the firmware you have the same challenges of authenticity that signing has.  UEFI is a solution, but I'm not sure there is a viable Linux busybox port out there yet.