[Owasp_embedded_application_security] Discussion

Aaron Guzman aaron.guzman at owasp.org
Wed Mar 18 21:40:27 UTC 2015


> 1. Cryptographic Signing of firmware required for firmware updating functions
> There are at-least three stages where cryptographic integrity checks on firmware can be made:
> * As firmware updates are downloaded to the device
> * Before firmware updates are applied to the device
> * Before firmware is being executed (during boot)


Great addition Tim

> 3.Modify Busybox to only libraries and functions that are being used. (e.g. take out telnet, perl etc)
> This is a good one. I have often seen developers report that busybox has been secured in this way but all they do is remove the symlinks, best practices should ensure that busybox is compiled without unnecessary functionality!

Symlinks to bash or other interpreters would also be a bad idea with Busybox. 

> 4.Prevent the use of static passwords such as admin/admin or similar variants for service passwords inside the firmware
> I think there are actually two issues here:
> * Prevent use of hard coded passwords (so that compromise one device does not equal to compromising all devices)
> * Prevent the use of weak passwords (such as admin/admin)


Good observation. We should separate or include the weak passwords in a details section.


> 5.Private Keys and passwords should not be stored on the embedded device.
> There are many legitimate uses of private keys and passwords (or password hashes) on embedded devices, can you expand on this?

Ah yes. If a TPM or “secure element” is present, then private keys may be stored in either of the two type of technologies. Limiting access to a TPM or secure element would be the next step. Unless, we are talking about Apple’s HomeKit which only lets iOS access their secure element. 

--
Aaron G
OWASP-LA Board Member
Twitter: @scriptingxss
Linkedin: http://lnkd.in/bds3MgN <http://lnkd.in/bds3MgN>
> On Mar 18, 2015, at 2:25 PM, Tim Sherlock <tbsherlock at gmail.com> wrote:
> 
> Hello Everyone,
> 
> Looks like a great starting point, here are some thoughts:
> 
> 1. Cryptographic Signing of firmware required for firmware updating functions
> There are at-least three stages where cryptographic integrity checks on firmware can be made:
> * As firmware updates are downloaded to the device
> * Before firmware updates are applied to the device
> * Before firmware is being executed (during boot)
> 
> 3.Modify Busybox to only libraries and functions that are being used. (e.g. take out telnet, perl etc)
> This is a good one. I have often seen developers report that busybox has been secured in this way but all they do is remove the symlinks, best practices should ensure that busybox is compiled without unnecessary functionality!
> 
> 4.Prevent the use of static passwords such as admin/admin or similar variants for service passwords inside the firmware
> I think there are actually two issues here:
> * Prevent use of hard coded passwords (so that compromise one device does not equal to compromising all devices)
> * Prevent the use of weak passwords (such as admin/admin)
> 
> 5.Private Keys and passwords should not be stored on the embedded device.
> There are many legitimate uses of private keys and passwords (or password hashes) on embedded devices, can you expand on this?
> 
> Thanks,
> Tim
> 
> 
> On Wed, Mar 18, 2015 at 9:17 AM, Aaron Guzman <aaron.guzman at owasp.org <mailto:aaron.guzman at owasp.org>> wrote:
> Hi Everyone, 
> 
> 
> Thanks to all who have joined within the last week. I have created a google group to collaborate better. 
> 
> https://groups.google.com/a/owasp.org/forum/?hl=en#!forum/embedded-appsec <https://groups.google.com/a/owasp.org/forum/?hl=en#!forum/embedded-appsec>
> 
> 
> Below is a discussion I have started on the google group. If anyone is interested in making additions, please fill free to reply on the google group thread.
> 
> 
> We want to start creating a list of best practices and top risks for embedded technology. Whether we want to keep it at a list of 10 or more, I think it is important that we collaborate and put our embedded experiences together for a reference. It is
> 
> I will start with my list of best practices 
> 
> 
> 1. Cryptographic Signing of firmware required for firmware updating functions
> 2.Verify SSL/TLS Certificates (SSL Pinning) during secure functions to embedded devices. I.E. Firmware updates
> 3.Modify Busybox to only libraries and functions that are being used. (e.g. take out telnet, perl etc)
> 4.Prevent the use of static passwords such as admin/admin or similar variants for service passwords inside the firmware
> 5.Private Keys and passwords should not be stored on the embedded device.
> 6.Protection against memory-corruption vulnerabilities inside firmware functions. (do not use dangerous C functions)
> 7.Update kernel and packages on embedded images to prevent known vulnerabilities
> 
> Maybe one about testing embedded images for ODM backdoors? up for discussion
> 
> 
> Feel free to make additions and discussions around embedded security. I would love to have a call in the coming weeks to flesh out and make a best practice list mature.
> 
> 
> thanks again!
> 
> --
> Aaron G
> OWASP-LA Board Member
> Twitter: @scriptingxss
> Linkedin: http://lnkd.in/bds3MgN <http://lnkd.in/bds3MgN>
> 
> _______________________________________________
> Owasp_embedded_application_security mailing list
> Owasp_embedded_application_security at lists.owasp.org <mailto:Owasp_embedded_application_security at lists.owasp.org>
> https://lists.owasp.org/mailman/listinfo/owasp_embedded_application_security <https://lists.owasp.org/mailman/listinfo/owasp_embedded_application_security>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_embedded_application_security/attachments/20150318/2a519845/attachment-0001.html>


More information about the Owasp_embedded_application_security mailing list