├── .gitignore ├── 404.html ├── Gemfile ├── README.md ├── _config.yml ├── assets └── images │ └── README.md ├── index.md ├── info.md ├── leaders.md ├── tab_project.md ├── tab_roadmap.md └── tab_tools.md /.gitignore: -------------------------------------------------------------------------------- 1 | __pycache__ 2 | env 3 | .vscode 4 | _site/ 5 | -------------------------------------------------------------------------------- /404.html: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | title: 404 - Not Found 4 | layout: col-generic 5 | 6 | --- 7 | 8 |
9 |

10 |

WHOA THAT PAGE CANNOT BE FOUND

11 |

Try the SEARCH function in the main navigation to find something. If you are looking for chapter information, please see Chapters for the correct chapter. For information about OWASP projects see Projects. For common attacks, vulnerabilities, or information about other community-led contributions see Contributed Content.

12 | 13 |
14 |

If all else fails you can search our historical site.

15 |
16 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source 'https://rubygems.org' 2 | group :jekyll_plugins do 3 | gem "github-pages" 4 | end -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Embedded Application Security Page on the OWASP Website 2 | 3 | This repository contains the files that build the OWASP Embedded Application Security Project's page on the main OWASP website. The page can be found at: https://github.com/OWASP/www-project-embedded-application-security 4 | 5 | Documentation explaining the files in this repo can be found at: https://owasp.org/migration 6 | 7 | ## Contributions 8 | 9 | Any contributions to the guide itself should be made via the [guide's project repo] (https://scriptingxss.gitbook.io/embedded-appsec-best-practices/) 10 | 11 | Made possible by contributions from: 12 | 13 | Jim Manico 14 | 15 | Benjamin Samuels 16 | 17 | Janet Kulp 18 | 19 | ## Getting Started 20 | 21 | For the most up to date best practices document, please visit the [GitBook] (https://scriptingxss.gitbooks.io/embedded-appsec-best-practices/) 22 | 23 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | remote_theme: "owasp/www--site-theme@main" 2 | plugins: 3 | - jekyll-include-cache-0.2.0 -------------------------------------------------------------------------------- /assets/images/README.md: -------------------------------------------------------------------------------- 1 | # placeholder 2 | 3 | Put images you wish to link to in this folder 4 | 5 | link would be in form /assets/images/ 6 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: OWASP Embedded Application Security 5 | tags: embedded 6 | level: 0 7 | type: documentation 8 | pitch: The Embedded Application Security Project produces a document that will provide a detailed technical pathway for manufacturers to build secure devices for an increasingly insecure world. 9 | 10 | 11 | --- 12 | 13 | ![OWASP Incubator Project](https://owasp.org/www-project-cyber-controls-matrix/assets/images/OWASP-Incubator_Project-blue.svg) 14 | 15 | 16 | ## Contributions 17 | 18 | You do not have to be a security expert in order to contribute\! 19 | 20 | Some of the ways you can help: 21 | 22 | - Technical editing 23 | - Review 24 | - Diagrams 25 | - Graphic design 26 | - Code snippets in your favorite language 27 | - Translate guidance material 28 | 29 | Feel free to sign up for a task out of our roadmap below or add your own 30 | idea to the roadmap. To get started, create a GitBook account or sign in 31 | with your Github credentials to add comments and make edits. All changes 32 | are tracked and synced to https://github.com/scriptingxss/embeddedappsec. 33 | 34 | 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. 35 | 36 | Any contributions to the guide itself should be made via the [guide's project repo] (https://scriptingxss.gitbook.io/embedded-appsec-best-practices/. 37 | 38 | Made possible by contributions from: 39 | 40 | Jim Manico 41 | Benjamin Samuels 42 | Janet Kulp 43 | 44 | ## Getting Started 45 | 46 | For the most up to date best practices document, please visit https://scriptingxss.gitbooks.io/embedded-appsec-best-practices/ 47 | -------------------------------------------------------------------------------- /info.md: -------------------------------------------------------------------------------- 1 | ### Project Classification 2 | 3 | * Incubator Project 4 | * Documentation 5 | * Builder 6 | * Defender 7 | 8 | ### What is the Embedded Application Security Project? 9 | 10 | The Embedded Application Security Project produces a document that will provide a detailed technical pathway for manufacturers to build secure devices for an increasingly insecure world. 11 | 12 | ### Project Links 13 | 14 | * [Latest](https://scriptingxss.gitbook.io/embedded-appsec-best-practices/) 15 | * [GitHub Repository](https://github.com/OWASP/www-project-embedded-application-security) 16 | 17 | ### Social 18 | 19 | * [Join OWASP Slack](https://owasp.org/slack/invite) 20 | * Channel: [#project-embeddedappsec] 21 | 22 | -------------------------------------------------------------------------------- /leaders.md: -------------------------------------------------------------------------------- 1 | ### Leaders 2 | 3 | * [Aaron Guzman](mailto:aaron.guzman@owasp.org) 4 | * [Alex Lafrenz](mailto:alex.lafrenz@owasp.org) 5 | -------------------------------------------------------------------------------- /tab_project.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Project 3 | layout: null 4 | tab: true 5 | order: 1 6 | tags: embedded 7 | --- 8 | 9 | # Embedded Best Practices 10 | 11 | # Embedded Top 10 Best Practices 12 | 13 | [Click here to find additional details pertaining to each of the top ten 14 | categories listed 15 | below](https://scriptingxss.gitbook.io/embedded-appsec-best-practices/) 16 | 17 | ## E1 – Buffer and Stack Overflow Protection 18 | 19 | Prevent the use of known dangerous functions and APIs in effort to 20 | protect against memory-corruption vulnerabilities within firmware. (e.g. 21 | Use of unsafe C functions - strcat, strcpy, sprintf, scanf) 22 | Memory-corruption vulnerabilities, such as buffer overflows, can consist 23 | of overflowing the stack (Stack overflow) or overflowing the heap (Heap 24 | overflow). For simplicity purposes, this document does not distinguish 25 | between these two types of vulnerabilities. In the event a buffer 26 | overflow has been detected and exploited by an attacker, the instruction 27 | pointer register is overwritten to execute the arbitrary malicious code 28 | provided by the attacker. 29 | 30 | ## E2 – Injection Prevention 31 | 32 | Ensure all untrusted data and user input is validated, sanitized, and/or 33 | outputs encoded to prevent unintended system execution. There are 34 | various injection attacks within application security such as operating 35 | system (OS) command injection, cross-site scripting (E.g. JavaScript 36 | injection), SQL injection, and others such as XPath injection. However, 37 | the most prevalent of the injection attacks within embedded software 38 | pertain to OS command injection; when an application accepts 39 | untrusted/insecure input and passes it to external applications (either 40 | as the application name itself or arguments) without validation or 41 | proper escaping. 42 | 43 | ## E3 – Firmware Updates and Cryptographic Signatures 44 | 45 | Ensure robust update mechanisms utilize cryptographically signed 46 | firmware images upon download and when applicable, for updating 47 | functions pertaining to third party software. Cryptographic signature 48 | allows for verification that files have not been modified or otherwise 49 | tampered with since the developer created and signed them. The signing 50 | and verification process uses public-key cryptography and it is 51 | difficult to forge a digital signature (e.g. PGP signature) without 52 | first gaining access to the private key. In the event a private key is 53 | compromised, developers of the software must revoke the compromised key 54 | and will need to re-sign all previous firmware releases with the new 55 | key. 56 | 57 | ## E4 – Securing Sensitive Information 58 | 59 | Do not hardcode secrets such as passwords, usernames, tokens, private 60 | keys or similar variants into firmware release images. This also 61 | includes the storage of sensitive data that is written to disk. If 62 | hardware security element (SE) or Trusted Execution Environment (TEE) is 63 | available, it is recommended to utilize such features for storing 64 | sensitive data. Otherwise, use of strong cryptography should be 65 | evaluated to protect the data. If possible, all sensitive data in 66 | clear-text should be ephemeral by nature and reside in a volatile memory 67 | only. 68 | 69 | ## E5 – Identity Management 70 | 71 | User accounts within an embedded device should not be static in nature. 72 | Features that allow separation of user accounts for internal web 73 | management, internal console access, as well as remote web management 74 | and remote console access should be available to prevent automated 75 | malicious attacks. 76 | 77 | ## E6 – Embedded Framework and C-Based Hardening 78 | 79 | Limit BusyBox, embedded frameworks, and toolchains to only those 80 | libraries and functions being used when configuring firmware builds. 81 | Embedded Linux build systems such as Buildroot, Yocto and others 82 | typically perform this task. Removal of known insecure libraries and 83 | protocols such as Telnet not only minimize attack entry points in 84 | firmware builds, but also provide a secure-by-design approach to 85 | building software in efforts to thwart potential security threats. 86 | 87 | ## E7 – Usage of Debug Code and Interfaces 88 | 89 | It is important to ensure all unnecessary pre-production build code, as 90 | well as dead and unused code, has been removed prior to firmware release 91 | to all market segments. This includes but is not limited to potential 92 | backdoor code and root privilege accounts that may have been left by 93 | parties such as Original Design Manufacturers (ODM) and Third-Party 94 | contractors. Typically this falls in scope for Original Equipment 95 | Manufacturers (OEM) to perform via reverse engineering of binaries. This 96 | should also require ODMs to sign Master Service Agreements (MSA) 97 | insuring that either no backdoor code is included and that all code has 98 | been reviewed for software security vulnerabilities holding all 99 | Third-Party developers accountable for devices that are mass deployed 100 | into the market. 101 | 102 | ## E8 – Transport Layer Security 103 | 104 | Ensure all methods of communication are utilizing industry standard 105 | encryption configurations for TLS. The use of TLS ensures that all data 106 | remains confidential and untampered with while in transit. Utilize free 107 | certificate authority services such as Let’s Encrypt if the embedded 108 | device utilizes domain names. 109 | 110 | ## E9 – Data collection Usage and Storage - Privacy 111 | 112 | It is critical to limit the collection, storage, and sharing of both 113 | personally identifiable information (PII) as well as sensitive personal 114 | information (SPI). Leaked information such as Social Security Numbers 115 | can lead to customers being compromised which could have legal 116 | repercussions for manufacturers. If information of this nature must be 117 | gathered, it is important to follow the concepts of Privacy-by-Design. 118 | 119 | ## E10 – Third Party Code and Components 120 | 121 | Following setup of the toolchain, it is important to ensure that the 122 | kernel, software packages, and third party libraries are updated to 123 | protect against publicly known vulnerabilities. Software such as 124 | Rompager or embedded build tools such as Buildroot should be checked 125 | against vulnerability databases as well as their ChangeLogs to determine 126 | when and if an update is needed. It is important to note this process 127 | should be tested by developers and/or QA teams prior to release builds 128 | as updates to embedded systems can cause issues with the operations of 129 | those systems. Embedded projects should maintain a “Bill of Materials” 130 | of the third party and open source software included in its firmware 131 | images. This Bill of Materials should be checked to confirm that none of 132 | the third party software included has any unpatched vulnerabilities. Up 133 | to date vulnerability information may be found through the National 134 | Vulnerability Database or Open Hub. 135 | 136 | Several solutions exist for cataloging and auditing third party 137 | software: Retirejs for Javascript projects (free) Black Duck (paid) 138 | Package Managers (free) Buildroot (free) 139 | -------------------------------------------------------------------------------- /tab_roadmap.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Roadmap 3 | layout: null 4 | tab: true 5 | order: 3 6 | tags: embedded 7 | --- 8 | 9 | ## 2020 Roadmap 10 | 11 | Introductory Embedded Section 12 | 13 | - \[ \] Layout of firmware for embedded linux, RTOS, and Embedded 14 | Window 15 | 16 | Expand on embedded best practices 17 | 18 | - \[ \] Secure boot recommendations 19 | - \[x\] U-boot 20 | - \[ \] Break out subsections for each of the platforms with 21 | contextual guidance and configurations 22 | - \[ \] Expand on hardening for: 23 | - \[ \] Embedded Linux 24 | - \[ \] RTOS (QNX/MQX) 25 | - \[ \] Best practices/considerations for PKI in embedded systems 26 | 27 | Create example embedded application security requirements for new 28 | products 29 | 30 | - \[ \] Integrate with ASVS or create an EASVS (Embedded Application 31 | Security Verification Standard) 32 | 33 | Join the mailing list, slack channel (\#embeddedappsec) and contact the 34 | Project leaders if you feel you can contribute. 35 | -------------------------------------------------------------------------------- /tab_tools.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Tools 3 | layout: null 4 | tab: true 5 | order: 2 6 | tags: embedded 7 | --- 8 | 9 | # Embedded Device Firmware Analysis Tools 10 | 11 | Over the years, embedded security hardware and software tools have been 12 | introduced. Some free, some commercially based. If the lists below are 13 | missing tools from your arsenal, please feel free to add them. 14 | 15 | ### Hardware 16 | 17 | - JTagulator [1](http://www.grandideastudio.com/jtagulator/) 18 | - UART to USB 19 | - Shikra [2](http://int3.cc/products/the-shikra) 20 | - TTL RS323 21 | - C232HM Cable 22 | - JTAG Adapters 23 | - JLINK 24 | - Jtagulator 25 | - Flyswatter2 26 | - BusPirate 27 | - BusBlaster 28 | - CPLDs (in lieu of FPGAs) 29 | - Oscilloscopes 30 | - Multimeter (Ammeter, Voltmeter, etc) 31 | - Logic Analyzers [3](https://www.saleae.com/logic16) 32 | - OpenOCD 33 | - GreatFET [4](https://greatscottgadgets.com/greatfet/) 34 | - Solder station 35 | - Hot air rework gun 36 | - Clips 37 | - Leads 38 | - Headers 39 | - hooks 40 | 41 | ### Software 42 | 43 | - Angr - [5](https://github.com/angr/angr) 44 | - Firmadyne [6](https://github.com/firmadyne/firmadyne) 45 | - Firmwalker [7](https://github.com/craigz28/firmwalker) 46 | - [Firmware Analysis 47 | Toolkit](https://github.com/attify/firmware-analysis-toolkit) 48 | - Binary Analysis 49 | [8](http://www.binaryanalysis.org/en/content/show/download) 50 | - Flawfinder [9](https://sourceforge.net/projects/flawfinder/) 51 | - IDA Pro (supports ARM / MIPS) 52 | - Radare2 [10](https://github.com/radare/radare2) 53 | - Buildroot 54 | - GDB 55 | - Binwalk [11](http://binwalk.org/) 56 | - Firmware-mod-toolkit 57 | [12](https://code.google.com/archive/p/firmware-mod-kit/) 58 | - Capstone framework [13](http://www.capstone-engine.org/) 59 | - [Firmware Analysis and Comparison 60 | Tool](https://github.com/fkie-cad/FACT_core) 61 | 62 | --------------------------------------------------------------------------------