This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Embedded Application Security"

From OWASP
Jump to: navigation, search
(Main)
 
(87 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
<div style="width:100%;height:100px;border:0,margin:0;overflow: hidden;">[[File:Incubator_big.jpg|link=OWASP_Project_Stages#tab=Incubator_Projects]]</div>
 
<div style="width:100%;height:100px;border:0,margin:0;overflow: hidden;">[[File:Incubator_big.jpg|link=OWASP_Project_Stages#tab=Incubator_Projects]]</div>
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
  
 
==OWASP Embedded Application Security Project ==
 
==OWASP Embedded Application Security Project ==
  
Each year, the number of enterprise and consumer devices with embedded software are on the rise. Given the publicity with IoT and more devices becoming network connected, it is essential to create secure coding guidelines for embedded software. Embedded Application Security is not often a high priority for embedded devices such as Routers, Managed Switches, IoT devices, and even ATM Kiosks. There are many challenges in the embedded field including ODM supply chain, limited memory, a small stack, and the challenge of pushing firmware updates securely to an endpoint.
+
Every year the prevalent use of embedded software within enterprise and consumer devices continues to rise exponentially. With widespread publicity of the Internet of Things (IoT), more and more devices are becoming network connected evidencing how essential it is to create secure coding guidelines for embedded software. Embedded Application Security is often not a high priority for embedded developers when they are producing devices such as routers, managed switches, medical devices, Industrial Control Systems (ICS), VoIP phones, IoT devices, and ATM Kiosks due to other challenges outside of development. Other challenges developers face may include, but are not limited to, the Original Design Manufacturer (ODM) supply chain, limited memory, a small stack, and the challenge of pushing firmware updates securely to an endpoint. The goals of this project are to create a list of best practices, provide practical guidance to embedded developers, and to draw on the existing OWASP resources that can bring application security expertise to the embedded world. It is important to note, each of the items and guidance points listed below are longstanding within software security. This document purely tailors issues that OWASP has previously provided guidance upon (e.g. OWASP Top 10, Mobile Top 10, etc.) to the embedded community. ''Given the prevalence of Linux kernels utilized within embedded devices, all code examples are geared towards a POSIX environment but the principles are designed to be platform agnostic.''
The goal of this project is to identify the risks in embedded applications on a generalized list of devices, create a list of best practices, draw on the resources that OWASP already has, and bring OWASP expertise to the embedded world.
 
  
==Introduction==
+
For the most up to date best practices document, please visit [https://scriptingxss.gitbooks.io/embedded-appsec-best-practices// https://scriptingxss.gitbooks.io/embedded-appsec-best-practices/]
  
<i>Contextual Output Encoding</i> is a computer programming technique necessary to stop [https://www.owasp.org/index.php/XSS_Prevention_Cheat_Sheet Cross Site Scripting]. This project is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. It provides numerous encoding functions to help defend against XSS in a variety of different HTML, JavaScript, XML and CSS contexts.
+
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
==Quick Overview==
+
== Mailing List / Group Communication ==
  
The OWASP Java Encoder library is intended for quick contextual encoding with very little overhead, either in performance or usage. To get started, simply add the encoder-1.2.jar, import org.owasp.encoder.Encode and start encoding.
+
[https://groups.google.com/a/owasp.org/forum/?hl=en#!forum/embedded-appsec Embedded Sec Mailing List]
 +
[http://owasp.herokuapp.com/ Please join our OWASP Slack channel; look for the #embeddedappsec]
  
Please look at the [http://search.maven.org/remotecontent?filepath=org/owasp/encoder/encoder/1.2/encoder-1.2-javadoc.jar javadoc for Encode] to see the variety of contexts for which you can encode. Tag libraries and JSP EL functions can be found in the encoder-jsp-1.2.jar.
+
== Project Leaders ==
 
 
If you want to try it out or see it in action, head over to "Can You XSS This? (.com)" and hit it with your best XSS attack vectors!
 
 
 
Happy Encoding!
 
 
 
==Licensing==
 
The OWASP Java Encoder is free to use under the [http://opensource.org/licenses/BSD-3-Clause New BSD License].
 
 
 
 
 
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
 
  
== What is this? ==
+
[https://owasp.org/index.php/User:Aaron.guzman Aaron Guzman] [mailto:aaron.guzman@owasp.org @]
 
+
<br>
The OWASP Java Encoder provides:
+
[https://owasp.org/index.php/User:Alex.Lafrenz Alex Lafrenz] [mailto:alex.lafrenz@owasp.org @]
 
 
* Output Encoding functions to help stop XSS
 
* Java 1.5+ standalone library
 
 
 
== Important Links ==
 
 
 
[https://github.com/OWASP/owasp-java-encoder/ Java Encoder at GitHub]<br/>
 
[https://github.com/owasp/owasp-java-encoder/issues Issue Tracker]
 
 
 
== Mailing List ==
 
 
 
[https://lists.owasp.org/mailman/listinfo/owasp-java-encoder-project Java Encoder Mailing List]
 
 
 
== Project Leaders ==
 
Author:  Jeff Ichnowski [mailto:[email protected] @]<br/>
 
[https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:jim.manico@owasp.org @]<br/>
 
[https://www.owasp.org/index.php/User:Jeremy_Long Jeremy Long] [mailto:jeremy.long@owasp.org @]
 
  
 
== Related Projects ==
 
== Related Projects ==
  
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
+
* [[OWASP Internet of Things Project]]
* [[OWASP Java HTML Sanitizer Project]]
+
* [[C-Based Toolchain Hardening]]
* [[OWASP JSON Sanitizer]]
+
* [[OWASP Mobile Security Project]]
* [[OWASP Dependency Check]]
+
* [[IoT Firmware Analysis]]
* [https://github.com/sourceclear/headlines Sourceclear Headlines]
 
* [https://code.google.com/p/keyczar/ Google KeyCzar]
 
* [http://shiro.apache.org/ Apache SHIRO]
 
  
 +
| valign="top" style="padding-left:25px;width:200px;" |
  
| valign="top"  style="padding-left:25px;width:200px;" |
+
== News and Events ==
 +
== Releases ==
 +
[https://scriptingxss.gitbooks.io/top-10-embedded-appsec-best-practices/content/ Living Document (GitBook)]
  
== Quick Download ==
+
[https://www.gitbook.com/download/pdf/book/scriptingxss/top-10-embedded-appsec-best-practices Version 1 (2017)]
  
* [https://search.maven.org/remotecontent?filepath=org/owasp/encoder/encoder/1.2/encoder-1.2.jar encoder-1.2.jar]
+
Version 2 scheduled for Fall 2018
* [https://search.maven.org/remotecontent?filepath=org/owasp/encoder/encoder-jsp/1.2/encoder-jsp-1.2.jar encoder-jsp-1.2.jar]
 
 
 
== News and Events ==
 
* [11 June 2016] No reported issues and library use is strong!
 
* [1 May 2015] Moved to GitHub
 
* [12 Apr 2015] 1.2 Released!
 
* [10 Apr 2015] GitHub move
 
* [1 Feb 2015] Removed ThreadLocal
 
* [20 Mar 2014] Doc additions
 
* [5 Feb 2014] New Wiki
 
* [4 Feb 2014] 1.1.1 Released
 
 
 
== In Print ==
 
We will be releasing a user guide soon!
 
  
 
==Classifications==
 
==Classifications==
Line 85: Line 44:
 
   {| width="200" cellpadding="2"
 
   {| width="200" cellpadding="2"
 
   |-
 
   |-
   | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
+
   | rowspan="2" align="center" valign="top" width="50%" | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
   | align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]   
+
   | align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=]]   
 
   |-
 
   |-
   | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
+
   | align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
 
   |-
 
   |-
   | colspan="2" align="center" | [http://opensource.org/licenses/BSD-3-Clause New BSD License]
+
   | colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
 
   |-
 
   |-
   | colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
+
   | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
 
   |}
 
   |}
  
 
|}
 
|}
  
= Use the Java Encoder Project =
+
= Embedded Best Practices =
  
The general API pattern is to utilize the Java Encoder Project in your user interface code and wrap all variables added dynamically to HTML with a proper encoding function. The encoding pattern is <b>"Encode.forContextName(untrustedData)"</b>, where "ContextName" is the name of the target context and "untrustedData" is untrusted output.
+
= Embedded Top 10 Best Practices =
 +
[https://scriptingxss.gitbooks.io/embedded-application-security-best-practices/content/ Click here to find additional details pertaining to each of the top ten categories listed below]
 +
== E1 –  Buffer and Stack Overflow Protection ==
 +
Prevent the use of known dangerous functions and APIs in effort to protect against memory-corruption vulnerabilities within firmware. (e.g. Use of unsafe C functions - strcat, strcpy, sprintf, scanf) Memory-corruption vulnerabilities, such as buffer overflows, can consist of overflowing the stack (Stack overflow) or overflowing the heap (Heap overflow). For simplicity purposes, this document does not distinguish between these two types of vulnerabilities. In the event a buffer overflow has been detected and exploited by an attacker, the instruction pointer register is overwritten to execute the arbitrary malicious code provided by the attacker.
 +
== E2 – Injection Prevention ==
 +
Ensure all untrusted data and user input is validated, sanitized, and/or outputs encoded to prevent unintended system execution. There are various injection attacks within application security such as operating system (OS) command injection, cross-site scripting (E.g. JavaScript injection), SQL injection, and others such as XPath injection. However, the most prevalent of the injection attacks within embedded software pertain to OS command injection; when an application accepts untrusted/insecure input and passes it to external applications (either as the application name itself or arguments) without validation or proper escaping.
  
== Basic HTML Context ==
+
== E3 – Firmware Updates and Cryptographic Signatures ==
 +
Ensure robust update mechanisms utilize cryptographically signed firmware images upon download and when applicable, for updating functions pertaining to third party software. Cryptographic signature allows for verification that files have not been modified or otherwise tampered with since the developer created and signed them. The signing and verification process uses public-key cryptography and it is difficult to forge a digital signature (e.g. PGP signature) without first gaining access to the private key. In the event a private key is compromised, developers of the software must revoke the compromised key and will need to re-sign all previous firmware releases with the new key.
  
<body><%= <b>Encode.forHtml(UNTRUSTED)</b> %></body>
+
== E4 – Securing Sensitive Information ==
 +
Do not hardcode secrets such as passwords, usernames, tokens, private keys or similar variants into firmware release images. This also includes the storage of sensitive data that is written to disk. If hardware security element (SE) or Trusted Execution Environment (TEE) is available, it is recommended to utilize such features for storing sensitive data. Otherwise, use of strong cryptography should be evaluated to protect the data.
 +
If possible, all sensitive data in clear-text should be ephemeral by nature and reside in a volatile memory only.
 +
== E5 – Identity Management ==
 +
User accounts within an embedded device should not be static in nature. Features that allow separation of user accounts for internal web management, internal console access, as well as remote web management and remote console access should be available to prevent automated malicious attacks.
  
== HTML Content Context ==
+
== E6 – Embedded Framework and C-Based Hardening ==
<textarea name="text"><%= <b>Encode.forHtmlContent(UNTRUSTED)</b> %></textarea>
+
Limit BusyBox, embedded frameworks, and toolchains to only those libraries and functions being used when configuring firmware builds. Embedded Linux build systems such as Buildroot, Yocto and others typically perform this task. Removal of known insecure libraries and protocols such as Telnet not only minimize attack entry points in firmware builds, but also provide a secure-by-design approach to building software in efforts to thwart potential security threats.
 +
== E7 – Usage of Debug Code and Interfaces ==
 +
It is important to ensure all unnecessary pre-production build code, as well as dead and unused code, has been removed prior to firmware release to all market segments. This includes but is not limited to potential backdoor code and root privilege accounts that may have been left by parties such as Original Design Manufacturers (ODM) and Third-Party contractors. Typically this falls in scope for Original Equipment Manufacturers (OEM) to perform via reverse engineering of binaries. This should also require ODMs to sign Master Service Agreements (MSA) insuring that either no backdoor code is included and that all code has been reviewed for software security vulnerabilities holding all Third-Party developers accountable for devices that are mass deployed into the market.
 +
== E8 – Transport Layer Security ==
 +
Ensure all methods of communication are utilizing industry standard encryption configurations for TLS. The use of TLS ensures that all data remains confidential and untampered with while in transit. Utilize free certificate authority services such as Let’s Encrypt if the embedded device utilizes domain names.
 +
== E9 – Data collection Usage and Storage - Privacy ==
 +
It is critical to limit the collection, storage, and sharing of both personally identifiable information (PII) as well as sensitive personal information (SPI). Leaked information such as Social Security Numbers can lead to customers being compromised which could have legal repercussions for manufacturers. If information of this nature must be gathered, it is important to follow the concepts of Privacy-by-Design.
 +
== E10 – Third Party Code and Components ==
 +
Following setup of the toolchain, it is important to ensure that the kernel, software packages, and third party libraries are updated to protect against publicly known vulnerabilities. Software such as Rompager or embedded build tools such as Buildroot should be checked against vulnerability databases as well as their ChangeLogs to determine when and if an update is needed. It is important to note this process should be tested by developers and/or QA teams prior to release builds as updates to embedded systems can cause issues with the operations of those systems.
 +
Embedded projects should maintain a “Bill of Materials” of the third party and open source software included in its firmware images. This Bill of Materials should be checked to confirm that none of the third party software included has any unpatched vulnerabilities. Up to date vulnerability information may be found through the National Vulnerability Database or Open Hub.
  
== HTML Attribute context ==
+
Several solutions exist for cataloging and auditing third party software:
 +
Retirejs for Javascript projects (free)
 +
Black Duck (paid)
 +
Package Managers (free)
 +
Buildroot (free)
  
<input type="text" name="address" value="<%= <b>Encode.forHtmlAttribute(UNTRUSTED)</b> %>" />
+
= Embedded Device Firmware Analysis Tools =
 +
Over the years, embedded security hardware and software tools have been introduced. Some free, some commercially based. If the lists below are missing tools from your arsenal, please feel free to add them.  
  
Generally <b>Encode.forHtml(UNTRUSTED)</b> is also safe but slightly less efficient for the above two contexts (for textarea content and input value text) since it encodes more characters than necessary but might be easier for developers to use.
+
=== Hardware ===
 +
* JTagulator [http://www.grandideastudio.com/jtagulator/]
 +
* UART to USB
 +
** Shikra [http://int3.cc/products/the-shikra]
 +
* TTL RS323
 +
* C232HM Cable
 +
* JTAG Adapters
 +
** JLINK
 +
** Jtagulator
 +
** Flyswatter2
 +
* BusPirate
 +
* BusBlaster
 +
* CPLDs (in lieu of FPGAs)
 +
* Oscilloscopes
 +
* Multimeter (Ammeter, Voltmeter, etc)
 +
* Logic Analyzers [https://www.saleae.com/logic16]
 +
* OpenOCD
 +
*GreatFET [https://greatscottgadgets.com/greatfet/]
 +
*Solder station
 +
*Hot air rework gun
 +
*Clips
 +
*Leads
 +
*Headers
 +
*hooks
  
== CSS contexts ==
+
=== Software ===
 +
* Angr - [https://github.com/angr/angr]
 +
* Firmadyne [https://github.com/firmadyne/firmadyne]
 +
* Firmwalker [https://github.com/craigz28/firmwalker]
 +
* [https://github.com/attify/firmware-analysis-toolkit Firmware Analysis Toolkit]
 +
* Binary Analysis [http://www.binaryanalysis.org/en/content/show/download]
 +
* Flawfinder [https://sourceforge.net/projects/flawfinder/]
 +
* IDA Pro (supports ARM / MIPS)
 +
* Radare2 [https://github.com/radare/radare2]
 +
* Buildroot
 +
* GDB
 +
* Binwalk [http://binwalk.org/]
 +
* Firmware-mod-toolkit [https://code.google.com/archive/p/firmware-mod-kit/]
 +
* Capstone framework [http://www.capstone-engine.org/]
 +
*[https://github.com/fkie-cad/FACT_core Firmware Analysis and Comparison Tool]
 +
*[https://github.com/attify/firmware-analysis-toolkit Firmware Analysis Toolkit]
  
<div style="width:<= <b>Encode.forCssString(UNTRUSTED)</b> %>">
+
= Roadmap =
<div style="background:<= <b>Encode.forCssUrl(UNTRUSTED)</b> %>">
 
  
== Javascript Block context ==
+
== 2018 Roadmap ==
 
+
Introductory Embedded Section
  <script type="text/javascript">
+
* [x] Expand on what embedded firmware is (8,16,32 bit, minimal hardware resources, list embedded use cases and industries)
  var msg = "<%= <b>Encode.forJavaScriptBlock(UNTRUSTED)</b> %>";
+
* [x] Describe types of architectures (MIPS, ARM, PowerPC, x86 etc.)
  alert(msg);
+
* [x] Describe types of firmware and operating systems
  </script>
+
* [ ] Layout of firmware for embedded linux, RTOS, and Embedded Window
 
+
Expand on embedded best practices
== Javascript Variable context ==
+
* [ ] Secure boot recommendations
 
+
** [x] U-boot
  <button
+
* [x] Create examples of software bill of materials (BOM)
  onclick="alert('<%= <b>Encode.forJavaScriptAttribute(UNTRUSTED)</b> %>');">
+
* [x] Additional example programming language command injection system calls or APIs
  click me</button>
+
* [ ] Break out subsections for each of the platforms with contextual guidance and configurations
 
+
* [ ] Expand on hardening for:
JavaScript Content Notes: <b>Encode.forJavaScript(UNTRUSTED)</b> is safe for the above two contexts, but encodes more characters and is less efficient.
+
** [ ] Embedded Linux
 
+
** [ ] RTOS (QNX/MQX)
== Encode URL parameter values ==
+
* [ ] Best practices/considerations for PKI in embedded systems
<a href="/search?value=<%= <b>Encode.forUriComponent(UNTRUSTED)</b> %>&order=1#top">
+
Create example embedded application security requirements for new products
 
+
* [ ] Integrate with ASVS or create an EASVS (Embedded Application Security Verification Standard)
== Encode REST URL parameters ==
+
* [ ] Integrate with the IoT project
<a href="/page/<%= <b>Encode.forUriComponent(UNTRUSTED)</b> %>">
+
Join the mailing list, slack channel (#embeddedappsec) and contact the Project leaders if you feel you can contribute.
 
 
== Handling an Full Untrusted URL ==
 
 
 
When handling a full url with the OWASP Java encoder, first verify the URL is a legal URL.
 
 
 
String url = validateURL(untrustedInput);
 
 
 
Then encode the URL as an HTML attribute when outputting to the page. Note the linkable text needs to be encoded in a different context.
 
 
 
  <a href="<%= <b>Encode.forHtmlAttribute(untrustedUrl)</b> %>">
 
  <%= <b>Encode.forHtmlContent(untrustedLinkName)</b> %>
 
  </a>
 
 
 
== To use in a JSP with EL ==
 
 
 
<%@page contentType="text/html" pageEncoding="UTF-8"%>
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 
    "<nowiki>http://www.w3.org/TR/html4/loose.dtd</nowiki>">
 
<%@taglib prefix="e" uri="<nowiki>https://www.owasp.org/index.php/OWASP_Java_Encoder_Project</nowiki>" %>
 
<html>
 
    <head>
 
        <title><b><e:forHtml value="${param.title}" /></b></title>
 
    </head>
 
    <body>
 
        &lt;h1&gt;<b>${e:forHtml(param.data)}</b>&lt;/h1&gt;
 
    </body>
 
</html>
 
 
 
Other contexts can be found in the org.owasp.Encode class methods, including CSS strings, CSS urls, XML contexts, URIs and URI components.
 
 
 
= Deploy the Java Encoder Project =
 
 
 
Prevent the use of dangerous functions and APIs in efforts to protect against memory-corruption vulnerabilities inside firmware functions.
 
Ensure secure compiler flags or switches are utilized upon each firmware build. (i.e For GCC -fPIE, -fstack-protector-all, -Wl,-z,noexecstack, -Wl,-z,noexecheap etc..)
 
Ensure robust update mechanisms utilize cryptographically signed firmware images for updating functions.
 
Do not hard code secrets such as passwords, usernames, tokens or similar variants into firmware images.
 
Dispose and securely wipe sensitive information stored in buffers or temporary files during runtime after they are no longer needed (e.g. Wipe buffers from locations where personal identifiable information is stored before releasing the buffers)
 
Modify Busybox and embedded frameworks alike to only libraries and functions that are being used. (e.g. Remove unused languages like perl and services such as Telnet, FTP etc)
 
Validate all debugging and pre-production code have been removed prior to firmware deployment.
 
Ensure all methods of communication are utilizing industry standard encryption configurations for TLS.
 
Limit collection, storage, and sharing of personal identifiable information (PII) to items that are only required for operation.
 
Ensure kernel and software packages on embedded images are updated to prevent from known publicly available exploits.
 
 
 
= Roadmap =
 
  
== 2016-2017 Roadmap ==
+
= Contributing =
* Add decoders and canonicalization
+
You do not have to be a security expert in order to contribute!
* Build more complex examples
 
  
__NOTOC__ <headertabs />
+
Some of the ways you can help:
 +
* Technical editing
 +
* Review
 +
* Diagrams
 +
* Graphic design
 +
* Code snippets in your favorite language
 +
* Translate guidance material
 +
Feel free to sign up for a task out of our roadmap below or add your own idea to the roadmap. To get started, create a GitBook account or sign in with your Github credentials to add comments and make edits. All changes are tracked and synced to <nowiki>https://github.com/scriptingxss/embeddedappsec</nowiki>. Alternatively, clone the Github repo, use your favorite markdown editor, apply/make your edits, and submit a pull request. Feel free to contact the project leaders for ways to get involved.
 +
__NOTOC__ <headertabs></headertabs>
  
[[Category:OWASP_Tool]]
+
[[Category:OWASP_Project]]
[[Category:OWASP_Alpha_Quality_Tool]]
 
[[Category:OWASP_Project|OWASP Java Encoder Project]]
 

Latest revision as of 21:23, 16 November 2018

Incubator big.jpg

OWASP Embedded Application Security Project

Every year the prevalent use of embedded software within enterprise and consumer devices continues to rise exponentially. With widespread publicity of the Internet of Things (IoT), more and more devices are becoming network connected evidencing how essential it is to create secure coding guidelines for embedded software. Embedded Application Security is often not a high priority for embedded developers when they are producing devices such as routers, managed switches, medical devices, Industrial Control Systems (ICS), VoIP phones, IoT devices, and ATM Kiosks due to other challenges outside of development. Other challenges developers face may include, but are not limited to, the Original Design Manufacturer (ODM) supply chain, limited memory, a small stack, and the challenge of pushing firmware updates securely to an endpoint. The goals of this project are to create a list of best practices, provide practical guidance to embedded developers, and to draw on the existing OWASP resources that can bring application security expertise to the embedded world. It is important to note, each of the items and guidance points listed below are longstanding within software security. This document purely tailors issues that OWASP has previously provided guidance upon (e.g. OWASP Top 10, Mobile Top 10, etc.) to the embedded community. Given the prevalence of Linux kernels utilized within embedded devices, all code examples are geared towards a POSIX environment but the principles are designed to be platform agnostic.

For the most up to date best practices document, please visit https://scriptingxss.gitbooks.io/embedded-appsec-best-practices/

Mailing List / Group Communication

Embedded Sec Mailing List Please join our OWASP Slack channel; look for the #embeddedappsec

Project Leaders

Aaron Guzman @
Alex Lafrenz @

Related Projects

News and Events

Releases

Living Document (GitBook)

Version 1 (2017)

Version 2 scheduled for Fall 2018

Classifications

Owasp-incubator-trans-85.png Owasp-builders-small.png
Owasp-defenders-small.png
Cc-button-y-sa-small.png
Project Type Files DOC.jpg

Click here to find additional details pertaining to each of the top ten categories listed below

E1 – Buffer and Stack Overflow Protection

Prevent the use of known dangerous functions and APIs in effort to protect against memory-corruption vulnerabilities within firmware. (e.g. Use of unsafe C functions - strcat, strcpy, sprintf, scanf) Memory-corruption vulnerabilities, such as buffer overflows, can consist of overflowing the stack (Stack overflow) or overflowing the heap (Heap overflow). For simplicity purposes, this document does not distinguish between these two types of vulnerabilities. In the event a buffer overflow has been detected and exploited by an attacker, the instruction pointer register is overwritten to execute the arbitrary malicious code provided by the attacker.

E2 – Injection Prevention

Ensure all untrusted data and user input is validated, sanitized, and/or outputs encoded to prevent unintended system execution. There are various injection attacks within application security such as operating system (OS) command injection, cross-site scripting (E.g. JavaScript injection), SQL injection, and others such as XPath injection. However, the most prevalent of the injection attacks within embedded software pertain to OS command injection; when an application accepts untrusted/insecure input and passes it to external applications (either as the application name itself or arguments) without validation or proper escaping.

E3 – Firmware Updates and Cryptographic Signatures

Ensure robust update mechanisms utilize cryptographically signed firmware images upon download and when applicable, for updating functions pertaining to third party software. Cryptographic signature allows for verification that files have not been modified or otherwise tampered with since the developer created and signed them. The signing and verification process uses public-key cryptography and it is difficult to forge a digital signature (e.g. PGP signature) without first gaining access to the private key. In the event a private key is compromised, developers of the software must revoke the compromised key and will need to re-sign all previous firmware releases with the new key.

E4 – Securing Sensitive Information

Do not hardcode secrets such as passwords, usernames, tokens, private keys or similar variants into firmware release images. This also includes the storage of sensitive data that is written to disk. If hardware security element (SE) or Trusted Execution Environment (TEE) is available, it is recommended to utilize such features for storing sensitive data. Otherwise, use of strong cryptography should be evaluated to protect the data. If possible, all sensitive data in clear-text should be ephemeral by nature and reside in a volatile memory only.

E5 – Identity Management

User accounts within an embedded device should not be static in nature. Features that allow separation of user accounts for internal web management, internal console access, as well as remote web management and remote console access should be available to prevent automated malicious attacks.

E6 – Embedded Framework and C-Based Hardening

Limit BusyBox, embedded frameworks, and toolchains to only those libraries and functions being used when configuring firmware builds. Embedded Linux build systems such as Buildroot, Yocto and others typically perform this task. Removal of known insecure libraries and protocols such as Telnet not only minimize attack entry points in firmware builds, but also provide a secure-by-design approach to building software in efforts to thwart potential security threats.

E7 – Usage of Debug Code and Interfaces

It is important to ensure all unnecessary pre-production build code, as well as dead and unused code, has been removed prior to firmware release to all market segments. This includes but is not limited to potential backdoor code and root privilege accounts that may have been left by parties such as Original Design Manufacturers (ODM) and Third-Party contractors. Typically this falls in scope for Original Equipment Manufacturers (OEM) to perform via reverse engineering of binaries. This should also require ODMs to sign Master Service Agreements (MSA) insuring that either no backdoor code is included and that all code has been reviewed for software security vulnerabilities holding all Third-Party developers accountable for devices that are mass deployed into the market.

E8 – Transport Layer Security

Ensure all methods of communication are utilizing industry standard encryption configurations for TLS. The use of TLS ensures that all data remains confidential and untampered with while in transit. Utilize free certificate authority services such as Let’s Encrypt if the embedded device utilizes domain names.

E9 – Data collection Usage and Storage - Privacy

It is critical to limit the collection, storage, and sharing of both personally identifiable information (PII) as well as sensitive personal information (SPI). Leaked information such as Social Security Numbers can lead to customers being compromised which could have legal repercussions for manufacturers. If information of this nature must be gathered, it is important to follow the concepts of Privacy-by-Design.

E10 – Third Party Code and Components

Following setup of the toolchain, it is important to ensure that the kernel, software packages, and third party libraries are updated to protect against publicly known vulnerabilities. Software such as Rompager or embedded build tools such as Buildroot should be checked against vulnerability databases as well as their ChangeLogs to determine when and if an update is needed. It is important to note this process should be tested by developers and/or QA teams prior to release builds as updates to embedded systems can cause issues with the operations of those systems. Embedded projects should maintain a “Bill of Materials” of the third party and open source software included in its firmware images. This Bill of Materials should be checked to confirm that none of the third party software included has any unpatched vulnerabilities. Up to date vulnerability information may be found through the National Vulnerability Database or Open Hub.

Several solutions exist for cataloging and auditing third party software: Retirejs for Javascript projects (free) Black Duck (paid) Package Managers (free) Buildroot (free)

Over the years, embedded security hardware and software tools have been introduced. Some free, some commercially based. If the lists below are missing tools from your arsenal, please feel free to add them.

Hardware

  • JTagulator [1]
  • UART to USB
  • TTL RS323
  • C232HM Cable
  • JTAG Adapters
    • JLINK
    • Jtagulator
    • Flyswatter2
  • BusPirate
  • BusBlaster
  • CPLDs (in lieu of FPGAs)
  • Oscilloscopes
  • Multimeter (Ammeter, Voltmeter, etc)
  • Logic Analyzers [3]
  • OpenOCD
  • GreatFET [4]
  • Solder station
  • Hot air rework gun
  • Clips
  • Leads
  • Headers
  • hooks

Software

2018 Roadmap

Introductory Embedded Section

  • [x] Expand on what embedded firmware is (8,16,32 bit, minimal hardware resources, list embedded use cases and industries)
  • [x] Describe types of architectures (MIPS, ARM, PowerPC, x86 etc.)
  • [x] Describe types of firmware and operating systems
  • [ ] Layout of firmware for embedded linux, RTOS, and Embedded Window

Expand on embedded best practices

  • [ ] Secure boot recommendations
    • [x] U-boot
  • [x] Create examples of software bill of materials (BOM)
  • [x] Additional example programming language command injection system calls or APIs
  • [ ] Break out subsections for each of the platforms with contextual guidance and configurations
  • [ ] Expand on hardening for:
    • [ ] Embedded Linux
    • [ ] RTOS (QNX/MQX)
  • [ ] Best practices/considerations for PKI in embedded systems

Create example embedded application security requirements for new products

  • [ ] Integrate with ASVS or create an EASVS (Embedded Application Security Verification Standard)
  • [ ] Integrate with the IoT project

Join the mailing list, slack channel (#embeddedappsec) and contact the Project leaders if you feel you can contribute.

You do not have to be a security expert in order to contribute!

Some of the ways you can help:

  • Technical editing
  • Review
  • Diagrams
  • Graphic design
  • Code snippets in your favorite language
  • Translate guidance material

Feel free to sign up for a task out of our roadmap below or add your own idea to the roadmap. To get started, create a GitBook account or sign in with your Github credentials to add comments and make edits. All changes are tracked and synced to https://github.com/scriptingxss/embeddedappsec. Alternatively, clone the Github repo, use your favorite markdown editor, apply/make your edits, and submit a pull request. Feel free to contact the project leaders for ways to get involved.