Modes Of Introduction
Requirements : Requirements development might not consider the importance of updates over the lifetime of the product, or might not choose the ability due to concerns such as expense or speed to market.
Architecture and Design : Lack of planning during architecture development and design, or external pressures such as speed to market, could ignore the capability to update.
Implementation : The weakness can appear through oversight during implementation.
Applicable Platforms
Language
Class: Not Language-Specific (Undetermined)
Operating Systems
Class: Not OS-Specific (Undetermined)
Architectures
Class: Not Architecture-Specific (Undetermined)
Technologies
Class: Not Technology-Specific (Undetermined)
Common Consequences
Scope |
Impact |
Likelihood |
Confidentiality Integrity Access Control Authentication Authorization | Gain Privileges or Assume Identity, Bypass Protection Mechanism, Execute Unauthorized Code or Commands, DoS: Crash, Exit, or Restart
Note: If an attacker can identify an exploitable vulnerability in one device that has no means of patching, the attack may be used against an entire class of devices. | Medium |
Observed Examples
References |
Description |
| Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are "end-of-support" and cannot be patched (CWE-1277). [REF-1097] |
| A hardware "smart lock" has weak key generation that allows attackers to steal the key by BLE sniffing, but the device's firmware cannot be upgraded and hence remains vulnerable [REF-1095]. |
Potential Mitigations
Phases : Requirements
Specify requirements to include the ability to update the firmware. Include integrity checks and authentication to ensure that untrusted firmware cannot be installed.
Phases : Architecture and Design
Design the device to allow for updating the firmware. Ensure that the design specifies how to distribute the updates and ensure their integrity and authentication.
Phases : Implementation
Implement the necessary functionality to allow the firmware to be updated.
Detection Methods
Manual Analysis
Create a new installable boot image of the current build with a minor version number change. Use the standard installation method to update the boot image. Verify that the minor version number has changed. Create a fake image. Verify that the boot updater will not install the fake image and generates an "invalid image" error message or equivalent.
Effectiveness : High
Architecture or Design Review
Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.
Effectiveness : Moderate
Manual Dynamic Analysis
Determine if there is a lack of a capability to update read-only memory (ROM) structure. This could manifest as a difference between the latest firmware version and the current version within the device.
Effectiveness : High
Vulnerability Mapping Notes
Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Related Attack Patterns
CAPEC-ID |
Attack Pattern Name |
CAPEC-682 |
Exploitation of Firmware or ROM Code with Unpatchable Vulnerabilities An adversary may exploit vulnerable code (i.e., firmware or ROM) that is unpatchable. Unpatchable devices exist due to manufacturers intentionally or inadvertently designing devices incapable of updating their software. Additionally, with updatable devices, the manufacturer may decide not to support the device and stop making updates to their software. |
NotesNotes
The "firmware" term does not have a single commonly-shared definition, so there may be variations in how this CWE entry is interpreted during mapping.
References
REF-1095
Bad news: KeyWe Smart Lock is easily bypassed and can't be fixed
Matthew Hughes.
https://www.theregister.com/2019/12/11/f_secure_keywe/ REF-1096
Alarm bells ring, the IoT is listening
Alex Scroxton.
https://www.computerweekly.com/news/252475324/Alarm-bells-ring-the-IoT-is-listening REF-1097
Zyxel Flaw Powers New Mirai IoT Botnet Strain
Brian Krebs.
https://krebsonsecurity.com/2020/03/zxyel-flaw-powers-new-mirai-iot-botnet-strain/
Submission
Name |
Organization |
Date |
Date release |
Version |
Paul A. Wortman |
Wells Fargo |
2020-05-13 +00:00 |
2020-02-24 +00:00 |
4.1 |
Modifications
Name |
Organization |
Date |
Comment |
CWE Content Team |
MITRE |
2020-08-20 +00:00 |
updated Common_Consequences, Demonstrative_Examples, Description, Potential_Mitigations |
CWE Content Team |
MITRE |
2020-12-10 +00:00 |
updated Description, Relationships |
CWE Content Team |
MITRE |
2021-03-15 +00:00 |
updated Maintenance_Notes |
CWE Content Team |
MITRE |
2021-07-20 +00:00 |
updated Demonstrative_Examples, Maintenance_Notes |
CWE Content Team |
MITRE |
2021-10-28 +00:00 |
updated Common_Consequences, Description, Detection_Factors, Maintenance_Notes, Modes_of_Introduction, Observed_Examples, References, Relationships, Terminology_Notes, Weakness_Ordinalities |
CWE Content Team |
MITRE |
2022-04-28 +00:00 |
updated Detection_Factors, Observed_Examples, Potential_Mitigations, Relationships |
CWE Content Team |
MITRE |
2022-10-13 +00:00 |
updated Related_Attack_Patterns |
CWE Content Team |
MITRE |
2023-04-27 +00:00 |
updated Relationships |
CWE Content Team |
MITRE |
2023-06-29 +00:00 |
updated Mapping_Notes |