- Overview
- Authorization (ISTG-FW-AUTHZ)
- Information Gathering (ISTG-FW-INFO)
- Cryptography (ISTG-FW-CRYPT)
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.
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.
Required Access Levels
| Physical | PA-1 - PA-4 (depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH) |
|---|---|
| Authorization | AA-1 |
Summary
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.
Test Objectives
-
It must be checked if authorization checks for access to the firmware are implemented.
-
In case that authorization checks are in place, it must be determined whether there is a way to bypass them.
Remediation
Proper authorization checks need to be implemented, which ensure that access to the firmware is only possible for authorized individuals.
References
For this test case, data from the following sources was consolidated:
- OWASP "Firmware Security Testing Methodology"
- "IoT Penetration Testing Cookbook" by Aaron Guzman and Aditya Gupta
- "The IoT Hacker's Handbook" by Aditya Gupta
- "Practical IoT Hacking" by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods
- Key aspects of testing of the T-Systems Multimedia Solutions GmbH
This test case is based on: ISTG-DES-AUTHZ-001.
Required Access Levels
| Physical | PA-1 - PA-4 (depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH) |
|---|---|
| Authorization | AA-1 - AA-3 (depending on the access model for the given device) |
Summary
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.
Test Objectives
- 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.
Remediation
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.
References
This test case is based on: ISTG-DES-AUTHZ-002.
As mentioned above, during the dynamic analysis, it is also possible to test whether user data is securely stored on the device during runtime.
Required Access Levels
| Physical | PA-1 - PA-4 (depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH) |
|---|---|
| Authorization | AA-1 - AA-4 (depending on the access model for the given device) |
Summary
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.
Test Objectives
- It has to be checked whether user data can be accessed by unauthorized individuals.
Remediation
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.
References
For this test case, data from the following sources was consolidated:
- OWASP "Firmware Security Testing Methodology"
- "IoT Penetration Testing Cookbook" by Aaron Guzman and Aditya Gupta
- "The IoT Hacker's Handbook" by Aditya Gupta
- "Practical IoT Hacking" by Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, and Beau Woods
- Key aspects of testing of the T-Systems Multimedia Solutions GmbH
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.
Required Access Levels
| Physical | PA-1 - PA-4 (depending on how the firmware can be accessed, e.g., via an internal/physical debugging interface or remotely via SSH) |
|---|---|
| Authorization | AA-1 - AA-4 (depending on the access model for the given device) |
Summary
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.
Test Objectives
- It must be checked if the signature of the bootloader is properly verified by the device during the boot process.
Remediation
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.