Bootloader ********
**** * ****** **** ** ********* system (**** * ****** ** ***/***) powers **, ** ***** ******** ********** code, ***** ** *********** *** ******* things **** ******* ******* *** ******* interfaces, ******* ** * ************** **** with ***** **********, *** **** ******* off *** ****** ********* ****** **** process. ********** **** ** **********, **** like ****** ********, *** ** **** cases * ****** **** ****** ********** code ******* *** ******* ************ ** authorization.
Secure ****
** * ****** **** ******, *** manufacturer ***** * ****** ********** *** into *** *********, *** *** ********* will **** ******* * ********** **** a ******** ***. **** ******** ******* from ********* *** ********** **** **** malicious **** **** ***** ** **** to ********** *** ******.
** *** ** **** ******/******** **********, the ********* ****** ***** ** ********** to **** *** ** ** ********** the **********, *** ***** **** ******* any ********** ************ ** ** ********* signed. ** *********** **** *** *** properly ****** ***** *** ** ********** by *** ********* ******.
* **** ****** **** ************** ******* that *** **********, ********* ******, *** any ********** ******** (**** ** *** components **** ****** ***** ********* ** a *** *********) *** *** ******** by *** ************ ** ***** *********. This ***-**-*** ************ ** **** ** often ******** ** ** * "****** Operating ***********" (***).
***** *** ********* **** ***** *********** forms ** ****** **** *** ** SOE ** ****** ***** ** * way ** **** ****** ******* ********* their ********.
Supported ** **** *************
********** *************,*****/*********** ******** *** ********* **** **** have ***** ********* ** *** ******** market **** ******* ****** ****, ****** none **** ** ************* ***** *** feature ** ******** ** *** **.
Secure **** / *** *****
****** **** ******** * *********/*** **** proper *******, ***** **** ************* ** these ********** **** ** ***** ******, though ********* *** * ****** ********** cost ******** ** *****-*** *****.
*** **** ***** ** ************** **** from ********** *********** **** ****** ** implement ****** ****/***. **** *** ******* heavily ********* ****-****** ****, **** *** things **** ******** ***** *******, ** support *** ****** *********** - **** effort **** ****** ********** ***** ******* to *******-********* ********. ************ ** *** can **** **** ** **** ********* to ******* ***** ***** **********, ** Axis **** ********.
Malware *** ***
************ * ****** ********* *********** ***** make ** ********* ********* *** ** attacker ** **** *** ******* ******* on *** ******. ** ** ** they ***** **** ** **** *** encryption *** *** ************ **** ** sign ***** ********, *** **********, *** highly ******** *** **** ******.
Not * ***-***
*** *** ******** *** ****** ** implementing ****** ****/***, **** ********* ***** still ***** ********* ** **** ****** to * ******, *** **** ***** be ******* ** **** ********** ********* that *** ************ *******. **** ***** still ***** * ****** ******** ** see *****, *********** ****** ************* ********, or **** ***** * ****** ** factory ********. *** **** ******, ****** passwords *** ****** ******* ******** *** still ****** **** ******* ******* ******.
* ****** ***** **** ***** **** exploitable **** ** ***** ****** ***** that ******* ********* ** ***** ***** with *** ******, *** ******* **** would ** ****** ** ****/******* ********* code *** ****** ***** ** **** more ********* **. ** ******** ***********.
Comments (47)
Marcelo Martinez
12/29/16 01:45pm
100% agree!
Create New Topic
Itamar Kerbel
As you wrote secure boot is only one way to protect a camera.
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.
I think the manufacturers think that first they need to solve the simple ways that malware get hold of a camera and only then handle the more sophisticated methods.
As all/most of the cameras use Linux as the camera OS it a little more difficult to create and maintain a secure boot but since there are already examples of how to do it out there I think its worth the effort.
More on secure boot and Linux can be found here: How Secure Boot Works on Windows 8 and 10, and What It Means for Linux
Create New Topic
Undisclosed Distributor #1
This would be a fantastic solution if implemented properly. There are a few flaws in doing so in our current world though. #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. This is why a list of 63 username/passwords were able to get into so many different devices, they were all using pretty much the same version of Busybox Linux that the manufacturers didn't know how to safely modify or just didn't want to. #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.
We (the professionals that use IPVM as a great industry reference tool) would love these changes, but unfortunately the manufacturers care more about just getting every single penny and if it can be done with cheaper parts and insecure software then so be it. They will suffer no consequences from these botnets other than an uncomfortable week or two of bad press and then it's back to normal.
Create New Topic
Undisclosed Distributor #1
I 100% agree with you on this. Unfortunately most of the "security" industry these days just wants the cheapest and easiest products to slap into a home/small business so they can get their check and hopefully never hear from the customer again until they want to buy another $10 camera. The true security professionals will try to guide customers and provide them with the best solution possible, but this costs more and in the current disposable, Walmart world we live in, the vast majority just wants cheap and quick which falls right into these manufacturers ball parks. Sorry for the cynicism, hasn't been the best year in the industry as I'm sure most of you are also suffering with.
Create New Topic
Itamar Kerbel
We have a branch here of a major US telecommunication company.
They are upgrading the cctv system in the building.
We offered them Tiandy cameras. They got back to us saying that the security check they did not approve Chinese cameras.
We offered them avigilon as the new avigilon cameras (h4) offer encrypted data communication between the camera and the nvr.
They got back to us after a few days saying that if we can close port 23 (telnet) in Tiandy they will be approved....
Money talks....
Create New Topic
Undisclosed End User #2
Interesting stuff, but I think that's more like "take care of the symptoms (can/have been cracked) instead of take care of the cause of symptoms (proper coding w/o vulnerabilities)".
Create New Topic
Undisclosed End User #2
That's true, it's possible to tamper the boot loader code to first load some other hidden code somewhere in the flash and then jump back, nothing new in that behaviour. (That's one way, which been used for ages by viruses)
When it comes to the name "secure boot", my reflection is that we talking about "securely" booting up the the device, not what's running after boot in user mode. I'm thinking of how the manufacture can/will "approve legal applications". Would be interesting to find out more about this.
Usually, when upgrading the FW, the boot loader will also be upgraded in most cases, so I don't see that as big issue.
Create New Topic
Josh Hendricks
12/30/16 04:46am
I could be wrong but I was under the impression this technology was only effective in preventing rootkit-level infection.
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).
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.
If I'm not wrong (I'm only feeling 50% here), then there would be little to no value in implementing secure boot with regard to the standard level of attacks out there including Mirai.
However, if I were sourcing equipment for a government or other high security project, I would prefer to use SOE-enabled devices as it would potentially protect against APT's or advanced persistent threats. I imagine nearly all APT's are carefully designed and implemented and are in a different classification from the "script kiddie" stuff usually seen.
If I'm wrong and the signature used by SOE is somehow based on the OS drive(s), such that any changes to key areas of the filesystem would invalidate the signature check, then this would be a beautiful way to lock down IoT devices. I think this would be fairly far-fetched though.
At the OS level, I'm sure linux has the same ability to deny running "unsigned" code considering Windows already does this to prevent unsigned device drivers from being installed. Linux probably had this feature first. It seems like configuring the linux to execute only code signed by a shortlist of keys would be the best bet.
If manufacturers were to do this, then the only ways to accomplish remote code execution would be to either steal the private key from the manufacturer so you can sign your infectious code, or to discover a flaw in the manufacturers proprietary software allowing for remote code execution directly through the manufacturers software/processes.
Create New Topic
Undisclosed Integrator #4
"why do manufacturers not enable it?" severely understates the effort that would be required for this. Signed bootloaders, kernels, and even kernel modules? Sure, that's already well-developed. But userspace? In Linux, at least, that's still a whole lot more than just something to be "enabled".
See: https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
Sure it's clarified later with "The main costs of implementation come from additional development work needed to implement Secure Boot/SOE. This can require heavily modifying open-source code", and maybe I'm just being pedantic, but the opening just seems flippant.
Nitpicking aside, do there exist today any OSes that will run only signed code at every level? Genuinely curious.
Create New Topic
Paul Curran
Wasn't some of the security issues found recently down to people reverse engineering the firmware to find hard coded accounts and passwords. To what extent does secure code limit this? Would the user set admin account (which is forcibly set at first boot to a unique identifier) be the encryption key for secure boot?
Create New Topic
Undisclosed Integrator #4
Sure, strictly speaking, but merely signing something does not also encrypt it, which is the point I was making. And yes, you do need a root of trust, but these are all things that experts have been working on for a very long time:
http://www.uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20(003).pdf
http://www.uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_Final.pdf
https://www.sans.org/reading-room/whitepapers/analyst/implementing-hardware-roots-trust-trusted-platform-module-age-35070
(Edit: This didn't link to the replied-to comment for some reason, so here's that)
Create New Topic
Undisclosed End User #2
Yup, I actually find the same
Create New Topic
Brian Karas
This is not an exact parallel to security cameras, but Google's custom security chips show some insight into how Google handles security and authentication on its servers. It is an interesting read for anyone interested in these topics.
Create New Topic