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