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?

The whole signed code angle could potentially be further secured by requiring cert transparency such that any newly added executable, even if signed by a valid/trusted cert, would have to be audited the first time by checking with the manufactures cert log server. That would block against threats where the private key is compromised, and potentially even be an early warning system for the manufacturer (if any valid certificate is audited and found never to have been issued, you may want to revoke that certificate).

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.

As well, even secure boot isn't a fix-all (as nothing ever can be):

https://www.youtube.com/watch?v=QDSlWa9xQuA

http://www.c7zero.info/stuff/DEFCON22-BIOSAttacks.pdf

http://www.ghacks.net/2016/08/10/secure-boot-bypass-revealed/

Still specifically in the UEFI world, sure, but the principle stands. I do agree that embedded device manufacturers need to keep up with the cat/mouse game, but I'm not hopeful that they'll ever care to--especially in the middle of a race to the bottom.

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.

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

iOS

Paul -

With secure boot the firmware would generally be encrypted. Granted, any encryption can (theoretically) be broken, but done right it would be very low odds that secure boot firmware would be easily examined.

Still, if that did happen, an attacker could learn default account credentials, and find other exploits in the firmware, but would be more limited in what they could do with that data, as they could not load/run additional software, they could only leverage what the manufacturer had already built into the firmware.

The encryption keys are set by the manufacturer, and are not otherwise publicized or controllable by the end user, so it is not tied to admin passwords or things like that.

Part of the assumption with a secure boot implementation is that the manufacturers are actually trying to make things more secure. They would likely (hopefully) not go through all the effort of implementing secure boot, and then leave telnet open (or leave an easily launched telnet backdoor), but that is technically possible.

I do not mean to imply that secure boot is a 100% fix for things like Mirai, but it would go a long way in making devices less exploitable, and making any found exploits less powerful, as well as instill more trust/confidence in users (for the users that care, many still do not give a crap about security ;) ).

...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.