├── .github └── workflows │ ├── create-checklists.yml │ ├── mdbook.yml │ └── scorecard.yml ├── CHANGELOG.md ├── LICENSE.md ├── README.md ├── SECURITY.md ├── acknowledgements.md ├── book.toml ├── checklists ├── checklist.md └── checklist.xlsx ├── resources ├── component_overview.drawio ├── istg_cover.pdf ├── istg_cover.pub ├── istg_cover_image.drawio └── istg_cover_image.png ├── roadmap.md ├── scripts ├── checklist_template.md ├── checklist_template.xlsx ├── create_checklists.py ├── mdbook_cleanup.sh ├── mdbook_prepare.sh └── requirements ├── src ├── 01_introduction │ └── README.md ├── 02_framework │ ├── README.md │ ├── attacker_model.md │ ├── device_model.md │ └── methodology.md ├── 03_test_cases │ ├── README.md │ ├── data_exchange_services │ │ └── README.md │ ├── firmware │ │ ├── README.md │ │ ├── firmware_update_mechanism.md │ │ └── installed_firmware.md │ ├── internal_interfaces │ │ └── README.md │ ├── memory │ │ └── README.md │ ├── physical_interfaces │ │ └── README.md │ ├── processing_units │ │ └── README.md │ ├── user_interfaces │ │ └── README.md │ └── wireless_interfaces │ │ └── README.md ├── SUMMARY.md └── img │ ├── Component_Overview.png │ ├── IoT_Device_Model.jpg │ └── istg_cover.png └── versioning.md /.github/workflows/create-checklists.yml: -------------------------------------------------------------------------------- 1 | name: Create checklists 2 | 3 | on: 4 | # Runs on pushes targeting the main branch, only if md-files in the test case directory were changed 5 | push: 6 | branches: [ "main" ] 7 | paths: [ "src/03_test_cases/**.md" ] 8 | 9 | # Allows to run this workflow manually from the actions tab 10 | workflow_dispatch: 11 | 12 | permissions: 13 | contents: write 14 | 15 | # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. 16 | # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. 17 | concurrency: 18 | group: "pages" 19 | cancel-in-progress: false 20 | 21 | jobs: 22 | build: 23 | runs-on: ubuntu-latest 24 | steps: 25 | - uses: actions/checkout@v3 26 | - name: Set up Python 3.10 27 | uses: actions/setup-python@v3 28 | with: 29 | python-version: "3.10" 30 | - name: Install dependencies 31 | run: | 32 | python -m pip install --upgrade pip 33 | if [ -f scripts/requirements ]; then pip install -r scripts/requirements; fi 34 | - name: Run script 35 | run: | 36 | python3 scripts/create_checklists.py 37 | - name: Commit and push 38 | uses: EndBug/add-and-commit@v9 39 | with: 40 | message: Update checklists 41 | add: "checklists/*" 42 | push: true 43 | -------------------------------------------------------------------------------- /.github/workflows/mdbook.yml: -------------------------------------------------------------------------------- 1 | name: Deploy mdBook to GH Pages 2 | 3 | on: 4 | # Runs on pushes targeting the main branch, only if files in the src directory were changed 5 | push: 6 | branches: ["main"] 7 | 8 | # Allows to run this workflow manually from the actions tab 9 | workflow_dispatch: 10 | 11 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages 12 | permissions: 13 | contents: read 14 | pages: write 15 | id-token: write 16 | 17 | # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. 18 | # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. 19 | concurrency: 20 | group: "pages" 21 | cancel-in-progress: false 22 | 23 | jobs: 24 | # Build job 25 | build: 26 | runs-on: ubuntu-latest 27 | env: 28 | MDBOOK_VERSION: 0.4.21 29 | steps: 30 | - uses: actions/checkout@v3 31 | - name: Install mdBook 32 | run: | 33 | curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf -y | sh 34 | rustup update 35 | cargo install --version ${MDBOOK_VERSION} mdbook 36 | - name: Prepare mdBook build 37 | run: bash ./scripts/mdbook_prepare.sh 38 | - name: Build with mdBook 39 | run: mdbook build 40 | - name: Clean up mdBook build 41 | run: bash ./scripts/mdbook_cleanup.sh 42 | - name: Setup Pages 43 | id: pages 44 | uses: actions/configure-pages@v3 45 | - name: Upload artifact 46 | uses: actions/upload-pages-artifact@v2 47 | with: 48 | path: ./book 49 | 50 | # Deployment job 51 | deploy: 52 | environment: 53 | name: github-pages 54 | url: ${{ steps.deployment.outputs.page_url }} 55 | runs-on: ubuntu-latest 56 | needs: build 57 | steps: 58 | - name: Deploy to GitHub Pages 59 | id: deployment 60 | uses: actions/deploy-pages@v2 61 | -------------------------------------------------------------------------------- /.github/workflows/scorecard.yml: -------------------------------------------------------------------------------- 1 | # This workflow uses actions that are not certified by GitHub. They are provided 2 | # by a third-party and are governed by separate terms of service, privacy 3 | # policy, and support documentation. 4 | 5 | name: Scorecard supply-chain security 6 | on: 7 | # For Branch-Protection check. Only the default branch is supported. See 8 | # https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection 9 | branch_protection_rule: 10 | # To guarantee Maintained check is occasionally updated. See 11 | # https://github.com/ossf/scorecard/blob/main/docs/checks.md#maintained 12 | schedule: 13 | - cron: '38 18 * * 0' 14 | push: 15 | branches: [ "main" ] 16 | 17 | # Declare default permissions as read only. 18 | permissions: read-all 19 | 20 | jobs: 21 | analysis: 22 | name: Scorecard analysis 23 | runs-on: ubuntu-latest 24 | permissions: 25 | # Needed to upload the results to code-scanning dashboard. 26 | security-events: write 27 | # Needed to publish results and get a badge (see publish_results below). 28 | id-token: write 29 | # Uncomment the permissions below if installing in a private repository. 30 | # contents: read 31 | # actions: read 32 | 33 | steps: 34 | - name: "Checkout code" 35 | uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8 # v3.1.0 36 | with: 37 | persist-credentials: false 38 | 39 | - name: "Run analysis" 40 | uses: ossf/scorecard-action@e38b1902ae4f44df626f11ba0734b14fb91f8f86 # v2.1.2 41 | with: 42 | results_file: results.sarif 43 | results_format: sarif 44 | # (Optional) "write" PAT token. Uncomment the `repo_token` line below if: 45 | # - you want to enable the Branch-Protection check on a *public* repository, or 46 | # - you are installing Scorecard on a *private* repository 47 | # To create the PAT, follow the steps in https://github.com/ossf/scorecard-action#authentication-with-pat. 48 | # repo_token: ${{ secrets.SCORECARD_TOKEN }} 49 | 50 | # Public repositories: 51 | # - Publish results to OpenSSF REST API for easy access by consumers 52 | # - Allows the repository to include the Scorecard badge. 53 | # - See https://github.com/ossf/scorecard-action#publishing-results. 54 | # For private repositories: 55 | # - `publish_results` will always be set to `false`, regardless 56 | # of the value entered here. 57 | publish_results: true 58 | 59 | # Upload the results as artifacts (optional). Commenting out will disable uploads of run results in SARIF 60 | # format to the repository Actions tab. 61 | - name: "Upload artifact" 62 | uses: actions/upload-artifact@3cea5372237819ed00197afe530f5a7ea3e805c8 # v3.1.0 63 | with: 64 | name: SARIF file 65 | path: results.sarif 66 | retention-days: 5 67 | 68 | # Upload the results to GitHub's code scanning dashboard. 69 | - name: "Upload to code-scanning" 70 | uses: github/codeql-action/upload-sarif@17573ee1cc1b9d061760f3a006fc4aac4f944fd5 # v2.2.4 71 | with: 72 | sarif_file: results.sarif 73 | -------------------------------------------------------------------------------- /CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # Changelog 2 | 3 | Changelogs are available as part of the releases, see [Releases page](https://github.com/OWASP/owasp-istg/releases). -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | 2 | Attribution-ShareAlike 4.0 International 3 | 4 | ======================================================================= 5 | 6 | Creative Commons Corporation ("Creative Commons") is not a law firm and 7 | does not provide legal services or legal advice. Distribution of 8 | Creative Commons public licenses does not create a lawyer-client or 9 | other relationship. Creative Commons makes its licenses and related 10 | information available on an "as-is" basis. Creative Commons gives no 11 | warranties regarding its licenses, any material licensed under their 12 | terms and conditions, or any related information. Creative Commons 13 | disclaims all liability for damages resulting from their use to the 14 | fullest extent possible. 15 | 16 | Using Creative Commons Public Licenses 17 | 18 | Creative Commons public licenses provide a standard set of terms and 19 | conditions that creators and other rights holders may use to share 20 | original works of authorship and other material subject to copyright 21 | and certain other rights specified in the public license below. The 22 | following considerations are for informational purposes only, are not 23 | exhaustive, and do not form part of our licenses. 24 | 25 | Considerations for licensors: Our public licenses are 26 | intended for use by those authorized to give the public 27 | permission to use material in ways otherwise restricted by 28 | copyright and certain other rights. Our licenses are 29 | irrevocable. Licensors should read and understand the terms 30 | and conditions of the license they choose before applying it. 31 | Licensors should also secure all rights necessary before 32 | applying our licenses so that the public can reuse the 33 | material as expected. Licensors should clearly mark any 34 | material not subject to the license. This includes other CC- 35 | licensed material, or material used under an exception or 36 | limitation to copyright. More considerations for licensors: 37 | wiki.creativecommons.org/Considerations_for_licensors 38 | 39 | Considerations for the public: By using one of our public 40 | licenses, a licensor grants the public permission to use the 41 | licensed material under specified terms and conditions. If 42 | the licensor's permission is not necessary for any reason--for 43 | example, because of any applicable exception or limitation to 44 | copyright--then that use is not regulated by the license. Our 45 | licenses grant only permissions under copyright and certain 46 | other rights that a licensor has authority to grant. Use of 47 | the licensed material may still be restricted for other 48 | reasons, including because others have copyright or other 49 | rights in the material. A licensor may make special requests, 50 | such as asking that all changes be marked or described. 51 | Although not required by our licenses, you are encouraged to 52 | respect those requests where reasonable. More considerations 53 | for the public: 54 | wiki.creativecommons.org/Considerations_for_licensees 55 | 56 | ======================================================================= 57 | 58 | Creative Commons Attribution-ShareAlike 4.0 International Public 59 | License 60 | 61 | By exercising the Licensed Rights (defined below), You accept and agree 62 | to be bound by the terms and conditions of this Creative Commons 63 | Attribution-ShareAlike 4.0 International Public License ("Public 64 | License"). To the extent this Public License may be interpreted as a 65 | contract, You are granted the Licensed Rights in consideration of Your 66 | acceptance of these terms and conditions, and the Licensor grants You 67 | such rights in consideration of benefits the Licensor receives from 68 | making the Licensed Material available under these terms and 69 | conditions. 70 | 71 | 72 | Section 1 -- Definitions. 73 | 74 | a. Adapted Material means material subject to Copyright and Similar 75 | Rights that is derived from or based upon the Licensed Material 76 | and in which the Licensed Material is translated, altered, 77 | arranged, transformed, or otherwise modified in a manner requiring 78 | permission under the Copyright and Similar Rights held by the 79 | Licensor. For purposes of this Public License, where the Licensed 80 | Material is a musical work, performance, or sound recording, 81 | Adapted Material is always produced where the Licensed Material is 82 | synched in timed relation with a moving image. 83 | 84 | b. Adapter's License means the license You apply to Your Copyright 85 | and Similar Rights in Your contributions to Adapted Material in 86 | accordance with the terms and conditions of this Public License. 87 | 88 | c. BY-SA Compatible License means a license listed at 89 | creativecommons.org/compatiblelicenses, approved by Creative 90 | Commons as essentially the equivalent of this Public License. 91 | 92 | d. Copyright and Similar Rights means copyright and/or similar rights 93 | closely related to copyright including, without limitation, 94 | performance, broadcast, sound recording, and Sui Generis Database 95 | Rights, without regard to how the rights are labeled or 96 | categorized. For purposes of this Public License, the rights 97 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 98 | Rights. 99 | 100 | e. Effective Technological Measures means those measures that, in the 101 | absence of proper authority, may not be circumvented under laws 102 | fulfilling obligations under Article 11 of the WIPO Copyright 103 | Treaty adopted on December 20, 1996, and/or similar international 104 | agreements. 105 | 106 | f. Exceptions and Limitations means fair use, fair dealing, and/or 107 | any other exception or limitation to Copyright and Similar Rights 108 | that applies to Your use of the Licensed Material. 109 | 110 | g. License Elements means the license attributes listed in the name 111 | of a Creative Commons Public License. The License Elements of this 112 | Public License are Attribution and ShareAlike. 113 | 114 | h. Licensed Material means the artistic or literary work, database, 115 | or other material to which the Licensor applied this Public 116 | License. 117 | 118 | i. Licensed Rights means the rights granted to You subject to the 119 | terms and conditions of this Public License, which are limited to 120 | all Copyright and Similar Rights that apply to Your use of the 121 | Licensed Material and that the Licensor has authority to license. 122 | 123 | j. Licensor means the individual(s) or entity(ies) granting rights 124 | under this Public License. 125 | 126 | k. Share means to provide material to the public by any means or 127 | process that requires permission under the Licensed Rights, such 128 | as reproduction, public display, public performance, distribution, 129 | dissemination, communication, or importation, and to make material 130 | available to the public including in ways that members of the 131 | public may access the material from a place and at a time 132 | individually chosen by them. 133 | 134 | l. Sui Generis Database Rights means rights other than copyright 135 | resulting from Directive 96/9/EC of the European Parliament and of 136 | the Council of 11 March 1996 on the legal protection of databases, 137 | as amended and/or succeeded, as well as other essentially 138 | equivalent rights anywhere in the world. 139 | 140 | m. You means the individual or entity exercising the Licensed Rights 141 | under this Public License. Your has a corresponding meaning. 142 | 143 | 144 | Section 2 -- Scope. 145 | 146 | a. License grant. 147 | 148 | 1. Subject to the terms and conditions of this Public License, 149 | the Licensor hereby grants You a worldwide, royalty-free, 150 | non-sublicensable, non-exclusive, irrevocable license to 151 | exercise the Licensed Rights in the Licensed Material to: 152 | 153 | a. reproduce and Share the Licensed Material, in whole or 154 | in part; and 155 | 156 | b. produce, reproduce, and Share Adapted Material. 157 | 158 | 2. Exceptions and Limitations. For the avoidance of doubt, where 159 | Exceptions and Limitations apply to Your use, this Public 160 | License does not apply, and You do not need to comply with 161 | its terms and conditions. 162 | 163 | 3. Term. The term of this Public License is specified in Section 164 | 6(a). 165 | 166 | 4. Media and formats; technical modifications allowed. The 167 | Licensor authorizes You to exercise the Licensed Rights in 168 | all media and formats whether now known or hereafter created, 169 | and to make technical modifications necessary to do so. The 170 | Licensor waives and/or agrees not to assert any right or 171 | authority to forbid You from making technical modifications 172 | necessary to exercise the Licensed Rights, including 173 | technical modifications necessary to circumvent Effective 174 | Technological Measures. For purposes of this Public License, 175 | simply making modifications authorized by this Section 2(a) 176 | (4) never produces Adapted Material. 177 | 178 | 5. Downstream recipients. 179 | 180 | a. Offer from the Licensor -- Licensed Material. Every 181 | recipient of the Licensed Material automatically 182 | receives an offer from the Licensor to exercise the 183 | Licensed Rights under the terms and conditions of this 184 | Public License. 185 | 186 | b. Additional offer from the Licensor -- Adapted Material. 187 | Every recipient of Adapted Material from You 188 | automatically receives an offer from the Licensor to 189 | exercise the Licensed Rights in the Adapted Material 190 | under the conditions of the Adapter's License You apply. 191 | 192 | c. No downstream restrictions. You may not offer or impose 193 | any additional or different terms or conditions on, or 194 | apply any Effective Technological Measures to, the 195 | Licensed Material if doing so restricts exercise of the 196 | Licensed Rights by any recipient of the Licensed 197 | Material. 198 | 199 | 6. No endorsement. Nothing in this Public License constitutes or 200 | may be construed as permission to assert or imply that You 201 | are, or that Your use of the Licensed Material is, connected 202 | with, or sponsored, endorsed, or granted official status by, 203 | the Licensor or others designated to receive attribution as 204 | provided in Section 3(a)(1)(A)(i). 205 | 206 | b. Other rights. 207 | 208 | 1. Moral rights, such as the right of integrity, are not 209 | licensed under this Public License, nor are publicity, 210 | privacy, and/or other similar personality rights; however, to 211 | the extent possible, the Licensor waives and/or agrees not to 212 | assert any such rights held by the Licensor to the limited 213 | extent necessary to allow You to exercise the Licensed 214 | Rights, but not otherwise. 215 | 216 | 2. Patent and trademark rights are not licensed under this 217 | Public License. 218 | 219 | 3. To the extent possible, the Licensor waives any right to 220 | collect royalties from You for the exercise of the Licensed 221 | Rights, whether directly or through a collecting society 222 | under any voluntary or waivable statutory or compulsory 223 | licensing scheme. In all other cases the Licensor expressly 224 | reserves any right to collect such royalties. 225 | 226 | 227 | Section 3 -- License Conditions. 228 | 229 | Your exercise of the Licensed Rights is expressly made subject to the 230 | following conditions. 231 | 232 | a. Attribution. 233 | 234 | 1. If You Share the Licensed Material (including in modified 235 | form), You must: 236 | 237 | a. retain the following if it is supplied by the Licensor 238 | with the Licensed Material: 239 | 240 | i. identification of the creator(s) of the Licensed 241 | Material and any others designated to receive 242 | attribution, in any reasonable manner requested by 243 | the Licensor (including by pseudonym if 244 | designated); 245 | 246 | ii. a copyright notice; 247 | 248 | iii. a notice that refers to this Public License; 249 | 250 | iv. a notice that refers to the disclaimer of 251 | warranties; 252 | 253 | v. a URI or hyperlink to the Licensed Material to the 254 | extent reasonably practicable; 255 | 256 | b. indicate if You modified the Licensed Material and 257 | retain an indication of any previous modifications; and 258 | 259 | c. indicate the Licensed Material is licensed under this 260 | Public License, and include the text of, or the URI or 261 | hyperlink to, this Public License. 262 | 263 | 2. You may satisfy the conditions in Section 3(a)(1) in any 264 | reasonable manner based on the medium, means, and context in 265 | which You Share the Licensed Material. For example, it may be 266 | reasonable to satisfy the conditions by providing a URI or 267 | hyperlink to a resource that includes the required 268 | information. 269 | 270 | 3. If requested by the Licensor, You must remove any of the 271 | information required by Section 3(a)(1)(A) to the extent 272 | reasonably practicable. 273 | 274 | b. ShareAlike. 275 | 276 | In addition to the conditions in Section 3(a), if You Share 277 | Adapted Material You produce, the following conditions also apply. 278 | 279 | 1. The Adapter's License You apply must be a Creative Commons 280 | license with the same License Elements, this version or 281 | later, or a BY-SA Compatible License. 282 | 283 | 2. You must include the text of, or the URI or hyperlink to, the 284 | Adapter's License You apply. You may satisfy this condition 285 | in any reasonable manner based on the medium, means, and 286 | context in which You Share Adapted Material. 287 | 288 | 3. You may not offer or impose any additional or different terms 289 | or conditions on, or apply any Effective Technological 290 | Measures to, Adapted Material that restrict exercise of the 291 | rights granted under the Adapter's License You apply. 292 | 293 | 294 | Section 4 -- Sui Generis Database Rights. 295 | 296 | Where the Licensed Rights include Sui Generis Database Rights that 297 | apply to Your use of the Licensed Material: 298 | 299 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 300 | to extract, reuse, reproduce, and Share all or a substantial 301 | portion of the contents of the database; 302 | 303 | b. if You include all or a substantial portion of the database 304 | contents in a database in which You have Sui Generis Database 305 | Rights, then the database in which You have Sui Generis Database 306 | Rights (but not its individual contents) is Adapted Material, 307 | including for purposes of Section 3(b); and 308 | 309 | c. You must comply with the conditions in Section 3(a) if You Share 310 | all or a substantial portion of the contents of the database. 311 | 312 | For the avoidance of doubt, this Section 4 supplements and does not 313 | replace Your obligations under this Public License where the Licensed 314 | Rights include other Copyright and Similar Rights. 315 | 316 | 317 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 318 | 319 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 320 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 321 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 322 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 323 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 324 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 325 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 326 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 327 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 328 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 329 | 330 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 331 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 332 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 333 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 334 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 335 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 336 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 337 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 338 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 339 | 340 | c. The disclaimer of warranties and limitation of liability provided 341 | above shall be interpreted in a manner that, to the extent 342 | possible, most closely approximates an absolute disclaimer and 343 | waiver of all liability. 344 | 345 | 346 | Section 6 -- Term and Termination. 347 | 348 | a. This Public License applies for the term of the Copyright and 349 | Similar Rights licensed here. However, if You fail to comply with 350 | this Public License, then Your rights under this Public License 351 | terminate automatically. 352 | 353 | b. Where Your right to use the Licensed Material has terminated under 354 | Section 6(a), it reinstates: 355 | 356 | 1. automatically as of the date the violation is cured, provided 357 | it is cured within 30 days of Your discovery of the 358 | violation; or 359 | 360 | 2. upon express reinstatement by the Licensor. 361 | 362 | For the avoidance of doubt, this Section 6(b) does not affect any 363 | right the Licensor may have to seek remedies for Your violations 364 | of this Public License. 365 | 366 | c. For the avoidance of doubt, the Licensor may also offer the 367 | Licensed Material under separate terms or conditions or stop 368 | distributing the Licensed Material at any time; however, doing so 369 | will not terminate this Public License. 370 | 371 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 372 | License. 373 | 374 | 375 | Section 7 -- Other Terms and Conditions. 376 | 377 | a. The Licensor shall not be bound by any additional or different 378 | terms or conditions communicated by You unless expressly agreed. 379 | 380 | b. Any arrangements, understandings, or agreements regarding the 381 | Licensed Material not stated herein are separate from and 382 | independent of the terms and conditions of this Public License. 383 | 384 | 385 | Section 8 -- Interpretation. 386 | 387 | a. For the avoidance of doubt, this Public License does not, and 388 | shall not be interpreted to, reduce, limit, restrict, or impose 389 | conditions on any use of the Licensed Material that could lawfully 390 | be made without permission under this Public License. 391 | 392 | b. To the extent possible, if any provision of this Public License is 393 | deemed unenforceable, it shall be automatically reformed to the 394 | minimum extent necessary to make it enforceable. If the provision 395 | cannot be reformed, it shall be severed from this Public License 396 | without affecting the enforceability of the remaining terms and 397 | conditions. 398 | 399 | c. No term or condition of this Public License will be waived and no 400 | failure to comply consented to unless expressly agreed to by the 401 | Licensor. 402 | 403 | d. Nothing in this Public License constitutes or may be interpreted 404 | as a limitation upon, or waiver of, any privileges and immunities 405 | that apply to the Licensor or You, including from the legal 406 | processes of any jurisdiction or authority. 407 | 408 | 409 | ======================================================================= 410 | 411 | Creative Commons is not a party to its public 412 | licenses. Notwithstanding, Creative Commons may elect to apply one of 413 | its public licenses to material it publishes and in those instances 414 | will be considered the “Licensor.” The text of the Creative Commons 415 | public licenses is dedicated to the public domain under the CC0 Public 416 | Domain Dedication. Except for the limited purpose of indicating that 417 | material is shared under a Creative Commons public license or as 418 | otherwise permitted by the Creative Commons policies published at 419 | creativecommons.org/policies, Creative Commons does not authorize the 420 | use of the trademark "Creative Commons" or any other trademark or logo 421 | of Creative Commons without its prior written consent including, 422 | without limitation, in connection with any unauthorized modifications 423 | to any of its public licenses or any other arrangements, 424 | understandings, or agreements concerning use of licensed material. For 425 | the avoidance of doubt, this paragraph does not form part of the 426 | public licenses. 427 | 428 | Creative Commons may be contacted at creativecommons.org. 429 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # OWASP IoT Security Testing Guide 4 | 5 | [![CC BY-SA 4.0][cc-by-sa-shield]][cc-by-sa] [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/8419/badge)](https://www.bestpractices.dev/projects/8419) 6 | 7 | The OWASP IoT Security Testing Guide provides a comprehensive methodology for penetration tests in the IoT field offering flexibility to adapt innovations and developments on the IoT market while still ensuring comparability of test results. The guide provides an understanding of communication between manufacturers and operators of IoT devices as well as penetration testing teams that’s facilitated by establishing a common terminology. 8 | 9 | Security assurance and test coverage can be demonstrated with the overview of IoT components and test case categories applicable to each below. The methodology, underlying models, and catalog of test cases present tools that can be used separately and in conjunction with each other. 10 | 11 | 12 | 13 | ![Component Overview](src/img/Component_Overview.png) 14 | 15 | 16 | 17 | 18 | - 🔔[Click here to read the OWASP ISTG 📖📚]( https://owasp.org/owasp-istg/)🔔 19 | - ✅ [Get the latest ISTG Checklists](https://github.com/OWASP/owasp-istg/tree/main/checklists)✅ 20 | - 📝 🔍 [Contribute to ISTG](https://owasp.org/www-project-iot-security-testing-guide/#div-contributing) 21 | 22 | 23 | 24 | ## Table of Contents 25 | 26 | 1. [**Introduction**](./src/01_introduction/README.md) 27 | 28 | 2. [**IoT Security Testing Framework**](./src/02_framework/README.md) 29 | 30 | 2.1. [IoT Device Model](./src/02_framework/device_model.md) 31 | 32 | 2.2. [Attacker Model](./src/02_framework/attacker_model.md) 33 | 34 | 2.3. [Testing Methodology](./src/02_framework/methodology.md) 35 | 36 | 3. [**Test Case Catalog**](./src/03_test_cases/README.md) 37 | 38 | 3.1. [Processing Units (ISTG-PROC)](./src/03_test_cases/processing_units/README.md) 39 | 40 | 3.2. [Memory (ISTG-MEM)](./src/03_test_cases/memory/README.md) 41 | 42 | 3.3. [Firmware (ISTG-FW)](./src/03_test_cases/firmware/README.md) 43 | 44 | 3.3.1. [Installed Firmware (ISTG-FW[INST])](./src/03_test_cases/firmware/installed_firmware.md) 45 | 46 | 3.3.1. [Firmware Update Mechnanism (ISTG-FW[UPDT])](./src/03_test_cases/firmware/firmware_update_mechanism.md) 47 | 48 | 3.4. [Data Exchange Services (ISTG-DES)](./src/03_test_cases/data_exchange_services/README.md) 49 | 50 | 3.5. [Internal Interfaces (ISTG-INT)](./src/03_test_cases/internal_interfaces/README.md) 51 | 52 | 3.6. [Physical Interfaces (ISTG-PHY)](./src/03_test_cases/physical_interfaces/README.md) 53 | 54 | 3.7. [Wireless Interfaces (ISTG-WRLS)](./src/03_test_cases/wireless_interfaces/README.md) 55 | 56 | 3.8. [User Interfaces (ISTG-UI)](./src/03_test_cases/user_interfaces/README.md) 57 | 58 | 59 | 60 | ## Related Work 61 | 62 | The concepts, models and test steps presented in the OWASP IoT Security Testing Guide are based on the master's thesis **"Development of a Methodology for Penetration Tests of Devices in the Field of the Internet of Things"** by Luca Pascal Rotsch. 63 | 64 | 65 | 66 | Test cases were derived from the following public sources: 67 | 68 | * OWASP [**"Web Security Testing Guide"**][owasp_wstg] 69 | * OWASP [**"Firmware Security Testing Methodology"**][owasp_fstm] 70 | * OWASP [**"Mobile Security Testing Guide"**][owasp_mstg] 71 | * [**"IoT Pentesting Guide"**][iot_pentesting_guide] by Aditya Gupta 72 | * [**"IoT Penetration Testing Cookbook"**][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 73 | * [**"The IoT Hacker's Handbook"**][iot_hackers_handbook] by Aditya Gupta 74 | * [**"Practical IoT Hacking"**][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 75 | * further sources are referenced in the respective test cases 76 | 77 | 78 | 79 | **We also like to thank our collaborators and supporters (see [Project Collaborators and Acknowledgements](./acknowledgements.md))!** 80 | 81 | 82 | 83 | [cc-by-sa]: http://creativecommons.org/licenses/by-sa/4.0/ 84 | [cc-by-sa-shield]: https://img.shields.io/badge/License-CC%20BY--SA%204.0-lightgrey.svg 85 | [owasp_wstg]: https://owasp.org/www-project-web-security-testing-guide/ "OWASP Web Security Testing Guide" 86 | [owasp_fstm]: https://github.com/scriptingxss/owasp-fstm "OWASP Firmware Security Testing Methodology" 87 | [owasp_mstg]: https://owasp.org/www-project-mobile-security-testing-guide/ "OWASP Mobile Security Testing Guide" 88 | [iot_pentesting_guide]: https://www.iotpentestingguide.com "IoT Pentesting Guide" 89 | [iot_penetration_testing_cookbook]: https://www.packtpub.com/product/iot-penetration-testing-cookbook/9781787280571 "IoT Penetration Testing Cookbook" 90 | [iot_hackers_handbook]: https://link.springer.com/book/10.1007/978-1-4842-4300-8 "The IoT Hacker's Handbook" 91 | [practical_iot_hacking]: https://nostarch.com/practical-iot-hacking "Practical IoT Hacking" 92 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # Security Policy 2 | 3 | ## Reporting a Vulnerability 4 | 5 | To report a vulnerability for this project, please create an issue following guidance described in the following page: https://owasp.org/www-project-iot-security-testing-guide/#div-contributing 6 | -------------------------------------------------------------------------------- /acknowledgements.md: -------------------------------------------------------------------------------- 1 | # Project Collaborators and Acknowledgements 2 | 3 | We would like to take this opportunity to acknowledge the contributions of our collaborators and supporters who volunteered their time and expertise to this project. Thank you for your support and commitment to IoT security! This guide would not have been possible without you. 4 | 5 | * Antje Winkler 6 | * Clemens Keil 7 | * Denny Vogt (Pyxon73) 8 | * Manfred Heinz (zaphoxx aka CptSpiff) 9 | * Martin Weißbach 10 | * Patrick "HomeSen" Walker 11 | * Sebastian Döring -------------------------------------------------------------------------------- /book.toml: -------------------------------------------------------------------------------- 1 | [book] 2 | title = "OWASP IoT Security Testing Guide" 3 | authors = ["Luca Pascal Rotsch", "Aaron Guzman"] 4 | description = "The OWASP IoT Security Testing Guide provides a comprehensive methodology for penetration tests in the IoT field." 5 | src = "src" 6 | language = "en" 7 | 8 | [build] 9 | build-dir = "book" 10 | create-missing = false 11 | -------------------------------------------------------------------------------- /checklists/checklist.md: -------------------------------------------------------------------------------- 1 | # Testing Checklist 2 | 3 | The following is the list of items to test during the assessment: 4 | 5 | Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A". 6 | 7 | 8 | ## Processing Units (ISTG-PROC) 9 | |Test ID|Test Name|Status|Notes| 10 | |-|-|-|-| 11 | |**ISTG-PROC-AUTHZ**|**Authorization**||| 12 | |ISTG-PROC-AUTHZ-001|Unauthorized Access to the Processing Unit||| 13 | |ISTG-PROC-AUTHZ-002|Privilege Escalation||| 14 | |**ISTG-PROC-LOGIC**|**Business Logic**||| 15 | |ISTG-PROC-LOGIC-001|Insecure Implementation of Instructions||| 16 | |**ISTG-PROC-SIDEC**|**Side-Channel Attacks**||| 17 | |ISTG-PROC-SIDEC-001|Insufficient Protection Against Side-Channel Attacks||| 18 | 19 | ## Memory (ISTG-MEM) 20 | |Test ID|Test Name|Status|Notes| 21 | |-|-|-|-| 22 | |**ISTG-MEM-INFO**|**Information Gathering**||| 23 | |ISTG-MEM-INFO-001|Disclosure of Source Code and Binaries||| 24 | |ISTG-MEM-INFO-002|Disclosure of Implementation Details||| 25 | |ISTG-MEM-INFO-003|Disclosure of Ecosystem Details||| 26 | |ISTG-MEM-INFO-004|Disclosure of User Data||| 27 | |**ISTG-MEM-SCRT**|**Secrets**||| 28 | |ISTG-MEM-SCRT-001|Unencrypted Storage of Secrets||| 29 | |**ISTG-MEM-CRYPT**|**Cryptography**||| 30 | |ISTG-MEM-CRYPT-001|Usage of Weak Cryptographic Algorithms||| 31 | 32 | ## Firmware (ISTG-FW) 33 | |Test ID|Test Name|Status|Notes| 34 | |-|-|-|-| 35 | |**ISTG-FW-INFO**|**Information Gathering**||| 36 | |ISTG-FW-INFO-001|Disclosure of Source Code and Binaries||| 37 | |ISTG-FW-INFO-002|Disclosure of Implementation Details||| 38 | |ISTG-FW-INFO-003|Disclosure of Ecosystem Details||| 39 | |**ISTG-FW-CONF**|**Configuration and Patch Management**||| 40 | |ISTG-FW-CONF-001|Usage of Outdated Software||| 41 | |ISTG-FW-CONF-002|Presence of Unnecessary Software and Functionalities||| 42 | |**ISTG-FW-SCRT**|**Secrets**||| 43 | |ISTG-FW-SCRT-001|Secrets Stored in Public Storage||| 44 | |ISTG-FW-SCRT-002|Unencrypted Storage of Secrets||| 45 | |ISTG-FW-SCRT-003|Usage of Hardcoded Secrets||| 46 | |**ISTG-FW-CRYPT**|**Cryptography**||| 47 | |ISTG-FW-CRYPT-001|Usage of Weak Cryptographic Algorithms||| 48 | 49 | ### Installed Firmware (ISTG-FW[INST]) 50 | |Test ID|Test Name|Status|Notes| 51 | |-|-|-|-| 52 | |**ISTG-FW[INST]-AUTHZ**|**Authorization**||| 53 | |ISTG-FW[INST]-AUTHZ-001|Unauthorized Access to the Firmware||| 54 | |ISTG-FW[INST]-AUTHZ-002|Privilege Escalation||| 55 | |**ISTG-FW[INST]-INFO**|**Information Gathering**||| 56 | |ISTG-FW[INST]-INFO-001|Disclosure of User Data||| 57 | |**ISTG-FW[INST]-CRYPT**|**Cryptography**||| 58 | |ISTG-FW[INST]-CRYPT-001|Insufficient Verification of the Bootloader Signature||| 59 | 60 | ### Firmware Update Mechanism (ISTG-FW[UPDT]) 61 | |Test ID|Test Name|Status|Notes| 62 | |-|-|-|-| 63 | |**ISTG-FW[UPDT]-AUTHZ**|**Authorization**||| 64 | |ISTG-FW[UPDT]-AUTHZ-001|Unauthorized Firmware Update||| 65 | |**ISTG-FW[UPDT]-CRYPT**|**Cryptography**||| 66 | |ISTG-FW[UPDT]-CRYPT-001|Insufficient Firmware Update Signature||| 67 | |ISTG-FW[UPDT]-CRYPT-002|Insufficient Firmware Update Encryption||| 68 | |ISTG-FW[UPDT]-CRYPT-003|Insecure Transmission of the Firmware Update||| 69 | |ISTG-FW[UPDT]-CRYPT-004|Insufficient Verification of the Firmware Update Signature||| 70 | |**ISTG-FW[UPDT]-LOGIC**|**Business Logic**||| 71 | |ISTG-FW[UPDT]-LOGIC-001|Insufficient Rollback Protection||| 72 | 73 | ## Data Exchange Services (ISTG-DES) 74 | |Test ID|Test Name|Status|Notes| 75 | |-|-|-|-| 76 | |**ISTG-DES-AUTHZ**|**Authorization**||| 77 | |ISTG-DES-AUTHZ-001|Unauthorized Access to the Data Exchange Service||| 78 | |ISTG-DES-AUTHZ-002|Privilege Escalation||| 79 | |**ISTG-DES-INFO**|**Information Gathering**||| 80 | |ISTG-DES-INFO-001|Disclosure of Implementation Details||| 81 | |ISTG-DES-INFO-002|Disclosure of Ecosystem Details||| 82 | |ISTG-DES-INFO-003|Disclosure of User Data||| 83 | |**ISTG-DES-CONF**|**Configuration and Patch Management**||| 84 | |ISTG-DES-CONF-001|Usage of Outdated Software||| 85 | |ISTG-DES-CONF-002|Presence of Unnecessary Software and Functionalities||| 86 | |**ISTG-DES-SCRT**|**Secrets**||| 87 | |ISTG-DES-SCRT-001|Access to Confidential Data||| 88 | |**ISTG-DES-CRYPT**|**Cryptography**||| 89 | |ISTG-DES-CRYPT-001|Usage of Weak Cryptographic Algorithms||| 90 | |**ISTG-DES-LOGIC**|**Business Logic**||| 91 | |ISTG-DES-LOGIC-001|Circumvention of the Intended Business Logic||| 92 | |**ISTG-DES-INPV**|**Input Validation**||| 93 | |ISTG-DES-INPV-001|Insufficient Input Validation||| 94 | |ISTG-DES-INPV-002|Code or Command Injection||| 95 | 96 | ## Internal Interfaces (ISTG-INT) 97 | |Test ID|Test Name|Status|Notes| 98 | |-|-|-|-| 99 | |**ISTG-INT-AUTHZ**|**Authorization**||| 100 | |ISTG-INT-AUTHZ-001|Unauthorized Access to the Interface||| 101 | |ISTG-INT-AUTHZ-002|Privilege Escalation||| 102 | |**ISTG-INT-INFO**|**Information Gathering**||| 103 | |ISTG-INT-INFO-001|Disclosure of Implementation Details||| 104 | |ISTG-INT-INFO-002|Disclosure of Ecosystem Details||| 105 | |ISTG-INT-INFO-003|Disclosure of User Data||| 106 | |**ISTG-INT-CONF**|**Configuration and Patch Management**||| 107 | |ISTG-INT-CONF-001|Usage of Outdated Software||| 108 | |ISTG-INT-CONF-002|Presence of Unnecessary Software and Functionalities||| 109 | |**ISTG-INT-SCRT**|**Secrets**||| 110 | |ISTG-INT-SCRT-001|Access to Confidential Data||| 111 | |**ISTG-INT-CRYPT**|**Cryptography**||| 112 | |ISTG-INT-CRYPT-001|Usage of Weak Cryptographic Algorithms||| 113 | |**ISTG-INT-LOGIC**|**Business Logic**||| 114 | |ISTG-INT-LOGIC-001|Circumvention of the Intended Business Logic||| 115 | |**ISTG-INT-INPV**|**Input Validation**||| 116 | |ISTG-INT-INPV-001|Insufficient Input Validation||| 117 | |ISTG-INT-INPV-002|Code or Command Injection||| 118 | 119 | ## Physical Interfaces (ISTG-PHY) 120 | |Test ID|Test Name|Status|Notes| 121 | |-|-|-|-| 122 | |**ISTG-PHY-AUTHZ**|**Authorization**||| 123 | |ISTG-PHY-AUTHZ-001|Unauthorized Access to the Interface||| 124 | |ISTG-PHY-AUTHZ-002|Privilege Escalation||| 125 | |**ISTG-PHY-INFO**|**Information Gathering**||| 126 | |ISTG-PHY-INFO-001|Disclosure of Implementation Details||| 127 | |ISTG-PHY-INFO-002|Disclosure of Ecosystem Details||| 128 | |ISTG-PHY-INFO-003|Disclosure of User Data||| 129 | |**ISTG-PHY-CONF**|**Configuration and Patch Management**||| 130 | |ISTG-PHY-CONF-001|Usage of Outdated Software||| 131 | |ISTG-PHY-CONF-002|Presence of Unnecessary Software and Functionalities||| 132 | |**ISTG-PHY-SCRT**|**Secrets**||| 133 | |ISTG-PHY-SCRT-001|Access to Confidential Data||| 134 | |**ISTG-PHY-CRYPT**|**Cryptography**||| 135 | |ISTG-PHY-CRYPT-001|Usage of Weak Cryptographic Algorithms||| 136 | |**ISTG-PHY-LOGIC**|**Business Logic**||| 137 | |ISTG-PHY-LOGIC-001|Circumvention of the Intended Business Logic||| 138 | |**ISTG-PHY-INPV**|**Input Validation**||| 139 | |ISTG-PHY-INPV-001|Insufficient Input Validation||| 140 | |ISTG-PHY-INPV-002|Code or Command Injection||| 141 | 142 | ## Wireless Interfaces (ISTG-WRLS) 143 | |Test ID|Test Name|Status|Notes| 144 | |-|-|-|-| 145 | |**ISTG-WRLS-AUTHZ**|**Authorization**||| 146 | |ISTG-WRLS-AUTHZ-001|Unauthorized Access to the Interface||| 147 | |ISTG-WRLS-AUTHZ-002|Privilege Escalation||| 148 | |**ISTG-WRLS-INFO**|**Information Gathering**||| 149 | |ISTG-WRLS-INFO-001|Disclosure of Implementation Details||| 150 | |ISTG-WRLS-INFO-002|Disclosure of Ecosystem Details||| 151 | |ISTG-WRLS-INFO-003|Disclosure of User Data||| 152 | |**ISTG-WRLS-CONF**|**Configuration and Patch Management**||| 153 | |ISTG-WRLS-CONF-001|Usage of Outdated Software||| 154 | |ISTG-WRLS-CONF-002|Presence of Unnecessary Software and Functionalities||| 155 | |**ISTG-WRLS-SCRT**|**Secrets**||| 156 | |ISTG-WRLS-SCRT-001|Access to Confidential Data||| 157 | |**ISTG-WRLS-CRYPT**|**Cryptography**||| 158 | |ISTG-WRLS-CRYPT-001|Usage of Weak Cryptographic Algorithms||| 159 | |**ISTG-WRLS-LOGIC**|**Business Logic**||| 160 | |ISTG-WRLS-LOGIC-001|Circumvention of the Intended Business Logic||| 161 | |**ISTG-WRLS-INPV**|**Input Validation**||| 162 | |ISTG-WRLS-INPV-001|Insufficient Input Validation||| 163 | |ISTG-WRLS-INPV-002|Code or Command Injection||| 164 | 165 | ## User Interfaces (ISTG-UI) 166 | |Test ID|Test Name|Status|Notes| 167 | |-|-|-|-| 168 | |**ISTG-UI-AUTHZ**|**Authorization**||| 169 | |ISTG-UI-AUTHZ-001|Unauthorized Access to the Interface||| 170 | |ISTG-UI-AUTHZ-002|Privilege Escalation||| 171 | |**ISTG-UI-INFO**|**Information Gathering**||| 172 | |ISTG-UI-INFO-001|Disclosure of Implementation Details||| 173 | |ISTG-UI-INFO-002|Disclosure of Ecosystem Details||| 174 | |ISTG-UI-INFO-003|Disclosure of User Data||| 175 | |**ISTG-UI-CONF**|**Configuration and Patch Management**||| 176 | |ISTG-UI-CONF-001|Usage of Outdated Software||| 177 | |ISTG-UI-CONF-002|Presence of Unnecessary Software and Functionalities||| 178 | |**ISTG-UI-SCRT**|**Secrets**||| 179 | |ISTG-UI-SCRT-001|Access to Confidential Data||| 180 | |**ISTG-UI-CRYPT**|**Cryptography**||| 181 | |ISTG-UI-CRYPT-001|Usage of Weak Cryptographic Algorithms||| 182 | |**ISTG-UI-LOGIC**|**Business Logic**||| 183 | |ISTG-UI-LOGIC-001|Circumvention of the Intended Business Logic||| 184 | |**ISTG-UI-INPV**|**Input Validation**||| 185 | |ISTG-UI-INPV-001|Insufficient Input Validation||| 186 | |ISTG-UI-INPV-002|Code or Command Injection||| 187 | -------------------------------------------------------------------------------- /checklists/checklist.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/checklists/checklist.xlsx -------------------------------------------------------------------------------- /resources/istg_cover.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/resources/istg_cover.pdf -------------------------------------------------------------------------------- /resources/istg_cover.pub: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/resources/istg_cover.pub -------------------------------------------------------------------------------- /resources/istg_cover_image.drawio: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | -------------------------------------------------------------------------------- /resources/istg_cover_image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/resources/istg_cover_image.png -------------------------------------------------------------------------------- /roadmap.md: -------------------------------------------------------------------------------- 1 | # Roadmap 2 | 3 | - [x] **Milestone 0: Preparation of Project Draft Done** 4 | - [x] Create a markdown-based IoT Security Testing Guide draft 5 | - [x] Review of the draft, provide feedback - @ all collaborators 6 | - [x] Discuss and implement feedback - @ all collaborators 7 | - [x] Review changes and, if needed, iteratively repeat the previous steps - @ all collaborators 8 | - [x] Prepare OWASP project requirements - @ all collaborators 9 | - [x] **Milestone 1: OWASP IoT Security Testing Guide Project Launched** 10 | - [x] Submit OWASP project request - @ project leaders 11 | - [x] Approve project request and provide project repositories - @ OWASP project board 12 | - [x] Set up project repositories - @ project leaders 13 | - [x] Peer review of project draft, provide feedback - @ public, all collaborators 14 | - [x] Discuss and implement feedback - @ all collaborators 15 | - [x] Review changes and, if needed, iteratively repeat the previous steps - @ all collaborators 16 | - [x] **Milestone 2: Project Team Established and Project Synced With other OWASP Projects** 17 | - [x] Meet and sync with other OWASP security testing guide leaders (WSTG, MASTG) - @ project leaders 18 | - [x] Prepare task tracking (Git Issues) to enable tracking, distribution and monitoring of tasks - @ project leaders 19 | - [x] Gather volunteers and establish project team - @ project leaders, project team 20 | - [x] **Milestone 3: Baseline Version Released** 21 | - [x] Gather feedback from the project team regarding draft version of the guide - @ project team 22 | - [x] Discuss and implement feedback - @ project team 23 | - [x] Review changes and, if needed, iteratively repeat the previous steps - @ project leaders, project team 24 | - [x] Approve and release baseline version - @ project leaders 25 | - [ ] **Milestone 4 - n: Continuous Development and Release of Modular Expansions** 26 | - [ ] Collect feedback and ideas for expansions; compile a list of technologies that future versions of the guide should cover - @ project leaders, project team 27 | - [ ] Prioritize technologies - @ project leaders, core team (feedback of project team welcome) 28 | - [ ] Assign team members to work on an expansion module - @ project leaders 29 | - [ ] Create a draft expansion module for this guide that includes detailed test cases for the given technology - @ expansion team 30 | - [ ] Review this draft, provide feedback - @ assigned reviewers 31 | - [ ] Discuss and implement feedback - @ expansion team 32 | - [ ] Review changes and, if needed, iteratively repeat the previous steps - @ assigned reviewers, expansion team 33 | - [ ] Approve and release expansion module - @ project leaders 34 | 35 | - [ ] Iteratively review, expand and update the prioritization list - @ project leaders, core team (feedback of project team welcome) 36 | 37 | 38 | 39 | 40 | ## Role Description 41 | 42 | | Role | Description | 43 | | ------------------- | ------------------------------------------------------------ | 44 | | OWASP project board | OWASP project board/committee that reviews and approves new project ideas | 45 | | Collaborators | All collaborators, who are working on the project | 46 | | Project leaders | OWASP project leaders | 47 | | Core team | Part of the team that monitors and updates the prioritized list of planned expansion modules
(depending on the project team size and feasibility either the whole project team or only a part of the team will be involved; feedback of all project team members is welcome) | 48 | | Expansion team | Part of the team that is working on a particular expansion module | 49 | | Assigned reviewers | Assigned team members, who are reviewing an expansion module draft | 50 | -------------------------------------------------------------------------------- /scripts/checklist_template.md: -------------------------------------------------------------------------------- 1 | # Testing Checklist 2 | 3 | The following is the list of items to test during the assessment: 4 | 5 | Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A". 6 | -------------------------------------------------------------------------------- /scripts/checklist_template.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/scripts/checklist_template.xlsx -------------------------------------------------------------------------------- /scripts/create_checklists.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3.10 2 | 3 | from os import walk 4 | from os.path import dirname, abspath, join 5 | from openpyxl import load_workbook 6 | 7 | 8 | ROOT_DIR = dirname(dirname(abspath(__file__))) 9 | 10 | CHECKLIST_DIR = join(ROOT_DIR, "checklists") 11 | TEST_CASE_DIR = join(ROOT_DIR, "src", "03_test_cases") 12 | TOOL_DIR = join(ROOT_DIR, "scripts") 13 | 14 | CHECKLIST_MARKDOWN = join(CHECKLIST_DIR, "checklist.md") 15 | CHECKLIST_TEMPLATE_MARKDOWN = join(TOOL_DIR, "checklist_template.md") 16 | 17 | CHECKLIST_EXCEL = join(CHECKLIST_DIR, "checklist.xlsx") 18 | CHECKLIST_TEMPLATE_EXCEL = join(TOOL_DIR, "checklist_template.xlsx") 19 | 20 | MD_TABLE_HEADER = "|Test ID|Test Name|Status|Notes|\n|-|-|-|-|\n" 21 | MD_STYLE_CATEGORY = "**" 22 | 23 | 24 | def main(): 25 | # step 1: parse test cases from markdown files 26 | test_case_catalog = parse_test_cases() 27 | 28 | # step 2: export test cases as checklists 29 | export_test_cases_markdown(test_case_catalog) 30 | export_test_cases_excel(test_case_catalog) 31 | 32 | 33 | def parse_test_cases(test_case_dir=TEST_CASE_DIR): 34 | test_case_catalog = {} 35 | 36 | # walk through directory structure of testing guide 37 | for (dirpath, dirnames, filenames) in walk(test_case_dir): 38 | 39 | # skip root directory of the test case chapter (first iteration of the loop) 40 | if dirpath != test_case_dir: 41 | component_id = None 42 | 43 | # each subdirectory of the test case chapter resembles a component (i.e., component directory) 44 | # each component directory should have a "README.md" file which includes all test cases for the component 45 | if "README.md" in filenames: 46 | test_cases_component = parse_file(join(dirpath, "README.md")) 47 | test_case_catalog = test_case_catalog | test_cases_component 48 | 49 | if len(test_cases_component.keys()) > 0: 50 | component_id = list(test_cases_component.keys())[0] 51 | 52 | # remove "README.md" from list of files to avoid parsing it two times 53 | filenames.remove("README.md") 54 | 55 | # only parse other files in the component directory if a component ID was set (meaning that the "README.md" file has been parsed successfully) 56 | if component_id is not None: 57 | 58 | # parse other files in the component directory 59 | # every file besides "README.md" resembles a component specialization 60 | for filename in filenames: 61 | 62 | test_cases_component_specialization = parse_file(join(dirpath, filename)) 63 | 64 | if "specializations" not in test_case_catalog[component_id]: 65 | test_case_catalog[component_id]["specializations"] = {} 66 | 67 | test_case_catalog[component_id]["specializations"] = test_case_catalog[component_id]["specializations"] | test_cases_component_specialization 68 | 69 | return test_case_catalog 70 | 71 | 72 | def parse_file(filepath): 73 | file = open(filepath, "r") 74 | content = {} 75 | 76 | # loop through each line in the file 77 | for line in file: 78 | 79 | # only parse headlines that have an ID 80 | if line[0] == "#" and "(" in line: 81 | 82 | # parse title 83 | title = line.split("# ")[1].split(" (")[0] 84 | 85 | # parse ID 86 | id = line.split("(")[1][0:-2] 87 | 88 | match line.count("#"): 89 | # title of component or component specialization 90 | case 1: 91 | chapter = title.split(" ")[0] 92 | title = title.split(". ")[1] 93 | 94 | content = { 95 | id: { 96 | "chapter": chapter, 97 | "title": title, 98 | "categories": {} 99 | } 100 | } 101 | 102 | # title of test case category 103 | case 2: 104 | component_id = "-".join(id.split("-")[0:-1]) 105 | content[component_id]["categories"][id] = { 106 | "title": title, 107 | "test_cases": {} 108 | } 109 | 110 | # title of test case 111 | case 3: 112 | component_id = "-".join(id.split("-")[0:-2]) 113 | category_id = "-".join(id.split("-")[0:-1]) 114 | content[component_id]["categories"][category_id]["test_cases"][id] = { 115 | "title": title 116 | } 117 | 118 | file.close() 119 | return content 120 | 121 | 122 | def sort_ids_by_chapter(content): 123 | sorted_content = {} 124 | for id in content: sorted_content[content[id]["chapter"]] = id 125 | return dict(sorted(sorted_content.items())).values() 126 | 127 | 128 | def export_test_cases_markdown(test_case_catalog, checklist=CHECKLIST_MARKDOWN, checklist_template=CHECKLIST_TEMPLATE_MARKDOWN): 129 | # read content from template 130 | file_template = open(checklist_template, "r") 131 | content_template = file_template.read() 132 | file_template.close() 133 | 134 | # add template content to output 135 | output = content_template + "\n" 136 | 137 | # loop through components 138 | for component_id in sort_ids_by_chapter(test_case_catalog): 139 | component_title = test_case_catalog[component_id]["title"] 140 | categories = test_case_catalog[component_id]["categories"] 141 | 142 | output += "\n## " + component_title + " (" + component_id + ")" + "\n" + MD_TABLE_HEADER 143 | 144 | # loop through categories 145 | for category_id in categories: 146 | test_cases = categories[category_id]["test_cases"] 147 | output += "|" + "|".join([MD_STYLE_CATEGORY + category_id + MD_STYLE_CATEGORY, MD_STYLE_CATEGORY + categories[category_id]["title"] + MD_STYLE_CATEGORY, "", "", "\n"]) 148 | 149 | # loop through test cases 150 | for test_case_id in test_cases: 151 | output += "|" + "|".join([test_case_id, test_cases[test_case_id]["title"], "", "", "\n"]) 152 | 153 | # loop through component specializations 154 | if "specializations" in test_case_catalog[component_id]: 155 | for specialization_id in sort_ids_by_chapter(test_case_catalog[component_id]["specializations"]): 156 | specialization_title = test_case_catalog[component_id]["specializations"][specialization_id]["title"] 157 | categories = test_case_catalog[component_id]["specializations"][specialization_id]["categories"] 158 | output += "\n### " + specialization_title + " (" + specialization_id + ")" + "\n" + MD_TABLE_HEADER 159 | 160 | # loop through categories 161 | for category_id in categories: 162 | test_cases = categories[category_id]["test_cases"] 163 | output += "|" + "|".join([MD_STYLE_CATEGORY + category_id + MD_STYLE_CATEGORY, 164 | MD_STYLE_CATEGORY + categories[category_id]["title"] + MD_STYLE_CATEGORY, 165 | "", "", "\n"]) 166 | 167 | # loop through test cases 168 | for test_case_id in test_cases: 169 | output += "|" + "|".join([test_case_id, test_cases[test_case_id]["title"], "", "", "\n"]) 170 | 171 | # write output to file 172 | file_checklist = open(checklist, "w") 173 | file_checklist.write(output) 174 | file_checklist.close() 175 | 176 | 177 | def export_test_cases_excel(test_case_catalog, checklist=CHECKLIST_EXCEL, checklist_template=CHECKLIST_TEMPLATE_EXCEL): 178 | # read content from template 179 | excel_wb = load_workbook(checklist_template) 180 | excel_ws = excel_wb["Checklist"] 181 | 182 | row = 2 183 | 184 | # loop through components 185 | for component_id in sort_ids_by_chapter(test_case_catalog): 186 | categories = test_case_catalog[component_id]["categories"] 187 | 188 | # loop through categories 189 | for category_id in categories: 190 | test_cases = categories[category_id]["test_cases"] 191 | 192 | # loop through test cases 193 | for test_case_id in test_cases: 194 | excel_ws["A" + str(row)] = test_case_id 195 | excel_ws["B" + str(row)] = test_case_catalog[component_id]["title"] 196 | excel_ws["C" + str(row)] = categories[category_id]["title"] 197 | excel_ws["D" + str(row)] = test_cases[test_case_id]["title"] 198 | row += 1 199 | 200 | # loop through component specializations 201 | if "specializations" in test_case_catalog[component_id]: 202 | for specialization_id in sort_ids_by_chapter(test_case_catalog[component_id]["specializations"]): 203 | categories = test_case_catalog[component_id]["specializations"][specialization_id]["categories"] 204 | 205 | # loop through categories 206 | for category_id in categories: 207 | test_cases = categories[category_id]["test_cases"] 208 | 209 | # loop through test cases 210 | for test_case_id in test_cases: 211 | excel_ws["A" + str(row)] = test_case_id 212 | excel_ws["B" + str(row)] = test_case_catalog[component_id]["specializations"][specialization_id]["title"] 213 | excel_ws["C" + str(row)] = categories[category_id]["title"] 214 | excel_ws["D" + str(row)] = test_cases[test_case_id]["title"] 215 | row += 1 216 | 217 | # write output to file 218 | excel_wb.save(checklist) 219 | 220 | 221 | main() 222 | -------------------------------------------------------------------------------- /scripts/mdbook_cleanup.sh: -------------------------------------------------------------------------------- 1 | rm ./src/README.md 2 | rm ./src/LICENSE.md 3 | rm ./src/acknowledgements.md 4 | 5 | find ./book/ -type f -name "*.html" -exec sed -i "s/README.html/index.html/g" {} + 6 | sed -i "s/\/src\//\//g" ./book/index.html -------------------------------------------------------------------------------- /scripts/mdbook_prepare.sh: -------------------------------------------------------------------------------- 1 | cp ./README.md ./src/ 2 | sed -i -e 's/src\/img/img/g' ./src/README.md 3 | 4 | cp ./LICENSE.md ./src/ 5 | cp ./acknowledgements.md ./src/ -------------------------------------------------------------------------------- /scripts/requirements: -------------------------------------------------------------------------------- 1 | openpyxl -------------------------------------------------------------------------------- /src/01_introduction/README.md: -------------------------------------------------------------------------------- 1 | # 1. Introduction 2 | 3 | ## Motivation 4 | 5 | The networking of a multitude of different devices towards the Internet of Things (IoT) poses new challenges for manufacturers and operators of respective solutions. Due to the interconnection of many different technologies, standards and protocols, a considerable amount of effort is necessary to build up and maintain a homogeneous level of network security, data security and IT security in general. Additionally, since the IoT field is changing and developing quickly, manufacturers and operators must continuously monitor potential threats to their devices and networks. 6 | 7 | While conventionally networked computer systems can be secured with established methods, e.g., restricting physical and authorization access to networks and important systems, these methods can be difficult to apply to IoT devices and ecosystems due to the above-mentioned heterogeneity and new network layouts. Compared to conventional computer networks, IoT infrastructures can be very wide-spread. Even though the back end infrastructure might be similar to conventional computer networks, IoT devices could be located at an arbitrary location, possibly even outside of a secure zone of the operator. In some cases, the devices are even physically accessible to third parties and potential attackers, e.g., connected cars, smart home devices or package stations. Hence, every IoT device represents a potential threat to user data and the entire infrastructure since a single manipulated device is sufficient to endanger the entire ecosystem. 8 | 9 | In order to reduce the risk of successful attacks, manufacturers and operators should periodically assess the security level of their IoT solutions. An instrument for this purpose is penetration testing. The goal of a penetration test is to identify security vulnerabilities within IoT solutions. The results can be used to address the detected vulnerabilities and thus strengthen the security level. 10 | 11 | 12 | 13 | ## Challenges 14 | 15 | Within the context of penetration tests, it is important that the test procedure is transparent. Otherwise, the manufacturer or operator might not be able to understand the meaning of the test results to the full extent and could draw wrong conclusions. Furthermore, test results have to be reproducible, so that on the one hand the developers can replicate how a vulnerability was exploited in order to craft a sufficient fix and on the other hand to enable a proper retest once the fix has been applied. 16 | 17 | Testing methodologies have been developed in order to make test procedures and results comparable and to ensure that the results of two or more testers, who perform the same test of the same target, do not differ. These well-known methodologies define a common approach for performing tests, including key aspects of testing and test cases, which have to be considered during a test. Unfortunately, only a few, not yet complete test methodologies for IoT penetration tests exist at the moment of writing this guide. Furthermore, these methodologies only focus on a specific technological area or are currently in an early development phase. 18 | 19 | 20 | 21 | ## Goals 22 | 23 | In order to solve the above-mentioned challenges, the aim of this guide is to develop a methodology for penetration tests of end devices in the IoT field, including general key aspects of testing. 24 | 25 | The methodology should: 26 | 27 | - be flexibly expandable so that more detailed test cases for certain technologies can be added later on (*expandability*). 28 | 29 | - enable the comparison of test procedure (test steps/cases) and results regardless of specific technologies or device types (*comparability*). 30 | 31 | - serve the purpose of a common language between manufacturers/operators and penetration testing service providers, meaning that it should facilitate the communication between both parties by establishing a comprehensible terminology (*comprehensibility*). 32 | 33 | - be efficient, so that it can be used as a supporting instrument by penetration testing teams without requiring major changes to any established workflows or additions of any new steps or testing phases (*efficiency*). 34 | 35 | 36 | 37 | ## Intended Audience 38 | 39 | As the name suggests, the OWASP IoT Security Testing Guide is mainly intended to be used by penetration testers and security analysts in the IoT, hardware and embedded fields. However, others might benefit from the concepts and test cases introduced in this guide as well: 40 | 41 | ### **Builder** 42 | 43 | - **Manufacturers of IoT devices** (e.g., architects, engineers, developers and managers) can use the contents of this guide to get an understanding of potential issues and vulnerabilities that might affect their products. Since vulnerable products can lead to various kinds of damages for the manufacturer (financial loss, loss of reputation, etc.), there should be an interest in understanding how a certain product could be vulnerable in any given context or operational environment. By increasing the awareness and understanding early on in the design and development process, it is possible to improve product security in the long term while keeping the respective costs as low as possible. 44 | ### **Breaker** 45 | 46 | - **Penetration testers and bug bounty researchers** can use the concepts introduced in [2. IoT Security Testing Framework](../02_framework/README.md) to plan their tests and define the test scope, test conditions and test approach. While performing the test, the test cases in [3. Test Case Catalog](../03_test_cases/README.md) and the respective [Checklists](../../checklists) can be used: 47 | - a) as a guide that shows which aspects should be tested, why they should be tested, how they should be tested and how potential issues could be mitigated as well as 48 | - b) to keep track of the test completion status, making sure that all relevant aspects have been examined. 49 | - **Security consultants and security managers** can use this guide and its contents as a common foundation for working with their teams and clients as well as communicating with any of the stakeholders mentioned above. Especially the terminology and structure defined in this guide should help to facilitate collaboration across different teams and organizations. 50 | ### **Defender** 51 | 52 | - **Operators of IoT devices** (e.g., users) can use this guide in a similar fashion as manufacturers. However, the operators who run IoT devices usually have no or very little influence on the design and development process. Hence, their focus is more directed towards understanding how a device might be vulnerable in a particular operational environment and how this environment could be affected in case that the device is compromised or insecure. 53 | 54 | 55 | 56 | ## Modularity as a Key Concept 57 | 58 | This guide is not a monolithic, all-encompassing instruction manual for IoT device penetration testing. Instead, it should be seen as a dynamic and growing collection of test cases for various technologies related to IoT devices. 59 | 60 | In its current state, this guide comprises test cases on a very high and generic level. This is intentional since the base version of this guide should be applicable to as many different IoT devices as possible (*comparability*). However, the long-term goal is that this guide will be expanded over time by adding modules with more detailed test cases for specific technologies (*expandability*). Thereby, the guide will evolve and become more and more detailed over time. 61 | 62 | 63 | 64 | ## Solution Approach 65 | 66 | During the preparation of a penetration test, a series of important decisions need to be made, which have a major impact on the test procedure and consequently the test results. Part of these decisions is to clarify what should be tested (*scope of the test*) and how the test should be performed (*test perspective*). 67 | 68 | In order to achieve the proposed solution, the following approach was chosen: 69 | 70 | 1. **Creation of an IoT device model, which represents an abstract, generalized IoT device:** 71 | 72 | Before the test scope for an IoT device penetration test can be identified, it must first be defined what an IoT device is and which parts it consists of. In order to support the test scope definition, the device model should include device components that can either be included in or excluded from the test scope. This guide will only focus on components, directly belonging to the device itself. All device-external elements, such as web applications, mobile applications and back end servers, will not be part of this guide although sister OWASP testing guides cover these areas. The device model will serve as a generalized scheme, depicting the common structure of IoT devices, thereby enhancing the comprehensibility and comparability of the methodology presented in this guide. As all further parts of the guide will rely on this basis, the creation of the device model is a mandatory and important first step. 73 | 74 | 2. **Creation of an attacker model, which represents and categorizes potential attackers:** 75 | 76 | The guide will comprise key aspects of testing for each component of the device model. Therefore, it will include a catalog of potential test cases for all device components. Since it might not be required to perform all of these test cases for any given kind of IoT device, a systematic approach is required, which yields a selection of applicable test cases based on the requirements and the intended operational environment of a specific device. The attacker model will support the definition of the test perspective, providing comprehensibility and comparability by defining common groups/types of attackers. In order to maintain efficiency, the attacker model will not incorporate extensive threat and risk analysis models. This also benefits the comparability across different device implementations. 77 | 78 | 3. **Creation of a test methodology, which includes general key aspects of testing:** 79 | 80 | Based on the IoT device model, a testing methodology including general key aspects of testing will be developed. These general key aspects represent security issues that are relevant for the device components and will be derived from more detailed test cases for specific exemplars of a given component or technology. This derivation should decouple the key aspects from specifics of the exemplar in order to enable the methodology to be used for as many different IoT device implementations as possible (*comparability*). However, the structure of the methodology will allow to add more detailed key aspects of testing for specific exemplars of a device component later on, thus providing expandability. 81 | 82 | 83 | -------------------------------------------------------------------------------- /src/02_framework/README.md: -------------------------------------------------------------------------------- 1 | # 2. IoT Security Testing Framework 2 | 3 | 2.1. [**IoT Device Model**](./device_model.md) 4 | 5 | 2.2. [**Attacker Model**](./attacker_model.md) 6 | 7 | 2.3. [**Testing Methodology**](./methodology.md) 8 | -------------------------------------------------------------------------------- /src/02_framework/attacker_model.md: -------------------------------------------------------------------------------- 1 | # 2.2. Attacker Model 2 | 3 | In this chapter, a selection scheme for test cases will be described, which is based on potential attackers that are assumed to be a threat to a given IoT device. Contrary to a full threat and risk modeling approach, like the STRIDE model, the attacker model used in this guide presents a more streamlined procedure for defining and selecting threats to IoT devices. 4 | 5 | The reasons for not using a formal threat and risk modeling approach are: 6 | 7 | - Threat and risk modeling is usually focused on one specific implementation design. Thus, the identified threats and risks are based on certain conditions of a given solution or device, which makes it difficult to compare different solutions with each other. 8 | 9 | - Performing a formal threat and risk analysis requires a significant amount of time, which further increases with the complexity of the subject. Making a formal threat and risk analysis a mandatory requirement for penetration tests would result in longer testing periods and consequently higher expenses per test. 10 | 11 | The spectrum of potential attackers reaches from anonymous global attackers to privileged individuals and users of the device. As will be explained in following sections, the list of attackers can be narrowed down by defining minimum and maximum access requirements, representing the test perspective. Every device component and test case will be tagged with the access level, which is required to perform the respective tests. Hence, the list of device components in scope of the test as well as the list of applicable test cases will be a result of applying the attacker model on the results, yielded by the device model. 12 | 13 | It must be noted that, within this chapter, the term "IoT device" refers to a single device or device type whereas, in the other chapters of this guide, it refers to IoT devices in general. 14 | 15 | 16 | 17 | 18 | ## Conceptual Basis for the Attacker Model 19 | 20 | This attacker model will characterize groups of potential attackers based on their access capabilities[^1]. The metrics that are used for this attacker model are based on the metrics of the [CVSS][cvss]. Even though the CVSS is primarily used to rate the severity of vulnerabilities in the web application and computer networking field, it implements a straightforward approach to assess the capabilities of attackers and the conditions that are required to exploit certain security issues. Another benefit of using a model that is similar to the CVSS is that many security professionals are already working with the CVSS. Hence, many testers and manufacturers/operators are familiar with this system, which also contributes to the acceptance of this attacker model. 21 | 22 | The CVSS defines the following exploitability metrics: 23 | 24 | - **Attack vector:** "This metric reflects the context by which vulnerability exploitation is possible" ([source][cvss]). Values for this metric are ranging from network access (e.g., via the internet) to physical access. Within the attacker model, this metric will be reflected by the physical access level. 25 | 26 | - **Attack complexity:** "This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability" ([source][cvss]). The attack complexity is not used in the attacker model since it refers to "conditions beyond the attacker's control" ([source][cvss]) and thus is not relevant for categorizing potential attackers. 27 | 28 | - **Privileges required:** "This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability" ([source][cvss]). Values for this metric are ranging from none (no privileges) to high. The required privileges are represented in the attacker model by the authorization access level. 29 | 30 | - **User interaction:** "This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable component" ([source][cvss]). The necessity of interactions by legitimate users will not be considered in the attacker model since, while being relevant for the exploitability of a vulnerability, it is not relevant for the selection of applicable test cases. 31 | 32 | [^1]: In regards of IT security, attackers are usually characterized based on further factors, e.g., their aggressiveness and their resources (processing power, time, money). However, these factors do not have or only have a minor impact for the selection of applicable test cases. 33 | 34 | 35 | 36 | ## Access Levels 37 | 38 | Within this attacker model, access levels are a measure for the relation between a certain group of individuals (access group) and the IoT device. They describe how individuals of the access group are intended to be able to interact with the device. These can either be physical interactions or logical authorization interactions. 39 | 40 | The degree of how close individuals can get to the device is measured by the physical access level. The physical access level is an adaption of the CVSS metric "attack vector" and it reflects the physical context that is required to perform attacks against a target device. Therefore, some of the original values from the CVSS were used (network, local, physical). However, the description of local access was adjusted in regards of the focus on the physical context. Additionally, the physical access as defined in the CVSS was split into two levels: non-invasive and invasive physical access. The reason for this is that some IoT devices are protected with special measures that restrict access to device-internal elements, e.g., locked or sealed enclosures. In this case, attackers might not be able to access device-internals in a reasonable amount of time, thus they only have non-invasive physical access. Other devices have enclosures that can be opened in a short time, e.g., by removing screws. Thus, attackers could access device-internals, therefore gaining invasive physical access. Overall, the physical access level can be affected by factors like geographical location, building security or the device enclosure. 41 | 42 | The following physical access levels are defined: 43 | 44 | 1. **Remote access (*PA-1*):** There is an arbitrary physical distance between an individual and the device. An attacker with remote access can be located anywhere in the world, which usually means that the device is directly accessible via a Global Area Network (GAN). 45 | 46 | 2. **Local access (*PA-2*):** There is a limited physical distance[^2] between an individual and the device, but direct physical interactions are not possible. An attacker with local access can use the device from close proximity, which usually means that the device is directly accessible via a Local Area Network (LAN) or Wireless Local Area Network (WLAN). 47 | 48 | 3. **Non-invasive access (*PA-3*):** There is no physical distance between an individual and the device, but the individual cannot directly access device-internal elements in a physical manner (i.e., cannot easily open the device enclosure). 49 | 50 | 4. **Invasive access (*PA-4*):** There is no physical distance between an individual and the device and the individual can directly access device-internal elements in a physical manner (i.e., open the device enclosure). 51 | 52 | The digital privileges of individuals are measured by the authorization access level. The authorization access level is an adaption of the CVSS metric "privileges required". In addition to the values, defined in the CVSS, another level of privileges, called manufacturer-level access, was added on top of the high privileges. Contrary to web applications and computer networks, which are usually operated from within the control zone of the operator (e.g., within a data center), IoT devices are often operated outside that control zone. Established methods for securing maintenance and debugging access (e.g., restricting maintenance access to pre-defined subnets, IP addresses or physical ports in the data center) can not always be applied. Hence, attacks against a device with manufacturer-level access might be possible. Overall, the authorization access level can be affected by factors like policies or role-based access models. 53 | 54 | The following authorization access levels are defined: 55 | 56 | 1. **Unauthorized access (*AA-1*):** An individual can get anonymous access to the device component. Attackers with anonymous access can be any unregistered user. 57 | 58 | 2. **Low-privileged access (*AA-2*):** An individual can only get access to the device component, if it is authenticated and in possession of standard authorization privileges. Attackers with low-privileged access can be any registered user. 59 | 60 | 3. **High-privileged access (*AA-3*):** An individual can only get access to the device component, if it is authenticated and in possession of extensive privileges. The term "extensive privileges" means that individuals have access to restricted functionalities that are not available to all registered users of the device component (e.g., configuration settings). 61 | 62 | 4. **Manufacturer-level access (*AA-4*):** An individual can only get access to the device component, if it is authenticated and in possession of manufacturer-level authorization privileges. Contrary to high-privileged access, manufacturer-level access is not restricted in any way and includes, e.g., debugging access for developers of the device, access to the source code or root-level access to the firmware. 63 | 64 | [^2]: Limited physical distance is not restricted to a specic maximum value per se. Depending on the technologies in use, the maximum distance might range from a few meters (e.g., in case of Bluetooth) to a few kilometers (e.g., in case of LTE). 65 | 66 | 67 | 68 | ## Mapping of Device Components and Access Levels 69 | 70 | The perspective of the testers during the test will be determined by minimal and maximal access levels, chosen as a baseline for the test. Physical and authorization access levels have different impacts on the penetration test and its scope. 71 | 72 | **Physical access level:** 73 | 74 | - The physical access level refers to the device as a whole. Thus, some physical access levels directly define that certain device components can not be tested with the given level since an attacker could not interact with these components at all. The relation between physical access levels and device components is shown in the table below. 75 | 76 | - Based on the specific requirements of a manufacturer or operator, the minimal and/or maximal physical access levels might be hard boundaries for the test execution since the contractee might want to specifically exclude certain tests, e.g., those which require invasive physical access. 77 | 78 | **Authorization access level:** 79 | 80 | - Since authorization access might be handled differently across multiple device components, the authorization access level rather refers to access to an individual component than to the device as a whole. Thus, the impact of authorization access levels on the test scope always depends on the specific implementation of the business logic and the authorization/permission scheme per component. 81 | 82 | - There is no reason for selecting a minimal authorization access level for the test perspective since evaluating whether it is possible to get access to (parts of) the device with lower privileges than intended should be part of the test. 83 | 84 | All in all, the attacker model can be used to create an abstract representation of potential attackers. It can be used to describe which kind of attackers is considered a threat to a given device in its operation environment. Contrary to other methodologies and models, this one can be used in a more streamlined manner, thus being more efficient, e.g., compared to full threat and risk analysis approaches. It is also takes the specifics of the IoT context more into account than the CVSS, which it is based on. In combination with the device model, it is possible to define the test scope and test perspective, thereby determining which test cases can and shall be performed. 85 | 86 | | Component | PA-4 | PA-3 | PA-2 | PA-1 | 87 | | ------------------------- | :---: | :-------: | :-------: | :-------: | 88 | | Processing Unit | **✓** | | | | 89 | | Memory | **✓** | | | | 90 | | Installed Firmware | **✓** | **?**[^3] | **?**[^3] | **?**[^3] | 91 | | Firmware Update Mechanism | **✓** | **?**[^3] | **?**[^3] | **?**[^3] | 92 | | Data Exchange Service | **✓** | **?**[^4] | **?**[^4] | **?**[^4] | 93 | | Internal Interface | **✓** | | | | 94 | | Physical Interface | **✓** | **✓** | **?**[^5] | | 95 | | Wireless Interface | **✓** | **✓** | **✓** | | 96 | | User Interface | **✓** | **✓** | **?**[^6] | **?**[^6] | 97 | 98 | [^3]: Installed firmware and the firmware update mechanism might be testable with non-invasive (*PA-3*), local (*PA-2*) or remote physical access (*PA-1*), depending on how direct access to the firmware can be accomplished (e.g., via SSH). 99 | 100 | [^4]: Data exchange services might be testable with non-invasive (*PA-3*), local (*PA-2*) or remote physical access (*PA-1*), depending on if they were designed for that kind of access, e.g., for remote control or monitoring purposes. 101 | 102 | [^5]: Physical interfaces might be testable with local physical access (*PA-2*) under certain circumstances, e.g., if the physical interface is connected to a local network. 103 | 104 | [^6]: User interfaces might be testable with local (*PA-2*) or remote physical access (*PA-1*), depending on if they were designed for that kind of access, e.g., for remote control or monitoring purposes. 105 | 106 | 107 | 108 | [cvss]: https://www.first.org/cvss/ "Common Vulnerability Scoring System" 109 | 110 | -------------------------------------------------------------------------------- /src/02_framework/device_model.md: -------------------------------------------------------------------------------- 1 | # 2.1. IoT Device Model 2 | 3 | This chapter will focus on the IoT device model representing the general structure of IoT devices. Creating the device model is the first step in order to achieve the goals defined in the solution approach (see [1. Introduction](../01_introduction/README.md)). All further steps, which will be described in [2.2. Attacker Model](./attacker_model.md), [2.3. Methodology](./methodology.md) and [3. Test Case Catalog](../03_test_cases/README.md), will be based on the device model. 4 | 5 | 6 | 7 | ## Related Work 8 | 9 | The device model was built upon a reference architecture for IoT platforms. Furthermore, potential attack vectors in the form of attack surface areas were also taken into account since the device model will be used in a security context. These are outlined by the following related work: 10 | 11 | - **["Comparison of IoT Platform Architectures: A Field Study based on a Reference Architecture"][reference_architecture]:** The aim of this paper is to propose a reference architecture for IoT ecosystems. This reference architecture was "kept \[\...\] abstract on purpose since the aim of \[the\] reference architecture is to serve as a uniform, abstract terminology, which eases the comparison of different platforms" ([source][reference_architecture]). As the device model developed in this guide should also serve as a uniform model for different IoT devices, independent of specific implementations and designs, the reference model after Guth et al. ([source][reference_architecture]) was taken as a basis. Nevertheless, the model after Guth et al. ([source][reference_architecture]) is superficial in terms of the IoT device itself. It depicts the device as a single component without further differentiation of its parts (besides drivers). Thus, it is not sufficient for this guide since it does not allow a fine-grained definition of the test scope (inclusion and exclusion of specific device parts). In the model introduced in this guide some adjustments were made in order to further differentiate individual parts of IoT devices. 12 | 13 | - **["IoT Attack Surface Areas Project"][owasp_iot_attack_surface_areas]:** OWASP regularly publishes penetration testing methodologies and collections of popular security risks (called "OWASP Top 10") in several technical fields, such as web and mobile application security. Due to its popularity, it has become one of the major sources for information regarding penetration testing. In 2014 and 2018, OWASP has also published a top 10 of security risks regarding the IoT field. The surface areas mentioned in the "IoT Attack Surface Areas Project" represent parts of an IoT solution which might be targeted by potential attackers. Due to the fact that this list already covers many potential attack vectors in regards to IoT devices and IoT ecosystems in general, it was also used as a basis for the device model proposed within this guide. However, some adjustments were made in order to further differentiate the details of IoT device implementations, especially in terms of the hardware side. Furthermore, the "IoT Attack Surface Areas Project" only consists of a simple list of device parts, which does not specify how these parts interact with each other. It also misses to define the characteristics of each device part (or respectively the attack surface area) and thus makes it difficult to differentiate them, e.g., "Device Memory" and "Local Data Storage". ([source][owasp_iot_attack_surface_areas]) 14 | 15 | 16 | 17 | ## Device Boundaries 18 | 19 | In order to distinguish between components belonging to an IoT device and components of the surrounding IoT ecosystem, it is necessary to first define the boundaries of an IoT device. An IoT device is generally encompassed by an enclosure of some kind, which (physically) separates device-internal elements from device-external elements. 20 | 21 | Interactions between internal and external elements are only possible via interfaces. Within this guide, these interfaces are not considered to be part of the enclosure. Instead, those interfaces will be categorized individually (see [Interfaces](#interfaces)). 22 | 23 | As will be explained in the next section, the term "component" refers to an item that can be the subject of a penetration test. Thus, device-internal elements and interfaces are considered components within this guide. 24 | 25 | 26 | 27 | ## Components 28 | 29 | As introduced in the previous sections, the proposed device model should provide a generalized selection of parts that IoT devices consist of. These parts will be referred to as components. Every component is a piece of soft- and/or hardware that, in theory, can be tested individually. The penetration test scope for an IoT device can therefore be defined as a list of components. 30 | 31 | ### Device-Internal Elements 32 | 33 | Every device-internal element is a component residing inside the device enclosure. Thus, they are part of the IoT device. IoT devices usually comprise the following internal elements, all of which are mentioned in the list of attack surfaces composed by OWASP ([source][owasp_iot_attack_surface_areas]): 34 | 35 | - **Processing unit:** The processing unit, also called processor, is responsible for managing and performing data processing tasks. These tasks are defined as a sequence of instructions that are loaded from the memory. A device has at least a central processing unit handling its core functionalities (defined by the firmware). However, more complex devices might also be equipped with further processing units that are assigned to specific subtasks. A special kind of processor are microprocessors, built on a single circuit. Microcontrollers are microprocessors, which also have analog and digital in- and outputs. They are typically used to control the behavior of a device and are often used in the embedded field. ([source][ekomp_processor]) 36 | 37 | *Examples: x86 processor, ARM processor, AVR processor* 38 | 39 | - **Memory:** Memory is used to store data, such as programs (instructions for a processing unit) and information, in binary form. Depending on the type of memory, it is used to temporarily store data while being processed by a processing unit (primary memory or cache) or to permanently store data on a device even while the device is turned off (secondary memory). A special kind of secondary memory is flash memory. It is commonly used in many devices because it is energy-saving, develops less heat and is less susceptible to vibration and magnetic fields due to the lack of moving parts. Flash memory is based on semiconductor technology and able to provide fast and permanent access to data (read, write, delete). ([source][ekomp_flash_memory], [source][ekomp_memory]) 40 | 41 | *Examples: EEPROM, flash memory* 42 | 43 | - **Firmware:** "Firmware is a software program or set of instructions programmed on a hardware device" ([source][tech_terms_firmware]). It is used to control the device and the communication between device-internal and -external elements (data in- and output via data exchange services). Firmware is stored on a memory and executed by a processing unit. In regards of device firmware, the following components might be potential targets for a penetration test: 44 | 45 | - **Installed firmware:** Installed firmware refers to firmware that is already installed on a device. It might be the target of dynamic analyses and usually handles the storage and processing of sensitive user data. 46 | 47 | - **Firmware update mechanism:** A firmware update mechanism is part of the firmware and defines how firmware updates, in the form of firmware packages, can be installed on a device. A crucial responsibility of a firmware update process is to ensure that only proper firmware packages can be installed and executed.[^1] 48 | 49 | *Examples: OS, RTOS, bare-metal embedded firmware* 50 | 51 | - **Data exchange service:** Data exchange services refer to programs or parts of programs, used to transfer data between two or more components via an interface (e.g., network, bus). These services are part of the firmware and can be used to transmit data, receive data or both. 52 | 53 | *Examples: network service, debug service, bus listener* 54 | 55 | [^1]: For performing a test of a firmware update mechanism, a firmware package is required. Due to the fact that a firmware package could also be inspected separately, it could be considered a component as well. However, since this guide focuses on device-internal elements and device interfaces only, firmware packages are not in scope. Contrary to installed firmware, an update package also includes the firmware header, which might include important data. 56 | 57 | ### Interfaces 58 | 59 | Interfaces are required to connect two or more components with each other. Interactions between device-internal elements or between device-internal and device-external elements are only possible via interfaces. Based on which components are connected by an interface, it can be categorized as a machine-to-machine or human-to-machine interface. As long as at least one of the connected components is a device-internal element, the interface itself is also part of the device. 60 | 61 | Within this guide, the following kinds of interfaces will be differentiated, all of which are either directly or indirectly mentioned in the list of attack surfaces, composed by OWASP ([source][owasp_iot_attack_surface_areas]): 62 | 63 | - **Internal interfaces (machine-to-machine):** These interfaces are used to establish a connection between device-internal elements and are not accessible from outside the device enclosure. 64 | 65 | *Examples: JTAG, UART, SPI* 66 | 67 | - **Physical interfaces (machine-to-machine):** Physical interfaces are used to establish a connection between device-internal and -external elements, based on a physical connection between the components or the respective interfaces of those components. Therefore, physical interfaces require a socket or a port, built into the device enclosure and thus are accessible from outside the device. 68 | 69 | *Examples: USB, Ethernet* 70 | 71 | - **Wireless interfaces (machine-to-machine):** Similar to physical interfaces, wireless interfaces are also used to establish a connection between device-internal and -external elements. However, the connection between wireless interfaces is not based on a physical connection, but on radio waves, optical signals or other wireless technologies. Wireless interfaces are accessible from outside the device, usually from a greater distance than physical interfaces. 72 | 73 | *Examples: Wi-Fi, Bluetooth, BLE, ZigBee* 74 | 75 | - **User interfaces (human-to-machine):** In contrast to all other above-mentioned interfaces, user interfaces are not utilized to establish a connection between two machines. Instead, their purpose is to allow interactions between device-internal elements and a user. These interactions can either be based on a physical connection, e.g., in case of a touch display, or wireless connections, e.g., in case of a camera or microphone. 76 | 77 | *Examples: touch display, camera, microphone, local web application (hosted on the device)* 78 | 79 | 80 | 81 | ## Device Model Scheme 82 | 83 | The device model is a combination of all above-mentioned components and can be seen in the figure below. It must be noted that, even though cardinalities were not included for better readability, more than one instance of each component might be built into an IoT device. 84 | 85 | 86 | 87 | ![IoT Device Model](../img/IoT_Device_Model.jpg) 88 | 89 | 90 | 91 | Other models, e.g., the ones mentioned in [Related Work](#related-work), include sensors and actors as components of a device. Within this guide, sensors and actors are considered physical, wireless or user interfaces respectively because they enable interactions between device-internal and -external elements or users via physical (e.g., touch sensor, door control) or wireless connections (e.g., microphone, temperature sensor). 92 | 93 | In some cases, it is also possible that devices comprise parts which can be considered devices themselves (i.e., nested devices). It then depends on the perspective of the observer which interfaces are classified as internal and external. The determining factor are the boundaries between the observer and the interface (see [Device Boundaries](#device-boundaries), [Device-Internal Elements](#device-internal-elements) and [Interfaces](#interfaces)). 94 | 95 | Overall, the device model, which was specifically developed in the context of this guide, can be used to create and share abstract representations of various different IoT devices. Contrary to other models, this one solely focuses on the IoT device and the components it is built of. Hence, the model allows to describe device implementations in a more detailed manner. In combination with the models and concepts, developed in the following chapters, it is possible to compile a list of applicable test cases for any given device regardless of the specific technologies or standards that are implemented. 96 | 97 | 98 | 99 | [reference_architecture]: https://ieeexplore.ieee.org/document/7872918 "Comparison of IoT platform architectures: A field study based on a reference architecture" 100 | [owasp_iot_attack_surface_areas]: https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Attack_Surface_Areas "OWASP IoT Attack Surface Areas Project" 101 | [tech_terms_firmware]: https://techterms.com/definition/firmware "TechTerms.com" 102 | [ekomp_processor]: https://www.elektronik-kompendium.de/sites/com/0309161.htm "CPU - Central Processing Unit / Hauptprozessor" 103 | [ekomp_flash_memory]: https://www.elektronik-kompendium.de/sites/com/0312261.htm "Flash-Speicher / Flash-Memory" 104 | [ekomp_memory]: https://www.elektronik-kompendium.de/sites/com/1812051.htm "Speicherarchitektur" 105 | -------------------------------------------------------------------------------- /src/02_framework/methodology.md: -------------------------------------------------------------------------------- 1 | # 2.3. Testing Methodology 2 | 3 | In this chapter, a methodology for performing IoT device penetration tests will be described. It is based on the concepts, presented in [2.1. IoT Device Model](./device_model.md) and [2.2. Attacker Model](./attacker_model.md) and serves as a supplement, which can be used with pre-existing penetration testing workflows and frameworks. The methodology comprises key aspects of testing that have to be performed during an IoT device penetration test. Therefore, it includes a catalog of test cases for each individual device component. As described in the previous chapters, the specific selection of applicable test cases depends on the results of applying the device and attacker models, which have been designed in the context of this methodology. 4 | 5 | At first, it will be described how this methodology can be integrated into other workflows and during which steps the models and concepts of this methodology can be used. Then, selected testing techniques will be explained, which can be applied during the test and are not restricted to certain test cases. Finally, the structural concept of the catalog of test cases will be explained. 6 | 7 | In comparison to other IoT penetration testing frameworks, this methodology follows a more generic yet comprehensive approach. It defines test cases for certain security issues that are relevant in the IoT context (key aspects of testing) without being restricted by the details of specific technologies or standards. Thereby, this methodology is more flexible than other frameworks, which is an important benefit given the volatility of the IoT field. Nonetheless, the methodology is applicable to various technologies and provides possibilities for further particularizations. 8 | 9 | It must be noted that test cases, which apply to multiple components, will not be included in this chapter. The full list of test cases can be found in [3. Test Case Catalog](../03_test_cases/README.md). 10 | 11 | 12 | 13 | ## Integration Into Other Workflows and Frameworks 14 | 15 | To achieve efficiency, no major adjustments to any pre-existing workflows should be required to incorporate this methodology. In the following, it will be shown how this methodology can be integrated into other frameworks based on the example of the BSI penetration testing model ([source][bsi_pentest]). In this case, no changes to the overall test workflow are required. 16 | 17 | The methodology proposed in this guide can be used to facilitate the following steps: 18 | 19 | - **Clarification of the Test Scope and Test Perspective:** The methodology supports the clarification of test objectives and conditions with the contractee during phases 1 and 3 of the BSI model ([source][bsi_pentest]) by establishing a common terminology in form of the device and attacker models, thus facilitating the communication. Furthermore, the device model supports the testing team during phase 2 by providing a generic scheme, which can be compared to the architecture of a given IoT device in order to identify potential attack vectors. 20 | 21 | - **Test Execution and Documentation:** The catalog of test cases acts as a guideline for testers during the active test (phase 4 of the BSI model ([source][bsi_pentest])). Depending on the test scope and test perspective, applicable test cases are defined, which have to be performed during the test. Thus, the test catalog can be used as a checklist to ensure that all mandatory tests were performed. It also allows to transparently document the test procedure in a reproducible manner during phase 5, due to the fact that performed test cases can be referenced in the report. 22 | 23 | 24 | 25 | ## Description of the Hierarchic Structure 26 | 27 | In the following, the overall structure of the test case catalog as well as the general layout of a test case will be defined. 28 | 29 | ### Structure of the Catalog of Test Cases 30 | 31 | The catalog of test cases will follow a hierarchic (tree) structure. Starting from a single root node (IOT), each component of the device model will be represented as a child node, thereby forming its own subtree. Subsequently, further nodes will be added as children to the component nodes, eventually resulting in each test case being a leaf node. A unique identifier, incorporating this structure, will be assigned to each node, allowing to reference it in the test report or other documents. 32 | 33 | The following hierarchic levels and types of nodes are defined: 34 | 35 | - **Component:** The first main hierarchy level is the component (see [2.1. IoT Device Model](./device_model.md)). The type of component (device-internal element/interface) was not included in the hierarchy for the sake of simplicity and due to the lack of added value. 36 | 37 | *Short representation: 2 - 5 uppercase alphabetic characters* 38 | 39 | *Examples: ISTG-PROC, ISTG-MEM, ISTG-FW, ISTG-DES, ISTG-INT, ISTG-PHY, ISTG-WRLS, ISTG-UI* 40 | 41 | - **Component Specialization (Optional):** Optional component specializations can be used to define test cases that are only relevant for certain parts or exemplars of a component (e.g., installed firmware - ISTG-FW[INST] - as specialization for the component firmware - ISTG-FW - or SPI - ISTG-INT[SPI] - as specialization for the component internal interface - ISTG-INT). 42 | 43 | By default, component specializations inherit all categories and test cases, defined for their parent node (e.g., all test cases defined for the component firmware - ISTG-FW - are inherited by the specialization installed firmware - ISTG-FW[INST]). 44 | 45 | If required, it is allowed to chain specializations, for example over-the-air firmware updates - ISTG-FW\[UPDT][OTA] - as specialization of firmware update - ISTG-FW[UPDT]. In this case, the second specialization inherits all categories and test cases, defined for the first specialization, thus also inheriting all test cases, defined for the component in general. 46 | 47 | Furthermore, if required, it is also allowed to define a list of categories or test cases, which should be excluded from being inherited by a component specialization. 48 | 49 | *Short representation: 2 - 5 uppercase alphabetic characters in square brackets* 50 | 51 | *Examples: ISTG-FW[INST], ISTG-FW[UPDT]* 52 | 53 | - **Category:** The second main hierarchy level is the category, which can be used to group test cases, e.g., all test cases related to authorization can be grouped in the category AUTHZ. 54 | 55 | *Short representation: 2 - 5 uppercase alphabetic characters* 56 | 57 | *Examples: ISTG-\*-AUTHZ, ISTG-\*-INFO, ISTG-\*-CONF* 58 | 59 | - **Test Case:** The third main hierarchy level is the test case. See [3. Test Case Catalog](../03_test_cases/README.md) for more details. 60 | 61 | *Short representation: three-digit incremental number of the test case.* 62 | 63 | *Examples: ISTG-FW-INFO-001, ISTG-FW-INFO-002, ISTG-FW-INFO-003* 64 | 65 | This kind of structure allows to efficiently determine applicable subtrees by deselecting nodes (e.g., components, component specializations and categories) that are not relevant for a given device or test scenario. The table below shows an exemplary list of nodes for each hierarchy level. An overview of all components and categories that are included in this guide can be seen in the figure below the table. 66 | 67 | The usage of component and category specializations allows to expand the catalog of general test cases to include test cases for specific standards and technologies. By inheriting test cases from their parent nodes, it is ensured that these test cases are also applied to the child nodes by default. However, at the time of writing this guide, the possibility that test cases of a parent node might not be applicable to a child node in particular cases could not be precluded. Thus, it is allowed to specify a list of test cases, which are excluded from being inherited by a certain child node. 68 | 69 | Another way to expand the catalog is to add custom components, categories and test cases. This way, the methodology could also be expanded to include further components, e.g., device-external elements of the IoT ecosystem. 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 |
Hierarchy LevelIDDescription
0IOTRoot Node
1Component
ISTG-PROCProcessing Unit
ISTG-MEMMemory
ISTG-FWFirmware
ISTG-DESData Exchange Service
ISTG-INTInternal Interface
ISTG-PHYPhysical Interface
ISTG-WRLSWireless Interface
ISTG-UIUser Interface
ISTG-*Custom Component (placeholder for future extensions)
Component Specialization (Optional)
ISTG-FW[INST]Installed Firmware
ISTG-FW[UPDT]Firmware Update Mechanism
ISTG-*[*]Custom Component Specialization (placeholder for future extensions)
2Category
ISTG-*-AUTHZAuthorization
ISTG-*-INFOInformation Gathering
ISTG-*-CRYPTCryptography
ISTG-*-SCRTSecrets
ISTG-*-CONFConfiguration and Patch Management
ISTG-*-LOGICBusiness Logic
ISTG-*-INPVInput Validation
ISTG-*-SIDECSide-Channel Attacks
ISTG-*-*Custom Category (placeholder for future extensions)
3Test Case
ISTG-*-INFO-001Disclosure of Source Code and Binaries
ISTG-*-INFO-002Disclosure of Implementation Details
ISTG-*-INFO-003Disclosure of Ecosystem Details
ISTG-*-*-*Custom Test Case (placeholder for future extensions)
202 | 203 | 204 | ![image](../img/Component_Overview.png) 205 | 206 | ### Structure of Test Cases 207 | 208 | Each individual test case, which is represented by a leaf node, is divided into the following sections: 209 | 210 | - **Requirements:** The requirements section will define which physical and authorization access levels are required to carry out the test case. Since these requirements also depend on the given test conditions, e.g., the specific implementation of the target device and its operational environment, a range of access levels might be defined which apply to the test case in general. 211 | 212 | - **Summary:** The summary section includes an overall description of the security issue, which the test case is based on. 213 | 214 | - **Test Objectives:** In the test objectives section, a list of checks that the tester has to perform is given. By performing these checks, the tester can determine whether the device is affected by the security issue described in the summary. 215 | 216 | - **Remediation:** The remediation section comprises recommendations regarding potential measures that can be applied to solve the security issue. However, these recommendations are only rough suggestions. It is the responsibility of the manufacturer/operator to derive detailed measures in regards of the device implementation. 217 | 218 | 219 | 220 | 221 | [bsi_pentest]: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Penetration/penetration_pdf.pdf?__blob=publicationFile&v=1 "Study: A Penetration Testing Model" 222 | [nvd]: https://nvd.nist.gov "National Vulnerability Database" 223 | [owasp_fuzzing]: https://owasp.org/www-community/Fuzzing "Fuzzing" 224 | 225 | -------------------------------------------------------------------------------- /src/03_test_cases/README.md: -------------------------------------------------------------------------------- 1 | # 3. Test Case Catalog 2 | 3 | 3.1. [**Processing Units (ISTG-PROC)**](./processing_units/README.md) 4 | 5 | 3.2. [**Memory (ISTG-MEM)**](./memory/README.md) 6 | 7 | 3.3. [**Firmware (ISTG-FW)**](./firmware/README.md) 8 | 9 | 3.3.1. [Installed Firmware (ISTG-FW[INST])](./firmware/installed_firmware.md) 10 | 11 | 3.3.1. [Firmware Update Mechnanism (ISTG-FW[UPDT])](./firmware/firmware_update_mechanism.md) 12 | 13 | 3.4. [**Data Exchange Services (ISTG-DES)**](./data_exchange_services/README.md) 14 | 15 | 3.5. [**Internal Interfaces (ISTG-INT)**](./internal_interfaces/README.md) 16 | 17 | 3.6. [**Physical Interfaces (ISTG-PHY)**](./physical_interfaces/README.md) 18 | 19 | 3.7. [**Wireless Interfaces (ISTG-WRLS)**](./wireless_interfaces/README.md) 20 | 21 | 3.8. [**User Interfaces (ISTG-UI)**](./user_interfaces/README.md) 22 | 23 | -------------------------------------------------------------------------------- /src/03_test_cases/firmware/README.md: -------------------------------------------------------------------------------- 1 | # 3.3. Firmware (ISTG-FW) 2 | 3 | ## Table of Contents 4 | * [Overview](#overview) 5 | * [Information Gathering (ISTG-FW-INFO)](#information-gathering-istg-fw-info) 6 | * [Disclosure of Source Code and Binaries (ISTG-FW-INFO-001)](#disclosure-of-source-code-and-binaries-istg-fw-info-001) 7 | * [Disclosure of Implementation Details (ISTG-FW-INFO-002)](#disclosure-of-implementation-details-istg-fw-info-002) 8 | * [Disclosure of Ecosystem Details (ISTG-FW-INFO-003)](#disclosure-of-ecosystem-details-istg-fw-info-003) 9 | * [Configuration and Patch Management (ISTG-FW-CONF)](#configuration-and-patch-management-istg-fw-conf) 10 | * [Usage of Outdated Software (ISTG-FW-CONF-001)](#usage-of-outdated-software-istg-fw-conf-001) 11 | * [Presence of Unnecessary Software and Functionalities (ISTG-FW-CONF-002)](#presence-of-unnecessary-software-and-functionalities-istg-fw-conf-002) 12 | * [Secrets (ISTG-FW-SCRT)](#secrets-istg-fw-scrt) 13 | * [Secrets Stored in Public Storage (ISTG-FW-SCRT-001)](#secrets-stored-in-public-storage-istg-fw-scrt-001) 14 | * [Unencrypted Storage of Secrets (ISTG-FW-SCRT-002)](#unencrypted-storage-of-secrets-istg-fw-scrt-002) 15 | * [Usage of Hardcoded Secrets (ISTG-FW-SCRT-003)](#usage-of-hardcoded-secrets-istg-fw-scrt-003) 16 | * [Cryptography (ISTG-FW-CRYPT)](#cryptography-istg-fw-crypt) 17 | * [Usage of Weak Cryptographic Algorithms (ISTG-FW-CRYPT-001)](#usage-of-weak-cryptographic-algorithms-istg-fw-crypt-001) 18 | 19 | 20 | 21 | 22 | ## Overview 23 | 24 | This section includes test cases and categories for the component firmware and the component specializations installed firmware ([ISTG-FW[INST]](./installed_firmware.md)) and firmware update mechanism ([ISTG-FW[UPDT]](./firmware_update_mechanism.md)) respectively. The firmware might be accessible with all physical access levels, depending on how this access is implemented in detail. 25 | 26 | In regards to test case categories that are relevant for processing units, the following were identified: 27 | 28 | - **Information Gathering:** Focuses on information that is stored within the firmware and that might be disclosed to potential attackers if not being properly protected or removed. 29 | 30 | - **Configuration and Patch Management:** Focuses on vulnerabilities and issues in the configuration of a firmware and its software components. 31 | 32 | - **Secrets:** Focuses on secrets that are stored within the firmware in an insecure manner. 33 | 34 | - **Cryptography:** Focuses on vulnerabilities in the cryptographic implementation. 35 | 36 | - **Authorization  (Installed Firmware):** Focuses on vulnerabilities that allow to get unauthorized access to the firmware or to elevate privileges in order to access restricted functionalities. 37 | 38 | - **Business Logic  (Firmware Update Process):** Focuses on vulnerabilities in the design and implementation of the firmware update process. 39 | 40 | All test cases and categories for the component [ISTG-FW](./README.md) focus on generic firmware analysis aspects, without regards to the specifics of specializations for this component. 41 | 42 | 43 | 44 | ## Information Gathering (ISTG-FW-INFO) 45 | 46 | The firmware of an IoT device can include various information, which, if disclosed, could reveal details regarding the inner workings of the device or the surrounding IoT ecosystem to potential attackers. This could enable and facilitate further, more advanced attacks. 47 | 48 | ### Disclosure of Source Code and Binaries (ISTG-FW-INFO-001) 49 | 50 | **Required Access Levels** 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on which component specialization should be tested and how it can be accessed)
62 | 63 | **Summary** 64 | 65 | The disclosure of uncompiled source code could accelerate the exploitation of the software implementation since vulnerabilities can be directly identified in the code without the need to perform tests in a trial and error manner. Furthermore, left-over source code might include internal development information, developer comments or hard-coded sensitive data, which were not intended for productive use. 66 | 67 | Similar to uncompiled source code, compiled binaries might also disclose relevant information. However, reverse-engineering might be required to retrieve useful data, which could take a considerable amount of time. Thus, the tester has to assess which binaries might be worth analyzing, ideally in coordination with the firmware manufacturer. 68 | 69 | **Test Objectives** 70 | 71 | - It must be checked if uncompiled source code can be identified within the firmware. 72 | 73 | - If uncompiled source code is detected, its content must be analyzed for the presence of sensitive data, which might be useful for potential attackers (also see [ISTG-FW-SCRT-003](#usage-of-hardcoded-secrets-istg-fw-scrt-003)). 74 | 75 | - Reverse-engineering of selected binaries should be performed in order to obtain useful information regarding the firmware implementation and the processing of sensitive data. 76 | 77 | **Remediation** 78 | 79 | If possible, uncompiled source code should be removed from firmware, intended for productive use. If the source code has to be included, it must be verified that all internal development data is removed before the firmware is released. 80 | 81 | Since it is not possible to prevent reverse-engineering completely, measures to restrict access to the firmware in general should be implemented to reduce the attack surface. Furthermore, the reverse-engineering process can be impeded, e.g., by obfuscating the code. 82 | 83 | **References** 84 | 85 | For this test case, data from the following sources was consolidated: 86 | 87 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 88 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 89 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 90 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 91 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 92 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 93 | 94 | ### Disclosure of Implementation Details (ISTG-FW-INFO-002) 95 | 96 | **Required Access Levels** 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
108 | 109 | **Summary** 110 | 111 | If details about the implementation, e.g., algorithms in use or the authentication procedure, are available to potential attackers, flaws and entry points for successful attacks are easier to detect. While the disclosure of such details alone is not considered to be a vulnerability, it facilitates the identification of potential attack vectors, thus allowing an attacker to exploit insecure implementations faster. 112 | 113 | For example, relevant information might be included in files of various types like configuration files, text files, system settings or databases. 114 | 115 | **Test Objectives** 116 | 117 | - Accessible details regarding the implementation must be assessed in order to prepare further tests. For example, this includes: 118 | - Cryptographic algorithms in use 119 | 120 | - Authentication and authorization mechanisms 121 | 122 | - Local paths and environment details 123 | 124 | 125 | **Remediation** 126 | 127 | As mentioned above, the disclosure of such information is not considered a vulnerability. However, in order to impede exploitation attempts, only information, necessary for the device operation, should be accessible. 128 | 129 | **References** 130 | 131 | For this test case, data from the following sources was consolidated: 132 | 133 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 134 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 135 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 136 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 137 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 138 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 139 | 140 | ### Disclosure of Ecosystem Details (ISTG-FW-INFO-003) 141 | 142 | **Required Access Levels** 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
154 | 155 | **Summary** 156 | 157 | The contents of the device firmware might disclose information about the surrounding IoT ecosystem, e.g., sensitive URLs, IP addresses, software in use etc. An attacker might be able to use this information to prepare and execute attacks against the ecosystem. 158 | 159 | For example, relevant information might be included in files of various types like configuration files and text files. 160 | 161 | **Test Objectives** 162 | 163 | - It must be determined if (parts of) the firmware, e.g., configuration files, contain relevant information about the surrounding ecosystem. 164 | 165 | **Remediation** 166 | 167 | The disclosure of information should be reduced to the minimum, which is required for operating the device. The disclosed information has to be assessed and all unnecessarily included data should be removed. 168 | 169 | **References** 170 | 171 | For this test case, data from the following available sources was consolidated: 172 | 173 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 174 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 175 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 176 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 177 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 178 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 179 | 180 | 181 | 182 | ## Configuration and Patch Management (ISTG-FW-CONF) 183 | 184 | Since IoT devices can have a long lifespan, it is important to make sure that the software, running on the device, is regularly updated in order to apply the latest security patches. The update process of the firmware itself will be covered by [ISTG-FW[UPDT]](../firmware/firmware_update_mechanism.md). However, it must also be verified that software packages, which are included in the firmware, are up-to-date as well. 185 | 186 | ### Usage of Outdated Software (ISTG-FW-CONF-001) 187 | 188 | **Required Access Levels** 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
200 | 201 | **Summary** 202 | 203 | Every piece of software is potentially vulnerable to attacks. For example, coding errors could lead to undefined program behavior, which then can be exploited by an attacker to gain access to data, processed by the application, or to perform actions in the context of the runtime environment. Furthermore, vulnerabilities in the used frameworks, libraries and other technologies might also affect the security level of a given piece of software. 204 | 205 | Usually, developers release an update once a vulnerability was detected in their software. These updates should be installed as soon as possible in order to reduce the probability of successful attacks. Otherwise, attackers could use known vulnerabilities to perform attacks against the device. 206 | 207 | **Test Objectives** 208 | 209 | - The version identifiers of installed software packages as well as libraries and frameworks in use must be determined. 210 | 211 | - Based on the detected version identifiers, it must be determined if the software version in use is up-to-date, e.g., by consulting the website of the software developer or public repositories. 212 | 213 | - By using vulnerability databases, such as the [National Vulnerability Database](https://nvd.nist.gov) of the NIST, it has to be checked whether any vulnerabilities are known for the detected software versions. 214 | 215 | **Remediation** 216 | 217 | The firmware should not include any outdated software packages. A proper patch management process, which ensures that applicable updates are installed once being available, should be implemented. 218 | 219 | **References** 220 | 221 | For this test case, data from the following available sources was consolidated: 222 | 223 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 224 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 225 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 226 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 227 | 228 | ### Presence of Unnecessary Software and Functionalities (ISTG-FW-CONF-002) 229 | 230 | **Required Access Levels** 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
242 | 243 | **Summary** 244 | 245 | Every piece of software, which is included in the firmware, broadens the attack surface since it might be used to perform attacks against the device. Even if the installed software is up-to-date, it might still be affected by unpublished vulnerabilities. It is also possible that a software program facilitates an attack without being vulnerable, e.g., by providing access to specific files or processes. 246 | 247 | **Test Objectives** 248 | 249 | - A list of software packages, that are included in the firmware, should be assembled. 250 | 251 | - Based on the device documentation, its behavior and the intended use cases, it must be determined whether any of the installed software packages are not mandatory for the device operation. 252 | 253 | **Remediation** 254 | 255 | The attack surface should be minimized as much as possible by removing or disabling every software that is not required for the device operation. 256 | 257 | Especially in case of general-purpose operating systems, such as Windows and Linux systems, it must be ensured that any unnecessary operating system features are disabled. 258 | 259 | **References** 260 | 261 | For this test case, data from the following sources was consolidated: 262 | 263 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 264 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 265 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 266 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 267 | 268 | 269 | 270 | ## Secrets (ISTG-FW-SCRT) 271 | 272 | IoT devices are often operated outside of the control space of their manufacturer. Still, they need to establish connections to other network nodes within the IoT ecosystem, e.g., to request and receive firmware updates or to send data to a cloud API. Hence, it might be required that the device has to provide some kind of authentication credential or secret. These secrets need to be stored on the device in a secure manner to prevent them from being stolen and used to impersonate the device. 273 | 274 | ### Secrets Stored in Public Storage (ISTG-FW-SCRT-001) 275 | 276 | **Required Access Levels** 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
288 | 289 | **Summary** 290 | 291 | Generally, there are multiple kinds of storage spaces within a file system, some of which are publicly available and some that can only be accessed with a certain level of privileges. If sensitive data or secrets are stored in publicly accessible storage spaces, users who should not have access to this data but who have access to the file system could read or modify it. In case of a successful attack, it is very likely that secrets, stored in public storage, are disclosed. 292 | 293 | **Test Objectives** 294 | 295 | - Files and databases within public storage spaces must be checked for the presence of secrets, such as passwords, symmetric or private keys and tokens. 296 | 297 | **Remediation** 298 | 299 | Access to secrets should only be granted to the accounts or processes with proper privileges. Thus, secrets should be stored in protected storage areas or designated key stores that are only available to certain entities. 300 | 301 | **References** 302 | 303 | For this test case, data from the following available sources was consolidated: 304 | 305 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 306 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 307 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 308 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 309 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 310 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 311 | 312 | ### Unencrypted Storage of Secrets (ISTG-FW-SCRT-002) 313 | 314 | **Required Access Levels** 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
326 | 327 | **Summary** 328 | 329 | Sensitive data and secrets should be stored in an encrypted manner, so that even if an attacker has managed to get access to it, he has no access to the respective plaintext data. 330 | 331 | Contrary to [ISTG-FW-SCRT-001](#secrets-stored-in-public-storage-istg-fw-scrt-001), it does not matter if the secrets are stored in public or restricted storage spaces, since it is assumed that the attacker has already gotten access to the data, e.g., by circumventing access restrictions or by exploiting a process with access to the restricted storage. Furthermore, the strength of the cryptographic algorithms in use will be covered by [ISTG-FW-CRYPT-001](#usage-of-weak-cryptographic-algorithms-istg-fw-crypt-001) and has no relevance for this test case. 332 | 333 | **Test Objectives** 334 | 335 | - By searching public and restricted storage spaces, it must be determined whether the firmware includes secrets in plaintext form. 336 | 337 | **Remediation** 338 | 339 | Secrets have to be stored using proper cryptographic algorithms. Only the encrypted form of the secret should be stored. 340 | 341 | **References** 342 | 343 | For this test case, data from the following sources was consolidated: 344 | 345 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 346 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 347 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 348 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 349 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 350 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 351 | 352 | ### Usage of Hardcoded Secrets (ISTG-FW-SCRT-003) 353 | 354 | **Required Access Levels** 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
366 | 367 | **Summary** 368 | 369 | Sometimes, developers tend to incorporate secrets directly into the source code of their software. This can lead to a variety of security issues like: 370 | 371 | - the disclosure of secrets via published source code snippets or decompiled source code, 372 | 373 | - endangering all devices that are using the given software since it is very likely that the same secret is used on all devices (otherwise, the source code needs to be changed and compiled for every device individually) and 374 | 375 | - impeding reactive measures in case of the secret being compromised since changing the secret requires a software update. 376 | 377 | **Test Objectives** 378 | 379 | - Based on [ISTG-FW-INFO-001](#disclosure-of-source-code-and-binaries-istg-fw-info-001), it must be checked if any hard-coded secrets can be identified. 380 | 381 | **Remediation** 382 | 383 | Secrets should not be hard-coded into the source code. Instead, secrets should be stored in a secure manner (see [ISTG-FW-SCRT-001](#secrets-stored-in-public-storage-istg-fw-scrt-001) and [ISTG-FW-SCRT-002](#unencrypted-storage-of-secrets-istg-fw-scrt-002)) and the software process should dynamically retrieve the secrets from the secure storage during runtime. 384 | 385 | **References** 386 | 387 | For this test case, data from the following available sources was consolidated: 388 | 389 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 390 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 391 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 392 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 393 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 394 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 395 | 396 | 397 | 398 | ## Cryptography (ISTG-FW-CRYPT) 399 | 400 | Many IoT devices need to implement cryptographic algorithms, e.g., to securely store sensitive data, for authentication purposes or to receive and verify encrypted data from other network nodes. Failing to implement secure, state of the art cryptography might lead to the exposure of sensitive data, device malfunctions or loss of control over the device. 401 | 402 | ### Usage of Weak Cryptographic Algorithms (ISTG-FW-CRYPT-001) 403 | 404 | **Required Access Levels** 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device) 
416 | 417 | **Summary** 418 | 419 | Cryptography can be implemented in various ways. However, due to evolving technologies, new algorithms and more computing power becoming available, many old cryptographic algorithms are nowadays considered weak or insecure. Thus, either new and stronger cryptographic algorithms have to be used or existing algorithms must be adapted, e.g., by increasing the key length or using alternative modes of operation. 420 | 421 | The usage of weak cryptographic algorithms might allow an attacker to recover the plaintext from a given ciphertext in a timely manner. 422 | 423 | **Test Objectives** 424 | 425 | - The data, stored by or within the firmware, must be checked for the presence of encrypted data segments. In case that encrypted data segments are found, it must be checked whether the cryptographic algorithms in use can be identified. 426 | 427 | - Furthermore, based on [ISTG-FW-INFO-001](#disclosure-of-source-code-and-binaries-istg-fw-info-001) and [ISTG-FW-INFO-002](#disclosure-of-implementation-details-istg-fw-info-002), it must be checked whether any source code, configuration files etc. disclose the usage of certain cryptographic algorithms. 428 | 429 | - In case that cryptographic algorithms can be identified, it must be determined whether the algorithms in use and their configuration are providing a sufficient level of security at the time of testing, e.g., by consulting cryptography guidelines like the technical guideline [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=10) by the BSI. 430 | 431 | **Remediation** 432 | 433 | Only strong, state of the art cryptographic algorithms should be used. Furthermore, these algorithms must be used in a secure manner by setting proper parameters, such as an appropriate key length or mode of operation. 434 | 435 | **References** 436 | 437 | For this test case, data from the following sources was consolidated: 438 | 439 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 440 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 441 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 442 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 443 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 444 | 445 | 446 | 447 | [owasp_fstm]: https://github.com/scriptingxss/owasp-fstm "OWASP Firmware Security Testing Methodology" 448 | [iot_pentesting_guide]: https://www.iotpentestingguide.com "IoT Pentesting Guide" 449 | [iot_penetration_testing_cookbook]: https://www.packtpub.com/product/iot-penetration-testing-cookbook/9781787280571 "IoT Penetration Testing Cookbook" 450 | [iot_hackers_handbook]: https://link.springer.com/book/10.1007/978-1-4842-4300-8 "The IoT Hacker's Handbook" 451 | [practical_iot_hacking]: https://nostarch.com/practical-iot-hacking "Practical IoT Hacking" -------------------------------------------------------------------------------- /src/03_test_cases/firmware/firmware_update_mechanism.md: -------------------------------------------------------------------------------- 1 | # 3.3.2. Firmware Update Mechanism (ISTG-FW[UPDT]) 2 | 3 | ## Table of Contents 4 | * [Overview](#overview) 5 | * [Authorization (ISTG-FW-AUTHZ)](#authorization-istg-fw[updt]-authz) 6 | * [Unauthorized Firmware Update (ISTG-FW-AUTHZ-001)](#unauthorized-firmware-update-istg-fw[updt]-authz-001) 7 | * [Cryptography (ISTG-FW-CRYPT)](#cryptography-istg-fw[updt]-crypt) 8 | * [Insufficient Firmware Update Signature (ISTG-FW-CRYPT-001)](#insufficient-firmware-update-signature-istg-fw[updt]-crypt-001) 9 | * [Insufficient Firmware Update Encryption (ISTG-FW-CRYPT-002)](#insufficient-firmware-update-encryption-istg-fw[updt]-crypt-002) 10 | * [Insecure Transmission of the Firmware Update (ISTG-FW-CRYPT-003)](#insecure-transmission-of-the-firmware-update-istg-fw[updt]-crypt-003) 11 | * [Insufficient Verification of the Firmware Update Signature (ISTG-FW-CRYPT-004)](#insufficient-verification-of-the-firmware-update-signature-istg-fw[updt]-crypt-004) 12 | * [Business Logic (ISTG-FW-LOGIC)](#business-logic-istg-fw[updt]-logic) 13 | * [Insufficient Rollback Protection (ISTG-FW-LOGIC-001)](#insufficient-rollback-protection-istg-fw[updt]-logic-001) 14 | 15 | 16 | 17 | ## Overview 18 | 19 | Another important aspect of the device firmware is the firmware update mechanism. Failing to implement a secure update mechanism might enable attackers to install a custom, manipulated firmware on the device, thus gaining complete control over it. 20 | 21 | The following categories are not inherited by the specialization [ISTG-FW[UPDT]](./firmware_update_mechanism.md): 22 | 23 | - **Configuration and Patch Management ([ISTG-FW-CONF](./README.md#configuration-and-patch-management-istg-fw-conf))**: This category focuses on the configuration and patch management aspects of a firmware file. Since [ISTG-FW[UPDT]](./firmware_update_mechanism.md) focuses on the firmware update mechanism rather than a specific firmware file, the respective test cases are not applicable. 24 | 25 | - **Secrets ([ISTG-FW-SCRT](./README.md#secrets-istg-fw-scrt))**: This category focuses on the handling of secrets within a firmware file. Since [ISTG-FW[UPDT]](./firmware_update_mechanism.md) focuses on the firmware update mechanism rather than a specific firmware file, the respective test cases are not applicable. 26 | 27 | 28 | 29 | ## Authorization (ISTG-FW[UPDT]-AUTHZ) 30 | 31 | Since the test of the firmware update mechanism is also a dynamic analysis, it is possible to check if only authorized individuals can initialize and perform an update. 32 | 33 | ### Unauthorized Firmware Update (ISTG-FW[UPDT]-AUTHZ-001) 34 | 35 | **Required Access Levels** 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-3
(depending on the access model for the given device)
47 | 48 | **Summary** 49 | 50 | Depending on the specific implementation of a given device, the permission to perform firmware updates might be restricted to individuals with a certain authorization access level, e.g., *AA-2*, *AA-3* or *AA-4*. If the device firmware fails to correctly verify these permissions, any attacker (*AA-1*) or an attacker with a lower authorization access level than intended might be able to perform unintended firmware updates. 51 | 52 | **Test Objectives** 53 | 54 | - It must be checked if authorization checks for performing a firmware update are implemented. 55 | 56 | - In case that authorization checks are in place, it must be determined whether there is a way to bypass them. 57 | 58 | **Remediation** 59 | 60 | Proper authorization checks need to be implemented, which ensure that a firmware update can only be performed by individuals with certain authorization access levels. 61 | 62 | **References** 63 | 64 | For this test case, data from the following sources was consolidated: 65 | 66 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 67 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 68 | 69 | 70 | 71 | ## Cryptography (ISTG-FW[UPDT]-CRYPT) 72 | 73 | During the firmware update process, cryptographic algorithms are used to verify the integrity of the new firmware and to ensure that no sensitive data is disclosed in transit. 74 | 75 | ### Insufficient Firmware Update Signature (ISTG-FW[UPDT]-CRYPT-001) 76 | 77 | **Required Access Levels** 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device)
89 | 90 | **Summary** 91 | 92 | One way to manipulate a device would be to install a manipulated firmware package. In order to enable the detection of modifications, the firmware update package needs to be digitally signed. This way, the validity of the package can be verified during the installation or update process. 93 | 94 | **Test Objectives** 95 | 96 | - It must be determined if a digital signature for the firmware update package is available. 97 | 98 | - If a digital signature is available, it must be checked whether the validity of the signature can be verified. 99 | 100 | - Based on [ISTG-FW-CRYPT-001](./README.md#usage-of-weak-cryptographic-algorithms-istg-fw-crypt-001), the cryptographic algorithm, used for generating the digital signature, has to be assessed in order to determine whether a weak our outdated algorithm was used. 101 | 102 | **Remediation** 103 | 104 | A valid digital signature must be available for the firmware update package. Furthermore, it must be possible to verify the validity of the digital signature. 105 | 106 | **References** 107 | 108 | For this test case, data from the following sources was consolidated: 109 | 110 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 111 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 112 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 113 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 114 | 115 | ### Insufficient Firmware Update Encryption (ISTG-FW[UPDT]-CRYPT-002) 116 | 117 | **Required Access Levels** 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device)
129 | 130 | **Summary** 131 | 132 | Firmware update packages might include confidential data of the soft- and hardware developer, e.g., intellectual property. Hence, it might be required to encrypt the package itself. 133 | 134 | **Test Objectives** 135 | 136 | - It has to be clarified with the firmware developer whether the firmware update package needs to be encrypted. 137 | 138 | - If encryption is required, it must be determined whether the package is encrypted. 139 | 140 | - Based on [ISTG-FW-CRYPT-001](./README.md#usage-of-weak-cryptographic-algorithms-istg-fw-crypt-001), it has to be determined whether proper algorithms were used for encryption. 141 | 142 | **Remediation** 143 | 144 | The firmware update package should be encrypted using state of the art cryptographic algorithms. 145 | 146 | **References** 147 | 148 | For this test case, data from the following sources was consolidated: 149 | 150 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 151 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 152 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 153 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 154 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 155 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 156 | 157 | ### Insecure Transmission of the Firmware Update (ISTG-FW[UPDT]-CRYPT-003) 158 | 159 | **Required Access Levels** 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device)
171 | 172 | **Summary** 173 | 174 | If the firmware update process is not performed via a secure channel or if no further measures are in place to ensure the confidentiality and to detect modifications of the transmitted data, an attacker with access to the communication channel might be able to interfere with the update process. 175 | 176 | **Test Objectives** 177 | 178 | - It has to be determined whether the firmware update is performed over a secure channel. 179 | 180 | - If the firmware update is performed over an insecure channel, like the internet, it must be checked whether proper measures in regards of confidentiality and integrity are in place. 181 | 182 | - If, for example, the communication channel is secured using TLS, it must be checked which cipher suites are supported and if the server certificate is validated by the client. 183 | 184 | **Remediation** 185 | 186 | If feasible, the firmware update should be performed via a secure channel. Otherwise, proper measures need to be implemented in order to prevent or detect interferences with potential attackers. 187 | 188 | **References** 189 | 190 | For this test case, data from the following sources was consolidated: 191 | 192 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 193 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 194 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 195 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 196 | 197 | ### Insufficient Verification of the Firmware Update Signature (ISTG-FW[UPDT]-CRYPT-004) 198 | 199 | **Required Access Levels** 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device)
211 | 212 | **Summary** 213 | 214 | Even if the firmware update package is digitally signed, an attacker could install a manipulated firmware package on the device in case that the digital signature is not properly validated. For example, the device might not reject the update if no signature is provided. 215 | 216 | **Test Objectives** 217 | 218 | - Based on [ISTG-FW-CRYPT-001](./README.md#usage-of-weak-cryptographic-algorithms-istg-fw-crypt-001), it must be checked if the signature of the firmware update package is properly verified by the device during the update process. 219 | 220 | **Remediation** 221 | 222 | The device must properly verify the digital signature of an update package before the installation process is started. Any update package without a valid signature or with no signature at all should be rejected. 223 | 224 | **References** 225 | 226 | For this test case, data from the following sources was consolidated: 227 | 228 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 229 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 230 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 231 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 232 | 233 | 234 | 235 | ## Business Logic (ISTG-FW[UPDT]-LOGIC) 236 | 237 | Even if all other aspects of the firmware update are securely implemented, issues in the underlying logic of the update process itself might render the device vulnerable to attacks. Thus, it must be verified if the process is working as intended and if exceptions are detected and properly handled. 238 | 239 | ### Insufficient Rollback Protection (ISTG-FW[UPDT]-LOGIC-001) 240 | 241 | **Required Access Levels** 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device)
253 | 254 | **Summary** 255 | 256 | Some manufacturers implement a rollback protection for their devices. This rollback protection prevents updating a device firmware to an older version than the currently installed one. This way, an attacker can not install a valid but outdated firmware in order to exploit known vulnerabilities of that version. 257 | 258 | **Test Objectives** 259 | 260 | - It has to be assessed whether it is possible to install older versions of the firmware. 261 | 262 | **Remediation** 263 | 264 | A proper rollback protection mechanism verifying that the firmware version to be installed is newer than the currently installed version should be implemented. 265 | 266 | **References** 267 | 268 | For this test case, data from the following sources was consolidated: 269 | 270 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 271 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 272 | 273 | 274 | 275 | [owasp_fstm]: https://github.com/scriptingxss/owasp-fstm "OWASP Firmware Security Testing Methodology" 276 | [iot_pentesting_guide]: https://www.iotpentestingguide.com "IoT Pentesting Guide" 277 | [iot_penetration_testing_cookbook]: https://www.packtpub.com/product/iot-penetration-testing-cookbook/9781787280571 "IoT Penetration Testing Cookbook" 278 | [iot_hackers_handbook]: https://link.springer.com/book/10.1007/978-1-4842-4300-8 "The IoT Hacker's Handbook" 279 | [practical_iot_hacking]: https://nostarch.com/practical-iot-hacking "Practical IoT Hacking" 280 | -------------------------------------------------------------------------------- /src/03_test_cases/firmware/installed_firmware.md: -------------------------------------------------------------------------------- 1 | # 3.3.1. Installed Firmware (ISTG-FW[INST]) 2 | 3 | ## Table of Contents 4 | * [Overview](#overview) 5 | * [Authorization (ISTG-FW-AUTHZ)](#authorization-istg-fw[inst]-authz) 6 | * [Unauthorized Access to the Firmware (ISTG-FW-AUTHZ-001)](#unauthorized-access-to-the-firmware-istg-fw[inst]-authz-001) 7 | * [Privilege Escalation (ISTG-FW-AUTHZ-002)](#privilege-escalation-istg-fw[inst]-authz-002) 8 | * [Information Gathering (ISTG-FW-INFO)](#information-gathering-istg-fw[inst]-info) 9 | * [Disclosure of User Data (ISTG-FW-INFO-001)](#disclosure-of-user-data-istg-fw[inst]-info-001) 10 | * [Cryptography (ISTG-FW-CRYPT)](#cryptography-istg-fw[inst]-crypt) 11 | * [Insufficient Verification of the Bootloader Signature (ISTG-FW-CRYPT-001)](#insufficient-verification-of-the-bootloader-signature-istg-fw[inst]-crypt-001) 12 | 13 | 14 | 15 | 16 | ## Overview 17 | 18 | One specialization of the component firmware is the installed form of a firmware, which might be the subject of a dynamic analysis. The dynamic analysis allows to test the handling of data during runtime. This way, the processing and storing of user data can also be analyzed. As a pre-requisite for the dynamic analysis, a device, which is running the target firmware version, must be provided. 19 | 20 | 21 | 22 | ## Authorization (ISTG-FW[INST]-AUTHZ) 23 | 24 | Usually, only certain individuals, e.g., administrators, should be allowed to access the device firmware during runtime. Thus, proper authentication and authorization procedures need to be in place, which ensure that only authorized users can get access to the firmware. 25 | 26 | ### Unauthorized Access to the Firmware (ISTG-FW[INST]-AUTHZ-001) 27 | 28 | **Required Access Levels** 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1
40 | 41 | **Summary** 42 | 43 | Depending on the specific implementation of a given device, access to the firmware or its functions might be restricted to individuals with a certain authorization access level, e.g., *AA-2*, *AA-3* or *AA-4*. If the device firmware fails to correctly verify access permissions, any attacker (*AA-1*) might be able to get access to the firmware. 44 | 45 | **Test Objectives** 46 | 47 | - It must be checked if authorization checks for access to the firmware are implemented. 48 | 49 | - In case that authorization checks are in place, it must be determined whether there is a way to bypass them. 50 | 51 | **Remediation** 52 | 53 | Proper authorization checks need to be implemented, which ensure that access to the firmware is only possible for authorized individuals. 54 | 55 | **References** 56 | 57 | For this test case, data from the following sources was consolidated: 58 | 59 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 60 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 61 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 62 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 63 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 64 | 65 | This test case is based on: [ISTG-DES-AUTHZ-001](../data_exchange_services/README.md#unauthorized-access-to-the-data-exchange-service-istg-des-authz-001). 66 | 67 | ### Privilege Escalation (ISTG-FW[INST]-AUTHZ-002) 68 | 69 | **Required Access Levels** 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-3
(depending on the access model for the given device)
81 | 82 | **Summary** 83 | 84 | Depending on the specific implementation of a given device, access to parts of the firmware or its functions might be restricted to individuals with a certain authorization access level, e.g., *AA-3* or *AA-4*. If the device firmware fails to correctly verify access permissions, an attacker with a lower authorization access level than intended might be able to get access to the restricted firmware parts. 85 | 86 | **Test Objectives** 87 | 88 | - Based on *ISTG-FW-AUTHZ-001*, it must be determined whether there is a way to elevate the given access privileges and thus to access restricted functions or parts of the firmware. 89 | 90 | **Remediation** 91 | 92 | Proper authorization checks need to be implemented, which ensure that access to restricted parts of the firmware is only possible for individuals with the required authorization access levels. 93 | 94 | **References** 95 | 96 | This test case is based on: [ISTG-DES-AUTHZ-002](../data_exchange_services/README.md#privilege-escalation-istg-des-authz-002). 97 | 98 | 99 | 100 | ## Information Gathering (ISTG-FW[INST]-INFO) 101 | 102 | As mentioned above, during the dynamic analysis, it is also possible to test whether user data is securely stored on the device during runtime. 103 | 104 | ### Disclosure of User Data (ISTG-FW[INST]-INFO-001) 105 | 106 | **Required Access Levels** 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device)
118 | 119 | **Summary** 120 | 121 | During runtime, a device is accumulating and processing data of different kinds, such as personal data of its users. If this data is not stored securely, an attacker might be able to recover it from the device. 122 | 123 | **Test Objectives** 124 | 125 | - It has to be checked whether user data can be accessed by unauthorized individuals. 126 | 127 | **Remediation** 128 | 129 | Access to user data should only be granted to individuals and processes that need to have access to it. No unauthorized or not properly authorized individual should be able to recover user data. 130 | 131 | **References** 132 | 133 | For this test case, data from the following sources was consolidated: 134 | 135 | * OWASP ["Firmware Security Testing Methodology"][owasp_fstm] 136 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 137 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 138 | * ["Practical IoT Hacking"][practical_iot_hacking] by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods 139 | * Key aspects of testing of the T-Systems Multimedia Solutions GmbH 140 | 141 | 142 | 143 | ## Cryptography (ISTG-FW[INST]-CRYPT) 144 | 145 | Many IoT devices need to implement cryptographic algorithms, e.g., to securely store sensitive data, for authentication purposes or to receive and verify encrypted data from other network nodes. Failing to implement secure, state of the art cryptography might lead to the exposure of sensitive data, device malfunctions or loss of control over the device. 146 | 147 | ### Insufficient Verification of the Bootloader Signature (ISTG-FW[INST]-CRYPT-001) 148 | 149 | **Required Access Levels** 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 |
PhysicalPA-1 - PA-4
(depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH)
AuthorizationAA-1 - AA-4
(depending on the access model for the given device)
161 | 162 | **Summary** 163 | 164 | Verifying the digital signature of the bootloader is an important measure to detect manipulations of the bootloader, thus preventing the execution of manipulated firmware on a device. 165 | 166 | **Test Objectives** 167 | 168 | - It must be checked if the signature of the bootloader is properly verified by the device during the boot process. 169 | 170 | **Remediation** 171 | 172 | The device must properly verify the digital signature of a bootloader before it is executed. A bootloader without a valid signature should not be executed. 173 | 174 | 175 | 176 | [owasp_fstm]: https://github.com/scriptingxss/owasp-fstm "OWASP Firmware Security Testing Methodology" 177 | [iot_penetration_testing_cookbook]: https://www.packtpub.com/product/iot-penetration-testing-cookbook/9781787280571 "IoT Penetration Testing Cookbook" 178 | [iot_hackers_handbook]: https://link.springer.com/book/10.1007/978-1-4842-4300-8 "The IoT Hacker's Handbook" 179 | [practical_iot_hacking]: https://nostarch.com/practical-iot-hacking "Practical IoT Hacking" -------------------------------------------------------------------------------- /src/03_test_cases/memory/README.md: -------------------------------------------------------------------------------- 1 | # 3.2. Memory (ISTG-MEM) 2 | 3 | ## Table of Contents 4 | * [Overview](#overview) 5 | * [Information Gathering (ISTG-MEM-INFO)](#information-gathering-istg-mem-info) 6 | * [Disclosure of Source Code and Binaries (ISTG-MEM-INFO-001)](#disclosure-of-source-code-and-binaries-istg-mem-info-001) 7 | * [Disclosure of Implementation Details (ISTG-MEM-INFO-002)](#disclosure-of-implementation-details-istg-mem-info-002) 8 | * [Disclosure of Ecosystem Details (ISTG-MEM-INFO-003)](#disclosure-of-ecosystem-details-istg-mem-info-003) 9 | * [Disclosure of User Data (ISTG-MEM-INFO-004)](#disclosure-of-user-data-istg-mem-info-004) 10 | * [Secrets (ISTG-MEM-SCRT)](#secrets-istg-mem-scrt) 11 | * [Unencrypted Storage of Secrets (ISTG-MEM-SCRT-001)](#unencrypted-storage-of-secrets-istg-mem-scrt-001) 12 | * [Cryptography (ISTG-MEM-CRYPT)](#cryptography-istg-mem-crypt) 13 | * [Usage of Weak Cryptographic Algorithms (ISTG-MEM-CRYPT-001)](#usage-of-weak-cryptographic-algorithms-istg-mem-crypt-001) 14 | 15 | 16 | 17 | 18 | ## Overview 19 | 20 | This section includes test cases and categories for the component memory. Similar to the processing unit, the memory is a device-internal element that can only be accessed with *PA-4*. Establishing a direct connection to the memory might require specific hardware equipment (e.g., a debugging board or test probes). 21 | 22 | In regards to test case categories that are relevant for memory, the following were identified: 23 | 24 | - **Information Gathering:** Focuses on information that is stored on the memory chip and that might be disclosed to potential attackers if not being properly protected or removed. 25 | 26 | - **Secrets:** Focuses on secrets that are stored on the memory chip in an insecure manner. 27 | 28 | - **Cryptography:** Focuses on vulnerabilities in the cryptographic implementation. 29 | 30 | 31 | 32 | ## Information Gathering (ISTG-MEM-INFO) 33 | 34 | The memory of an IoT device can include various data, which, if disclosed, could reveal details regarding the inner workings of the device or the underlying IoT ecosystem to potential attackers. This could enable and facilitate further, more advanced attacks. 35 | 36 | Tests on the device memory are performed by directly accessing the memory chips. Thus, invasive physical access (*PA-4*) is required while no user accounts are used (*AA-1*). 37 | 38 | ### Disclosure of Source Code and Binaries (ISTG-MEM-INFO-001) 39 | **Required Access Levels** 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 |
PhysicalPA-4
AuthorizationAA-1
50 | 51 | **Summary** 52 | 53 | The disclosure of uncompiled source code could accelerate the exploitation of the software implementation since vulnerabilities can be directly identified in the code without the need to perform tests in a trial and error manner. Furthermore, left-over source code might include internal development information, developer comments or hard-coded sensitive data, which were not intended for productive use. 54 | 55 | Similar to uncompiled source code, compiled binaries might also disclose relevant information. However, reverse-engineering might be required to retrieve useful data, which could take a considerable amount of time. Thus, the tester has to assess which binaries might be worth analyzing, ideally in coordination with the device manufacturer. 56 | 57 | **Test Objectives** 58 | 59 | - It must be checked if uncompiled source code can be identified within the device memory. 60 | 61 | - If uncompiled source code is detected, its content must be analyzed for the presence of sensitive data, which might be useful for potential attackers. 62 | 63 | - Reverse-engineering of selected binaries should be performed in order to obtain useful information regarding the device implementation and the processing of sensitive data. 64 | 65 | **Remediation** 66 | 67 | If possible, uncompiled source code should be removed from devices, intended for productive use. If the source code has to be included, it must be verified that all internal development data is removed before releasing the device. 68 | 69 | Since it is not possible to prevent reverse-engineering completely, measures to restrict access to the device memory in general should be implemented to reduce the attack surface. Furthermore, the reverse-engineering process can be impeded, e.g., by obfuscating the code. 70 | 71 | **References** 72 | 73 | For this test case, data from the following sources was consolidated: 74 | 75 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 76 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 77 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 78 | 79 | This test case is based on: [ISTG-FW-INFO-001](../firmware/README.md#disclosure-of-source-code-and-binaries-istg-fw-info-001). 80 | 81 | ### Disclosure of Implementation Details (ISTG-MEM-INFO-002) 82 | **Required Access Levels** 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 |
PhysicalPA-4
AuthorizationAA-1
93 | 94 | **Summary** 95 | 96 | If details about the implementation, e.g., algorithms in use or the authentication procedure, are available to potential attackers, flaws and entry points for successful attacks are easier to detect. While the disclosure of such details alone is not considered to be a vulnerability, it facilitates the identification of potential attack vectors, thus allowing an attacker to exploit insecure implementations faster. 97 | 98 | **Test Objectives** 99 | 100 | - Accessible details regarding the implementation must be assessed in order to prepare further tests. For example, this includes: 101 | - Cryptographic algorithms in use 102 | 103 | - Authentication and authorization mechanism 104 | 105 | - Local paths and environment details 106 | 107 | 108 | **Remediation** 109 | 110 | As mentioned above, the disclosure of such information is not considered a vulnerability. However, in order to impede exploitation attempts, only information necessary for the device operation should be stored on it. 111 | 112 | **References** 113 | 114 | For this test case, data from the following sources was consolidated: 115 | 116 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 117 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 118 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 119 | 120 | This test case is based on: [ISTG-FW-INFO-002](../firmware/README.md#disclosure-of-implementation-details-istg-fw-info-002). 121 | 122 | ### Disclosure of Ecosystem Details (ISTG-MEM-INFO-003) 123 | **Required Access Levels** 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 |
PhysicalPA-4
AuthorizationAA-1
134 | 135 | **Summary** 136 | 137 | The contents of the device memory might disclose information about the surrounding IoT ecosystem, e.g., sensitive URLs, IP addresses, software in use etc. An attacker might be able to use this information to prepare and execute attacks against the ecosystem. 138 | 139 | For example, relevant information might be included in files of various types like configuration files and text files. 140 | 141 | **Test Objectives** 142 | 143 | - It must be determined if the data stored in the device memory, e.g., configuration files, contain relevant information about the surrounding ecosystem. 144 | 145 | **Remediation** 146 | 147 | The disclosure of information should be reduced to the minimum, which is required for operating the device. The disclosed information has to be assessed and all unnecessarily included data should be removed. 148 | 149 | **References** 150 | 151 | For this test case, data from the following sources was consolidated: 152 | 153 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 154 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 155 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 156 | 157 | This test case is based on: [ISTG-FW-INFO-003](../firmware/README.md#disclosure-of-ecosystem-details-istg-fw-info-003). 158 | 159 | ### Disclosure of User Data (ISTG-MEM-INFO-004) 160 | **Required Access Levels** 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 |
PhysicalPA-4
AuthorizationAA-1
171 | 172 | **Summary** 173 | 174 | During runtime, a device is accumulating and processing data of different kinds, such as personal data of its users. If this data is not stored securely, an attacker might be able to recover it from the device. 175 | 176 | **Test Objectives** 177 | 178 | - It has to be checked whether user data can be accessed by unauthorized individuals. 179 | 180 | **Remediation** 181 | 182 | Access to user data should only be granted to individuals and processes that need to have access to it. No unauthorized or not properly authorized individual should be able to recover user data. 183 | 184 | **References** 185 | 186 | For this test case, data from the following sources was consolidated: 187 | 188 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 189 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 190 | * ["The IoT Hacker's Handbook"][iot_hackers_handbook] by Aditya Gupta 191 | 192 | This test case is based on: [ISTG-FW[INST]-INFO-001](../firmware/installed_firmware.md#disclosure-of-user-data-istg-fw[inst]-info-001). 193 | 194 | 195 | 196 | ## Secrets (ISTG-MEM-SCRT) 197 | 198 | IoT devices are often operated outside of the control space of their manufacturer. Still, they need to establish connections to other network nodes within the IoT ecosystem, e.g., to request and receive firmware updates or to send data to a cloud API. Hence, it might be required that the device can provide some kind of authentication credential or secret. These secrets need to be stored on the device in a secure manner to prevent them from being stolen and used to impersonate the device. 199 | 200 | ### Unencrypted Storage of Secrets (ISTG-MEM-SCRT-001) 201 | **Required Access Levels** 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 |
PhysicalPA-4
AuthorizationAA-1
212 | 213 | **Summary** 214 | 215 | Sensitive data and secrets should be stored in an encrypted manner, so that even if an attacker has managed to get access to the memory, he has no access to the respective plaintext data. 216 | 217 | The strength of the cryptographic algorithms in use will be covered by [ISTG-MEM-CRYPT-001](#usage-of-weak-cryptographic-algorithms-istg-mem-crypt-001) and has no relevance for this test case. 218 | 219 | **Test Objectives** 220 | 221 | - By searching the contents of the device memory, it must be determined whether it includes secrets in plaintext form. 222 | 223 | **Remediation** 224 | 225 | Secrets have to be stored using proper cryptographic algorithms. Only the encrypted form of the secret should be stored. 226 | 227 | **References** 228 | 229 | For this test case, data from the following sources was consolidated: 230 | 231 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 232 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 233 | 234 | This test case is based on: [ISTG-FW-SCRT-002](../firmware/README.md#unencrypted-storage-of-secrets-istg-fw-scrt-002). 235 | 236 | 237 | 238 | ## Cryptography (ISTG-MEM-CRYPT) 239 | 240 | Many IoT devices need to implement cryptographic algorithms, e.g., to securely store sensitive data, for authentication purposes or to receive and verify encrypted data from other network nodes. Failing to implement secure, state of the art cryptography might lead to the exposure of sensitive data, device malfunctions or loss of control over the device. 241 | 242 | ### Usage of Weak Cryptographic Algorithms (ISTG-MEM-CRYPT-001) 243 | **Required Access Levels** 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 |
PhysicalPA-4
AuthorizationAA-1
254 | 255 | **Summary** 256 | 257 | Cryptography can be implemented in various ways. However, due to evolving technologies, new algorithms and more computing power becoming available, many old cryptographic algorithms are nowadays considered weak or insecure. Thus, either new and stronger cryptographic algorithms have to be used or existing algorithms must be adapted, e.g., by increasing the key length or using alternative modes of operation. 258 | 259 | The usage of weak cryptographic algorithms might allow an attacker to recover the plaintext from a given ciphertext in a timely manner. 260 | 261 | **Test Objectives** 262 | 263 | - The data, stored on the device, must be checked for the presence of encrypted data segments. In case that encrypted data segments are found, it must be checked whether the cryptographic algorithms in use can be identified. 264 | 265 | - Furthermore, based on [ISTG-MEM-INFO-001](#disclosure-of-source-code-and-binaries-istg-mem-info-001) and [ISTG-MEM-INFO-002](#disclosure-of-implementation-details-istg-mem-info-002), it must be checked whether any source code, configuration files etc. disclose the usage of certain cryptographic algorithms. 266 | 267 | - In case that cryptographic algorithms can be identified, it must be determined whether the algorithms in use and their configuration are providing a sufficient level of security at the time of testing, e.g., by consulting cryptography guidelines like the technical guideline [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=10) by the BSI. 268 | 269 | **Remediation** 270 | 271 | Only strong, state of the art cryptographic algorithms should be used. Furthermore, these algorithms must be used in a secure manner by setting proper parameters, such as an appropriate key length or mode of operation. 272 | 273 | **References** 274 | 275 | For this test case, data from the following sources was consolidated: 276 | 277 | * ["IoT Pentesting Guide"][iot_pentesting_guide] by Aditya Gupta 278 | * ["IoT Penetration Testing Cookbook"][iot_penetration_testing_cookbook] by Aaron Guzman and Aditya Gupta 279 | 280 | This test case is based on: [ISTG-FW-CRYPT-001](../firmware/README.md#usage-of-weak-cryptographic-algorithms-istg-fw-crypt-001). 281 | 282 | 283 | 284 | [iot_pentesting_guide]: https://www.iotpentestingguide.com "IoT Pentesting Guide" 285 | [iot_penetration_testing_cookbook]: https://www.packtpub.com/product/iot-penetration-testing-cookbook/9781787280571 "IoT Penetration Testing Cookbook" 286 | [iot_hackers_handbook]: https://link.springer.com/book/10.1007/978-1-4842-4300-8 "The IoT Hacker's Handbook" 287 | -------------------------------------------------------------------------------- /src/03_test_cases/processing_units/README.md: -------------------------------------------------------------------------------- 1 | # 3.1. Processing Units (ISTG-PROC) 2 | 3 | ## Table of Contents 4 | * [Overview](#overview) 5 | * [Authorization (ISTG-PROC-AUTHZ)](#authorization-istg-proc-authz) 6 | * [Unauthorized Access to the Processing Unit (ISTG-PROC-AUTHZ-001)](#unauthorized-access-to-the-processing-unit-istg-proc-authz-001) 7 | * [Privilege Escalation (ISTG-PROC-AUTHZ-002)](#privilege-escalation-istg-proc-authz-002) 8 | * [Business Logic (ISTG-PROC-LOGIC)](#business-logic-istg-proc-logic) 9 | * [Insecure Implementation of Instructions (ISTG-PROC-LOGIC-001)](#insecure-implementation-of-instructions-istg-proc-logic-001) 10 | * [Side-Channel Attacks (ISTG-PROC-SIDEC)](#side-channel-attacks-istg-proc-sidec) 11 | * [Insufficient Protection Against Side-Channel Attacks (ISTG-PROC-SIDEC-001)](#insufficient-protection-against-side-channel-attacks-istg-proc-sidec-001) 12 | 13 | 14 | 15 | 16 | ## Overview 17 | 18 | This section includes test cases and categories for the component processing unit. A processing unit is a device-internal element that can only be accessed with *PA-4*. Establishing a direct connection to the processing unit might require specific hardware equipment (e.g., a debugging board, an oscilloscope or test probes). 19 | 20 | The following test case categories, relevant for processing units, were identified: 21 | 22 | - **Authorization:** Focuses on vulnerabilities that allow to get unauthorized access to the processing unit or to elevate privileges in order to access restricted functionalities. 23 | 24 | - **Business Logic:** Focuses on vulnerabilities in the design and implementation of instructions as well as the presence of undocumented, potentially vulnerable, instructions. 25 | 26 | - **Side-channel Attacks:** Focuses on the resilience against side-channel attacks like timing and glitching attacks. 27 | 28 | 29 | 30 | ## Authorization (ISTG-PROC-AUTHZ) 31 | 32 | Depending on the access model for a given device, only certain individuals might be allowed to access a processing unit directly. Thus, proper authentication and authorization procedures need to be in place, which ensure that only authorized entities can get access. 33 | 34 | ### Unauthorized Access to the Processing Unit (ISTG-PROC-AUTHZ-001) 35 | 36 | **Required Access Levels** 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 |
PhysicalPA-4
AuthorizationAA-1
48 | 49 | **Summary** 50 | 51 | Depending on the specific implementation of a given device, access to a processing unit might be restricted to entities with a certain authorization access level, e.g., *AA-2*, *AA-3* or *AA-4*. If the device fails to correctly verify access permissions, any attacker (*AA-1*) might be able to get access. 52 | 53 | **Test Objectives** 54 | 55 | - It must be checked if authorization checks for access to the processing unit are implemented. 56 | 57 | - In case that authorization checks are in place, it must be determined whether there is a way to bypass them. 58 | 59 | **Remediation** 60 | 61 | Proper authorization checks need to be implemented, which ensure that access to the processing unit is only possible for authorized entities. 62 | 63 | **References** 64 | 65 | This test case is based on: [ISTG-DES-AUTHZ-001](../data_exchange_services/README.md#unauthorized-access-to-the-data-exchange-service-istg-des-authz-001). 66 | 67 | ### Privilege Escalation (ISTG-PROC-AUTHZ-002) 68 | 69 | **Required Access Levels** 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 |
PhysicalPA-4
AuthorizationAA-2 - AA-3
(depending on the access model for the given device)
81 | 82 | **Summary** 83 | 84 | Depending on the specific implementation of a given device, access to some functionalities of a processing unit might be restricted to individuals with a certain authorization access level, e.g., *AA-3* or *AA-4*. If the processing unit fails to correctly verify access permissions, an attacker with a lower authorization access level than intended might be able to get access to the restricted functionalities. 85 | 86 | **Test Objectives** 87 | 88 | - Based on [ISTG-PROC-AUTHZ-001](#unauthorized-access-to-the-processing-unit-istg-proc-authz-001), it must be determined whether there is a way to elevate the given access privileges and thus to access restricted functionalities. 89 | 90 | **Remediation** 91 | 92 | Proper authorization checks need to be implemented, which ensure that access to restricted functionalities is only possible for individuals with the required authorization access levels. 93 | 94 | **References** 95 | 96 | This test case is based on: [ISTG-DES-AUTHZ-002](../data_exchange_services/README.md#privilege-escalation-istg-des-authz-002). 97 | 98 | 99 | 100 | ## Business Logic (ISTG-PROC-LOGIC) 101 | 102 | Issues in the underlying logic of a processing unit might render the device vulnerable to attacks. Thus, it must be verified if the processing unit and its functionalities are working as intended and if exceptions are detected and properly handled. 103 | 104 | ### Insecure Implementation of Instructions (ISTG-PROC-LOGIC-001) 105 | 106 | **Required Access Levels** 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 |
PhysicalPA-4
AuthorizationAA-1 - AA-4
(depending on what level of privileges is required to successfully submit instructions to the processing unit)
118 | **Summary** 119 | 120 | Flaws in the implementation of the business logic might result in unintended behavior or malfunctions of the device. For example, if an attacker intentionally tries to skip or change important instructions in the processing workflow, the device might end up in an unknown, potentially insecure state. 121 | 122 | **Test Objectives** 123 | 124 | - Based on the specific implementation, it has to be determined whether instructions can be misused to manipulate the behavior of the device. 125 | 126 | - It must be checked if the processing unit in use supports undocumented, potentially vulnerable instructions. For example, this can be done by fuzzing instructions or performing research regarding the processing unit model. 127 | 128 | **Remediation** 129 | 130 | The device should not end up in an unknown state. Anomalies in the workflow must be detected and exceptions have to be handled properly. 131 | 132 | **References** 133 | 134 | This test case is based on: [ISTG-DES-LOGIC-001](../data_exchange_services/README.md#circumvention-of-the-intended-business-logic-istg-des-logic-001). 135 | 136 | 137 | 138 | ## Side-Channel Attacks (ISTG-PROC-SIDEC) 139 | 140 | Side-channel attacks, such as timing and glitching attacks, are usually targeted against the physical implementation of a device or more specifically a processing unit instead of the device firmware or its interfaces. The goal of such attacks is to gather information about cryptographic algorithms and operations, performed by a processing unit, in order to retrieve key material, manipulate the cryptographic calculations or gain access to protected information. 141 | 142 | ### Insufficient Protection Against Side-Channel Attacks (ISTG-PROC-SIDEC-001) 143 | 144 | **Required Access Levels** 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 |
PhysicalPA-4
AuthorizationAA-1 - AA-4
(depending on how the attack is being performed; see summary for more details)
156 | **Summary** 157 | 158 | As mentioned above, side-channel attacks can be used by an attacker to get access to sensitive data or to manipulate the device operation. Usually, side-channel attacks are customized attacks tailored to a specific hardware implementation. 159 | 160 | Depending on how the attack is being performed, different levels of authorization access might be required. Some side-channel attacks, such as glitching attacks, do not require authorization access at all since the attack is performed on a physical level by manipulating the power supply. Other side-channel attack vectors, such as the Meltdown vulnerability, require the execution of code by an attacker. Thus, some kind of authorization access is necessary. 161 | 162 | **Test Objectives** 163 | 164 | - It has to be determined whether the processing unit is affected by known vulnerabilities, such as Meltdown and Spectre. 165 | 166 | - During the testing period, the behavior of the processing unit has to be analyzed in order to assess the probability of successful side-channel attacks like timing or glitching attacks. 167 | 168 | **Remediation** 169 | 170 | Based on the results of the analysis, the hardware design should be adjusted to be resilient against side-channel attacks. Furthermore, if publicly known vulnerabilities exist, the latest patches should be installed. 171 | 172 | **References** 173 | 174 | For this test case, data from the following sources was consolidated: 175 | 176 | * ["A practical implementation of the timing attack"][timing_attack] by Jean-François Dhem, François Koeune, Philippe-Alexandre Leroux, Patrick Mestré, Jean-Jacques Quisquater, and Jean-Louis Willems *(In Jean-Jacques Quisquater and Bruce Schneier, editors, Smart Card Research and Applications, pages 167 - 182, Berlin, Heidelberg, 2000. Springer Berlin Heidelberg.)* 177 | * ["Injecting Power Attacks with Voltage Glitching and Generation of Clock Attacks for Testing Fault Injection Attacks"][power_glitching_attack] by Shaminder Kaur, Balwinder Singh, Harsimranjit Kaur, and Lipika Gupta *(In Pradeep Kumar Singh, Arti Noor, Maheshkumar H. Kolekar, Sudeep Tanwar, Raj K. Bhatnagar, and Shaweta Khanna, editors, Evolving Technologies for Computing, Communication and Smart World, pages 23 - 37, Singapore, 2021. Springer Singapore.)* 178 | * ["Spectre attacks: Exploiting speculative execution"][spectre_attack] by Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, and Yuval Yarom *(In 40th IEEE Symposium on Security and Privacy (S&P'19), 2019.)* 179 | * ["Meltdown: Reading kernel memory from user space"][meltdown_attack] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, and Mike Hamburg *(In 27th USENIX Security Symposium (USENIX Security 18), 2018.)* 180 | 181 | 182 | 183 | [timing_attack]: https://link.springer.com/chapter/10.1007/10721064_15 "A practical implementation of the timing attack" 184 | [power_glitching_attack]: https://link.springer.com/chapter/10.1007/978-981-15-7804-5_3 "Injecting Power Attacks with Voltage Glitching and Generation of Clock Attacks for Testing Fault Injection Attacks" 185 | [spectre_attack]: https://ieeexplore.ieee.org/document/8835233 "Spectre attacks: Exploiting speculative execution" 186 | [meltdown_attack]: https://www.usenix.org/conference/usenixsecurity18/presentation/lipp "Meltdown: Reading kernel memory from user" 187 | -------------------------------------------------------------------------------- /src/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | [OWASP IoT Security Testing Guide](./README.md) 4 | 5 | # Introduction 6 | - [Introduction](./01_introduction/README.md) 7 | 8 | 9 | # IoT Security Testing Framework 10 | - [IoT Security Testing Framework](./02_framework/README.md) 11 | - [IoT Device Model](./02_framework/device_model.md) 12 | - [Attacker Model](./02_framework/attacker_model.md) 13 | - [Testing Methodology](./02_framework/methodology.md) 14 | 15 | # Catalog of Test Cases 16 | - [Catalog of Test Cases](./03_test_cases/README.md) 17 | - [Processing Units (ISTG-PROC)](./03_test_cases/processing_units/README.md) 18 | - [Memory (ISTG-MEM)](./03_test_cases/memory/README.md) 19 | - [Firmware (ISTG-FW)](./03_test_cases/firmware/README.md) 20 | - [Installed Firmware (ISTG-FW[INST])](./03_test_cases/firmware/installed_firmware.md) 21 | - [Firmware Update Mechnanism (ISTG-FW[UPDT])](./03_test_cases/firmware/firmware_update_mechanism.md) 22 | - [Data Exchange Services (ISTG-DES)](./03_test_cases/data_exchange_services/README.md) 23 | - [Internal Interfaces (ISTG-INT)](./03_test_cases/internal_interfaces/README.md) 24 | - [Physical Interfaces (ISTG-PHY)](./03_test_cases/physical_interfaces/README.md) 25 | - [Wireless Interfaces (ISTG-WRLS)](./03_test_cases/wireless_interfaces/README.md) 26 | - [User Interfaces (ISTG-UI)](./03_test_cases/user_interfaces/README.md) 27 | 28 | [Acknowlegdements](./acknowledgements.md) 29 | [License](./LICENSE.md) 30 | -------------------------------------------------------------------------------- /src/img/Component_Overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/src/img/Component_Overview.png -------------------------------------------------------------------------------- /src/img/IoT_Device_Model.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/src/img/IoT_Device_Model.jpg -------------------------------------------------------------------------------- /src/img/istg_cover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/owasp-istg/b4c29fe9566b28bebf07e94e89a4e4cb6d0edceb/src/img/istg_cover.png -------------------------------------------------------------------------------- /versioning.md: -------------------------------------------------------------------------------- 1 | # Versioning Guide 2 | 3 | ## Version Structure 4 | 5 | The version structure for this project is defined as follows: 6 | 7 | 1. **MAJOR version:** Major versions consolidate extensive changes to multiple parts of the guide (e.g., framework changes, multiple new/updated [components / component specializations](./src/02_framework/methodology#structure-of-the-catalog-of-test-cases), greater depth of detail for a considerable amount of test cases). 8 | 2. **MINOR version:** Minor versions are released once a [components / component specializations](./src/02_framework/methodology#structure-of-the-catalog-of-test-cases) has been added or extensively updated/refined. 9 | 3. **PATCH version:** Patch version releases are used for smaller fixes (bugs, typos, issues). 10 | 11 | Each release will be tagged with a version identifier "*v[MAJOR].[MINOR].[PATCH]*". 12 | 13 | 14 | 15 | ## Branch Structure 16 | 17 | The following branch structure has been defined: 18 | 19 | - **main:** Latest release version 20 | - **latest:** Main working branch that includes all finished but unreleased changes 21 | - **istg-[component_id]:** Used for adding/updating parts of [components / component specializations](./src/02_framework/methodology#structure-of-the-catalog-of-test-cases) 22 | - Further branches will be created for individual topics. Self-explanatory names should be used. --------------------------------------------------------------------------------