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.
The following categories are not inherited by the specialization ISTG-FW[UPDT]:
-
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] focuses on the firmware update mechanism rather than a specific firmware file, the respective test cases are not applicable.
-
Secrets (ISTG-FW-SCRT): This category focuses on the handling of secrets within a firmware file. Since ISTG-FW[UPDT] focuses on the firmware update mechanism rather than a specific firmware file, the respective test cases are not applicable.
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.
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, 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.
Test Objectives
-
It must be checked if authorization checks for performing a firmware update 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 a firmware update can only be performed by individuals with certain authorization access levels.
References
For this test case, data from the following sources was consolidated:
- OWASP "Firmware Security Testing Methodology"
- Key aspects of testing of the T-Systems Multimedia Solutions GmbH
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.
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
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.
Test Objectives
-
It must be determined if a digital signature for the firmware update package is available.
-
If a digital signature is available, it must be checked whether the validity of the signature can be verified.
-
Based on 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.
Remediation
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.
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
- "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
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
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.
Test Objectives
-
It has to be clarified with the firmware developer whether the firmware update package needs to be encrypted.
-
If encryption is required, it must be determined whether the package is encrypted.
-
Based on ISTG-FW-CRYPT-001, it has to be determined whether proper algorithms were used for encryption.
Remediation
The firmware update package should be encrypted using state of the art cryptographic algorithms.
References
For this test case, data from the following sources was consolidated:
- OWASP "Firmware Security Testing Methodology"
- "IoT Pentesting Guide" by Aditya Gupta
- "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
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
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.
Test Objectives
-
It has to be determined whether the firmware update is performed over a secure channel.
-
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.
-
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.
Remediation
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.
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
- "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
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
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.
Test Objectives
- Based on 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.
Remediation
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.
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
- "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
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.
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
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.
Test Objectives
- It has to be assessed whether it is possible to install older versions of the firmware.
Remediation
A proper rollback protection mechanism verifying that the firmware version to be installed is newer than the currently installed version should be implemented.
References
For this test case, data from the following sources was consolidated:
- "IoT Penetration Testing Cookbook" by Aaron Guzman and Aditya Gupta
- Key aspects of testing of the T-Systems Multimedia Solutions GmbH