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.

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

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.

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