Sorry, we've misplaced that URL or it's pointing to something that doesn't exist.
diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html index 4960e6e..05f37f9 100644 --- a/404.html +++ b/404.html @@ -1 +1 @@ -
Sorry, we've misplaced that URL or it's pointing to something that doesn't exist.
Sorry, we've misplaced that URL or it's pointing to something that doesn't exist.
The model is a result of a collaborative effort by MITRE, Niyo Little Thunder Pearson, Red Balloon Security, and Narf Industries.
After garnering significant interest for peer review across diverse industries, numerous organizations piloted the threat model, offering invaluable feedback. We appreciate the interest and feedback from vendors and integrators across many industries including energy, water, manufacturing, robotics, aerospace, health, automotive, as well as researchers and threat tool vendors. This ongoing collaborative effort has been instrumental in refining and enhancing the model’s content and useability. We look forward to continued collaboration to strengthen the ability of the model to enable “secure by design.”
Please send inquiries about EMB3D to emb3d@mitre.org
Material on this site is ©2024 The MITRE Corporation and may be copied and distributed with permission only.
This project makes use of MITRE ATT&CK®.
ATT&CK® Terms of Use - https://attack.mitre.org/resources/legal-and-branding/terms-of-use/
See the ATT&CK® FAQ for more information on how to use and represent the ATT&CK name.
The model is a result of a collaborative effort by MITRE, Niyo Little Thunder Pearson, Red Balloon Security, and Narf Industries.
After garnering significant interest for peer review across diverse industries, numerous organizations piloted the threat model, offering invaluable feedback. We appreciate the interest and feedback from vendors and integrators across many industries including energy, water, manufacturing, robotics, aerospace, health, automotive, as well as researchers and threat tool vendors. This ongoing collaborative effort has been instrumental in refining and enhancing the model’s content and useability. We look forward to continued collaboration to strengthen the ability of the model to enable “secure by design.”
Please send inquiries about EMB3D to emb3d@mitre.org
Material on this site is ©2024 The MITRE Corporation. The EMBED framework and web site content may be used according to the Terms of Use.
This project makes use of MITRE ATT&CK®.
ATT&CK® Terms of Use - https://attack.mitre.org/resources/legal-and-branding/terms-of-use/
See the ATT&CK® FAQ for more information on how to use and represent the ATT&CK name.
The EMB3D Threat Model provides a cultivated knowledge base of cyber threats to embedded devices, providing a common understanding of these threats with security mechanisms to mitigate them.
EMB3D aligns with and expands on several existing models like Common Weakness Enumeration, MITRE ATT&CK®, and Common Vulnerabilities and Exposures, specifically focusing on embedded devices. EMB3D provides a cultivated knowledge base of cyber threats to devices, including those observed in the field environment or demonstrated through proofs-of-concept and theoretic research. Mapping these threats to device properties helps users develop and tailor accurate threat models for specific embedded devices. For each threat, suggested mitigations are provided for technical mechanisms that device vendors should implement to mitigate the given threat by building security into the device. EMB3D is a comprehensive framework for the entire security ecosystem — device vendors, asset owners and operators, security researchers, and testing organizations.
EMB3D is a living framework that will be updated with new threats and mitigations as security researchers discover new vulnerabilities, threats, and security defenses. EMB3D is a public, community resource where all information is openly available, and the security community can submit additions and revisions.
The EMB3D Threat Model provides a cultivated knowledge base of cyber threats to embedded devices, providing a common understanding of these threats with security mechanisms to mitigate them.
EMB3D aligns with and expands on several existing models like Common Weakness Enumeration, MITRE ATT&CK®, and Common Vulnerabilities and Exposures, specifically focusing on embedded devices. EMB3D provides a cultivated knowledge base of cyber threats to devices, including those observed in the field environment or demonstrated through proofs-of-concept and theoretic research. Mapping these threats to device properties helps users develop and tailor accurate threat models for specific embedded devices. For each threat, suggested mitigations are provided for technical mechanisms that device vendors should implement to mitigate the given threat by building security into the device. EMB3D is a comprehensive framework for the entire security ecosystem — device vendors, asset owners and operators, security researchers, and testing organizations.
EMB3D is a living framework that will be updated with new threats and mitigations as security researchers discover new vulnerabilities, threats, and security defenses. EMB3D is a public, community resource where all information is openly available, and the security community can submit additions and revisions.
First, identify the set of Device Properties List that apply to the device being evaluated based on device knowledge and documentation. While a vendor may be able to fully enumerate all properties, an asset operator or security researcher may need to review available documentation or perform initial device testing or decomposition to fully enumerate the relevant properties.
Select the applicable properties in the Properties Mapper Tool to generate the list of Threats the device may be exposed to because it incorporates those properties and features.
Properties to Threats MapperAfter identifying the device’s properties list and obtaining the candidate threat mapping, the next step is to review each potential threat to determine if it truly applies to the device and how much risk it poses. For additional details, follow the threat detail links output by the Mapper Tool or look up the associated Threat ID (TID) in the Threats catalog. Each threat description provides additional information about that threat, including its maturity level, documented threat evidence and CVEs, and associated weaknesses from the CWE database. This information helps to better understand the mechanics of the threat, its prerequisites, how it manifests on embedded devices, and how threat actors might utilize it, which can be used to better understand the risk of that threat to the device in question.
Equipped with a list of threats that pose a viable risk to the device, the next step is to determine if the device sufficiently defends against those threats. Coming in the next release of EMB3D in Summer 2024, each threat description will include a set of Foundational, Intermediate, and Leading mitigations. These mitigations will provide guidance on what technical mechanisms can best prevent or reduce the risk of that threat. Mitigations will include references to guidance documents and best practices, along with information about potential limitations and challenges when deploying each mitigation.
The mitigation recommendations can then be used to make decisions and plans about the device. Device vendors may use the mitigations mapping to prioritize their security engineering efforts and choose technical security mechanisms that will be most effective against current and future threats. Asset owners and operators may use it to inform acquisitions, make judgements about the risks of devices deployed in their environments, or what additional environmental-level mitigations they wish to make to address residual risk. Finally, security researchers can use this information to organize and triage their efforts to determine which aspects of a device are worth deeper investigation.
First, identify the set of Device Properties List that apply to the device being evaluated based on device knowledge and documentation. While a vendor may be able to fully enumerate all properties, an asset operator or security researcher may need to review available documentation or perform initial device testing or decomposition to fully enumerate the relevant properties.
Select the applicable properties in the Properties Mapper Tool to generate the list of Threats the device may be exposed to because it incorporates those properties and features.
Properties to Threats MapperAfter identifying the device’s properties list and obtaining the candidate threat mapping, the next step is to review each potential threat to determine if it truly applies to the device and how much risk it poses. For additional details, follow the threat detail links output by the Mapper Tool or look up the associated Threat ID (TID) in the Threats catalog. Each threat description provides additional information about that threat, including its maturity level, documented threat evidence and CVEs, and associated weaknesses from the CWE database. This information helps to better understand the mechanics of the threat, its prerequisites, how it manifests on embedded devices, and how threat actors might utilize it, which can be used to better understand the risk of that threat to the device in question.
Equipped with a list of threats that pose a viable risk to the device, the next step is to determine if the device sufficiently defends against those threats. Each threat description includes a set of Foundational, Intermediate, and Leading mitigations. These mitigations provide guidance on what technical mechanisms can best prevent or reduce the risk of that threat. Mitigations will include references to guidance documents and best practices, along with information about potential limitations and challenges when deploying each mitigation.
The mitigation recommendations can then be used to make decisions and plans about the device. Device vendors may use the mitigations mapping to prioritize their security engineering efforts and choose technical security mechanisms that will be most effective against current and future threats. Asset owners and operators may use it to inform acquisitions, make judgements about the risks of devices deployed in their environments, or what additional environmental-level mitigations they wish to make to address residual risk. Finally, security researchers can use this information to organize and triage their efforts to determine which aspects of a device are worth deeper investigation.
The EMB3D Threat Model provides a cultivated knowledge base of cyber threats to embedded devices, providing a common understanding of these threats with security mechanisms to mitigate them.
This initial release of EMB3D includes the Device Properties and Threats enumerations. The full set of Mitigations will be available in the Summer 2024 update.
EMB3D is a threat model for embedded devices found in industries such as critical infrastructure, Internet of Things, automotive, healthcare, manufacturing, and many more. The threat model is intended to be a resource to help vendors, asset owners/operators, test organizations, and security researchers to improve the overall security of embedded devices' hardware and software. This threat model aims to serve as a central repository of information, defining known threats to embedded devices and their unique device features/properties that enable specific threat actions. By mapping the threats to the associated device features/properties, the user can easily enumerate threat exposure based on the known device features.
Device properties describe a device's hardware and software components and capabilities of a device. These include physical hardware, network services and protocols, software, and firmware. Each category is further divided into sub-properties that are then mapped to a set of threats. By mapping properties, users can identify the threats associated with a given device property.
EMB3D threats identify how a threat actor can achieve a specific objective or effect on a system or device. Each threat description includes (i) information about the technical features that are targeted by the threat; (ii) the actions that must be performed by the threat actor to cause the threat's effect, including the impact or effect the threat will have on the device; and (iii) the vulnerabilities or weaknesses within that mechanism that enable the threat actions.
Mitigation strategies and techniques are described for each threat. These can be leveraged by device vendors to prevent and reduce the risk of a threat, and by end users to validate that devices are sufficiently protected against that threat. The mitigations define the mechanisms or technologies that protect against the threat while remaining flexible in how mitigations can be implemented within the device's unique constraints.
Support device threat models and provide guidelines for mitigations requirements/designs. Develop device roadmaps for evaluating device risk and prioritizing mitigation efforts.
Inform acquisition requirements and decisions about unmitigated threats/risks. Support acquisition efforts related to evaluating a device's security capabilities. Guide the development and deployment of compensating controls around unmitigated threats.
Scope assessment activities and outcomes. Help identify potential trouble spots for deeper investigation. Contribute to research efforts around novel threats and mitigations.
The EMB3D Threat Model provides a cultivated knowledge base of cyber threats to embedded devices, providing a common understanding of these threats with security mechanisms to mitigate them.
EMB3D is a threat model for embedded devices found in industries such as critical infrastructure, Internet of Things, automotive, healthcare, manufacturing, and many more. The threat model is intended to be a resource to help vendors, asset owners/operators, test organizations, and security researchers to improve the overall security of embedded devices' hardware and software. This threat model aims to serve as a central repository of information, defining known threats to embedded devices and their unique device features/properties that enable specific threat actions. By mapping the threats to the associated device features/properties, the user can easily enumerate threat exposure based on the known device features.
Device properties describe a device's hardware and software components and capabilities of a device. These include physical hardware, network services and protocols, software, and firmware. Each category is further divided into sub-properties that are then mapped to a set of threats. By mapping properties, users can identify the threats associated with a given device property.
EMB3D threats identify how a threat actor can achieve a specific objective or effect on a system or device. Each threat description includes (i) information about the technical features that are targeted by the threat; (ii) the actions that must be performed by the threat actor to cause the threat's effect, including the impact or effect the threat will have on the device; and (iii) the vulnerabilities or weaknesses within that mechanism that enable the threat actions.
Mitigation strategies and techniques are described for each threat. These can be leveraged by device vendors to prevent and reduce the risk of a threat, and by end users to validate that devices are sufficiently protected against that threat. The mitigations define the mechanisms or technologies that protect against the threat while remaining flexible in how mitigations can be implemented within the device's unique constraints.
Support device threat models and provide guidelines for mitigations requirements/designs. Develop device roadmaps for evaluating device risk and prioritizing mitigation efforts.
Inform acquisition requirements and decisions about unmitigated threats/risks. Support acquisition efforts related to evaluating a device's security capabilities. Guide the development and deployment of compensating controls around unmitigated threats.
Scope assessment activities and outcomes. Help identify potential trouble spots for deeper investigation. Contribute to research efforts around novel threats and mitigations.
Foundational | Intermediate | Leading |
---|---|---|
' + foundational.join(" ") + " | ";
+ mitigationsDiv_inner +=
+ '' + intermediate.join(" ") + " | ";
+ mitigationsDiv_inner +=
+ '' + leading.join(" ") + " | ";
+ mitigationsDiv_inner += "
Under a software bootloader authentication scheme, the bootloader is authenticated using a software-based mechanism where the key, authenticated integrity measurement, and verification logic are stored within memory and the authentication is performed on a main/multipurpose processor. This performs boot-time integrity verification of the bootloader to ensure it was not previously modified or tampered with. Before a bootloader is executed, it should be authenticated by taking an integrity measurement (e.g., hash) of the bootloader, and verifying the hash against a stored signed integrity measurement stored in a bootrom. A device may have multiple bootloaders which operate in multiple stages; therefore, this mitigation may need to be implemented and executed multiple times across the stages to ensure the integrity of each stage.
Lastly, authenticating the first and all subsequent bootloaders allows the device to build a chain-of-trust, through which a secure boot scheme can be made for the device. Secure boot schemes allow the device to use earlier-staged authenticated bootloaders to authenticate and launch subsequent bootloaders and software.
Because this mitigation stores the keys and authentication logic/mechanisms in memory and executes checks on the main CPU, this mitigation is vulnerable to key extractions (TID-214: Secrets Extracted from Device Root of Trust) and tampering with the authentication process (TID-214: Inadequate Bootloader Protection and Verification). To minimize this threat, the first stage of the bootloader that performs this check should be stored within ROM to prevent modification by possible malicious code injected at runtime.
Note: This mitigation is in contrast to a hardware-based bootloader authentication scheme (MID-002 - Hardware-backed Bootloader Authentication), where dedicated hardware is used to protect the key and authentication process.
Limitation: A software-based bootloader authentication scheme can be bypassed if a threat actor is able to physically extract symmetric keys from storage, memory, or through side-channel analysis of the processor while the key is in-use. Additionally, if the device is using asymmetric encryption, these protections can be undermined by changing the hash of the public key or the public key itself stored on the device.
[1] Ubuntu. “Signing.” ubuntu.com. Accessed: Aug. 28, 2024. [Online.] Available: https://wiki.ubuntu.com/UEFI/SecureBoot/Signing
[2] U-Boot. “U-Boot Verified Boot.” u-boot.org. Accessed: Aug. 28, 2024. [Online.] Available: https://docs.u-boot.org/en/latest/usage/fit/verified-boot.html
[3] T. Lewis and M. Khandelwal. “Best Practices for UEFI Secure Boot Guidelines.” uefi.org. Accessed: Aug. 28, 2024. [Online.] Available: https://uefi.org/sites/default/files/resources/Insyde%20HPE%20NSA%20and%20UEFI%20Secure%20Boot%20Guidelines_FINAL%20v2%20%281%29.pdf
[4] National Security Agency. “Boot Security Modes and Recommendations.” nsa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/csi-boot-security-modes-and-recommendations.pdf
[5] Android. “Implementing dm-verity.” android.com. Accessed: Aug. 28, 2024. [Online.] Available: https://source.android.com/docs/security/features/verifiedboot/dm-verity
[6] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
A secure boot scheme where a hardware root of trust verifies the integrity of the bootloader will give a device strong security against bootloader tampering prior to boot time. A hardware root of trust gives a device the ability to securely store signatures and keys somewhere that they cannot be accessed before or after booting. This root of trust can then be used to perform boot-time integrity verification of the bootloader to ensure it was not previously modified or tampered with. Before a bootloader is executed, it should be authenticated by taking an integrity measurement (e.g., hash) of the bootloader, and verifying the integrity measurement against a signed integrity measurement stored in the hardware element. A device may have multiple bootloaders which operate in multiple stages, this mitigation may need to be implemented and executed across multiple times to ensure integrity of each stage.
Additionally, this hardware root of trust can be used to anchor a chain-of-trust flowing from the bootloader that can be used to verify the integrity of other modules on the device.
This implementation will vary based on different secure boot schemes and frameworks, along with device architectures and operating systems.
Note: This Mitigation requires that the device has a secure hardware root of trust. Please see PID-25 - Device includes software/hardware root of trust for information about related threats and mitigations.
[1] Microsoft. “Secure boot.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot
[2] T. Lewis and M. Khandelwal. “Best Practices for UEFI Secure Boot Guidelines.” uefi.org. Accessed: Aug. 28, 2024. [Online.] Available: https://uefi.org/sites/default/files/resources/Insyde%20HPE%20NSA%20and%20UEFI%20Secure%20Boot%20Guidelines_FINAL%20v2%20%281%29.pdf
[3] ARM. “Trusted Board Boot Requirements Client (TBBR-CLIENT) Armv8-A.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/den0006/d
[4] National Security Agency. “Boot Security Modes and Recommendations.” nsa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/csi-boot-security-modes-and-recommendations.pdf
[5] Intel. “Intel Hardware Shield - Below-the-OS Security.” intel.com. Accessed: Aug. 28, 2024. [Online.] Available: https://web.archive.org/web/20231220181349/https://www.intel.com/content/dam/www/central-libraries/us/en/documents/below-the-os-security-white-paper.pdf
[6] ARM. “Secure boot.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system/Secure-boot?lang=en
[7] Chromium. “Security in ChromeOS.” chromium.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.chromium.org/chromium-os/developer-library/reference/security/security-whitepaper/#hardware-root-of-trust-and-verified-boot
[8] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
Building on the simpler MID-009 - Operating System-based Runtime Integrity Check, devices can go further and periodically take integrity measurements and send them out in remote attestation messages. These measurements can be implemented separately across multiple parts of the device stack, such as the bootloader, firmware, software, and application process level, and can include readings on bootloader integrity, device timing statistics, process and page-table integrity, and overall memory integrity. With a combination of all of this information, users can gain a reasonable sense of if the device’s normal operations have been manipulated.
Note: Periodic integrity measurements are the most valuable and trustworthy when a device has a secure operating environment in which to perform its measurement calculations and network encryption. The presence of these properties may however expose a device to threats related to PID-41 - Device exposes remote network services, PID-4113 - Device includes cryptographic functions for sensitive data, such as encryption or authentication, PID-251 - Root of Trust is physically accessible or is not immutable, or PID-252 - Root of Trust is immutable
[1] Microsoft. “Microsoft Azure Attestation.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/azure/attestation/overview
[2] Microsoft. “Attestation.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/azure/confidential-computing/attestation-solutions
[3] Z. Ling, H. Yan, X. Shao, J. Luo., Y. Xu, B. Pearson, and X. Fu. “Secure boot, trusted boot, and remote attestation for ARM TrustZone-based IoT Nodes” in Journal of Systems Architecture, Jul. 2021. Vol. 119. [Online.] Available: https://www.sciencedirect.com/science/article/pii/S1383762121001661
[4] Red Balloon Security. “Symbiote Injection Process.” redballoon.com. Accessed: Aug. 28, 2024. [Online.] Available: https://redballoonsecurity.com/symbiote-injection-process/
Mechanisms to protect memory against code injection include restricting what parts of memory can execute code and randomizing address space to prevent the development of effective exploits.
Executable Space Protection and Write xor Execute (W^X) should be used to restrict what code can be executed in memory. Executable Space Protection uses either hardware or software features to mark memory as non-executable, thereby preventing injected code from being executed. W^X restricts a memory page from being both writable and executable, therefore, any memory that can be overwritten by a threat actor (W), cannot be executable (X).
Address space layout randomization (ASLR) is designed to reduce the predictability of memory addresses so that a threat actor cannot consistently find areas of memory that are able to be exploited or manipulated. This can be done across the application and kernel (KASLR) data spaces.
Lastly, program stack specific mitigations, such as stack canaries [5], safe/unsafe stack schemes [4], etc. can be used to detect or increase the difficulty of stack overwrite attacks.
Devices should use a combination of the above classes of code and memory injection protections to give their device a more secure posture.
Limitations: Some mechanisms that specifically address code injection can be bypassed by attacks that reuse existing code, such as return-to-libc and return-oriented programming (ROP). Further, ASLR can be undermined by secondary vulnerabilities that disclose memory space addresses.
[1] Microsoft. “What is Data Execution Prevention (DEP)?.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://support.microsoft.com/en-us/topic/what-is-data-execution-prevention-dep-60dabc2b-90db-45fc-9b18-512419135817
[2] The kernel development community. “Kernel Self-Protection.” kernel.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.kernel.org/doc/html/v5.4/security/self-protection.html?highlight=kaslr
[3] J. Thompson. “Six Facts about Address Space Layout Randomization on Windows.” google.com. Accessed: Aug. 28, 2024. [Online.] Available: https://cloud.google.com/blog/topics/threat-intelligence/six-facts-about-address-space-layout-randomization-on-windows/
[4] The Clang Team. “SafeStack.” llvm.org. Accessed: Aug. 28, 2024. [Online.] Available: https://releases.llvm.org/15.0.0/tools/clang/docs/SafeStack.html
[5] E. Styger. “Stack Canaries with GCC: Checking for Stack Overflow at Runtime.” mcuoneclipse.com. Accessed: Aug. 28, 2024. [Online.] Available: https://mcuoneclipse.com/2019/09/28/stack-canaries-with-gcc-checking-for-stack-overflow-at-runtime/
Memory safe programming languages will give the device security guarantees around the bounds of memory that are safe to read, write, or execute. This can greatly reduce attacks targeting memory bounding errors. Memory safety integration in a device can take multiple forms. Individual drivers, libraries, critical kernel functions, or applications should be implemented in memory safe programming languages. In other instances, it may be possible to use entire kernels or OSes written in memory safe programming languages.
Consideration: Memory safe programming languages implement memory safety using different mechanisms. Based on a device’s resources and properties, using one language over another may be desirable. For example, certain memory safe programming languages use more resources due to their runtime memory protections. These can include garbage collection, virtual runtime environments, and code interpreters. Languages that fall into this category are Java, Python, and Go. Other languages, such as Rust, use compile-time checks to handle address spacing mappings and frees.
Limitation: Use of a memory safe language can help protect against a significant number of common vulnerabilities; however, it does not address every type of software weakness. For example, issues related to input validation, logic flaws, or deserialization can still occur in software written in memory safe languages.
[1] National Security Agency. “Software Memory Safety.” defense.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
Driver memory isolation separates a given driver from other drivers and OS/Kernel functionality wherever possible. Examples include microkernel architectures and schemes that split some or all of a driver to run in user space vs within a monolithic kernel.
Deploying drivers in a memory isolated context is an effective way of reducing the attack surface of an OS/Kernel because drivers are frequently handling I/O operations and external data, making them readily targetable. When drivers are not memory isolated, a vulnerability in one driver may enable a threat actor to move laterally to other drivers or OS/Kernel components, potentially giving them more access on a device. Memory isolation makes lateral movement more difficult.
Limitations: Memory can likely never be fully separated due to a need for driver information to be handled by the system or applications running on the device. For this reason, the attack surface will never be entirely eliminated, and other protections, such as the usage of memory safe programming languages, could be put in place to further decrease the threat actor’s attack surface.
[1] Y. Huang, V. Narayanan, D. Detweiler, K. Huang, G. Tan, T. Jaeger, A. Burtsev. (Jul. 2022). KSplit: Automating Device Driver Isolation. Presented at Proceedings of the 16th USENIX Symposium on Operating Systems Design and Implementation. [Online.] Available: https://www.usenix.org/system/files/osdi22-huang-yongzhe.pdf
[2] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
Control Flow Integrity (CFI) mechanisms ensure that the runtime flow of the program does not deviate from the developer’s intended control flow. In the presence of CFI, threat actors have a more difficult time changing the flow of a program or violating program behaviors because the program has checks in place to ensure that the right functions are called at predictable memory locations. This can prevent against attacks that abuse valid memory spaces and existing code, such as Return Oriented Programming (ROP) seen in TID-206: Memory Management Protections Subverted, because the program code flow, and therefore sections of code such as return addresses, are guaranteed integrity and therefore cannot be manipulated.
[1] M. Benatto. “Fighting exploits with Control-Flow Integrity (CFI) in Clang.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.redhat.com/en/blog/fighting-exploits-control-flow-integrity-cfi-clang
[2] Android. “Control flow integrity.” android.com. Accessed: Aug. 28, 2024. [Online.] Available: https://source.android.com/docs/security/test/cfi
[3] R. Walls, N. Brown, T. Le Baron, C. Chue, H. Okharvi, B. Ward. “Control-Flow Integrity for Real-Time Embedded Systems.” mit.edu. Accessed: Aug. 28, 2024. [Online.] Available: https://web.mit.edu/ha22286/www/papers/ECRTS19.pdf
[4] I. Anati and O. Simhon. “Control Flow Enforcement Technology.” intel.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.intel.com/content/dam/develop/external/us/en/documents/catc17-introduction-intel-cet-844137.pdf
[5] National Security Agency. “Software Memory Safety.” defense.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
[6] Apple. “Improving control flow integrity with pointer authentication.” apple.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.apple.com/documentation/browserenginekit/improving-control-flow-integrity-with-pointer-authentication
[7] Microsoft. “Control Flow Guard for platform security.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
[8] ARM. “Overview of Control Flow Integrity.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/100748/0619/Security-features-supported-in-Arm-Compiler-for-Embedded/Overview-of-Control-Flow-Integrity
One way to understand a protocol’s complexity is through a computational theoretic perspective (e.g., LangSec). For example, the Chomsky hierarchical rank of the grammar used to create a protocol directly dictates the minimum computational model necessary to recognize and parse the protocol. Therefore, 1) structured data and protocols should be designed using the lowest level grammar possible so that 2) parsers can be made using minimally and appropriately matched computational models (e.g., a deterministic push-down automata being used to parse context free input languages instead of a Turing machine).
1. Regarding implementing your own protocol
The design of any new protocol should include an understanding of the grammar used to create that protocol and the computational model necessary to parse that protocol to ensure that the language can be correctly represented by a decidable computational model, particularly with regard to the equivalence problem. This would mean building a protocol out of a regular or deterministic context-free grammar.
Unless a protocol or input language can be built from a regular or deterministic context-free grammar, any corresponding parsers cannot be built to be recognizers and parsers of that protocol without being made undecidable with regard to the equivalence problem and maintain full protocol functionality. This is important because if a parser built to run over an undecidable grammar with regard to the equivalence problem, it will be impossible to guarantee that the parser does not enter an unwanted or vulnerable state. This makes the parser have a higher chance of exhibiting exploitable behaviors.
2. Regarding implementing your own parser
The design of any new protocol parser should be made such that the computational model of that parser conforms to the minimally sufficient computational model necessary to parse that protocol. If a protocol parser is made to be more complex than the grammar used to make the protocol would otherwise require, threat actors may be able to discover unwanted or vulnerable states that could lead to exploitation. Minimally necessary computational models, ideally ones that are decidable with regard to the equivalence problem, allow for machine states to be checked and give threat actors less opportunities to exploit parser behavior.
[1] L. Sassaman, M. L. Patterson, S. Bratus, A. Shubina, “The Halting Problems of Network Stack Insecurity,” USENIX ;login:, vol. 36, no. 6, pp. 22-32, Dec. 2011. [Online]. Available: https://www.usenix.org/legacy/publications/login/2011-12/openpdfs/Sassaman.pdf
[2] “LangSec: Recognition, Validation, and Compositional Correctness for Real World Security.” Accessed: Aug. 27, 2024. [Online]. Available: http://langsec.org/bof-handout.pdf
[3] Sergey Bratus, Adam J. Crain, Sven M. Hallberg, Daniel P. Hirsch, Meredith L. Patterson, Maxwell Koo, and Sean W. Smith. 2016. Implementing a vertically hardened DNP3 control stack for power applications. In Proceedings of the 2nd Annual Industrial Control System Security Workshop (ICSS ‘16). Association for Computing Machinery, New York, NY, USA, 45–53.
Runtime integrity checks can be performed by the operating system kernel to verify the integrity of files, data, and executables read from storage before use or execution. Checks may be performed at different levels of granularity depending on the implementation, for example at the file level [1], or as filesystem blocks are read from a storage device [2]. Signatures and hashes of the data is stored as metadata and used by the mechanism to check the integrity of data as it is accessed by the kernel and prepared for reading of execution. If the integrity check fails, an error condition will be raised which may range from triggering an audit event, producing a read error for the data, or even halting the system.
Limitations: This is an OS-enforced control; therefore, an attacker may bypass it by exploiting a privilege escalation vulnerability to obtain access to the kernel at runtime or by undermining the integrity of the OS kernel early in the boot process.
[1] H. Sidhpurwala. “How to use the Linux kernel’s Integrity Measurement Architecture.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture
[2] Android. “Implementing dm-verity.” android.com. Accessed: Aug. 28, 2024. [Online.] Available: https://source.android.com/docs/security/features/verifiedboot/dm-verity
[3] V. Pamnani. “System Guard: How a hardware-based root of trust helps protect Windows.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows#secure-launchthe-dynamic-root-of-trust-for-measurement-drtm
The ability to load kernel modules and drivers during runtime is a vector for threat actors to exploit, either by loading an adversary-controlled module that is directly malicious or a vulnerable, but otherwise legitimate, module containing a privilege escalation vulnerability that can be later exploited. Therefore, if there is no need to support runtime loading and executing of drivers, removing that ability can eliminate this threat vector.
When there is a need for loadable drivers and kernel modules, MID-011 - OS Driver/Peripheral Authentication discusses how to do so safely.
OSes should prevent the execution of malicious drivers by authenticating the drivers before they are loaded and executed on the device. This can be done by only allowing drivers that have been signed and authenticated with a vendor private key to load. These signatures can be checked locally on the device and accepted if and only if the signature passes verification.
Additionally, a central operating system is sometimes responsible for loading firmware at runtime onto peripheral devices (often by way of an associated driver). The operating system should verify the authenticity of those peripheral firmware packages as part of, or alongside, the checking the driver prior to loading them on the peripheral hardware (e.g., an FPGA, sub-component microcontroller, etc.)
This authentication scheme should be coupled with MID-001- Software Only Bootloader Authentication or MID-002 - Hardware-backed Bootloader Authentication, where the device authenticates the bootloader and then leverages that trusted bootloader to verify all the drivers that are going to be run on the device. Therefore, drivers are verified by the bootloader, which is in turn given security guarantees from the root of trust.
[1] H. Sidhpurwala. “How to use the Linux kernel’s Integrity Measurement Architecture.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture
[2] Gentoo Authors. “Signed kernel module support.” gentoo.org. Accessed: Aug. 28, 2024. [Online.] Available: https://wiki.gentoo.org/wiki/Signed_kernel_module_support
[3] Allen-Bradley. “ControlLogix EtherNet/IP Module.” rockwellautomation.com. Accessed: Aug. 28, 2024. [Online.] Available: https://literature.rockwellautomation.com/idc/groups/literature/documents/rn/1756-rn659_-en-p.pdf
The OS should enforce access controls for all users and programs to prevent unauthorized access to OS resources, services, and system calls. There are numerous methods of restricting permissions and privileges to users and programs, including leveraging OS-based access control mechanisms that restrict OS system calls or sandbox-based approaches that encapsulate programs within restrictive environments. These mechanisms should be implemented to enforce access based on the principle of least privilege - which states that programs and users should only have access to the resources that they absolutely need to operate, and nothing else.
Operating systems typically deploy various access control mechanisms that restrict which system calls can be executed and what resources those system calls can access. While many operating systems include a default Discretionary Access Control (DAC) mechanism, these have limitations on their ability to define granular permissions for privileged functions. Strong access control mechanisms include (i) capabilities-based permission models, which provide more granular controls over privileged functions, or (ii) mandatory access control (MAC) mechanisms (e.g., SELinux), which allow fully customizable privileges across all system calls and resources. Further, programs should obtain privileged access only for key functions and then downgrade those privileges after the function is performed (e.g., setuid/setguid). The access control mechanisms deployed by the device must be sufficiently sophisticated to support the variety of programs and applications, their exposure to threats (e.g., networks services), and the criticality of specific data or resources.
Other mechanisms can be used to further restrict what resources an executing process may access. For example, in Linux the seccomp feature can be used to limit which of the OS kernel’s system calls a process may invoke, further constricting the attack surface a compromised process can access to increase its foothold on a device.
[1] AppArmor. “Linux kernel security module.” apparmor.net. Accessed: Aug. 28, 2024. [Online.] Available: https://www.apparmor.net/
[2] M. Kerrisk. “seccomp.” man7.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.man7.org/linux/man-pages/man2/seccomp.2.html
[3] RedHat. “4.2 SELinux and Mandatory Access Control (MAC).” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_security_guide/sect-virtualization_security_guide-svirt-mac
[4] RedHat. “10.4. Defining Role-Based Access Controls.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/defining-roles
[5] J. Kline. “The Linux Security Hardening Checklist for Embedded Systems.” starlab.io. Accessed: Aug. 28, 2024. [Online.] Available: https://www.starlab.io/blog/the-linux-security-hardening-checklist-for-embedded-systems
Separating the memory between processes and threads, using enforcement mechanisms like memory management units (MMUs) or memory protection units (MPUs), shrinks the attack surface available to threat actors. Memory space separation prevents a threat actor from trivially accessing the memory of other threads or processes to conduct lateral movement, privilege escalation, or process manipulation. This is frequently done through using virtual memory allocation schemes with the MMU.
Additionally, running all software/applications in separate isolated memory-restricted regions and using the kernel/OS to broker between processes can greatly reduce a device’s threat landscape. This is because restricting software/applications to their own segments and using kernel-brokered inter-process communication (IPC) forces adversaries to kernel to gain unauthorized access to other processes.
Limitations: IPC implementations will vary and will depend on the function of the devices and its hardware architecture. IPC mechanisms and kernel system calls can have their own vulnerabilities that allow privilege escalation or lateral movement.
[1] timlt. “Develop secure embedded applications with Eclipse ThreadX.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/azure/iot-develop/concepts-azure-rtos-security-practices#embedded-security-components-memory-protection
[2] D. Pandey. “Inter Process Communication (IPC).” geeksforgeeks.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.geeksforgeeks.org/inter-process-communication-ipc/
[3] BlackBerry. “Interprocess Communication (IPC).” qnx.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.sys_arch/topic/ipc.html
Sandboxes are software execution environments that run code under restrictions to limit that code’s access to system resources a non-restricted user-level process would otherwise have access to. This is especially useful when handling untrusted code provided by users (e.g., a PLC program) or 3rd parties (e.g., JavaScript from a remote web site), especially when supporting such code is a mandatory device function and cannot simply be forbidden (as in MID-051).
A sandbox runtime provides only filtered and managed access to system resources. For example, an untrusted program will not have direct access to invoke kernel syscalls, read or write to files, access network interfaces, etc. The runtime can then provide only limited access to specific constrained resources governed by security policy, which can significantly reduce the risk of executing untrusted code. These protections will make lateral movement to different processes more difficult for malicious code running within a sandbox, as the code has no access to memory in those processes and has very little, to no, access to privileged function calls. Malicious code will be unable to access and manipulate data, memory, and code outside the sandbox without first finding and exploiting a vulnerability in the sandbox itself. Mobile devices running iOS and Android are a widely used example of this, running all applications in individual sandboxes to protect user data from malicious applications [1][4]. Another example is the WebAssembly format, adopted recently in web browsers, which allows compiled code to safely execute in a sandbox created by the browser (similar to how JavaScript code is sandboxed) [5].
Additionally, the abstraction provided by a sandbox can be used to prevent untrusted code from exploiting vulnerabilities that require low-level access to hardware (e.g., TID-103, TID-110). For example, in response to the Spectre and Meltdown vulnerabilities, web browsers deployed changes to their JavaScript engines to reduce the resolution of timers available to JavaScript code, reducing timer accuracy below the threshold necessary to successfully exploit the timing-based side channel [2][3]. A similar change in Chromium-based browsers eliminates a form of RowHammer that researchers crafted using JavaScript and WebGL [2].
[1] Apple. “Apple Platform Security.” apple.com. Accessed: Aug. 26, 2024. [Online]. Available: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
[2] The Chromium Projects. “Mitigating Side-Channel Attacks.” Chromium Security. Accessed: Sep. 5, 2024. [Online.] Available: https://www.chromium.org/Home/chromium-security/ssca/
[3] L. Wagner. “Mitigations landing for new class of timing attack.” Mozilla Security Blog. Accessed: Sep. 5, 2024. [Online.] Available: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
[4] Android Open Source Project. “Application Sandbox.” AOSP Documentation. Accessed: Sep. 10, 2024. [Online.] Available: https://source.android.com/docs/security/app-sandbox
[5] WebAssembly. “Security.” webassembly.org. Accessed: Sep. 10, 2024. [Online.] Available: https://webassembly.org/docs/security/
Some operating systems offer the ability to create containers that wrap small sets of applications in isolated partitions. Each container has its own view of system resources that is isolated from other containers and the host OS. Examples include Linux containers (LXC), Docker, BSD jails, etc. Container partitions are created by the host OS kernel which provides each container with isolated copies of various system resources, such as a unique guest filesystem, partitioned network stack, process ID space, user ID space, etc. Unlike virtualization (see MID-022), container systems do not need to provide virtualized views of hardware running separate full operating systems, instead abstracting at the level of a single kernel instance allows for lower performance overhead. However, OS kernels typically have a larger attack surface than a VM system’s hypervisor, so containers are generally considered to be a weaker form of isolation than virtualization [2]. Device designers should consider risk vs performance tradeoffs when selecting which isolation technology to implement, although both technologies can used in parallel to achieve the desired balance.
Containers offer several opportunities for security hardening. All the capabilities of MID-012 and MID-013 are available within each container partition. Furthermore, container filesystems can be stripped down to the bare minimum necessary for the applications within the container to function (see MID-016 – Least Functionality). So-called “rootless” container design patterns can be employed such that all processes within a container context run with unprivileged non-root user permissions. Host-side orchestration tools like Docker, can enforce additional security restrictions over container contexts when they are created [1]. For example, seccomp syscall filters can be applied to each container to restrict what kernel interfaces any process within that container may access, which reduces the opportunities for container breakout attacks [4]. Finally, device developers may consider utilizing non-persistent or immutable (read-only) container image design patterns. These increase the difficulty for attackers to establish a foothold within a container while simplifying the process of restoring containers to a known-good state through restarting containers from an integrity-checked known-good state periodically or in response to indicators of compromise.
Note: Containers can offer additional non-security benefits to device developers. The additional modularization they provide can make application development and maintenance more efficient, including making various devops practices more accessible to embedded device development workflows [6].
SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
CR 3.4 – Software and information integrity
[1] Docker. “Docker security.” docker.com. Accessed: Aug. 28, 2024. [Online.] Available: https://docs.docker.com/engine/security/
[2] M. Ahuje. “CVE-2022-0185: Kubernetes Container Escape Using Linux Kernel Exploit.” crowdstrike.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/
[4] V. Rothberg. “Improving Linux container security with seccomp.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.redhat.com/sysadmin/container-security-seccomp
[5] M. Kerrisk. “seccomp.” man7.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.man7.org/linux/man-pages/man2/seccomp.2.html
[6] Wind River Systems Inc. “What are Embedded Containers?” Accessed: Sep. 5, 2024. [Online.] Available: https://www.windriver.com/solutions/learning/embedded-containers
Removing all unnecessary programs or features can greatly limit the amount of tools available on a device for adversaries to potentially use. For example, by removing a compiler, unnecessary code, device drivers, or unnecessary binaries from a device, adversaries won’t be able to leverage that functionality into device exploits. If devices starve the threat actors of available tools, it will be more difficult for them to leverage capabilities into malicious activity.
Limitations: Many device functions that could be abused by a threat actor are necessary to support the device’s core operational or management functions and therefore cannot be removed.
[1] CISA. “Identifying and Mitigating Living Off the Land Techniques.” cisa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.cisa.gov/sites/default/files/2024-02/Joint-Guidance-Identifying-and-Mitigating-LOTL_V3508c.pdf
[2] J. Phipps. “Living Off the Land Attacks: LOTL Definition & Prevention.” esecurityplanet.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.esecurityplanet.com/networks/living-off-the-land-attacks/#best-practices
[3] B. Lenaerts-Bergmans. “What Are Living Off the Land (LOTL) Attacks?.” crowdstrike.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.crowdstrike.com/cybersecurity-101/living-off-the-land-attacks-lotl/
Devices should include audit logs of all user access, configuration changes, program updates, service starts and stops, and other events related to security. This allows device operators and security teams to investigate device actions and hunt for unusual behavior that may be indicators of compromise.
Programmable devices like PLCS should keep logs of all program changes so that device operators have the ability to audit them to check for threat actor attempts to manipulate device operating environments. Particularly useful auditable events include program edits, appends, and online edits.
Limitations: Embedded devices often have constraints that limit the extent of on-device logging, such as a lack of storage space, NVRAM burnout, and network bandwidth limitations. Device designers and operators should take these limitations into account when choosing what data should be logged either locally or remotely.
Consideration: Devices should take TID-224: Excessive Access via Software Diagnostic Features into consideration when designing their logging and log access scheme. Logging sensitive information, such as system crash information (core dumps, memory addresses), credentials, or keys, or giving read access to non-privileged users, could expose the device to information leaks.
Note: It is possible to overcome some of the storage limitations by offloading the data over the network. While this presents other issues related to network bandwidth, data reliability, and network-data costs, it helps to overcome some other device-level limitations.
Note: See the threats associated with PID-324 - Device includes support for “program uploads” to retrieve programs from the device from an engineering workstation for more information about uploading programs for inspection.
CR 2.8 - Auditable events
CR 3.7 – Error handling
[1] CISA. “Identifying and Mitigating Living Off the Land Techniques.” cisa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.cisa.gov/sites/default/files/2024-02/Joint-Guidance-Identifying-and-Mitigating-LOTL_V3508c.pdf
[2] P. Czanik. “Reliable IoT event logging with syslog-ng.” opensource.com. Accessed: Aug. 28, 2024. [Online.] Available: https://opensource.com/article/18/3/logging-iot-events-syslog-ng
[3] RedHat. “A. Bharadwaj Madabhushana.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.redhat.com/sysadmin/configure-linux-auditing-auditd
Privileged functions that can severely affect the performance or critical functions of a device should only be accessible to authenticated privileged users. This includes functions such as configuration changes, user account changes, role and permission changes, operating state changes, etc. Alerting for failed access attempts is recommended to detect brute-force login attempts. Additionally, the authentication scheme should include controls for limiting session lifetimes, such as requiring reauthentication based on periods of in-activity.
Note: The mitigation MID-031 - Physical Presence Validation can be paired with this mitigation for more robust device security.
[1] CISA. “Identifying and Mitigating Living Off the Land Techniques.” cisa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.cisa.gov/sites/default/files/2024-02/Joint-Guidance-Identifying-and-Mitigating-LOTL_V3508c.pdf
[2] Magisk. “sudo Command in Linux with Examples.” geeksforgeeks.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.geeksforgeeks.org/sudo-command-in-linux-with-examples/
Applying Return Oriented Programming (ROP) gadget protection techniques to device code involves eliminating sequences of instructions that can be used as ROP gadgets, zeroing out registers, monitoring gadget history, using gadgets to hide other gadgets, modifying gadgets to make them unusable, etc. The goal of these mechanisms is to reduce the number of reusable code fragments that can successfully be used as ROP gadgets, reducing the likelihood that a threat actor can assemble a number and variety of gadgets sufficient to craft a working exploit payload.
Gadget minimization is most easily be performed at compile time, when the compiler is in control over the precise strings of machine instructions it produces [2][3][4]. Other work seeks to identify and potentially remove or neutralize gadgets found in previously compiled libraries and executables. [1]
[1] ivanfrantic. “ropguard.” github.com. Accessed: Aug. 28, 2024. [Online.] Available: https://github.com/ivanfratric/ropguard
[2] pagabuc. “gfree.” github.com. Accessed: Aug. 28, 2024. [Online.] Available: https://github.com/pagabuc/gfree
[3] K. Onarlioglu, L. Bilge, A. Lanzi, D. Balzarotti, and E. Kirda. “G-Free: defeating return-oriented programming through gadget-less binaries” in Proceedings of the 26th Annual Computer Security Applications Conference, ACSAC ‘10. [Online.] Available: https://doi.org/10.1145/1920261.1920269
[4] F. Cassano, C. Bershatsky, J. Ginesin, S. Bashenko, “SafeLLVM: LLVM Without The ROP Gadgets!,” 2023, arXiv:2305.06092v3
Pointer authentication is a hardware security feature added to some recent processor designs (e.g., ARMv8.3) which attach authentication codes to designated pointer values in memory. When the pointer is accessed, for example as a function pointer to jump execution to, its value is checked against the authentication code to ensure it has not been tampered with by a threat actor attempting to perform return-oriented programming or another form of control flow hijack. To implement pointer-level authentication, supported hardware, OS, and compilers are necessary.
Pointer authentication features can be utilized in the implementation of a MID-007 - Control Flow Integrity scheme, but with the advantage of hardware support that should reduce the performance overhead cost typically associated with software-based CFI implementations.
[1] H. Liljestrand, T. Nyman, K. Wang, C. Perez, J. Ekberg, N. Asokan. “PAC it up: Towards Pointer Integrity using ARM Pointer Authentication” presented at 28th USENIX Security Symposium, Aug. 2019. [Online.] Available: https://www.usenix.org/system/files/sec19-liljestrand_0.pdf
[2] M. Rutland. “ARMv8.3 Pointer Authentication” presented at Linux Security Summit., Sept. 2017, Available: https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
[3] ARM. Pointer Authentication on ARMv8.3. Accessed: Aug. 28, 2024. [Online.] Available: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/pointer-auth-v7.pdf
[4] A. Mujumdar. “Armv8.1-M Pointer Authentication and Branch Target Identification Extension.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
[5] ARM. “Basics of Pointer Authentication.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.arm.com/learning-paths/servers-and-cloud-computing/pac/pac/
Virtual Machines (VMs) provide programs with execution environments that are separated from the rest of the system, providing useful security properties (seen in MID-022 - Segmentation Through Hardware-assisted VMs). To help ensure that those guarantees are maintained, the hypervisor’s attack surface accessible from within a VM should be minimized.
VM platforms often offer a variety of virtual hardware devices and APIs to access other hypervisor-provided resources and services to ease tasks like sharing data into and out of a VM. A threat actor that has thoroughly compromised the operating systems resident in a guest VM can access these interfaces and attempt to exploit any vulnerabilities to escalate once again into the hypervisor’s privilege level. Restricting virtual hardware and hypervisor service access to the minimum required by each guest VM reduces the likelihood of a compromise spreading from laterally to other VMs or into the hypervisor.
[1] vmware. “VMware Infrastructure 3 Security Hardening.” vmware.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.vmware.com/pdf/vi3_security_hardening_wp.pdf
[2] M. Jha. “Hardening Virtual Machine Security.” vstellar.com. Accessed: Aug. 28, 2024. [Online.] Available: https://vstellar.com/2017/12/hardening-virtual-machine-security/
[3] RedHat. “Chapter 4. sVirt.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_security_guide/chap-virtualization_security_guide-svirt
Virtual machines increase the level of isolation for software and data by virtualizing and partitioning device hardware and running their own dedicated operating system kernel (unlike containers that share a kernel). This provides stronger separation than kernel-based containers (MID-015) or process separation (MID-013) but at the cost of higher performance overhead. Software compromises will be contained within a VM even if the threat actor can successfully exploit a privilege escalation vulnerability in the OS kernel within a given VM, protecting any code or data present in other VMs.
Hardware-assisted Virtual Machines (VMs) take advantage of CPU extensions that specifically support virtualization use cases to enforce strict separation between VMs’ RAM and other resources. A hypervisor can utilize these CPU features to provide a high degree of assurance in that separation with relatively little performance overhead compared to a fully software-based VM scheme. More advanced hardware features extend the hardware-based separation to I/O device access by extending the functionality of IOMMU features (see MID-053).
Note: Implementing this mitigation will likely expose devices to threats associated with PID-242 - Device includes hypervisor.
[1] OpenSystems Media. “Embedded virtualization: Latest trends and techniques.” embeddedcomputing.com. Accessed: Aug. 28, 2024. [Online.] Available: https://embeddedcomputing.com/technology/processing/embedded-virtualization-latest-trends-and-techniques
[2] BlackBerry. “What Is Virtualization for Embedded Systems?.” qnx.com. Accessed: Aug. 28, 2024. [Online.] Available: https://blackberry.qnx.com/en/ultimate-guides/embedded-system-security/virtualization-for-embedded-systems
[3] E. Kou. “Virtualization for embedded industrial systems.” ti.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.ti.com/lit/wp/spry317b/spry317b.pdf
[4] openstack. “Hardening the virtualization layers.” openstack.org. Accessed: Aug. 28, 2024. [Online.] Available: https://docs.openstack.org/security-guide/compute/hardening-the-virtualization-layers.html
Highly privileged hypervisor software is required to orchestrate and manage the execution of multiple virtual machines. The hypervisor brokers the access guest VMs have to virtual and physical hardware resources and any support services implemented by the hypervisor itself. Because of its privilege level, the hypervisor must be hardened against comprise, a multi-faceted process that can involve multiple technical controls to increase hypervisor security.
Hypervisor-side software components that help implement hypervisor service APIs and the virtual hardware devices exposed to guest VMs should be isolated and sandboxed with minimal privileges to constrain any compromise of those components from spreading to more privileged domains within the hypervisor context. For example, in a hypervisor/host-OS combination based on Linux’s KVM features, the software processes implementing each VM could be run with reduced privileges and under a restrictive SELinux policy [4].
In an embedded systems context, the configuration of the hypervisor and guest VMs is likely to be relatively static with no need to dynamically stop, start, or alter the configurations of VMs during runtime. In that case the hypervisor software and its configurations could be stored in immutable memory to the extent possible and only allowed to be changed as a result of the device’s secure update mechanism.
Hypervisor software and data should also be integrated into the secure boot process to ensure its integrity before the device starts, as can be seen in MID-002 - Hardware-backed Bootloader Authentication. This can be done by placing bootloader-time integrity checks over the hypervisor to ensure that hypervisor code is safe to run according to factory or user-defined signatures.
CR 7.7 – Least functionality
CR 2.1 – Authorization enforcement (1) Authorization enforcement for all users (humans, software processes and devices)
[1] E. Kou. “Virtualization for embedded industrial systems.” ti.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.ti.com/lit/wp/spry317b/spry317b.pdf
[2] BlackBerry. “What Is Virtualization for Embedded Systems?.” qnx.com. Accessed: Aug. 28, 2024. [Online.] Available: https://blackberry.qnx.com/en/ultimate-guides/embedded-system-security/virtualization-for-embedded-systems
[3] ARM. “Secure virtualization.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/102142/0100/Secure-virtualization
[4] RedHat. “Chapter 4. sVirt.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_security_guide/chap-virtualization_security_guide-svirt
VM’s inherent memory isolation provides many protections for memory that is specifically allocated to that VM, there are still opportunities for attacks launched from the hypervisor or any other system component with access to the physical memory. By virtue of virtual machines (VMs) being run on the same hardware, potential exploits and data leaks are present through hardware or device architecture vulnerabilities.
Encrypting VMs and VM-related information can help maintain VM isolation in the presence of an untrustworthy hypervisor by keeping each VMs data confidential during execution. The added encryption makes it such that the VM’s memory space is protected against unauthorized reads by the hypervisor or any other VM. Only undecipherable could be seen from any context other than the intended guest VM that memory belongs to.
Cloud computing uses cases are driving the adoption of these confidential computing features in newer processors. They build upon the RAM encryption functionality (described further in MID-065) that creates encrypted enclaves in memory associated with a particular execution context (thread, process, etc.) such that the contents of that memory are encrypted automatically by the CPU before being written to RAM and automatically decrypted when read in and placed in the CPU’s cache and registers.
CR 4.1 – Information confidentiality
CR 2.1 – Authorization enforcement (1) Authorization enforcement for all users (humans, software processes and devices)
[1] Intel. “Trust Domain Security Guidance for Developers.” intel.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/trusted-domain-security-guidance-for-developers.html
[2] ARM. “Learn the architecture - Realm Management Extension.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/den0126/0100/Overview
[3] M Scapicchio and M. Kozinski. “What is confidential computing?.” ibm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.ibm.com/topics/confidential-computing
[4] Microsoft. “Azure confidential computing.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://azure.microsoft.com/en-us/solutions/confidential-compute
[5] Intel. “Intel Confidential Computing Solutions.” intel.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.intel.com/content/www/us/en/security/confidential-computing.html
[6] AMD. “AMD Secure Encrypted Virtualization (SEV).” amd.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.amd.com/en/developer/sev.html
When vendor-provided device maintenance stops, devices that may contain vulnerabilities are left unsupported and unpatched. Any vulnerability found during this time may be present in a device for as long as that device continues to be used. By allowing device users to perform end-of-life management, device users to optionally attempt to maintain a higher security posture on their device through third-party firmware updates or security software. For this to be possible, the device vendor may have to include technical controls, such as “unlocking” parts of the device through a final firmware update or distribution of keys or allowing device users to upload their own keys for use in functions like firmware update mechanisms and secure boot processes. Additionally, the device vendor will likely have to update their device usage terms of service to include statements that once an end-of-life determination is made, certain liability mechanisms and warranties are no longer applicable.
Limitations: Giving device users access to device management tools that are typically reserved for vendors, such as firmware updates, may open up threat vectors for threat actors.
[1] RedHat. “Chapter 3. Signing a kernel and modules for Secure Boot.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel
[2] H. Mbugua, A. Buck, C. Werner, J. Flores, B. Lamos, C. Wales, B. de Koning, F. Ombongi, M. Macy, A. Cornelissen, B. Braig, C. Chiedo. “Create a self-signed public certificate to authenticate to your application.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-self-signed-certificate
[3] Android. “Lock and unlock the bootloader.” android.com. Accessed: Aug. 28, 2024. [Online.] Available: https://source.android.com/docs/core/architecture/bootloader/locking_unlocking
[4] B. Schoon. “LG is closing the bootloader unlock program that would help keep its Android phones alive.” 9to5google.com. Accessed: Aug. 28, 2024. [Online.] Available: https://9to5google.com/2021/12/06/lg-bootloader-unlock-program-closing/
[5] D. Wallach. “Assured Micropatching (AMP).” darpa.mil. Accessed: Aug. 28, 2024. [Online.] Available: https://www.darpa.mil/program/assured-micropatching
Firmware update mechanisms can provide a vector for threat actors to install malicious code, extract secrets from the firmware, or disrupt the device’s availability. A secure firmware update mechanism must ensure the authenticity of the firmware, encrypt the file or communication channel, ensure updates cannot be triggered at inopportune times, and prevent rollback to insecure versions. Key functions of a secure firmware update are provided below.
1- Authenticity and Integrity: The device should validate that the firmware update has not been tampered with before installing it on the device. The vendor should digitally sign the firmware using a protected private key, while the device should include an associated public key or public key hash to verify the signature scheme [1]. The digital signature should be computed across the entire firmware file. To sign a firmware image, the firmware signer should compute a hash of the firmware and run that hash through a signing software. The device can then take a hash of the firmware that it receives and use the public key to verify the signature from the signed hash to compare the two hash values [7].
2- Encryption: Encrypting firmware in-transit and at-rest is an effective way to prevent adversaries from reverse engineering the firmware to extract secrets or discovering vulnerabilities.
At-rest: If the firmware deployment requires firmware to be manually downloaded and transferred, stored on intermediary devices before reaching the target device, or stored anywhere on the device before loading into flash memory, then the firmware file should be encrypted. Encryption on-device could be implemented by encrypting all sections of the firmware and having the bootloader decrypt the firmware when it needs to be loaded. The bootloader would check the authenticity and integrity of the encrypted firmware, as mentioned in step 1, and then would decrypt the firmware if all the checks pass. The firmware would then be available for execution [8][9].
In-transit: If the firmware is deployed using an over-the-air update scheme (i.e., the firmware file will not reside on any intermediary systems), encryption should be provided by using an encrypted and authenticated communication protocol with public key-based authentication [9].
3- Update Initiation: If a device can have its firmware update process initiated at any time, threat actors may be able to cause a denial-of-service attack against the device by initiating it at an unwanted time. To prevent these scenarios, all manually initiated firmware updates should only be initiated by authenticated and authorized privileged administrative users. In the event that the device is using automatic firmware updates, any requests to initiate the firmware update should go over an encrypted and authenticated protocol.
4- Rollback Protection: Optionally, rollback protections can be added to the firmware update process to prevent threat actors from reinstalling an older, vulnerable version of firmware for future exploitation. Adding rollback protections are not always needed and may complicate device processes. See MID-030 - Firmware Rollback Protections for more information.
Additional Threats: This mitigation depends on multiple cryptographic mechanisms, protocols, and keys, which are all potentially vulnerable to different threats (listed below), which should also be considered with the implemented solution.
TID-330 Cryptographic Timing Side-Channel
TID-214 Secrets Extracted from Device Root of Trust
TID-411 Weak/Insecure Cryptographic Protocol
TID-318 Insecure Cryptographic Implementation
TID-317 Predictable Cryptographic Key
[1] K. Goldman, E. Palmer, T. Block, C. Engel, and D. Heller. “Best Practices for Firmware Code Signing.” opencompute.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.opencompute.org/documents/ibm-white-paper-best-practices-for-firmware-code-signing
[2] A. Regensheid. “NIST 800-193 - Platform Firmware Resiliency Guidelines.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf
[3] K. Masica. “Firmware Management Best Practices Guide for Energy Infrastructure Embedded Control Devices.” dtic.mil. Accessed: Aug. 28, 2024. [Online.] Available: https://apps.dtic.mil/sti/trecms/pdf/AD1135234.pdf
[4] J. Beningo. “5 Elements to a Secure Embedded System, Part 5: Secure Storage.” designnews.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.designnews.com/embedded-systems/5-elements-to-a-secure-embedded-system-part-5-secure-storage
[5] Embedded Staff. “Building a security-optimized embedded design using protected key storage.” embedded.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.embedded.com/building-a-security-optimized-embedded-design-using-protected-key-storage
[6] S. Garg. “Protecting Security Critical Firmware.” linaro.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.linaro.org/blog/protecting-security-critical-firmware/
[7] Chipkin. “What Is Signed Firmware.” chipkin.com. Accessed: Aug. 28, 2024. [Online.] Available: https://store.chipkin.com/articles/what-is-signed-firmware
[8] G. Garcia. “Securing Firmware Updates With AES.” memfault.com. Accessed: Aug. 28, 2024. [Online.] Available: https://interrupt.memfault.com/blog/firmware-encryption-with-python
[9] D. Pang. “Cryptographic Techniques for Safer Firmware.” electronicdesign.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.electronicdesign.com/technologies/embedded/article/21163055/neuronicworks-cryptographic-techniques-for-safer-firmware
[10] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
Devices should use validated cryptographic libraries (e.g., adhering to FIPS-140 or equivalent). These are libraries that have been examined, tested, and vetted for safety, security, and protection against side-channels by independent laboratories according to industry approved specifications. Building cryptographic libraries is a complex and difficult process that oftentimes results in libraries that have issues either with the generation or processing of cryptographic primitives or the processing of implemented algorithms over the input data.
Additionally, if any of the above issues do arise, using libraries that aren’t validated and aren’t maintained could lead to vulnerabilities persisting while fixes are developed. Therefore, using widely used, well maintained, and validated cryptographic libraries is a safer way to manage device cryptography. Vulnerabilities will be less likely to arise and, if/when they do, the wide level of use and maintenance will mean that patches should come quickly for it.
Limitations: By using a widely used library, a device’s cryptographic library is more likely to be targeted, which could lead to the device being vulnerable to exploitation.
Consideration: Devices that use cryptographic algorithms may introduce threats via the choice or implementation of the cryptographic algorithm or software. Device builders should take precautionary steps wherever possible to mitigate this threat. See MID-044 - Strong Cryptographic Algorithms and Protocols for more information about choosing a good algorithm.
[1] NIST. “Cryptographic Module Validation Program.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://csrc.nist.gov/projects/cryptographic-module-validation-program
[2] J. Flores. “Microsoft SDL cryptographic recommendations.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/security/sdl/cryptographic-recommendations
[3] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
Using hardware-backed keystores allows a device to benefit from hardware-based protections for preventing key extraction or manipulation, as opposed to relying on weaker software-only protections. Hardware-backed keystores leverage dedicated hardware and hardware abstraction layers to provide security features, such as storing a root-of-trust, keys, certificates or sensitive data. Hardware-backed keystores can take different forms and can be integrated with various functionalities, such as secure elements, TPMs, or cryptographic coprocessors to offer more secure key management. For example, Android has been using hardware-backed keystores for digital signing and verification operations, key generation, and the storage of asymmetric key signing pairs.
Consideration: MID-060 - Dedicated Cryptographic Processors will include key storage mechanisms and will enable secure operation using the keys. It is also a more comprehensive and complicated mitigation.
CR 1.9 – Strength of public key-based authentication - RE (1) Hardware security for public key-based authentication
CR 1.14 – Strength of symmetric key-based Authentication - RE (1) Hardware security for symmetric key-based authentication
CR 1.5 – Authenticator management - RE (1) Hardware security for authenticators
[1] Android. “Hardware-backed Keystore.” android.com. Accessed: Aug. 28, 2024. [Online.] Available: https://source.android.com/docs/security/features/keystore
[2] Rambus. “Hardware Root of Trust: Everything you need to know.” rambus.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.rambus.com/blogs/hardware-root-of-trust/
[3] V. Zimmer and M. Krau. “Establishing the Root of Trust.” uefi.org. Accessed: Aug. 28, 2024. [Online.] Available: https://uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20(003).pdf
[4] Analog Devices. “Secure Element.” analog.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.analog.com/en/resources/glossary/secure-element.html
A hardware root of trust (RoT) is a piece of hardware that typically stores the software code for critical boot functions that execute before any other functions on the device can operate. For example, 1st stage bootloader code stored in a hardware RoTs can be used to check firmware or later-stage bootloader authenticity and integrity before installing and running. This then allows the device to have a degree of certainty that the low-level code it is running is secure.
Usually, a hardware RoT consists of cryptographic keys and minimal boot code that uses the keys to ensure that the next piece of code is trusted to run. In the case of an immutable RoT, the cryptographic keys are immutable, for example written in OTP (One-Time Programmable) memory, and the boot code is immutable (BootROM).
Consideration: Making a RoT immutable can provide greater assurance by preventing the RoT from being tampered with by threat actors. If the RoT can never be changed, then threat actors cannot manipulate it to perform malicious actions. However, if a RoT is immutable and a vulnerability is found in the code stored within it, there are no ways to patch the device (see TID-220). Code on RoTs should therefore have minimal complexity and should be developed and deployed with the highest possible code quality standards.
[1] ARM. “Booting a secure system.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system
[2] ST. “Getting started with STiRoT (ST immutable Root of Trust) for STM32H5 MCUs.” st.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.st.com/resource/en/application_note/an6007-getting-started-with-stirot-st-immutable-root-of-trust-for-stm32h5-mcus-stmicroelectronics.pdf
To deploy firmware rollback protections, devices need to take steps to ensure that once new firmware has been deployed and is confirmed to be operational on the device, older firmware cannot be deployed again. There are many ways to handle increasing firmware version numbers, with two implementations being an automatic update on reset and an update on command.
“Automatic update on reset” [1] involves the Boot ROM updating the anti-rollback reference version when a newer version has been successfully loaded. To reach a success stage, the new image must pass all secure boot checks, such as the authenticity and integrity checks in MID-026 - Secure Firmware Update. This method gives no window of attack for threat actors trying to rollback firmware between updates and firmware success, however it also means that if there are errors in the firmware the user cannot revert to the last-known-good copy. Vendors themselves however can still rollback to a previous version by repackaging the firmware and distributing it with new version numbers [1].
“Update on command” [1] involves the anti-rollback reference version being updated in response to a secure message from an authorized management service. The previous version is therefore revoked only after the device management service signals that the newer version has no identified faults. This means that the device will be able to revert to an earlier version of the firmware before they receive the final message. While this gives users increased flexibility because they can choose to accept or reject firmware after trying it out, it also means that devices are left vulnerable during the window between firmware update and when the secure message is received. Additionally, this method may leave devices vulnerable to a denial-of-service attack that can be initiated by blocking the secure completion message. The device will therefore never accept the firmware and won’t begin operations [1].
Consideration: If an attacker can spoof the anti-rollback references to increment the versions, the device could be rendered inoperable. Vendors must ensure that only authorized software is able to update the anti-rollback references. See MID-026 - Secure Firmware Update for more information. Given the risks and challenges in creating a resilient rollback protection feature, device designers should carefully consider whether this mitigation is appropriate for their use case before pursuing it.
EDR / HDR / NDR 3.10 - Support for updates
SAR / EDR / HDR / NDR 3.2 - Protection for malicious code
[1] ARM. “Platform Security Model.” psacertificed.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM_V1.1_BET0.pdf
Requirements such as a key being inserted, a button being pressed, a switch being flipped, etc. can provide a device with guarantees around the physical presence of an operator. Devices can then choose to not perform a critical operation until that physical step is taken, with a lack of action (e.g. a device being left in “run mode” and not being put in “program mode”) preventing all critical actions. This can prevent threat actors from undertaking malicious actions because the device will reject any changes or actions while in an operating mode that does not accept changes.
Limitations: Devices that require physical presence may be difficult to manage in remote locations, can increase response or update rollout timelines, and provide limited benefits in locations that have poor physical security. For those reasons, it may not be suitable for all devices or environments.
[1] A. Regensheid. “NIST 800-193 - Platform Firmware Resiliency Guidelines.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf
Methods to monitor and restart services, such as software and hardware-based watchdogs, can add additional resilience and prevent devices from falling into complete deadlock states or failing. This is because these mechanisms will monitor and send restart service signals that will ensure that critical processes cannot die indefinitely. Additionally, if a device cannot safely have its services restarted, these monitors can be used to alert users about device-level activity.
CR 7.2 – Resource management
[1] K. Odom. “What Is a Watchdog Timer and Why Is It Important?” ti.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.ti.com/lit/ta/ssztah7/ssztah7.pdf
[2] DigiKey’s North American Editors. “Improving IoT System Robustness Using Watchdog Timers.” digikey.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.digikey.com/en/articles/improving-iot-system-robustness-using-watchdog-timers
[3] MITRE. “Watchdog Timers.” mitre.org. Accessed: Aug. 28, 2024. [Online.] Available: https://attack.mitre.org/mitigations/M0815/
Using unique keys lowers the risk to devices because the compromise of one device will not reveal keys used on other devices. If keys are not unique, threat actors that can extract a key from one device may be able to leverage that key across multiple devices. Therefore, if unique keys per device are used, threat actors have less opportunities to exploit devices before patches are available when one device is compromised.
[1] Apple. “Apple Platform Security.” apple.com. Accessed: Aug. 26, 2024. [Online]. Available: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
Authenticating network traffic makes it more difficult for threat actors to leverage unauthenticated network data sent by or to the device. A lack of message authentication can result in the device accepting and remaining unaware of messages spoofed or modified by an attacker with network access to the device. By authenticating network traffic, threat actors cannot send any data that will be accepted unless they also compromise the corresponding authentication credentials.
Network authentication can be implemented via several technical means, including message authentication codes (MACs), authenticated encryption (AE), and digital certificates/signatures that are used to protect all or part of the network packet or protocol message. These schemes allow the device receiving the network traffic to perform cryptographic checks of the data to ensure that it originated from a trusted source and has not been modified in-transit. Only then will it parse the message and process data within.
Note: Authentication should be paired with MID-035 - Encrypt Network Traffic to prevent eavesdropping.
Limitations: Malicious actors may be able to circumvent authentication protections through various means. When implementing session authentication, best practices should be followed to prevent authentication attacks (replay, spoofed users, default accounts, etc.)
[1] okta. “Authentication Protocols 101: Definition, Types, and When to Use.” okta.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.okta.com/identity-101/authentication-protocols/
[2] nile. “Secure Network Authentication Methods, Types, and Protocols.” nilesecure.com. Accessed: Aug. 28, 2024. [Online.] Available: https://nilesecure.com/network-security/secure-network-authentication-methods-types-and-protocols
[3] Cloudflare. “What is TLS (Transport Layer Security)?.” cloudflare.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/
Encrypting network traffic typically involves taking network data and running it through an encryption algorithm such that the network data cannot be read in its encrypted form - this achieves data confidentiality. Therefore, encrypting network traffic allows devices to share critical or secret information without worrying about a third party reading the data.
Some encryption algorithms, such as AES-GCM, include authentication and integrity features to give the receiving devices some guarantees that their data has not been tampered with. See MID-034 - Authenticate Network Messages for more information.
Lastly, besides the implementation of the cryptographic library itself, other related architecture considerations must be made. These can include using a secure and validated algorithm (MID-044 - Strong Cryptographic Algorithms and Protocols), secure key storage, secure key sharing/agreement (e.g., DH), and secure key generation (MID-047 - Sufficient Entropy for Keys), to name a few.
[1] K. McKay and D. Cooper. “NIST 800-52r2 - Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://doi.org/10.6028/NIST.SP.800-52r2
[2] E. Barker, A. Roginsky, and R. Davis. “NIST 800-133r2 - Recommendation for Cryptographic Key Generation.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf
[3] Y. Sheffer, R. Holz, and P. Saint-Andre. “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).” ietf.org. Accessed: Aug. 28, 2024. [Online.] Available: https://datatracker.ietf.org/doc/html/rfc7525
[4] NIST. “Cryptographic Module Validation Program.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?SearchMode=Basic&CertificateStatus=Active&ValidationYear=0
[5] M. Turnan, E. Barker, J. Kelsey, K. McKay, M. Baish, and M. Boyle. “NIST 800-90B - Recommendation for the Entropy Sources Used for Random Bit Generation.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf
A nonce is a piece of data, typically a number, that is created uniquely per message to ensure that messages cannot be replayed. When a device receives a message, it checks the nonce to make sure that the nonce is still valid, and if it is, it will accept the message. If the nonce is no longer valid, the device will know that the same message was sent to them multiple times, potentially indicating a replay attack, and will reject the message.
The first nonce in a communication is oftentimes sent in the first message by the device that is initiating the communication. The nonce will then undergo some operation that both the sender and receiver know. Subsequently, in every message the device will receive a transmission with a nonce, perform the operation, and send the new nonce in the next message. This results in a situation where every message has a unique nonce and the sender and receiver can know what the next nonce will be in advance, but the adversary cannot derive it as they do not know the operation or initial nonce.
Nonces can sometimes be implemented alongside MID-037 - Network Timestamps to give devices time windows and unique message identifiers to work with. If the device is not using a timestamp, it will have to ensure that the nonce is it using is sufficiently large or random so that it cannot be guessed. If it can be guessed, it may be possible for threat actors to send malicious messages with valid nonces. For example, if a device uses a counter as the initial nonce and adding one as its operation, it may be possible for a threat actor to guess the next number in sequence. A random-number generator with a hashing function on the other hand would produce results that are much harder to guess.
CR 4.3 - Use of cryptography
CR 3.1 – Communication integrity (1) Communication authentication
[1] E. Barker. “NIST 800-89 - Recommendation for Obtaining Assurances for Digital Signature Applications.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf
[2] okta. “What is a Cryptographic Nonce? Definition and Meaning.” okta.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.okta.com/identity-101/nonce/
Network timestamps have multiple use-cases in a device. They can be used to reject messages that are too old, be used as unique seeds for certain functions, aid with logging, and be used to synchronize network data interactions across multiple devices. Timestamps can also be used to prevent replay attacks, either as an additional piece of information alongside a nonce (MID-036 - Cryptographic Nonces) or to reject data that is too old, which may be another indicator of a replayed message.
Limitations: Timestamp-based packet rejection may present operational issues if network guarantees aren’t met or if adversaries derive a means to slow down packet delivery. In both of these cases, valid packets may be delivered late, and the device may reject them.
[1] E. Barker. “NIST 800-89 - Recommendation for Obtaining Assurances for Digital Signature Applications.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf
[2] E. Barker. “NIST 800-102 - Recommendation for Digital Signature Timeliness.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-102.pdf]
[3] F. Farha, H. Ning, S. Yang, J. Xu, W. Zhang and K. -K. R. Choo, “Timestamp Scheme to Mitigate Replay Attacks in Secure ZigBee Networks,” in IEEE Transactions on Mobile Computing, vol. 21, no. 1, pp. 342-351, 1 Jan. 2022, doi: 10.1109/TMC.2020.3006905.
Administrative actions on a device usually involve a subset of device actions that, if undertaken, could have an impact on the integrity of the device or its operations. These may include accessing certain I/O interfaces, changing the roles of another user, changing user permissions or credentials, using debugging modes, or altering device operating states, to name a few. Because these actions could have a large impact on device operations, users should have to authenticate to perform administrative actions and should only be allowed to take actions that they are permitted to after authentication.
Limitations: If the threat actor can gain access to valid credentials, they will be able to subvert these protections. Adding in mitigations like MID-031 - Physical Presence Validation will increase its efficacy because threat actors won’t be able to perform administrative actions without first authenticating and demonstrating physical access to the device. Physical security measures, such as locks and gates, can then be used as a line for cyber defense.
CR 1.1 - Human user interaction and authentication
CR 2.1 - Authorization Enforcement
Diagnostic software functions or modes oftentimes give users who control them access to low-level device information. This control could involve read/write permissions of raw memory, process control, process monitoring, and power information, for example. To prevent a threat actor from having this level of access, device designers could either remove the functionality or, if it is needed, heavily restrict its usage.
If a device doesn’t need diagnostic functionality, it is more secure for that device to not have any present. Diagnostic functions provide a large threat vector for threat actors because of their inherently privileged nature. By removing the functionality, threat actors have no already-installed tool on the device that gives them such low level access.
If a device must have diagnostic functionality, those functions should be heavily restricted. One way this can be done is by restricting the diagnostic functions to certain processes. This could limit the potential impact of a threat actor because they would be scoped to a narrow part of the device. Another way to implement this is by using a processor that has features to prevent unintended tampering (open states, restricted state, and closed state). This would provide a hardware-enforced means to limit the ability of a remote threat actor from accessing the diagnostic functions.
Limitations: If threat actors are able to take control over the protection mechanisms that grant or revoke diagnostic functionality access, they may be able to escalate their privileges and take control over a device.
CR 1.1 - Human user interaction and authentication
CR 2.1 - Authorization Enforcement
CR 6.1 – Audit log accessibility
CR 3.7 – Error handling
CR 3.9 – Protection of audit information
For programmable devices like PLCs, signing programs gives the device the ability to ensure that the programs that they are installing and running originate from a verified source. If the programs are not signed, it may be possible for a threat actor to install malicious programs that alter device behavior.
Devices can enable these capabilities by allowing the device to accept, store, and use verifying keys to verify that a program is signed. If the program is not signed, the device should automatically reject the new program and send out an alert.
Users should be able to generate signing and verifying keys (public and private asymmetric keys) and send the verifying key to downstream devices that will be receiving programs. Programs can then be signed, either by Integrated Development Environments (IDEs) or another signing mechanism and distributed to the device for verification and deployment.
Note: This mitigation is heavily dependent on the security of the source of the programs/application. Many devices, such as PLCs, require the deployment of custom programs that are developed individually at each organization.
Limitation: This would require a dedicated signing key to be deployed within the IDE and a verifying key within the end device. Ideally this would be a unique signing key for every organization, however, this would require each organization to perform the key initialization and exchange with each new IDE or device. This scheme gets more complex as typically there are many IDEs within an organization that may need to deploy programs to a device, further organizations need to perform key escrow to store keys, otherwise if the IDEs and associated keys are lost, they will be unable to deploy programs to the device. If organizational keys are not used, and the same signing key is used across an entire product line, a threat actor may be able to extract this key from the IDE (such as through reverse engineering) and then use it to sign an unauthorized program.
SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
CR 3.4 – Software and information integrity
[1] Codesys. “Protecting an Application.” codesys.com. Accessed: Aug. 28, 2024. [Online.] Available: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_encrypting_application.html
Vendor programs, libraries, and other software components are guaranteed to come from a single source, the vendor. Therefore, vendors can use a digital signing scheme where their programs are signed using the vendor’s private key and can be verified using the device’s public key. This signing scheme would ensure that only vendor-supplied programs would be accepted, downloaded, and executed.
Devices, such as Programmable Logic Controllers (PLCs), oftentimes will have two copies of a program stored in their memory. One copy is the compiled binary that is executing run on the device - this program is machine readable but would be difficult for a human to easily read. The other copy is a textual code representation of the program. This form is in a human-readable format and is typically the form of the code that the programmer worked on before the program download. It is this latter copy that is returned to the programmer when using “upload from device” functions in the IDE. The binary and textual representations should be cryptographically bound so that the IDE can test whether the textual representation matches the executable representation.
One way to ensure consistency would be to perform upload both the running binaries and text code during a program upload. The IDE would then be able to recompile the text code and perform hashes over it and the binary code to check for consistency. Another way to do this would be to compile the text code on the device itself and then hash both it and the running binaries and then compare them.
[1] S. Brizinov. “The Old Switcheroo: Hiding Code on Rockwell Automation PLCs.” claroty.com. Accessed: Aug. 28, 2024. [Online.] Available: https://claroty.com/team82/research/hiding-code-on-rockwell-automation-plcs
If it is necessary for a device to ship with default passwords for user accounts, these passwords should be unique, random, and not based on any inherent device properties (such as serial number or MAC address). Additionally, these default passwords should be at least 8 characters long and contain a mix of uppercase and lowercase letters and numbers. Users can access these default passwords through physical access to the device or the device’s documentation delivered with the hardware.
Users can be prompted upon the first-time use of the device to change the default passwords and should be able to change them at any time after.
In some cases, it may be better to ship a device without default credentials. In this scenario, users can be prompted upon first use of the device to set credentials.
CR 1.1 – Human user identification and authentication - RE (1) Unique identification and authentication
CR 1.5 - Authenticator management
[1] CISA. “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software.” cisa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf
[2] P. Grassi, J. Fenton, E. Newton, R. Perlner, A. Regensheid, W. Burr, J. Richer, N. Lefkovitz, J. Danker, Y. Choong, K. Greene, and M. Theofanos. “NIST 800-63B - Digital Identity Guidelines - Authentication and Lifecycle Management.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
Device implementors should use cryptographic libraries that have been validated and rigorously tested against different cryptographic attacks. “Rolling your own crypto”, meaning creating and using homemade cryptographic algorithms, has been shown to be riskier than using heavily tested and validated libraries due to the tendency of individuals or small teams not being able to match the validation process and cryptographic rigor supplied by dedicated teams of experts.
Choosing a strong cryptographic algorithm or primitive is not always sufficient, there are often many pitfalls in using it safely and correctly. Network communications, user authentication handshakes, data protection, and other protocols are implemented using cryptographic algorithms and operations to protect information and achieve other desired security guarantees. Devices should implement protocols that are widely used, well tested, verified for security assurances, and utilize strong cryptographic algorithms. Examples of these are WPA3 and TLS.
Note: Chosen protocols should incorporate anti-metadata analysis features such as packet length standardization, packet frequency standardization, header length standardization, etc. Overall, packet metadata shouldn’t be able to be used to derive the contents of encrypted messages. This is only needed where confidentiality exists and is important to device security [3] [4] [5].
Note: Many leading cryptographic algorithms are publicly available for use and inspection, meaning that device implementors can verify for themselves that the algorithms are safe to use and compatible with their devices.
Note: Choosing a high-quality implementation of the desired cryptographic tools is very important to ensure that they will operate as intended and that cryptographic security guarantees cannot be undermined by implementation flaws. See MID-027 - Validated Cryptographic Library for more information. In addition to library choice, other related architecture considerations must be made. These can include secure key storage (MID-028 - Hardware-backed Key Storage) and secure key generation (MID-047 - Sufficient Entropy for Keys), to name a few.
Note: Encryption may introduce operational difficulties and constraints. Review all processes and functional requirements when encrypting traffic in transit.
CR 4.3 - Use of cryptography
CR 1.14 - Strength of symmetric key-based authentication
CR 1.9 - Strength of public key-based authentication
[1] S. Morrow. “The Dangers of “Rolling Your Own” Encryption.” infosecinstitute.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.infosecinstitute.com/resources/cryptography/the-dangers-of-rolling-your-own-encryption/
[2] NIST. “Cryptographic Module Validation Program.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?SearchMode=Basic&CertificateStatus=Active&ValidationYear=0
[3] C. Tezcan. “On Hiding Message Length in Symmetric-key Cryptography.” forgottenlance.com. Accessed: Aug. 28, 2024. [Online.] Available: https://cihangir.forgottenlance.com/papers/length_hiding_lasec.pdf
[4] Alyami M, Alghamdi A, Alkhowaiter MA, Zou C, Solihin Y. Random Segmentation: New Traffic Obfuscation against Packet-Size-Based Side-Channel Attacks. Electronics. 2023; 12(18):3816. https://doi.org/10.3390/electronics12183816
[5] S. Xiong, A. D. Sarwate and N. B. Mandayam, “Defending Against Packet-Size Side-Channel Attacks in Iot Networks,” 2018 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), Calgary, AB, Canada, 2018, pp. 2027-2031, doi: 10.1109/ICASSP.2018.8461330.
[6] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
Multi-factor authentication “requires users to present two or more authentication factors at login to verify their identity before they are granted access.” [1] These typically include some combination of 1) something you know, like a password; 2) something you have, like a hardware or mobile token; or 3) something you are, such as fingerprints or other biometric data [1, 2]. Devices will not authenticate a user unless all required forms of authentication are presented.
Threat actors therefore will not be able to authenticate to a device with simple username/password combinations that can be intercepted, phished, guessed by brute-force, or otherwise acquired.
[1] CISA. “Multi-factor Authentication.” cisa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.cisa.gov/sites/default/files/publications/MFA-Fact-Sheet-Jan22-508.pdf
[2] P. Grassi, J. Fenton, E. Newton, R. Perlner, A. Regensheid, W. Burr, J. Richer, N. Lefkovitz, J. Danker, Y. Choong, K. Greene, and M. Theofanos. “NIST 800-63B - Digital Identity Guidelines - Authentication and Lifecycle Management.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
[3] H. Guevera. “Multi-factor Authentication Guide.” Auth0 by Okta Blog. Accessed: Aug. 28, 2024. [Online]. Available: https://auth0.com/blog/multifactor-authentication-mfa/
Implementing a lockout or delay after a certain number of incorrect guesses increases the time it would take threat actors successfully guess a password.
Progressively increasing lockouts are a common implementation pattern. For example, a device may institute a 1-minute lockout after 5 wrong guesses, 3-minute lockout after 10 wrong guesses, 30-minute lockout after 20 wrong guesses, and so on. The threat actor therefore has to wait 34 minutes just to guess 20 passwords, while legitimate users that mistype their password once or twice are minimally impacted.
Depending on the environment, lockouts can also be used. A lockout would instead lock the device so that no more authentication attempts can be made after a certain amount of password attempts were performed. Lockouts present risks to the device because devices will be unusable until the lockout is lifted, meaning that a denial-of-service-type effect is possible. This lockout can be lifted either through some authenticated administrative process and/or by requiring physical presence on the device (see MID-031 - Physical Presence Validation for more information).
CR 1.11 - Unsuccessful login attempts
CR 2.5 - Session lock
To create sufficiently random keys, devices need a source of data with a high degree of entropy to ensure that the keys are not predictable. If a device does not have a source of sufficient entropy and tries to create a key, it may be possible that the inputs that seeded the key or pseudo-random number generator (PRNG) can be guessed and therefore threat actors may be able to recreate the key or predict the PRNG output. By using a high degree of entropy, keys and seeds are fully random and cannot be recreated by threat actors, thereby making them cryptographically stronger.
Devices typically feed their entropy pools by collecting the unpredictable least significant bits from device events like the absolute and relative timing between things like hardware interrupts, user input, and other similarly unpredictable events. Complex devices like desktop and server PCs can rely on plentiful sources of such events. Embedded devices often do not have as rich a set of hardware, may have no direct interactive user input, fewer processes and applications executing, and are generally more regular and constrained in their actions. This can result in embedded systems having a shallower pool of entropy to draw upon when the need to generate cryptographic keys arises.
Operations that consume data from an entropy pool to generate keys of seed PRNGs must wait until a sufficient quantity is available. To avoid (potentially long) pauses in operation, especially at boot up, some devices have been known to use non-blocking sources, and as a result the keys they generated were predictable and vulnerable to attack. To remain secure, devices should use a blocking entropy pool that waits until there is sufficient entropy to fulfill the request for random numbers. If the device doesn’t have a way to generate enough entropy on first boot, devices may require mechanisms to obtain additional sufficient entropy (e.g. ask for random user inputs). If that is not practical, the design may need to be modified to include a cryptographic quality hardware-based random number generator (see MID-048 - Hardware Random Number Generator and MID-060 - Dedicated Hardware Cryptographic Modules).
Note: Using sufficiently random keys is an important part of maintaining the security guarantees that a good cryptographic algorithm will provide. See MID-044 - Strong Cryptographic Algorithms and Protocols for more information about cryptographic algorithms.
[1] E. Barker, A. Roginsky, R. Davis, “Recommendation for Cryptographic Key Generation”, NIST, Special Publication 800-133 Revision 2, 2020. doi: 10.6028/NIST.SP.800-133r2
[2] M. T. Turam, E. Barker, J. Kelsey, K. A. McKay, M. L. Baish, M. Boyle, “Recommendation for the Entropy Sources Used for Random Bit Generation”, NIST, Special Publication 800-90B, 2018. doi: 10.6028/NIST.SP.800-90B
[3] “Cryptographic Module Validation Program.” NIST Computer Security Resource Center. Accessed: Aug. 28, 2024. [Online]. Available: https://csrc.nist.gov/projects/cryptographic-module-validation-program
[4] Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. 2012. Mining your Ps and Qs: detection of widespread weak keys in network devices. In Proceedings of the 21st USENIX conference on Security symposium (Security’12). USENIX Association, USA, 35. Available: https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger
Hardware random number generators, sometimes called true random number generators, are pieces of hardware that use environmental noise, such as electromagnetic or thermal data, to create random numbers. Since these devices use local data that is constantly varying to create their random numbers, it is very difficult to recreate the environment in which the number was generated. Therefore, hardware random number generators can be used to create keys that have a high degree of entropy for their seeds and themselves have a high degree of randomness.
Note: Implementors should be sure to verify that the hardware RNG they are considering produces a random stream of sufficient cryptographic quality for use in key generation and not simply a hardware implementation of a lower quality pseudo-random number generator (PRNG) algorithm.
[1] C. Hoffman. “How Computers Generate Random Numbers.” howtogeek.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.howtogeek.com/183051/htg-explains-how-computers-generate-random-numbers/
[2] C. Shaw. “Hardware Random Number Generators.” Cerberus Security Labs. Accessed: Aug. 28, 2024. [Online]. Available: https://cerberus-laboratories.com/blog/random_number_generators/
Passwords should be stored only in a non-reversible salted and hashed format that is calculated by a cryptographically strong hashing algorithm. Hashing algorithms are one-way algorithms that can turn data into a unique fixed-length string representation of that data. Since this algorithm is one-way, data that is hashed cannot be turned back into its cleartext form, meaning that threat actors who come across hashed passwords have to try to hash every password combination until they have a match.
Threat actors have been known to use pre-calculated lookup tables of hashed potential password values to accelerate the password guessing process. Salting can prevent this from happening by increasing the required size of the lookup tables to make this approach to guessing impractical. Salts are pieces of random data that are appended to the password before hashing and then are stored with the hashed password. What this does is make the password hash unique because the password is actually the password + the hashed data. Therefore, this password cannot be found in a hash lookup table, but the salted hash can still be calculated by the device within an acceptably short time bound.
A device’s system software (operating system, hypervisor, etc.) can take precautions to defend against data leakage due to memory timing and speculative execution side channels like Spectre and Meltdown, and other more recently discovered issues with other processor microarchitecture features.
For example, context switches can be hardened to better isolate memory between lower and higher privileged contexts, strengthening page table separation, and invalidating caches. Additionally, compiler-based mitigations like the “retpoline” technique are effective against the branch target injection vulnerability in Spectre.
Note: Where applicable, the system firmware and OS should ensure any relevant CPU microcode updates are applied that include patches for such vulnerabilities.
Limitation: These software-based defenses have unavoidable performance impacts that can be significant depending on the workload involved.
[1] C. Stevens, N. Poggi, T. Desrosiers, R. Xin. “Meltdown and Spectre: Exploits and Mitigation Strategies.” Databricks. Accessed: Aug. 27, 2024. [Online.] Available: https://www.databricks.com/blog/2018/01/16/meltdown-and-spectre-exploits-and-mitigation-strategies.html
Several threats are made easier to exploit when a device allows the execution of adversary-provided code, such as a user provided program in a PLC or JavaScript code in an embedded web browser. If this functionality is not strictly necessary to the device’s feature set, devices could simply not include the functionality on the device and these threats can be avoided.
Note: The inherent loss of this device functionality from this approach is not always practical (e.g., when the device is intended to be programmable). See MID-014 – Sandboxing and MID-040 - Cryptographically Signed Custom Programs for alternative approaches to safely handle user-provided code when it cannot be avoided.
SAR / EDR / HDR / NDR 3.2 - Protection for malicious code
CR 3.4 – Software and information integrity
Data bus interception, chip readout, and other physical circuit board manipulation can be made more difficult through mechanical and design changes, such as moving bus traces to internal board layers, eliminating test headers, removing the silkscreen layer, choosing chip packages without exposed pins (e.g., BGA), placing epoxy over chips and traces, etc.
All of these mitigations hide board pins and traces, thereby making it more difficult for the threat actor to read data going to/from the chip without removing the chips themselves and altering the board, potentially damaging it beyond repair. Therefore, these mitigations increase the cost and difficulty for threat actors attempting to access information from the physical device.
Limitations: This mitigation increases the level of effort required to successfully exploit this threat but is not a full solution. Skilled and well-resourced adversaries may be slowed but not deterred. This approach may be useful when stronger mitigations such as bus encryption are not feasible. Additionally, these techniques can make the system more difficult to debug during development and during failure analysis of defective units.
[1] Royal Circuit Solutions. “Hack-Attack — PCB Design Ideas to Foil Potential Hackers.” royalcircuits.com. Accessed: Aug. 28, 2024. [Online]. Available: https://www.royalcircuits.com/2019/11/22/hack-attack-pcb-design-ideas-to-foil-potential-hackers/
Many modern processors that support Direct Memory Access (DMA) also contain an Input/Output Memory Management Unit (IOMMU) that can be configured to enforce an access control policy that prevents peripherals (e.g., PCIExpress devices) from reading or writing portions of system RAM they are not authorized to. This creates a barrier for threat actors attempting to maliciously access memory directly from a compromised or untrustworthy peripheral.
SAR / EDR / HDR / NDR 3.2 - Protection for malicious code
CR 2.1 – Authorization enforcement
[1] A. T. Markettos, C. Rothwell, B. F. Gutstein, A. Pearce, P. G. Neumann, S. W. Moore, R. N. M. Watson, “Thunderclap: Exploring Vulnerabilities in Operating System IOMMU Protection via DMA from Untrustworthy Peripherals,” in Network and Distributed Systems Security (NDSS) Symposium 2019, San Diego, CA, 2019, doi: 10.14722/ndss.2019.23194.
[2] Apple. “Direct memory access protections for Mac computers.” apple.com. Accessed: Aug. 28, 2024. [Online]. Available: https://support.apple.com/guide/security/direct-memory-access-protections-seca4960c2b5/
Data that is stored in non-volatile storage external to the processor should be cryptographically protected, and only decrypted and authenticated within the processor at time of use. This removes opportunities for threat actors to access or modify unencrypted firmware code, configurations, or other sensitive data.
Limitations: Extensive use of encryption can impact performance as data must be decrypted every time it is loaded for use. This may limit what portions of data are practical to encrypt or require migrating a design to use processors with hardware acceleration for decryption. Additionally, private and secret keys must be sufficiently protected, ideally in a hardware-backed keystore (see MID-028), or at least in on-chip memory (see MID-064) and should not be shared between devices (see MID-033).
CR 4.1 – Information confidentiality
CR 4.2 - Information persistence
[1] S. Garg. “Protecting Security Critical Firmware.” linaro.org. Accessed: Aug. 27, 2024. [Online]. Available: https://old.linaro.org/blog/protecting-security-critical-firmware/
[2] D. Kleidermacher, “Enhance system security with better data-at-rest encryption.” embedded.com. Accessed: Aug. 27, 2024. [Online]. Available: https://www.embedded.com/enhance-system-security-with-better-data-at-rest-encryption/
Highly integrated processors, particularly system-on-chip and system-in-package, combine some or all of processing, RAM (e.g., SRAM, DRAM), non-volatile storage, and peripherals within a single physical package. Integration of these components avoids the need to connect separate single-purpose components across a circuit board via physically accessible busses and traces. This removes many of the opportunities for a threat actor to perform bus interception, chip contents extraction, and other physical attacks.
Note: Certain chips, particularly microcontrollers, utilize SRAM-based memory instead of DRAM. SRAM’s lack of capacitance makes it resistant to the original cold boot attacks, however newer research has demonstrated analogous techniques for extracting the contents of SRAM-based memories, caches, and registers [1].
[1] Jubayer Mahmod and Matthew Hicks. 2022. SRAM has no chill: exploiting power domain separation to steal on-chip secrets. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ‘22). Association for Computing Machinery, New York, NY, USA, 1043–1055. https://doi.org/10.1145/3503222.3507710
If a device supports removable external storage media (e.g., USB sticks), implement device configuration options that give administrators the option to disable this support (temporarily or permanently) and reenable it only if and when needed. Disablement should account for both the OS level (e.g., mounting a filesystem) and firmware level (e.g., booting from external storage) interaction with a storage device.
Physical ports used during the device development and debugging process should be disabled or removed in devices meant for production use. This includes dedicated memory debug interfaces (e.g., JTAG), UART serial ports that expose sensitive data or command shells, or any similar port. These ports should be disabled in hardware (preferably) by engaging security fuses or at least in software. Simply depopulating physical headers on device circuit boards is not sufficient. Ideally, such ports should be disabled permanently, but if some degree of diagnostic capability is desired for production devices, reenabling one of these ports should be an authenticated administrative action.
[1] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
Many integrated processors contain security configuration options that can be engaged to disable programming and debugging features in devices intended for production use. These can irreversibly disable debugging interfaces that can read and write device memory (e.g., JTAG, boundary scan), block flash memory readout, lock down boot options, etc.
EDR / HDR / NDR 2.13 - Use of physical diagnostic and test interfaces
EDR / HDR / NDR 3.11 (1) - Physical tamper resistance and detection
[1] ST. “STM32 Readout Protection (RDP).” stm32world.com. Accessed: Aug. 28, 2024. [Online]. Available: https://stm32world.com/wiki/STM32_Readout_Protection_(RDP)
Adhering to certain software development patterns can increase the resistance of code to side channel data leakage and limit a threat actor’s ability to extract information via timing, power, or EM-based side channel analysis. Countermeasures can be organized into three categories: hiding (reducing the leakage and adding noise), masking (disassociating leakage from sensitive values, and by protocol (e.g., limiting the usage of sensitive values like cryptographic keys). Example techniques include designing computations to be independent of sensitive values from a time or power perspective, balancing the operations on either side of conditional statements, using unpredictable ordering for bit or byte test and comparison operations, adding randomness or noise, and limiting secret key reuse.
[1] M. Witteman, “Secure Application Programming in the presence of Side Channel Attacks,” Riscure, The Netherlands. Accessed: Aug. 21, 2024. [Online.] Available: https://sidechannel.riscure.com/publications/secure-application-programming-in-the-presence-of-side-channel-attacks/.
[2] Intel. “Security Best Practices for Side Channel Resistance.” intel.com. Accessed: Aug 21, 2024. [Online.] Available: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/security-best-practices-side-channel-resistance.html
A hardware-based cryptographic module can be an effective solution for a device when a purely software-based cryptographic library (MID-027) does not sufficiently mitigate against threats of concern (e.g., to side channel attacks, cryptographic key compromise) or meet performance constraints. Dedicated cryptographic modules can implement hardware-based defenses that are not possible in a software library. In processor-constrained designs, hardware acceleration of cryptographic algorithms can enable implementing stronger algorithms and key sizes than may be practical in a software-only solution. As with software cryptographic libraries, implementors should prefer modules that have been examined, tested, and vetted by independent laboratories according to industry approved specifications.
Note: This has several important distinctions from MID-028 - Hardware-backed Key Storage. In the MID-028 case, key material may reside in hardware-backed or hardware-based storage, but the hardware lacks the means to perform cryptographic operations using that key without exposing it to the system’s processor. A fully hardware cryptographic module is capable of performing cryptographic operations internally on provided data without exposing the keys.
CR 4.3 - Use of cryptography
CR 1.9 – Strength of public key-based authentication - RE (1) Hardware security for public key-based authentication
CR 1.14 – Strength of symmetric key-based Authentication - RE (1) Hardware security for symmetric key-based authentication
CR 1.5 – Authenticator management - RE (1) Hardware security for authenticators
[1] NIST. “Cryptographic Module Validation Program.” nist.gov. Accessed: Aug. 28, 2024. [Online]. Available: https://csrc.nist.gov/projects/cryptographic-module-validation-program
Inter-process data leakage side channels like Spectre, Meltdown, etc. that rely on memory cache behavior, speculative execution, and similar processor features can only occur when workloads share the same processor. Isolating workloads onto multiple physically separate processors avoids any such potential problems.
Partitioning workloads by criticality or security level is recommended. For example, functions that process untrusted data or otherwise make up the device’s attack surface should be separated from security and functionality critical operations. Avoid separating security decisions (e.g., authorization checks, signature validations) from the data and operations they govern; doing so can introduce weaknesses that allow bypassing those checks.
Limitations: Adding additional processors to separate device functions and data necessarily increases the complexity and cost of the device’s hardware and software. If chosen, care must be taken to avoid introducing new vulnerabilities in the course of implementing this mitigation approach.
Numerous hardware-level defenses have been proposed to address the different varieties of fault injection. Tunable Replica Circuits (TRCs) [1] can be used to detect voltage and clock timing changes and have been deployed within some newer commercial CPUs from Intel [2]. Brown-out detection and reset circuits, as found in some microcontrollers, have been proposed to interrupt voltage glitch attacks if sensitive enough [8], however research has shown these can be bypassed by tuning the attack carefully [9][10] although it does increase the difficulty of the attack [10]. Comparison techniques can be used to detect attacks on processor clock signals [3][4]. Finely targeted electromagnetic interference (EMI) attacks can bypass single chip-wide voltage and clock-based defenses but have been shown to be detectable embedding multiple detectors within a chip [3] and by phase locked loop (PLL)-based sensor circuits [5]. [6] examines several detection schemes for optical fault injection techniques, such as embedding photosensors and shielding in a chip.
A combination of multiple hardware and software-based mitigation techniques (see MID-063) to address the range of fault injection types, as recommended by [8], can prove more effective than any individual mitigation.
[1] K. A. Bowman and J. W. Tschanz, “Resilient microprocessor design for improving performance and energy efficiency,” 2010 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), San Jose, CA, USA, 2010, pp. 85-88, doi: 10.1109/ICCAD.2010.5654317.
[2] D. Nemiroff, C. Tokunaga, “Tunable Replica Circuit for Fault- Injection Detection,” in Blackhat USA 2022, Las Vegas, NV, USA, 2022. Available: https://i.blackhat.com/USA-22/Wednesday/US-22-Nemiroff-Fault-Injection-Detection-Circuits.pdf
[3] L. Zussa et al., “Efficiency of a glitch detector against electromagnetic fault injection,” 2014 Design, Automation & Test in Europe Conference & Exhibition (DATE), Dresden, Germany, 2014, pp. 1-6, doi: 10.7873/DATE.2014.216.
[4] C. Deshpande, “Hardware Fault Attack Detection Methods for Secure Embedded Systems,” M.S. dissertation, Dept. Comp. Eng., Virginia Tech, Blacksburg, VA, USA, 2017. [Online]. Available: https://vtechworks.lib.vt.edu/server/api/core/bitstreams/2b264fa1-1286-4802-9125-461ca4839c1c/content
[5] Noriyuki Miura, Zakaria Najm, Wei He, Shivam Bhasin, Xuan Thuy Ngo, Makoto Nagata, and Jean-Luc Danger. 2016. PLL to the rescue: a novel EM fault countermeasure. In Proceedings of the 53rd Annual Design Automation Conference (DAC ‘16). Association for Computing Machinery, New York, NY, USA, Article 90, 1–6. https://doi.org/10.1145/2897937.2898065
[6] N. A. Anagnostopoulos, “Optical Fault Injection Attacks in Smart Card Chips and an Evaluation of Countermeasures Against Them,” M.S. thesis, Dept. Comp. Sci., Univ. of Twente, Enschede, Netherlands, 2014. [Online]. Available: https://essay.utwente.nl/66028/7/Anagnostopoulos_MA_EEMCS.pdf
[7] Bilgiday Yuce, Nahid F. Ghalaty, Chinmay Deshpande, Conor Patrick, Leyla Nazhandali, and Patrick Schaumont. 2016. FAME: Fault-attack Aware Microprocessor Extensions for Hardware Fault Detection and Software Fault Response. In Proceedings of the Hardware and Architectural Support for Security and Privacy 2016 (HASP ‘16). Association for Computing Machinery, New York, NY, USA, Article 8, 1–8. https://doi.org/10.1145/2948618.2948626
[8] J. Boone, S. Q. Khan. “Alternative Approaches for Fault Injection Countermeasures (Part 3/3).” NCC Group. Accessed: Aug. 28, 2024. [Online]. Available: https://research.nccgroup.com/2021/07/09/alternative-approaches-for-fault-injection-countermeasures-part-3-3/
[9] T. Korak and M. Hoefler, “On the Effects of Clock and Power Supply Tampering on Two Microcontroller Platforms,” 2014 Workshop on Fault Diagnosis and Tolerance in Cryptography, Busan, Korea (South), 2014, pp. 8-17, doi: 10.1109/FDTC.2014.11.
[10] C. Bozzato, R. Focardi, and F. Palmarini. “Shaping the Glitch: Optimizing Voltage Fault Injection Attacks”, TCHES, vol. 2019, no. 2, pp. 199–224, Feb. 2019, doi: 10.13154/tches.v2019.i2.199-224.
[11] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
Many software-based mitigations to fault injection have been imposed. These range from coding patterns and strategies that can be used at development time, to automated compiler-based techniques, and hybrid approaches that take advantage of hardware features.
Certain programming patterns can harden pieces of code against common faults [1][2][3]. Redundancy is one such pattern, i.e., performing certain comparisons, memory reads, or function calls multiple times and comparing the results. Others include: choosing constant flag values with a large Hamming distance between them that are hard for a fault to generate or flip between, (e.g., multi-byte random bit strings instead of 0 and 1); adding code checks for ‘impossible’ paths through logic trees that could only be reached as a result of a fault; adding random time delays to operations; checking that loops executed to completion without stopping early; etc.
Other research has proposed more systematic approaches to hardening code at compile time. As compile-time approaches must be automated and generally applicable to all code, they often implement more narrow protections against specific types of faults. Examples include automating the insertion of duplicate computations and comparisons throughout an application [4] or hardening the control flow of loops [5]. Instruction duplication (ID) is one commonly proposed technique that can be automatically applied [6][7], however it has been shown over time that ID is only effective against faults that skip single instructions [8][9]. An attacker that can coordinate multiple faults to target each duplication can likely still achieve their objective. [13] demonstrates that such coordination is feasible with readily accessible tools.
Other general-purpose protections that protect a program’s control flow graph, e.g., control flow integrity (CFI), can provide some protection against faults that alter function pointers and jump addresses similar to how a software exploit would. Software-based CFI schemes [10][11] and hardware-assisted schemes (e.g., using ARM pointer authentication) [12] have been explored. See MID-007 and MID-020 for more information on CFI and pointer authentication/encryption.
A combination of multiple hardware and software-based mitigation techniques (see MID-062) to address the range of fault injection types, as recommended by [3], can prove more effective than any individual mitigation.
[1] M. Witterman, “Fault Mitigation Patterns,” Riscure. [Online]. Available: https://sidechannel.riscure.com/publications/fault-mitigation-patterns/
[2] J. Boone, S. Q. Khan. “Software-Based Fault Injection Countermeasures (Part 2/3).” NCC Group. Accessed: Aug. 28, 2024. [Online]. Available: https://research.nccgroup.com/2021/07/08/software-based-fault-injection-countermeasures-part-2-3/
[3] J. Boone, S. Q. Khan. “Alternative Approaches for Fault Injection Countermeasures (Part 3/3).” NCC Group. Accessed: Aug. 28, 2024. [Online]. Available: https://research.nccgroup.com/2021/07/09/alternative-approaches-for-fault-injection-countermeasures-part-3-3/
[4] G. A. Reis, J. Chang, N. Vachharajani, R. Rangan and D. I. August, “SWIFT: software implemented fault tolerance,” International Symposium on Code Generation and Optimization, San Jose, CA, USA, 2005, pp. 243-254, doi: 10.1109/CGO.2005.34.
[5] Julien Proy, Karine Heydemann, Alexandre Berzati, and Albert Cohen. 2017. Compiler-Assisted Loop Hardening Against Fault Attacks. ACM Trans. Archit. Code Optim. 14, 4, Article 36 (December 2017), 25 pages. https://doi.org/10.1145/3141234
[6] Alessandro Barenghi, Luca Breveglieri, Israel Koren, Gerardo Pelosi, and Francesco Regazzoni. 2010. Countermeasures against fault attacks on software implemented AES: effectiveness and cost. In Proceedings of the 5th Workshop on Embedded Systems Security (WESS ‘10). Association for Computing Machinery, New York, NY, USA, Article 7, 1–10. https://doi.org/10.1145/1873548.1873555
[7] Thierno Barry, Damien Couroussé, and Bruno Robisson. 2016. Compilation of a Countermeasure Against Instruction-Skip Fault Attacks. In Proceedings of the Third Workshop on Cryptography and Security in Computing Systems (CS2 ‘16). Association for Computing Machinery, New York, NY, USA, 1–6. https://doi.org/10.1145/2858930.2858931
[8] Cojocar, L., Papagiannopoulos, K., Timmers, N. (2018). Instruction Duplication: Leaky and Not Too Fault-Tolerant!. In: Eisenbarth, T., Teglia, Y. (eds) Smart Card Research and Advanced Applications. CARDIS 2017. Lecture Notes in Computer Science(), vol 10728. Springer, Cham. https://doi.org/10.1007/978-3-319-75208-2_10
[9] B. Yuce, N. F. Ghalaty, H. Santapuri, C. Deshpande, C. Patrick and P. Schaumont, “Software Fault Resistance is Futile: Effective Single-Glitch Attacks,” 2016 Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC), Santa Barbara, CA, USA, 2016, pp. 47-58, doi: 10.1109/FDTC.2016.21.
[10] V. B. Thati, J. Vankeirsbilck, J. Boydens and D. Pissort, “Selective Duplication and Selective Comparison for Data Flow Error Detection,” 2019 4th International Conference on System Reliability and Safety (ICSRS), Rome, Italy, 2019, pp. 10-15, doi: 10.1109/ICSRS48664.2019.8987731.
[11] R. Schilling, M. Werner and S. Mangard, “Securing conditional branches in the presence of fault attacks,” 2018 Design, Automation & Test in Europe Conference & Exhibition (DATE), Dresden, Germany, 2018, pp. 1586-1591, doi: 10.23919/DATE.2018.8342268.
[12] Schilling, R., Nasahl, P., Mangard, S. (2022). FIPAC: Thwarting Fault- and Software-Induced Control-Flow Attacks with ARM Pointer Authentication. In: Balasch, J., O’Flynn, C. (eds) Constructive Side-Channel Analysis and Secure Design. COSADE 2022. Lecture Notes in Computer Science, vol 13211. Springer, Cham. https://doi.org/10.1007/978-3-030-99766-3_5
[13] M. Alt. “Glitching in 3D: Low Cost EMFI Attacks,” presented at CanSecWest 2024, Vancouver, BC, Canada, March, 2024. Available: https://github.com/voidstarsec/csw-2024/blob/gh-pages/csw.pdf
[14] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf
On-chip non-volatile storage in a processor can be used to protect high-value data from extraction and modification. Many processors include ROM, NVRAM, or specialized write-once storage (e.g. security fuses). Common implementation patterns include storing keys and bootloader code used to bootstrap loading further stages of encrypted firmware (see MID-054) from external storage and to verify its authenticity as part of a secure boot chain. In other applications, the device firmware may be small enough to fit entirely within such on-chip storage (see MID-055).
Note: MID-058 must be implemented as well to obtain the protection afforded by this mitigation.
Limitations: Motivated attackers may resort to invasive and destructive analysis of ICs which can extact data or reset security fuses. In the case of keys and other secrets, combining this mitigation with MID-033 can prevent an invasive attack from affecting more than the single device attacked.
Some modern processors from Intel, AMD, and ARM include support for dynamically encrypting portions of memory to create secure enclaves for sensitive processes or virtual machines. This mechanism prevents unauthorized accesses to the cleartext contents of these memory regions from attacks such as (i) memory extraction through direct reads like in a Coldboot attack, (ii) DMA access to data in volatile memory not in active use, (iii) privilege escalation that gives processes direct memory reads, (iiii) reading memory being transferred into/out of volatile memory, and (iv) can prevent RowHammer-style attacks from targeting specific bit flip manipulations (e.g., for privilege escalation) and reduce them to denial of service.
[1] Intel. “Runtime Encryption of Memory with Intel® Total Memory Encryption–Multi-Key.” intel.com. Accessed: Aug. 28, 2024. [Online]. Available: https://www.intel.com/content/www/us/en/developer/articles/news/runtime-encryption-of-memory-with-intel-tme-mk.html
[2] D. Kaplan, J. Powell, T. Woller, ”AMD Memory Encryption,” amd.com, 2021. Accessed: Aug. 28, 2024. [Online]. Available: https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/memory-encryption-white-paper.pdf
[3] ARM. “Learn the Architecture – Realm Management Engine.” arm.com. Accessed: Aug. 28, 2024. [Online]. Available: https://developer.arm.com/documentation/den0126/0100/Overview
Systems that require high reliability may implement redundant memory and processors to tolerate faults. These ensure data validity before acting on it, for example by implementing a voting mechanism or other error detection algorithm. This can make a system more resistant to (1) manipulations that cause memory bit errors, such as RowHammer, as it is unlikely a majority of a redundant set of memory chips will exhibit identical bit flips when subjected to an attack, and (2) fault injection attacks if the fault is probabilistic and cannot be made to effect each redundant processor identically.
Limitations: A motivated adversary may coordinate simultaneous fault injections against all of the redundant components to still achieve a successful attack, however this will be more challenging than attacking a design without redundancy. The benefits of increasing attack difficulty must be weighed against the additional complexity added to the device design and its corresponding costs and risks.
As DRAM densities increase and cell sizes shrink, they become increasingly vulnerable to RowHammer-style attacks. Since its discovery, many solutions have been proposed in the research community to varying degrees of success [1]. ECC memory can provide some protection against single bit errors, but multi-bit flip RowHammer variants have been demonstrated that exceed ECC’s ability to correct [2]. ECC-detectable single bit errors may occur during an attempted RowHammer and provide indication to a firmware or operating system-level mitigation that an attack is underway.
Newer DRAM specifications have introduced defenses, such as DDR4’s Target Row Refresh (TRR) mechanism, that have made a successful RowHammer attack more difficult. However, attack methods have been refined to achieve success even on TRR-enabled DRAMs [3]. Not all DRAM modules are equally susceptible, and the memory controllers built into processors have implemented defenses of various efficacy. In [3], the authors show how to test the performance of a particular combination.
JEDEC updated the DDR5 specification in 2024 (JESD79-5C) to add Per-Row Activation Counting (PRAC) [4]. PRAC-enabled DRAM chips track individual DRAM row activations and signal the memory controller when the count exceeds a threshold value indicating a potential victim row requires a refresh that the controller must then command. Recent research concludes that PRAC does mitigate a RowHammer-style attack in many cases, although is subject to potentially high performance and energy overheads [5].
If the CPU/SoC’s memory controller supports it, system firmware and device operating system could cooperate with the memory controller hardware to leverage indicators from ECC, PRAC, etc. to inform additional layers of mitigation, such as identifying and terminating the offending application process conducting the RowHammer attack [6].
[1] Onur Mutlu, Ataberk Olgun, and A. Giray Yağlıkcı. 2023. Fundamentally Understanding and Solving RowHammer. In Proceedings of the 28th Asia and South Pacific Design Automation Conference (ASPDAC ‘23). Association for Computing Machinery, New York, NY, USA, 461–468.
[2] VUSec. “ECCPLOIT: ECC Memory Vulnerable to RowHammer Attacks After All.” visec.net. Accessed: Aug. 28, 2024. [Online]. Available: https://www.vusec.net/projects/eccploit/
[3] P. Frigo et al., “TRRespass: Exploiting the Many Sides of Target Row Refresh,” 2020 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2020, pp. 747-762, doi: 10.1109/SP40000.2020.00090.
[4] JEDEC. “JEDEC Updates JESD79-5C DDR5 SDRAM Standard: Elevating Performance and Security for Next-Gen Technologies.” jedec.org. Accessed: Aug. 28, 2024. [Online]. Available: https://www.jedec.org/news/pressreleases/jedec-updates-jesd79-5c-ddr5-sdram-standard-elevating-performance-and-security
[5] O. Canpolat, A. G. Yağlıkçı, G. F. Oliveira, A. Olgun, O. Ergin, O. Mutlu, “Understanding the Security Benefits and Overheads of Emerging Industry Solutions to DRAM Read Disturbance,” 2024, arXiv:2406.19094.
[6] “System Level Rowhammer Mitigation,” JEDEC, JEP301-1, Mar. 2021.
Applying cryptographic solutions to inter-chip and inter-peripheral data bus messaging can protect against data interception and modification. A message authentication code (MAC) scheme can be sufficient to protect the integrity of bus data from manipulation, but a more complete encryption scheme is required to maintain confidentiality. More complex chips (e.g., microcontrollers) will often be needed on either end of the communication that have specialized support for pairing, key management, message authentication codes, and encryption. Additionally, the extra overhead of adding encryption often requires migrating to newer, more capable bus protocols that support encryption, for examples CAN-FD vs. CAN [1]. On the higher end of performance, the PCI SIG is developing the Integrity and Data Encryption feature for inclusion in a future version of the PCIe bus specification [2].
Apple’s TouchID fingerprint authentication mechanism incorporates an example of this mitigation [3]. The device’s TouchID fingerprint sensor and the Secure Enclave chip are provisioned with a unique shared key at manufacturing time. This key is used to negotiate an additional session key that encrypts and authenticates the sensor data as it passes between the two chips.
Limitations: Many common PCB-level bus and interconnect protocols do not support encryption or authentication. Restricting a device design to components that do have these features may be a too limiting or too costly constraint. Device pairing and key management mechanisms and processes are necessary, add complexity to device design and manufacturing, especially to implement unique keys on each device (see MID-033).
CR 3.1 – Communication integrity - RE (1) Communication authentication
EDR / HDR / NDR 3.11 (1) - Physical tamper resistance and detection
[1] W. Busch. “Boosting security in cars with CAN-FD.” Avnet Silica. Accessed: Aug. 28, 2024. [Online]. Available: https://my.avnet.com/silica/resources/article/boosting-security-in-cars-with-can-fd/
[2] D. Harriman. “Integrity and Data Encryption (IDE) and IO Security Updates.” PCI SIG. Accessed: Aug. 28, 2024. [Online]. Available: https://pcisig.com/blog/integrity-and-data-encryption-ide-and-io-security-updates
[3] Apple. “Apple Platform Security.” apple.com. Accessed: Aug. 26, 2024. [Online]. Available: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
Externally accessible I/O ports should be protected against damaging electrical faults such as electro-static discharge (ESD), voltage transients, surges, reverse polarity, etc. Protections include adding protection circuits to vulnerable ports (e.g., protection diodes, optoisolators, etc.) and selecting ICs and other components that are more resilient to electrical faults. In addition to general guidance, industry-specific standards exist for many embedded device market domains that provide recommendations and requirements tailored more specifically to the needs of each domain (e.g., automotive, medical, etc.)
[1] “Design Guide: TIDA-00731 IEC ESD, EFT, and Surge RS-485 Bus Protection Design Guide,” Texas Instruments, TIDUAS1B, 2019. Accessed: Aug. 28, 2024. [Online]. Available: https://www.ti.com/lit/ug/tiduas1b/tiduas1b.pdf?ts=1721068648253
[2] Analog Devices. “ESD Protection for I/O Ports.” analog.com. Accessed: Aug. 28, 2024. [Online]. Available: https://www.analog.com/en/resources/technical-articles/esd-protection-for-io-ports.html
[3] V. Nandam, L. Ghulyani, “Simplifying EFT, Surge and Power-Fail Protection Circuits in PLC Systems,” Texas Instruments, SLVA833D, 2021. Accessed: Aug. 28, 2024. [Online]. Available: https://www.ti.com/lit/an/slva833d/slva833d.pdf?ts=1721068743110
To protect against malicious or compromised peripherals, a system might institute a scheme in which peripherals are considered untrusted until authenticated and authorized to access necessary system resources (e.g., system memory for DMA). Internal system components are often implicitly trusted, although many contain firmware of their own that, if modified, may cause the device to behave maliciously. Trusting external peripherals (e.g., USB devices) is always a risk. Each of a device’s processors and other components may instead treat other bus-connected components similarly to remote nodes on a network, perform cryptographic mutual authentication of a components’ identities, and use this to execute trust decisions. Measurement and attestation of component firmware can add further assurance.
Some Apple devices implement a form of this for certain security-sensitive components like the TouchID fingerprint reader [2].
Upcoming revisions of the PCI Express specification will add the Component Measurement and Authentication (CMA) mechanism [1], which will allow a system to verify the authenticity of a PCIe device and its firmware before allowing it to access system resources, preventing malicious or compromised peripherals from obtaining the degree of system access needed to perform attacks.
[1] N. Edwards, T. Koulouris, M. Krause. “PCIe Component Authentication.” PCI SIG. Accessed: Aug. 28, 2024. [Online]. Available: https://pcisig.com/pcie%C2%AE-component-authentication
[2] Apple. “Apple Platform Security.” apple.com. Accessed: Aug. 26, 2024. [Online]. Available: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
Web applications should encode all outputs of user data, put safety controls around all inputs, and store variables in safe attributes. Encoding outputs ensures that all outputted variables on the web application are converted into text before displaying. Encoded or escaped text will not execute on the user’s browser, making the variables safe for display. For example, putting quotes around variables, using escape sequences, using encoding formats for special characters like single or double quotes, and putting displayed variables in safe HTML or CSS structures can all help to prevent code execution upon output. These controls should be used when the user has the ability to edit any HTML on the webpage.
Potential ways to sanitize HTML input include using the JavaScript DOMPurify.sanitize() function and storing variables in safe structures or “safe sinks”. Safe sinks are HTML structures that will always treat the stored variable as text and therefore will never execute it.
Note: It is best to use web application frameworks that have this functionality already built-in and have been well tested and are widely used.
[1] OWASP. “Cross Site Scripting Prevention Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
[2] OWASP. “Input Validation Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
Web apps should not pass SQL queries for execution by a database unless they conform to one of the recommended query formation mitigations below. Methods can include 1) only executing prepared statements with parameterized queries, 2) only executing stored procedures, and 3) allow-list input validation [1].
Prepared statements with parameterized queries change the way that the web app will process a user request and form a query. When using prepared statements, the web app that processes the user data will take the user data and place it into a pre-defined section of the query, with the rest of the query already formed. Therefore, the actual SQL commands that the database will be executing are handled and compiled before the user input is processed and inserted, so the user input cannot introduce any new potentially malicious commands. This is then coupled with parameterized variables, where variables are set to be a certain type before being inserted into the SQL statement to ensure that no variable can be misconstrued as a command and not a string, for example.
Stored procedures are procedures that are crafted and pre-stored on the web app. They can be sent to the SQL database upon prompting from the client to the web app. Since these statements are pre-crafted and stored before the client has any interaction with the web app, the client cannot send custom queries that may be malicious. Assuming that the user data is parameterized here as well, users will not be able to inject data into the query that will not be interpreted as a literal data type. Therefore, the threat surface is lowered because the stored procedures can be implemented safely, and user input will not be able to add any new commands.
Allow-list input validation is implemented by creating an allow-list of parameters for clients to choose from. This allow list can be implemented through conditionals like if…else and switch statements. This would prevent potential commands contained in user inputs from being a part of the final SQL query statement given to the database.
Limitation: If a device is using stored procedures, particular care needs to be made to what permissions the stored procedure executor has. If the device has device-level users, the user that executes the procedures may need a high-level of permissions, which could make that user a target to threat actors.
[1] OWASP. “SQL Injection Prevention Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.htmlLinked
The web application should use session tokens or IDs to manage each authenticated user session. Core requirements for secure session management include:
Sessions tokens should be implemented using a trusted web framework to ensure that tokens are correctly assigned, enforced, tracked, and maintained to ensure that they keep their integrity and provide all necessary security guarantees.
Each session should be associated with a unique and non-predictable session IDs, which includes sufficient entropy to prevent guessing and is totally decoupled from and unrelated to any inherent user information.
Session IDs should be protected against leakage. HTTP Cookies provide multiple ways to prevent leakage, including the HTTPOnly, SameSite, Domain and Path information, expiration, and max-age secure attributes.
[1] OWASP. “Session Management Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
The web application should include mechanisms that will ensure that only authentic HTTP requests are processed. These mitigation mechanisms include synchronizer token patterns, double-submit cookie patterns, and forbidding simple requests. Additional techniques can be deployed to bolster the device’s other mitigations, such as such as using SameSite cookies, using standard headers, and requiring user interaction for all privileged actions (instead blindly allowing actions to take place just based on the URL). Ideally a web application framework should be used to implement these mitigations to ensure they are effectively and consistently deployed.
[1] OWASP. “Cross-Site Request Forgery Prevention Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
To avoid path traversal attacks, devices should not use raw user input as direct inputs to file system calls. For example, OWASP [1] recommends: (i) using indexes instead of file names, (ii) validating the user’s input by only accepting it if it matches predefined values, (iii) using technical mechanisms to limit where the user can access files from, and (iv) normalizing user inputs.
Additionally, devices should choose a single path to access a file and canonicalize it, as opposed to allowing all absolute paths access to that file. This can prevent threat actors from inserting alternative paths (e.g., using relative directory names or symlinks) that map to the target file but that the device was not expecting, which may result in bypassing file access control policies. Devices should convert all received paths into canonicalized absolute paths and then use the resulting canonicalized path as the subject for access control decisions.
[1] OWASP. “Path Traversal.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://owasp.org/www-community/attacks/Path_Traversal
[2] OWASP. “Input Validation Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
[3] PortSwigger. “Path traversal.” portswigger.net. Accessed: Aug. 28, 2024. [Online.] Available: https://portswigger.net/web-security/file-path-traversal
Every direct object reference should be governed by a session authentication and permission check [1]. Where possible, devices should use web application frameworks to host their files instead of hosting directly from their web servers. When using frameworks, ensure that all file formats associated with a web application (.txt, .pdf, documents) are being hosted on and managed by the framework [2].
Note: To learn more about session authentication, see MID-073 – Secure HTTP Session Management.
[1] OWASP. “Insecure Direct Object Reference Prevention Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
[2] D. Tidmarsh. “Insecure Direct Object Reference (IDOR) Vulnerability Detection and Prevention.” eccouncil.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.eccouncil.org/cybersecurity-exchange/web-application-hacking/idor-vulnerability-detection-prevention/
Serialized data should not be implicitly trusted. To check for the structure and contents of serialized data, that data needs to be deserialized, which could cause vulnerable code to run. For example, data that is serialized in a legitimately valid format may still include data that is unsafe and can lead to code injection. Input validation against the serialization format is insufficient defense in this case.
When its use cannot be avoided, serialized data’s authenticity should be checked prior to performing deserialization, such as signing it to verify the authenticity of the origin of the data. Additionally, if data needs to be serialized/deserialized, simpler structures and formats should be preferred that are easier to verify for safety prior to deserialization.
CR 3.5 - Input validation
SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
[1] OWASP. “Deserialization Cheat Sheet.” owasp.org. Accessed: Aug. 28, 2024. [Online.] Available: https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
[2] B. Vermeer. “Serialization and deserialization in Java: explaining the Java deserialize vulnerability.” synk.io. Accessed: Aug. 28, 2024. [Online.] Available: https://snyk.io/blog/serialization-and-deserialization-in-java/
HTTP requests should be checked for special characters (CR, LF, etc.) to ensure parsing logic errors do not occur, such as one request being broken into two separate requests. Additionally, HTTP requests should have enforceable and robust request-length checks.
Any request that fails these two checks should be rejected and the TCP connection facilitating it should be closed. By using these two validating mechanisms, devices can ensure that no extra text, such as the insertion of malicious requests, can be added to the legitimate request.
Note: HTTP/2 includes features such as length checking and should be used end-to-end wherever possible.
[1] PortSwigger. “HTTP request smuggling.” portswigger.net. Accessed: Aug. 28, 2024. [Online.] Available: https://portswigger.net/web-security/request-smuggling#how-to-prevent-http-request-smuggling-vulnerabilities
All network protocol functionality, including function codes, should be documented and available to the owners/operators of a device. The presence of undocumented functionality prevents device operators from adequately taking precautions and monitoring network behavior based on a device’s potential threat landscape. Without proper documentation, device users have no knowledge of what function codes are going over their network, leaving them exposed to potential threats and preventing them from implementing security features on their network, such as a message-level firewalls.
Documentation should include (i) describing the full set of function codes or message types that the device produces or accepts, (ii) functions that affect device management or can cause configuration changes, and (iii) authentication and encryption modes and mechanisms it is capable of. Any functions that are not meant for use in a production environment should be removed. The device operator should have full knowledge of any network-accessible function that can affect the behavior or performance of the device.
A device can be susceptible to denial-of-service when its ability to process network messages and requests is overwhelmed by a threat actor, causing device resources (e.g., processing, memory, bandwidth, ports, etc.) to be exhausted and leading it to become unresponsive. The effect is magnified when asymmetries exist allowing small messages, which are inexpensive for an attacker to generate, lead to expensive response processing on the device.
Technical mechanisms to implement this mitigation can include timeout functions that will return/cancel request processing after a set amount of time after the request is made, limiting the overall bandwidth that a device will process, constraining the number of active connections a device will support, instituting request queue management and prioritization, or separating request handler code paths so that resource limits can be imposed on them. These mechanisms can work together to ensure that the network protocol handlers and services remain responsive, and that no one handler, or source of traffic, can monopolize all system processing resources.
If protocol designs allow for it, expensive operations should not be performed as a result of unauthenticated or pre-authentication messages (MID-034 - Authenticate Network Traffic), constraining threat actors’ access to easily access the most exhaustible resources.
Note: Device creators should take care to ensure that the processing limits do not become the target of denial-of-service attacks themselves. For example, if a device only allows one connection at a time, threat actors may try to occupy that connection, preventing legitimate users from communicating.
Limitation: Device-level mitigations cannot cope with flooding attacks that simply overwhelm the bandwidth capacity of the device’s network link. In this case, upstream network devices must impose appropriate rate limits.
CR 7.1 – Denial of service protection
CR 7.2 – Resource management
[1] Cloudflare. “What is Rate limiting? | Rate limiting and bots.” cloudflare.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.cloudflare.com/learning/bots/what-is-rate-limiting/
[2] MITRE. “Limit Access to Resource Over Network.” mitre.org. Accessed: Aug. 28, 2024. [Online.] Available: https://attack.mitre.org/mitigations/M1035/
When a protocol itself does not support authentication, encryption, and/or message integrity checking, secure network tunnels can be implemented to provide communications with those security features. Secure network tunnels are best used when devices need to support a specific insecure protocol, either for functionality or to support legacy devices, and cannot have that protocol replaced by a protocol that is more secure by default.
Secure network tunnels will wrap a protocol in a more secure protocol (e.g., TLS, IPsec, SSH tunneling, etc.) that provides security features such as encryption, authentication, and message integrity checking. These added features make sending spoofed, illegitimate, or replayed messages more difficult.
To enable secure network tunnels, both the sending and receiving device must be compatible with the secure tunnel protocol and the underlying wrapped protocol. If the devices themselves cannot be made compatible with the wrapping protocol, a dedicated gateway device can be placed between the incompatible device and upstream network to implement the tunnel. Therefore, the downstream device may continue to use the insecure underlying protocol, while it is shielded within the tunnel while traversing intervening networks.
CR 4.1 – Information confidentiality
CR 3.1 – Communication integrity - RE (1) Communication authentication
[1] W. Floyd. “The TLS (Transport Layer Security) Protocol in Secure Modbus/TCP.” control.com. Accessed: Aug. 28, 2024. [Online.] Available: https://control.com/technical-articles/tls-transport-layer-security-protocol-secure-modbus-TCP/
Post-quantum cryptography refers to a class of cryptographic algorithms that are resistant to attacks by quantum computers, which could otherwise undermine the non-quantum-resistant algorithms’ cryptographic guarantees (e.g., RSA, Diffie-Hellman, ECC, etc.). By using these post-quantum algorithms, devices can make their communications more secure against attacks by future quantum computers which may enter practical use during the expected lifetime of the device.
Limitations: Current post-quantum cryptographic schemes and algorithms are still emerging [2][3] and may require some time before implementations become widely available in cryptographic libraries (see MID-027) and hardware modules (MID-060).
[1] L. Chen, S. Jordan, Y. Liu, D. Moody, R. Peralta, R. Perlner, and D. Smith-Tone. “NIST IR 8105 - Report on Post-Quantum Cryptography.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf
[2] NIST. “NIST Announces First Four Quantum-Resistant Cryptographic Algorithms.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms
[3] NIST. “NIST Releases First 3 Finalized Post-Quantum Encryption Standards.” nist.gov. Accessed: Sep. 5, 2024. [Online.] Available: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
If a device has routing capabilities, the device should have a firewall and access control list (ACL) present to prevent unintended network connections from being made and maintained. Firewalls and ACLs, when properly configured, can be used to drop packets and block undesired data flows.
Note: Any change to this firewall and ACL rules should be logged for future audits (MID-017 - Security-relevant Auditing and Logging) and authenticated to prevent threat actor tampering (MID-018 - Require Authentication for Privileged Functions).
Hardware | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-11 | Device includes a microprocessor |
| ||||||||||||||
PID-121 | Device includes buses for external memory/storage |
| ||||||||||||||
PID-122 | Device includes discrete chips/devices that have access to the same physical memory |
| ||||||||||||||
PID-123 | Device includes ROM, VRAM, or removable Storage |
| ||||||||||||||
PID-124 | Device includes Random Access Memory (RAM) chips |
| ||||||||||||||
PID-1241 | Device includes DDR DRAM |
| ||||||||||||||
PID-13 | Device includes peripheral chips and integrated data buses |
| ||||||||||||||
PID-14 | Device includes external peripheral interconnects (e.g., USB, Serial) |
| ||||||||||||||
PID-15 | Device includes a hardware access port (e.g., UART, JTAG) |
| ||||||||||||||
System Software | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-21 | Device includes a bootloader |
| ||||||||||||||
PID-22 | Device includes a debugging capabilities |
| ||||||||||||||
PID-23 | Device includes OS/kernel |
| ||||||||||||||
PID-231 | Device includes an operating system that uses drivers/modules that can be loaded |
| ||||||||||||||
PID-2321 | Device lacks an access enforcement/privilege mechanism |
| ||||||||||||||
PID-23221 | Device includes and enforces OS user accounts |
| ||||||||||||||
PID-23222 | Device includes a memory management model, including protections of memory access (read-only/, executable, writable) |
| ||||||||||||||
PID-241 | Device includes containers |
| ||||||||||||||
PID-242 | Device includes hypervisor |
| ||||||||||||||
PID-251 | Root of Trust is physically accessible or is not immutable |
| ||||||||||||||
PID-252 | Root of Trust is immutable |
| ||||||||||||||
PID-26 | Device lacks firmware/software update support |
| ||||||||||||||
PID-271 | Device has firmware or software that is not cryptographically checked for integrity validation |
| ||||||||||||||
PID-272 | Device includes cryptographic firmware/software integrity protection mechanisms |
| ||||||||||||||
PID-2721 | Device includes a shared key for firmware integrity validation |
| ||||||||||||||
PID-2722 | Device includes digitally signed firmware (with private key) |
| ||||||||||||||
PID-273 | Device has unencrypted firmware updates |
| ||||||||||||||
PID-274 | Device includes user firmware/software version selection during updates |
| ||||||||||||||
PID-275 | Device includes remotely-initiated firmware/software updates |
| ||||||||||||||
Application Software | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-31 | Application-level software is present and running on the device |
| ||||||||||||||
PID-311 | Device includes the usage of a web/HTTP applications |
| ||||||||||||||
PID-3121 | Device includes support for object oriented programming languages(e.g., Java, Python, PHP, C++) |
| ||||||||||||||
PID-3122 | Device includes support for manual memory management programming languages (e.g. C, C++) |
| ||||||||||||||
PID-32 | Device includes the ability to deploy custom or external programs (e.g., ladder logic, compiled binaries) |
| ||||||||||||||
PID-321 | Device includes ability to deploy custom programs from engineering software or IDE |
| ||||||||||||||
PID-322 | Device includes a program runtime environment for custom or external programs |
| ||||||||||||||
PID-3231 | Device includes ability to run custom/external programs as native binary without a confined/restricted environment |
| ||||||||||||||
PID-3232 | Device includes ability to run custom/external programs/processes through an execution sandboxed environment |
| ||||||||||||||
PID-324 | Device includes support for "program uploads" to retrieve programs from the device from an engineering workstation |
| ||||||||||||||
PID-331 | Device includes unauthenticated services |
| ||||||||||||||
PID-332 | Device includes authenticated services |
| ||||||||||||||
PID-3321 | Device includes passwords to authenticate the users |
| ||||||||||||||
PID-3322 | Device includes cryptographic mechanism to authenticate users and sessions |
| ||||||||||||||
Networking | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-41 | Device exposes remote network services |
| ||||||||||||||
PID-4111 | Device lacks protocol support for message authentication |
| ||||||||||||||
PID-4112 | Device lacks protocol support for message encryption |
| ||||||||||||||
PID-4113 | Device includes cryptographic functions for sensitive data, such as encryption or authentication |
| ||||||||||||||
PID-42 | Device includes procedure to forward or route network messages |
|
Hardware | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-11 | Device includes a microprocessor |
| ||||||||||||||
PID-121 | Device includes buses for external memory/storage |
| ||||||||||||||
PID-122 | Device includes discrete chips/devices that have access to the same physical memory |
| ||||||||||||||
PID-123 | Device includes ROM, VRAM, or removable Storage |
| ||||||||||||||
PID-124 | Device includes Random Access Memory (RAM) chips |
| ||||||||||||||
PID-1241 | Device includes DDR DRAM |
| ||||||||||||||
PID-13 | Device includes peripheral chips and integrated data buses |
| ||||||||||||||
PID-14 | Device includes external peripheral interconnects (e.g., USB, Serial) |
| ||||||||||||||
PID-15 | Device includes a hardware access port (e.g., UART, JTAG) |
| ||||||||||||||
System Software | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-21 | Device includes a bootloader |
| ||||||||||||||
PID-22 | Device includes a debugging capabilities |
| ||||||||||||||
PID-23 | Device includes OS/kernel |
| ||||||||||||||
PID-231 | Device includes an operating system that uses drivers/modules that can be loaded |
| ||||||||||||||
PID-2321 | Device lacks an access enforcement/privilege mechanism |
| ||||||||||||||
PID-23221 | Device includes and enforces OS user accounts |
| ||||||||||||||
PID-23222 | Device includes a memory management model, including protections of memory access (read-only/, executable, writable) |
| ||||||||||||||
PID-241 | Device includes containers |
| ||||||||||||||
PID-242 | Device includes hypervisor |
| ||||||||||||||
PID-251 | Root of Trust is physically accessible or is not immutable |
| ||||||||||||||
PID-252 | Root of Trust is immutable |
| ||||||||||||||
PID-26 | Device lacks firmware/software update support |
| ||||||||||||||
PID-271 | Device has firmware or software that is not cryptographically checked for integrity validation |
| ||||||||||||||
PID-272 | Device includes cryptographic firmware/software integrity protection mechanisms |
| ||||||||||||||
PID-2721 | Device includes a shared key for firmware integrity validation |
| ||||||||||||||
PID-2722 | Device includes digitally signed firmware (with private key) |
| ||||||||||||||
PID-273 | Device has unencrypted firmware updates |
| ||||||||||||||
PID-274 | Device includes user firmware/software version selection during updates |
| ||||||||||||||
PID-275 | Device includes remotely-initiated firmware/software updates |
| ||||||||||||||
Application Software | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-31 | Application-level software is present and running on the device |
| ||||||||||||||
PID-311 | Device includes the usage of a web/HTTP applications |
| ||||||||||||||
PID-3121 | Device includes support for object oriented programming languages(e.g., Java, Python, PHP, C++) |
| ||||||||||||||
PID-3122 | Device includes support for manual memory management programming languages (e.g. C, C++) |
| ||||||||||||||
PID-32 | Device includes the ability to deploy custom or external programs (e.g., ladder logic, compiled binaries) |
| ||||||||||||||
PID-321 | Device includes ability to deploy custom programs from engineering software or IDE |
| ||||||||||||||
PID-322 | Device includes a program runtime environment for custom or external programs |
| ||||||||||||||
PID-3231 | Device includes ability to run custom/external programs as native binary without a confined/restricted environment |
| ||||||||||||||
PID-3232 | Device includes ability to run custom/external programs/processes through an execution sandboxed environment |
| ||||||||||||||
PID-324 | Device includes support for "program uploads" to retrieve programs from the device from an engineering workstation |
| ||||||||||||||
PID-331 | Device includes unauthenticated services |
| ||||||||||||||
PID-332 | Device includes authenticated services |
| ||||||||||||||
PID-3321 | Device includes passwords to authenticate the users |
| ||||||||||||||
PID-3322 | Device includes cryptographic mechanism to authenticate users and sessions |
| ||||||||||||||
Networking | ||||||||||||||||
Device Properties | Threats | |||||||||||||||
PID-41 | Device exposes remote network services |
| ||||||||||||||
PID-4111 | Device lacks protocol support for message authentication |
| ||||||||||||||
PID-4112 | Device lacks protocol support for message encryption |
| ||||||||||||||
PID-4113 | Device includes cryptographic functions for sensitive data, such as encryption or authentication |
| ||||||||||||||
PID-42 | Device includes procedure to forward or route network messages |
|
The properties tool encodes the mapping from Device Properties to EMB3D Threats. Start by selecting the properties relevant to the device you are mapping from using the checkboxes in each of the four categories below. As you select properties, additional sub-properties may be uncovered, and the Applicable Threats list is populated with entries that may be relevant to your device. When finished, you may save a copy of the threats report by clicking the 'Download CSV' button.
Properties ListThe properties tool encodes the mapping from Device Properties to EMB3D Threats. Start by selecting the properties relevant to the device you are mapping from using the checkboxes in each of the four categories below. As you select properties, additional sub-properties may be uncovered, and the Applicable Threats list is populated with entries that may be relevant to your device. When finished, you may save a copy of the threats report by clicking the 'Download CSV' button.
Properties ListThe MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use EMB3D™ for internal business purposes only. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.
“© 2024 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.”
For all other uses of EMB3D™, contact MITRE at emb3d@mitre.org.
MITRE does not claim EMB3D™ enumerates all possibilities for the types of actions and behaviors documented as part of EMB3D™’s adversary model and framework of techniques. Using the information contained within EMB3D™ to address or cover full categories of techniques will not guarantee full defensive coverage as there may be undisclosed techniques or variations on existing techniques not documented by EMB3D™.
ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN “AS IS” BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES, OFFICERS, AGENTS, AND EMPLOYEES, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF ACCURACY, NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
Devices will oftentimes consume variable amounts of power depending on the operations the device is performing. Power consumption analysis involves the reading and analyzing of power usage of a device.
If a device is vulnerable to a power consumption analysis attack, it may be possible to extract or deduce information about the operating state of the device. This can include extracting secrets/keys, discovering operations conducted on sections of memory, and device control flow. A threat actor can therefore physically monitor the power consumption of a device during an execution of a cryptographic operation to create a trace of its power usage over time. By leveraging the understanding of the operations of common cryptographic properties, the power usage traces can be used to infer various information, such as the cryptographic keys.
Proof of Concept
Differential power analysis (DPA) and correlation power analysis (CPA) on Arduino Uno
Researchers “demonstrate that both DPA and CPA techniques are viable in deducing the full 16-byte key of AES-128 by monitoring the power consumption of an Arduino Uno which implements the AddRoundKey and SubBytes steps in round 1 of AES.”
CWE-1300: Improper Protection of Physical Side Channels (Base)
“The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.”
CWE-1255: Comparison Logic is Vulnerable to Power Side-Channel Attacks (Variant)
“A device’s real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.”
Devices will oftentimes consume variable amounts of power depending on the operations the device is performing. Power consumption analysis involves the reading and analyzing of power usage of a device.
If a device is vulnerable to a power consumption analysis attack, it may be possible to extract or deduce information about the operating state of the device. This can include extracting secrets/keys, discovering operations conducted on sections of memory, and device control flow. A threat actor can therefore physically monitor the power consumption of a device during an execution of a cryptographic operation to create a trace of its power usage over time. By leveraging the understanding of the operations of common cryptographic properties, the power usage traces can be used to infer various information, such as the cryptographic keys.
Proof of Concept
Differential power analysis (DPA) and correlation power analysis (CPA) on Arduino Uno
Researchers “demonstrate that both DPA and CPA techniques are viable in deducing the full 16-byte key of AES-128 by monitoring the power consumption of an Arduino Uno which implements the AddRoundKey and SubBytes steps in round 1 of AES.”
CWE-1300: Improper Protection of Physical Side Channels (Base)
“The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.”
CWE-1255: Comparison Logic is Vulnerable to Power Side-Channel Attacks (Variant)
“A device’s real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.”
Devices will oftentimes emit different electromagnetic signals during different operations. Electromagnetic analysis involves the collection and analysis of these signals.
If devices are vulnerable to electromagnetic analysis attacks, it may be possible for attackers with physical device presence to extract secrets, such as encryption keys, by analyzing the electromagnetic radiation that is emitted by the device. By analyzing these frequencies and comparing them against one another, it may be possible to derive information about device data or operations.
Proof of Concept
Differential Electromagnetic Analysis (DEMA) on FPGA
Researchers demonstrated “that DEMA can be performed against hardware implementation of AES using an FPGA.”
CWE-1300: Improper Protection of Physical Side Channels (Base)
“The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.”
Devices will oftentimes emit different electromagnetic signals during different operations. Electromagnetic analysis involves the collection and analysis of these signals.
If devices are vulnerable to electromagnetic analysis attacks, it may be possible for attackers with physical device presence to extract secrets, such as encryption keys, by analyzing the electromagnetic radiation that is emitted by the device. By analyzing these frequencies and comparing them against one another, it may be possible to derive information about device data or operations.
Proof of Concept
Differential Electromagnetic Analysis (DEMA) on FPGA
Researchers demonstrated “that DEMA can be performed against hardware implementation of AES using an FPGA.”
CWE-1300: Improper Protection of Physical Side Channels (Base)
“The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.”
Cache-based timing analysis attacks exploit variations in timing used for memory access, across both cached and uncached memory, to infer the contents of memory. This bypasses existing OS privilege mechanisms.
If a threat actor capable of executing arbitrary code on the device, they may be able to use a cache-based side-channel attack to extract data and sensitive information from more privileged processes or areas of memory on a device (e.g., passwords, keys). Executing a cache-based attack assumes the threat actor can deploy custom software to the device (including scripts).
Known Exploitable Weakness
Spectre and Meltdown Cache Timing
Cache Timing was used to create micro-architecture side-channels in devices to read whether data was in the cache or not for the Spectre/Meltdown based-attacks. Through this side-channel data leak, it would be possible to dump entire sections of program memory in the case of Spectre/Meltdown, and kernel memory in the case of Meltdown. Both Spectre and Meltdown have been observed in the wild.
CVE-2017-5754 (Meltdown)
“Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.”
CVE-2017-5753 (Spectre)
“Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.”
Cache-based timing analysis attacks exploit variations in timing used for memory access, across both cached and uncached memory, to infer the contents of memory. This bypasses existing OS privilege mechanisms.
If a threat actor capable of executing arbitrary code on the device, they may be able to use a cache-based side-channel attack to extract data and sensitive information from more privileged processes or areas of memory on a device (e.g., passwords, keys). Executing a cache-based attack assumes the threat actor can deploy custom software to the device (including scripts).
Known Exploitable Weakness
Spectre and Meltdown Cache Timing
Cache Timing was used to create micro-architecture side-channels in devices to read whether data was in the cache or not for the Spectre/Meltdown based-attacks. Through this side-channel data leak, it would be possible to dump entire sections of program memory in the case of Spectre/Meltdown, and kernel memory in the case of Meltdown. Both Spectre and Meltdown have been observed in the wild.
CVE-2017-5754 (Meltdown)
“Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.”
CVE-2017-5753 (Spectre)
“Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.”
A threat actor with physical access to a device may be able to manipulate the processor’s intended code execution by subjecting it to hardware faults or “glitching”. Hardware faults can be induced by various methods, including voltage fault injection (power glitching), electromagnetic pulses (EM glitching), and optical fault injection. Glitching can be used to bypass various security protections on a device, such as skipping a firmware integrity check during a secure boot process or protections against firmware or data read-out from the device. This threat requires physical access to the device to perform the glitching, and also typically requires substantial iterative testing to identify the precise nature, magnitude, and timing of signals that need to be injected to cause the glitch condition.
Known Exploitable Weakness
Glitching the Switch
In pursuit of extracting the 1st stage boot ROM code from the Nvidia Tegra X1 SoC, the researchers implemented a power glitching attack against the processor to prevent the bootloader from enabling the SoC’s readout protection for that code segment. The glitch interrupts the boot ROM code from writing to a security configuration register, leaving the processor in a state that allows exporting the code responsible for the establishing the processor’s root of trust for secure boot. Analysis of the bootloader code yielded an exploitable buffer overflow in a USB protocol implementation (see TID-327) used to inject code that bypasses secure boot and allows executing unauthorized firmware. The presence of this flaw in the unmodifiable initial boot ROM prevents patching this vulnerability in already deployed devices (see TID-220).
Proof of Concept
Electromagnetic Fault Injection: Towards a Fault Model on a 32-bit Microcontroller
“These experiments confirm the fact that an attacker could change an instruction into another one and change the value of a piece of data loaded from the Flash memory. But they also provide a more accurate fault model, in which some instructions or registers seem to be more vulnerable than others”
Oops..! I Glitched It Again! How to Multi-Glitch the Glitching-Protections on ARM TrustZone-M
“In this paper, we present μ-Glitch, the first Voltage Fault Injection (VFI) platform which is capable of injecting multiple, coordinated voltage faults into a target device, requiring only a single trigger signal…We evaluate and showcase the effectiveness and practicality of our attack platform on four real-world chips, featuring TrustZone-M”
CWE-1247: Improper Protection Against Voltage and Clock Glitches (Base)
“The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.”
CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI) (Base)
“The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.”
A threat actor with physical access to a device may be able to manipulate the processor’s intended code execution by subjecting it to hardware faults or “glitching”. Hardware faults can be induced by various methods, including voltage fault injection (power glitching), electromagnetic pulses (EM glitching), and optical fault injection. Glitching can be used to bypass various security protections on a device, such as skipping a firmware integrity check during a secure boot process or protections against firmware or data read-out from the device. This threat requires physical access to the device to perform the glitching, and also typically requires substantial iterative testing to identify the precise nature, magnitude, and timing of signals that need to be injected to cause the glitch condition.
Known Exploitable Weakness
Glitching the Switch
In pursuit of extracting the 1st stage boot ROM code from the Nvidia Tegra X1 SoC, the researchers implemented a power glitching attack against the processor to prevent the bootloader from enabling the SoC’s readout protection for that code segment. The glitch interrupts the boot ROM code from writing to a security configuration register, leaving the processor in a state that allows exporting the code responsible for the establishing the processor’s root of trust for secure boot. Analysis of the bootloader code yielded an exploitable buffer overflow in a USB protocol implementation (see TID-327) used to inject code that bypasses secure boot and allows executing unauthorized firmware. The presence of this flaw in the unmodifiable initial boot ROM prevents patching this vulnerability in already deployed devices (see TID-220).
Proof of Concept
Electromagnetic Fault Injection: Towards a Fault Model on a 32-bit Microcontroller
“These experiments confirm the fact that an attacker could change an instruction into another one and change the value of a piece of data loaded from the Flash memory. But they also provide a more accurate fault model, in which some instructions or registers seem to be more vulnerable than others”
Oops..! I Glitched It Again! How to Multi-Glitch the Glitching-Protections on ARM TrustZone-M
“In this paper, we present μ-Glitch, the first Voltage Fault Injection (VFI) platform which is capable of injecting multiple, coordinated voltage faults into a target device, requiring only a single trigger signal…We evaluate and showcase the effectiveness and practicality of our attack platform on four real-world chips, featuring TrustZone-M”
CWE-1247: Improper Protection Against Voltage and Clock Glitches (Base)
“The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.”
CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI) (Base)
“The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.”
A threat actor could intercept data across a data bus used to connect a process to either volatile memory or non-volatile storage (e.g. ROM, NVRAM, disk). Depending on the scope of the interception, it may be possible to read and/or perform an adversary-in-the-middle (AITM) attack to write information going over the bus, especially if it lacks adequate encryption and authentication. For example, if a device has discrete RAM external from the processor, it may be possible to tap the address and data lines to observe and capture memory contents as they are loaded and stored for processing. Similar attacks can also be performed in software. Captured data may leak sensitive information (e.g., keys, cleartext firmware code) that can aid in reverse engineering or executing other stages of an attack. Interception and modification may enable an adversary to alter a device’s behavior, achieve persistence, evade detection, or other objectives.
NOTE: This is different from TID-114 in that this threat refers to data moving between the processor and storage devices, whereas TID-114 refers to the data moving between the main board or processing chip to a peripheral device.
Proof of Concept
An Off-Chip Attack on Hardware Enclaves via the Memory Bus
“This paper shows how an attacker can break the confidentiality of a hardware enclave with MEMBUSTER, an off-chip attack based on snooping the memory bus. An attacker with physical access can observe an unencrypted address bus and extract fine-grained memory access patterns of the victim”
CWE-311: Missing Encryption of Sensitive Data (Class)
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-319: Cleartext Transmission of Sensitive Information (Base)
“The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.”
A threat actor could intercept data across a data bus used to connect a process to either volatile memory or non-volatile storage (e.g. ROM, NVRAM, disk). Depending on the scope of the interception, it may be possible to read and/or perform an adversary-in-the-middle (AITM) attack to write information going over the bus, especially if it lacks adequate encryption and authentication. For example, if a device has discrete RAM external from the processor, it may be possible to tap the address and data lines to observe and capture memory contents as they are loaded and stored for processing. Similar attacks can also be performed in software. Captured data may leak sensitive information (e.g., keys, cleartext firmware code) that can aid in reverse engineering or executing other stages of an attack. Interception and modification may enable an adversary to alter a device’s behavior, achieve persistence, evade detection, or other objectives.
NOTE: This is different from TID-114 in that this threat refers to data moving between the processor and storage devices, whereas TID-114 refers to the data moving between the main board or processing chip to a peripheral device.
Proof of Concept
An Off-Chip Attack on Hardware Enclaves via the Memory Bus
“This paper shows how an attacker can break the confidentiality of a hardware enclave with MEMBUSTER, an off-chip attack based on snooping the memory bus. An attacker with physical access can observe an unencrypted address bus and extract fine-grained memory access patterns of the victim”
CWE-311: Missing Encryption of Sensitive Data (Class)
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-319: Cleartext Transmission of Sensitive Information (Base)
“The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.”
If separate discrete chips/peripherals that have access to the same physical memory, a threat actor with access to one peripheral could perform a Direct Memory Access (DMA) attack to maliciously read/write memory from a connected chip or peripheral. This threat is especially relevant if there is insufficient hardware or software restrictions on what memory can be accessed/manipulated. A DMA attack can be used to extract cryptographic keys or other sensitive data, and also to manipulate the operation of the chip.
Proof of Concept
High-Speed DMA Attacks Bypass Built-in Hardware Protections on Enterprise Devices
“Eclypsium’s latest research shows that enterprise laptops, servers, and cloud environments continue to be vulnerable to powerful Direct Memory Access (DMA) attacks, even in the presence of protections such as UEFI Secure Boot, Intel Boot Guard, HP Sure Start, and Microsoft Virtualization-Based Security.”
Exploiting an I/OMMU vulnerability
In the 2010 5th International Conference on Malicious and Unwanted Software, researchers demonstrated how vulnerabilities on Intel’s VT-d could be exploited via a DMA attack.
Thunderspy
“The attack involved opening the device’s back cover, connecting a hacking device called a Bus Pirate to the SPI flash interface associated with the Thunderbolt controller firmware, connecting the Bus Pirate to the attacker’s laptop, copying the Thunderbolt firmware using a tool called Flashrom, modifying the Thunderbolt firmware to disable all Thunderbolt security, and writing it back to the targeted device. The attacker then connects a Thunderbolt-based direct memory access (DMA) attack device running PCILeech to the targeted PC, and uses it to load a kernel module that allows them to bypass the Windows login screen.”
CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges (Base)
“The product allows address regions to overlap, which can result in the bypassing of intended memory protection.”
CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
“The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.”
CWE-284: Improper Access Control
“The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.”
If separate discrete chips/peripherals that have access to the same physical memory, a threat actor with access to one peripheral could perform a Direct Memory Access (DMA) attack to maliciously read/write memory from a connected chip or peripheral. This threat is especially relevant if there is insufficient hardware or software restrictions on what memory can be accessed/manipulated. A DMA attack can be used to extract cryptographic keys or other sensitive data, and also to manipulate the operation of the chip.
Proof of Concept
High-Speed DMA Attacks Bypass Built-in Hardware Protections on Enterprise Devices
“Eclypsium’s latest research shows that enterprise laptops, servers, and cloud environments continue to be vulnerable to powerful Direct Memory Access (DMA) attacks, even in the presence of protections such as UEFI Secure Boot, Intel Boot Guard, HP Sure Start, and Microsoft Virtualization-Based Security.”
Exploiting an I/OMMU vulnerability
In the 2010 5th International Conference on Malicious and Unwanted Software, researchers demonstrated how vulnerabilities on Intel’s VT-d could be exploited via a DMA attack.
Thunderspy
“The attack involved opening the device’s back cover, connecting a hacking device called a Bus Pirate to the SPI flash interface associated with the Thunderbolt controller firmware, connecting the Bus Pirate to the attacker’s laptop, copying the Thunderbolt firmware using a tool called Flashrom, modifying the Thunderbolt firmware to disable all Thunderbolt security, and writing it back to the targeted device. The attacker then connects a Thunderbolt-based direct memory access (DMA) attack device running PCILeech to the targeted PC, and uses it to load a kernel module that allows them to bypass the Windows login screen.”
CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges (Base)
“The product allows address regions to overlap, which can result in the bypassing of intended memory protection.”
CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
“The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.”
CWE-284: Improper Access Control
“The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.”
Contents of non-volatile memory chips or non-fixed storage (e.g., SD cards, Compact Flash, hard disks, USB sticks) can be directly read out for examination or modification by a chip reader. In some cases this may be possible without removing the chip from the circuit board, but most often this will involve physically desoldering the chip and non-destructively removing it from the device. By reading information from ROM or NVRAM, a threat actor would be able to extract any secrets stored on it.
If the extracted storage contents contain unencrypted firmware (even partial), this can ease reverse engineering by an adversary to identify other potential vulnerabilities or security-relevant data (e.g., passwords, cryptographic keys).
Threat actors may also be able to load malicious changes to the ROM/NVRAM, potentially giving them increased and unauthorized access to the device.
Proof of Concept
Uprooting Trust: Learnings from an Unpatchable Hardware Root-of-Trust Vulnerability in Siemens S7-1500 PLCs
“This Siemens S7-1500 uses two non-volatile NAND flash memories as primary storage for the main SoC. We identified these two non-volatile NAND flash memory chips as W29N01HV (1G-bit) NAND Flash memory [35]. We desoldered the two NAND chips from the device’s PCB and used the Xgecu Minipro TL866II [36] NAND programmer to extract the content of them.”
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-312: Cleartext Storage of Sensitive Information
“The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.”
CWE-1282: Assumed-Immutable Data is Stored in Writable Memory
“Immutable data, such as a first-stage bootloader, device identifiers, and “write-once” configuration settings are stored in writable memory that can be re-programmed or updated in the field.”
Contents of non-volatile memory chips or non-fixed storage (e.g., SD cards, Compact Flash, hard disks, USB sticks) can be directly read out for examination or modification by a chip reader. In some cases this may be possible without removing the chip from the circuit board, but most often this will involve physically desoldering the chip and non-destructively removing it from the device. By reading information from ROM or NVRAM, a threat actor would be able to extract any secrets stored on it.
If the extracted storage contents contain unencrypted firmware (even partial), this can ease reverse engineering by an adversary to identify other potential vulnerabilities or security-relevant data (e.g., passwords, cryptographic keys).
Threat actors may also be able to load malicious changes to the ROM/NVRAM, potentially giving them increased and unauthorized access to the device.
Proof of Concept
Uprooting Trust: Learnings from an Unpatchable Hardware Root-of-Trust Vulnerability in Siemens S7-1500 PLCs
“This Siemens S7-1500 uses two non-volatile NAND flash memories as primary storage for the main SoC. We identified these two non-volatile NAND flash memory chips as W29N01HV (1G-bit) NAND Flash memory [35]. We desoldered the two NAND chips from the device’s PCB and used the Xgecu Minipro TL866II [36] NAND programmer to extract the content of them.”
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-312: Cleartext Storage of Sensitive Information
“The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.”
CWE-1282: Assumed-Immutable Data is Stored in Writable Memory
“Immutable data, such as a first-stage bootloader, device identifiers, and “write-once” configuration settings are stored in writable memory that can be re-programmed or updated in the field.”
If a threat actor can physically access a RAM chip, they may be able to readout the contents of the chip. Multiple techniques can be used to extract the contents of RAM, including both runtime and physical access, such as the threat actor can use a Cold-boot attack to physically cool the RAM to minimize the decay of the electrical charge and then physically copy the contents of that RAM
Through these methods, critical data, including firmware or secrets (such as passwords and cryptographic keys), may therefore be vulnerable to extraction. Extraction of this information could then lead to reverse engineering to identify vulnerabilities, abusing secrets to gain unauthorized access, or subverting at-rest encryption schemes.
Proof of Concept
Cold Boot Attacks
“We provide an independent study based on 12 computer systems with different hardware configurations that verifies the empirical practicability of cold boot attacks against DDR1 and DDR2”
Cryo-Mechanical RAM Content Extraction Against Modern Embedded Systems
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-1384: Improper Handling of Physical or Environmental Conditions
“Hardware products are typically only guaranteed to behave correctly within certain physical limits or environmental conditions. Such products cannot necessarily control the physical or external conditions to which they are subjected. However, the inability to handle such conditions can undermine a product’s security. For example, an unexpected physical or environmental condition may cause the flipping of a bit that is used for an authentication decision. This unexpected condition could occur naturally or be induced artificially by an adversary.”
If a threat actor can physically access a RAM chip, they may be able to readout the contents of the chip. Multiple techniques can be used to extract the contents of RAM, including both runtime and physical access, such as the threat actor can use a Cold-boot attack to physically cool the RAM to minimize the decay of the electrical charge and then physically copy the contents of that RAM
Through these methods, critical data, including firmware or secrets (such as passwords and cryptographic keys), may therefore be vulnerable to extraction. Extraction of this information could then lead to reverse engineering to identify vulnerabilities, abusing secrets to gain unauthorized access, or subverting at-rest encryption schemes.
Proof of Concept
Cold Boot Attacks
“We provide an independent study based on 12 computer systems with different hardware configurations that verifies the empirical practicability of cold boot attacks against DDR1 and DDR2”
Cryo-Mechanical RAM Content Extraction Against Modern Embedded Systems
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-1384: Improper Handling of Physical or Environmental Conditions
“Hardware products are typically only guaranteed to behave correctly within certain physical limits or environmental conditions. Such products cannot necessarily control the physical or external conditions to which they are subjected. However, the inability to handle such conditions can undermine a product’s security. For example, an unexpected physical or environmental condition may cause the flipping of a bit that is used for an authentication decision. This unexpected condition could occur naturally or be induced artificially by an adversary.”
If a device uses certain types of vulnerable dynamic random access memory (DRAM), a threat actor with malicious software installed on the device may be manipulate the contents of memory by repeatedly accessing physically nearby memory cells.
An example of this is Rowhammer, where a threat actor can deploy code (including written in JavaScript loaded from a web site) that performs many repeated memory access attempts. This repeated access causes a leakage of electric charge within memory, leading to a manipulation of the charge of nearby memory locations. This charge manipulation results in a manipulation of the contents of memory itself. By manipulating the contents of memory, the threat actor may be able to escalate privileges on a device or otherwise bypass security controls.
Proof of Concept
RowHammer
In 2014 and thereafter, researchers demonstrated the ability to corrupt data in nearby DDR3 and DDR4 DRAM rows by repeatedly accessing data from the same row. It is possible to turn this phenomenon into exploits through various means.
CWE-1256: Improper Restriction of Software Interfaces to Hardware Interfaces
“The product provides software-controllable device functionality for capabilities such as power and clock management, but it does not properly limit functionality that can lead to modification of hardware memory or register bits, or the ability to observe physical side channels.”
If a device uses certain types of vulnerable dynamic random access memory (DRAM), a threat actor with malicious software installed on the device may be manipulate the contents of memory by repeatedly accessing physically nearby memory cells.
An example of this is Rowhammer, where a threat actor can deploy code (including written in JavaScript loaded from a web site) that performs many repeated memory access attempts. This repeated access causes a leakage of electric charge within memory, leading to a manipulation of the charge of nearby memory locations. This charge manipulation results in a manipulation of the contents of memory itself. By manipulating the contents of memory, the threat actor may be able to escalate privileges on a device or otherwise bypass security controls.
Proof of Concept
RowHammer
In 2014 and thereafter, researchers demonstrated the ability to corrupt data in nearby DDR3 and DDR4 DRAM rows by repeatedly accessing data from the same row. It is possible to turn this phenomenon into exploits through various means.
CWE-1256: Improper Restriction of Software Interfaces to Hardware Interfaces
“The product provides software-controllable device functionality for capabilities such as power and clock management, but it does not properly limit functionality that can lead to modification of hardware memory or register bits, or the ability to observe physical side channels.”
An untrusted storage peripheral (e.g., USB) could be installed on the device. If malicious code is executed from the untrusted storage, or transferred to the device, it could provide a way for a threat actor to get unauthorized code to execute on the device. Further, any files transferred from the untrusted storage could potentially be used to modify critical device configurations or settings files.
Proof of Concept
BadUSB
“The malware they created, called BadUSB, can be installed on a USB device to completely take over a PC, invisibly alter files installed from the memory stick, or even redirect the user’s internet traffic. …Because BadUSB resides not in the flash memory storage of USB devices, but in the firmware that controls their basic functions, the attack code can remain hidden long after the contents of the device’s memory would appear to the average user to be deleted.”
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface (Base)
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
An untrusted storage peripheral (e.g., USB) could be installed on the device. If malicious code is executed from the untrusted storage, or transferred to the device, it could provide a way for a threat actor to get unauthorized code to execute on the device. Further, any files transferred from the untrusted storage could potentially be used to modify critical device configurations or settings files.
Proof of Concept
BadUSB
“The malware they created, called BadUSB, can be installed on a USB device to completely take over a PC, invisibly alter files installed from the memory stick, or even redirect the user’s internet traffic. …Because BadUSB resides not in the flash memory storage of USB devices, but in the firmware that controls their basic functions, the attack code can remain hidden long after the contents of the device’s memory would appear to the average user to be deleted.”
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface (Base)
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
A threat actor could manipulate the firmware associated with a peripheral prior to it being loaded and executed. The attackers may be able to manipulate actions on the device by sending it commands that were not the original intention of the user or by manipulating a bitstream before it is loaded, There are multiple possible cases where this could occur, including:
Case 1: Peripheral firmware is stored in a dedicated ROM/NVRAM chip. An adversary with physical access to the device might alter the contents of the peripheral firmware storage to alter peripheral behavior.
Case 2: Peripheral firmware stored as a file in the parent processor’s context. An adversary able to execute code in the parent processor context could replace or alter the firmware image before it is loaded into the peripheral during bootup or other initialization process.
Case 3: The parent processor’s context has privileged access to peripherals and malicious code running there could alter peripheral firmware dynamically (e.g., through shared memory).
Observed Adversary Behavior
EQUATION GROUP: QUESTIONS AND ANSWERS
“Although the implementation of their malware systems is incredibly complex, surpassing even Regin in sophistication, there is one aspect of the EQUATION group’s attack technologies that exceeds anything we have ever seen before. This is the ability to infect the hard drive firmware… The plugin supports two main functions: reprogramming the HDD firmware with a custom payload from the EQUATION group, and providing an API into a set of hidden sectors (or data storage) of the hard drive. This achieves several important things:
Proof of Concept
PERILOUS PERIPHERALS: THE HIDDEN DANGERS INSIDE WINDOWS & LINUX COMPUTERS
“In new research, Eclypsium found unsigned firmware in WiFi adapters, USB hubs, trackpads, and cameras used in computers from Lenovo, Dell, HP and other major manufacturers. We then demonstrated a successful attack on a server via a network interface card with unsigned firmware used by each of the big three server manufacturers.”
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface (Base)
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
CWE-1316: Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges (Base)
“The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.”
A threat actor could manipulate the firmware associated with a peripheral prior to it being loaded and executed. The attackers may be able to manipulate actions on the device by sending it commands that were not the original intention of the user or by manipulating a bitstream before it is loaded, There are multiple possible cases where this could occur, including:
Case 1: Peripheral firmware is stored in a dedicated ROM/NVRAM chip. An adversary with physical access to the device might alter the contents of the peripheral firmware storage to alter peripheral behavior.
Case 2: Peripheral firmware stored as a file in the parent processor’s context. An adversary able to execute code in the parent processor context could replace or alter the firmware image before it is loaded into the peripheral during bootup or other initialization process.
Case 3: The parent processor’s context has privileged access to peripherals and malicious code running there could alter peripheral firmware dynamically (e.g., through shared memory).
Observed Adversary Behavior
EQUATION GROUP: QUESTIONS AND ANSWERS
“Although the implementation of their malware systems is incredibly complex, surpassing even Regin in sophistication, there is one aspect of the EQUATION group’s attack technologies that exceeds anything we have ever seen before. This is the ability to infect the hard drive firmware… The plugin supports two main functions: reprogramming the HDD firmware with a custom payload from the EQUATION group, and providing an API into a set of hidden sectors (or data storage) of the hard drive. This achieves several important things:
Proof of Concept
PERILOUS PERIPHERALS: THE HIDDEN DANGERS INSIDE WINDOWS & LINUX COMPUTERS
“In new research, Eclypsium found unsigned firmware in WiFi adapters, USB hubs, trackpads, and cameras used in computers from Lenovo, Dell, HP and other major manufacturers. We then demonstrated a successful attack on a server via a network interface card with unsigned firmware used by each of the big three server manufacturers.”
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface (Base)
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
CWE-1316: Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges (Base)
“The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.”
Messages and data passing between discrete sub-components and peripherals may be intercepted and/or modified from through the peripheral bus (e.g., SPI, I2C, ISA, PCI, USB). Captured data may leak sensitive information (e.g., keys, cleartext firmware code) that can aid in reverse engineering and extracting data needed for other stages of an attack. Additionally, threat actors may be able to alter sensitive information in transit to cause malicious effects through data manipulation or interaction in transit over the bus.
NOTE: This is different from TID-106 in that this threat refers to the data moving between the main board or processing chip to a peripheral device, whereas TID-106 refers to data moving between the processor and storage devices.
Proof of Concept
Toward a hardware man-in-the-middle attack on PCIe bus
“In this paper, we present a new attack vector on PCIe based on a hardware Man-in-the-Middle. This system allows real-time data analysis, data-replay, and a copy technique inspired by the shadow-copy principle. Through this one, it is possible to locate, duplicate, and replay sensitive data.”
Critical Architectural Vulnerabilities in Siemens SIMATIC S7-1500 Series Allow for Bypass of All Protected Boot Features
“An attacker with physical access to the device can either attach to the I2C communication bus or extract the physical ATECC chip from the PLC’s PCB to falsely authenticate and use it as an oracle to generate firmware decryption material. “
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-319: Cleartext Transmission of Sensitive Information
“The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.”
Messages and data passing between discrete sub-components and peripherals may be intercepted and/or modified from through the peripheral bus (e.g., SPI, I2C, ISA, PCI, USB). Captured data may leak sensitive information (e.g., keys, cleartext firmware code) that can aid in reverse engineering and extracting data needed for other stages of an attack. Additionally, threat actors may be able to alter sensitive information in transit to cause malicious effects through data manipulation or interaction in transit over the bus.
NOTE: This is different from TID-106 in that this threat refers to the data moving between the main board or processing chip to a peripheral device, whereas TID-106 refers to data moving between the processor and storage devices.
Proof of Concept
Toward a hardware man-in-the-middle attack on PCIe bus
“In this paper, we present a new attack vector on PCIe based on a hardware Man-in-the-Middle. This system allows real-time data analysis, data-replay, and a copy technique inspired by the shadow-copy principle. Through this one, it is possible to locate, duplicate, and replay sensitive data.”
Critical Architectural Vulnerabilities in Siemens SIMATIC S7-1500 Series Allow for Bypass of All Protected Boot Features
“An attacker with physical access to the device can either attach to the I2C communication bus or extract the physical ATECC chip from the PLC’s PCB to falsely authenticate and use it as an oracle to generate firmware decryption material. “
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
CWE-319: Cleartext Transmission of Sensitive Information
“The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.”
Unprotected programming or debugging interfaces may be used to extract device firmware, exposing it to reverse engineering that may reveal proprietary information, other exploitable vulnerabilities, or security-sensitive data stored in the firmware (such as keys and passwords). Examples include the Joint Test Action Group (JTAG) interface.
Proof of Concept
Extracting firmware from devices using JTAG
Researcher Sergio Prado demonstrates in this article how to use the JTAG interface to extract firmware from a device.
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
CWE-1191: On-Chip Debug and Test Interface With Improper Access Control
“The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.”
Unprotected programming or debugging interfaces may be used to extract device firmware, exposing it to reverse engineering that may reveal proprietary information, other exploitable vulnerabilities, or security-sensitive data stored in the firmware (such as keys and passwords). Examples include the Joint Test Action Group (JTAG) interface.
Proof of Concept
Extracting firmware from devices using JTAG
Researcher Sergio Prado demonstrates in this article how to use the JTAG interface to extract firmware from a device.
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
CWE-1191: On-Chip Debug and Test Interface With Improper Access Control
“The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.”
If a device has a latent user access port, it may be possible for attackers to leverage physical access to obtain privileges that were not accounted for when considering software or remote access controls.
Proof of Concept
How to Hack Hardware using UART - Black Hills
Researchers from Black Hills demonstrate how to gain root access to a device through shell access granted and transmitted over UART.
IoT Devices - The Not-So-Hidden Risk of UART Interface
Satish S demonstrates how to gain root access to a device over a UART interface.
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
CWE-1191: On-Chip Debug and Test Interface With Improper Access Control
“The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.”
CVE-2022-29402
“TP-Link TL-WR840N EU v6.20 was discovered to contain insecure protections for its UART console. This vulnerability allows attackers to connect to the UART port via a serial connection and execute commands as the root user without authentication.”
If a device has a latent user access port, it may be possible for attackers to leverage physical access to obtain privileges that were not accounted for when considering software or remote access controls.
Proof of Concept
How to Hack Hardware using UART - Black Hills
Researchers from Black Hills demonstrate how to gain root access to a device through shell access granted and transmitted over UART.
IoT Devices - The Not-So-Hidden Risk of UART Interface
Satish S demonstrates how to gain root access to a device over a UART interface.
CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface
“The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.”
CWE-1191: On-Chip Debug and Test Interface With Improper Access Control
“The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.”
CVE-2022-29402
“TP-Link TL-WR840N EU v6.20 was discovered to contain insecure protections for its UART console. This vulnerability allows attackers to connect to the UART port via a serial connection and execute commands as the root user without authentication.”
If a threat actor has physical access to a device, they may be able to cause physical damage to the circuit board of a device, in some cases even destroying the device. A malicious actor may short circuit or introduce out-of-spec voltages and currents to pins on external connectors. This can lead to effects as mild as interrupting device functionality, by causing crashes or reboots, or as significant as corrupting data, corrupting firmware, or permanent hardware damage. Depending on how robust the hardware design is, physical damage may be limited to a single affected peripheral port or as extensive as destroying the entire device.
Known Exploitable Weakness
USBKILL
“The USBKill is a device that stress tests hardware. When plugged in power is taken from a USB-Port, multiplied, and discharged into the data-lines, typically disabling an unprotected device.”
CWE-1384: Improper Handling of Physical or Environmental Conditions
“The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.”
If a threat actor has physical access to a device, they may be able to cause physical damage to the circuit board of a device, in some cases even destroying the device. A malicious actor may short circuit or introduce out-of-spec voltages and currents to pins on external connectors. This can lead to effects as mild as interrupting device functionality, by causing crashes or reboots, or as significant as corrupting data, corrupting firmware, or permanent hardware damage. Depending on how robust the hardware design is, physical damage may be limited to a single affected peripheral port or as extensive as destroying the entire device.
Known Exploitable Weakness
USBKILL
“The USBKill is a device that stress tests hardware. When plugged in power is taken from a USB-Port, multiplied, and discharged into the data-lines, typically disabling an unprotected device.”
CWE-1384: Improper Handling of Physical or Environmental Conditions
“The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.”
Hardware debugging ports (e.g., JTAG) oftentimes have high privileges or direct access to the running device’s memory and integrated hardware. By leveraging one of these hardware debugging ports, an adversary may be able to read memory values off of the device, change the value of a section of memory during runtime, or control the execution of code on the processor. This can give threat actors increased privileges on the device or bypass other security protections.
Proof of Concept
hw-101-jtag (Parts 1, 2 and 3)
Researchers at River Loop Security demonstrate here how to manipulate and read memory from a JTAG port.
CWE-1191: On-Chip Debug and Test Interface With Improper Access Control
“The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.”
Hardware debugging ports (e.g., JTAG) oftentimes have high privileges or direct access to the running device’s memory and integrated hardware. By leveraging one of these hardware debugging ports, an adversary may be able to read memory values off of the device, change the value of a section of memory during runtime, or control the execution of code on the processor. This can give threat actors increased privileges on the device or bypass other security protections.
Proof of Concept
hw-101-jtag (Parts 1, 2 and 3)
Researchers at River Loop Security demonstrate here how to manipulate and read memory from a JTAG port.
CWE-1191: On-Chip Debug and Test Interface With Improper Access Control
“The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.”
Some devices utilize bootloaders that are either stored in writable memory or memory that can be made writable. It may then be possible for a threat actor to alter the contents of the device’s designated boot code storage locations to inject malicious code or modify the bootloader’s operation. This could allow the installation of a “bootkit”, which is loaded before the operating system and can undermine any security protections within the bootloader or operating system. Typically this is done through a vulnerability or lack of write protections in the bootloader loader/runtime environment.
Observed Adversarial Behavior
ATT&CK Technique: Pre-OS Boot: Bootkit (T1542.003)
“Adversaries may use bootkits to persist on systems. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.”
Detecting UEFI Bootkits in the Wild (Part 1)
“As UEFI boot systems are going mainstream, the bootkits are also shifting to an implementation of infecting firmware in a flash chip on the motherboard instead of the MBR/VBR on the hard drive. The first PoC of UEFI bootkits was presented in 2013 and the threats have been observed in the wild since 2018.”
LOJAX First UEFI rootkit found in the wild, courtesy of the Sednit group
“Sednit also known as APT28, Sofacy, Strontium and Fancy Bear – has been operating since at least 2004, and has made headlines frequently in the past years: it is believed to be behind major, high profile attacks. … this white paper details the first time this group is known to have used a UEFI rootkit.”
MosaicRegressor: Lurking in the Shadows of UEFI
“During an investigation, we came across several suspicious UEFI firmware images. A deeper inspection revealed that they contained four components that had an unusual proximity in their assigned GUID values, those were two DXE drivers and two UEFI applications. After further analysis we were able to determine that they were based on the leaked source code of HackingTeam’s VectorEDK bootkit, with minor customizations.”
TRICKBOT NOW OFFERS ‘TRICKBOOT’: PERSIST, BRICK, PROFIT
“This new functionality, which we have dubbed “TrickBoot,” makes use of readily available tools to check devices for well-known vulnerabilities that can allow attackers to read, write, or erase the UEFI/ BIOS firmware of a device. “
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
CWE-284: Improper Access Control
“The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.”
Some devices utilize bootloaders that are either stored in writable memory or memory that can be made writable. It may then be possible for a threat actor to alter the contents of the device’s designated boot code storage locations to inject malicious code or modify the bootloader’s operation. This could allow the installation of a “bootkit”, which is loaded before the operating system and can undermine any security protections within the bootloader or operating system. Typically this is done through a vulnerability or lack of write protections in the bootloader loader/runtime environment.
Observed Adversarial Behavior
ATT&CK Technique: Pre-OS Boot: Bootkit (T1542.003)
“Adversaries may use bootkits to persist on systems. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.”
Detecting UEFI Bootkits in the Wild (Part 1)
“As UEFI boot systems are going mainstream, the bootkits are also shifting to an implementation of infecting firmware in a flash chip on the motherboard instead of the MBR/VBR on the hard drive. The first PoC of UEFI bootkits was presented in 2013 and the threats have been observed in the wild since 2018.”
LOJAX First UEFI rootkit found in the wild, courtesy of the Sednit group
“Sednit also known as APT28, Sofacy, Strontium and Fancy Bear – has been operating since at least 2004, and has made headlines frequently in the past years: it is believed to be behind major, high profile attacks. … this white paper details the first time this group is known to have used a UEFI rootkit.”
MosaicRegressor: Lurking in the Shadows of UEFI
“During an investigation, we came across several suspicious UEFI firmware images. A deeper inspection revealed that they contained four components that had an unusual proximity in their assigned GUID values, those were two DXE drivers and two UEFI applications. After further analysis we were able to determine that they were based on the leaked source code of HackingTeam’s VectorEDK bootkit, with minor customizations.”
TRICKBOT NOW OFFERS ‘TRICKBOOT’: PERSIST, BRICK, PROFIT
“This new functionality, which we have dubbed “TrickBoot,” makes use of readily available tools to check devices for well-known vulnerabilities that can allow attackers to read, write, or erase the UEFI/ BIOS firmware of a device. “
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
CWE-284: Improper Access Control
“The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.”
Devices may have vulnerabilities within software used to parse various network protocols. If the device does not properly parse a protocol, a threat actor can send improperly formatted messages to the device, which may result in memory corruptions. Vulnerabilities resulting from protocol manipulation can then be used to perform remote code execution or to perform a denial of service attack on the device. There are a number of known complexities with network protocol parsing, including unclear protocol specifications or parsing expectation.
Known Exploitable Weakness
Broadpwn: Remotely Compromising Android and iOS via a Bug in Broadcom’s Wi-Fi Chipsets
“Broadpwn is a fully remote attack against Broadcom’s BCM43xx family of WiFi chipsets, which allows for code execution on the main application processor in both Android and iOS. It is based on an unusually powerful 0-day that allowed us to leverage it into a reliable, fully remote exploit.”
Ripple20
“Ripple20 vulnerabilities are unique both in their widespread effect and impact due to supply chain effect and being vulnerabilities allowing attackers to bypass NAT and firewalls and take control of devices undetected, with no user interaction required. This is due to the vulnerabilities being in a low level TCP/IP stack, and the fact that for many of the vulnerabilities, the packets sent are very similar to valid packets, or, in some cases are completely valid packets. This enables the attack to pass as legitimate traffic.”
Urgent/11
“The Armis research team, Armis Labs, has discovered 11 zero-day vulnerabilities in VxWorks®, the most widely used operating system you may have never heard about. VxWorks is used by over 2 billion devices including critical industrial, medical and enterprise devices. Dubbed “URGENT/11,” the vulnerabilities reside in VxWorks’ TCP/IP stack (IPnet), impacting all versions since version 6.5, and are a rare example of vulnerabilities found to affect the operating system over the last 13 years. Armis has worked closely with Wind River®, the maintainer of VxWorks, and the latest VxWorks 7 released on July 19 contains fixes for all the discovered vulnerabilities.”
AMNESIA:33
“In this study, we discuss the results of the security analysis of seven open source TCP/IP stacks and report a bundle of 33 new vulnerabilities found in four of the seven analyzed stacks that are used by major IoT, OT and IT device vendors”
CWE-20: Improper Input Validation (Class)
“The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.”
CWE-121: Stack-based Buffer Overflow (Simple)
“A stack-based buffer overflow condition is a condition on where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).”
ICSA-13-291-01B
“An attacker could cause the software to go into an infinite loop with a specifically crafted TCP packet, causing the process to crash. The system must be restarted manually to clear the condition.”
CVE-2013-2811: GE Proficy HMI/SCADA DNP3 Driver Input Validation
“The DNP master station server (DNPDrv.exe) that processes incoming messages via Serial, IP, or Modem does not validate all inputs and can be exploited to generate an unhandled exception or denial of service.”
CVE-2019-6529: Kunbus PR100088 Modbus Gateway
“An attacker could specially craft an FTP request that could crash the device.”
CVE-2013-0662: Schneider Electric Serial Modbus Driver Buffer Overflow
“The Modbus Serial Driver creates a listener on Port 27700/TCP. When a connection is made, the Modbus Application Header is first read into a buffer. If a large buffer size is specified in this header, a stack-based buffer overflow results. A second overflow problem can then be exploited by overwriting the return address, allowing the attacker to execute arbitrary code with the permission of the user running the software.”
Devices may have vulnerabilities within software used to parse various network protocols. If the device does not properly parse a protocol, a threat actor can send improperly formatted messages to the device, which may result in memory corruptions. Vulnerabilities resulting from protocol manipulation can then be used to perform remote code execution or to perform a denial of service attack on the device. There are a number of known complexities with network protocol parsing, including unclear protocol specifications or parsing expectation.
Known Exploitable Weakness
Broadpwn: Remotely Compromising Android and iOS via a Bug in Broadcom’s Wi-Fi Chipsets
“Broadpwn is a fully remote attack against Broadcom’s BCM43xx family of WiFi chipsets, which allows for code execution on the main application processor in both Android and iOS. It is based on an unusually powerful 0-day that allowed us to leverage it into a reliable, fully remote exploit.”
Ripple20
“Ripple20 vulnerabilities are unique both in their widespread effect and impact due to supply chain effect and being vulnerabilities allowing attackers to bypass NAT and firewalls and take control of devices undetected, with no user interaction required. This is due to the vulnerabilities being in a low level TCP/IP stack, and the fact that for many of the vulnerabilities, the packets sent are very similar to valid packets, or, in some cases are completely valid packets. This enables the attack to pass as legitimate traffic.”
Urgent/11
“The Armis research team, Armis Labs, has discovered 11 zero-day vulnerabilities in VxWorks®, the most widely used operating system you may have never heard about. VxWorks is used by over 2 billion devices including critical industrial, medical and enterprise devices. Dubbed “URGENT/11,” the vulnerabilities reside in VxWorks’ TCP/IP stack (IPnet), impacting all versions since version 6.5, and are a rare example of vulnerabilities found to affect the operating system over the last 13 years. Armis has worked closely with Wind River®, the maintainer of VxWorks, and the latest VxWorks 7 released on July 19 contains fixes for all the discovered vulnerabilities.”
AMNESIA:33
“In this study, we discuss the results of the security analysis of seven open source TCP/IP stacks and report a bundle of 33 new vulnerabilities found in four of the seven analyzed stacks that are used by major IoT, OT and IT device vendors”
CWE-20: Improper Input Validation (Class)
“The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.”
CWE-121: Stack-based Buffer Overflow (Simple)
“A stack-based buffer overflow condition is a condition on where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).”
ICSA-13-291-01B
“An attacker could cause the software to go into an infinite loop with a specifically crafted TCP packet, causing the process to crash. The system must be restarted manually to clear the condition.”
CVE-2013-2811: GE Proficy HMI/SCADA DNP3 Driver Input Validation
“The DNP master station server (DNPDrv.exe) that processes incoming messages via Serial, IP, or Modem does not validate all inputs and can be exploited to generate an unhandled exception or denial of service.”
CVE-2019-6529: Kunbus PR100088 Modbus Gateway
“An attacker could specially craft an FTP request that could crash the device.”
CVE-2013-0662: Schneider Electric Serial Modbus Driver Buffer Overflow
“The Modbus Serial Driver creates a listener on Port 27700/TCP. When a connection is made, the Modbus Application Header is first read into a buffer. If a large buffer size is specified in this header, a stack-based buffer overflow results. A second overflow problem can then be exploited by overwriting the return address, allowing the attacker to execute arbitrary code with the permission of the user running the software.”
Threat actors may be able to install a driver or kernel module with malicious code to load a rootkit and manipulate the OS. Drivers and kernel modules generally operate with a high-level privileges (e.g. Ring 0) and therefore can be used to manipulate the operation of the existing OS. OS kernel modules and drivers can typically be installed by any users with root/administrative permissions, though some OSes require that drivers be digitally signed by a trusted OEM before they can be installed on a device.
Observed Adversary Behavior
Syslogk Rootkit
“The Syslogk rootkit installed itself as a Linux kernel module where it had the ability to hook functions/syscalls, manipulate and create its own syscalls, and launch a payload that contains a backdoor at the request of remote threat actors.”
CWE-306 Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
Threat actors may be able to install a driver or kernel module with malicious code to load a rootkit and manipulate the OS. Drivers and kernel modules generally operate with a high-level privileges (e.g. Ring 0) and therefore can be used to manipulate the operation of the existing OS. OS kernel modules and drivers can typically be installed by any users with root/administrative permissions, though some OSes require that drivers be digitally signed by a trusted OEM before they can be installed on a device.
Observed Adversary Behavior
Syslogk Rootkit
“The Syslogk rootkit installed itself as a Linux kernel module where it had the ability to hook functions/syscalls, manipulate and create its own syscalls, and launch a payload that contains a backdoor at the request of remote threat actors.”
CWE-306 Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
Without a correctly enforced operating system privilege model, a compromised or untrusted application program could access to data, memory, or programs associated with the underlying OS or other applications. This could also be used to further manipulate the underlying OS.
Proof of Concept
Security Issues In Compiled PLC Logic (CoDeSys & ProConOs) - Reid Wightman (Dragos) (at S4x23)
Researcher Reid Wightman demonstrated that it is possible to compromise a given feature of a controller, in this example the network protocol handler, and leverage that to overwrite memory in other critical portions of the CoDeSys and ProConOs runtime environments.
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
Without a correctly enforced operating system privilege model, a compromised or untrusted application program could access to data, memory, or programs associated with the underlying OS or other applications. This could also be used to further manipulate the underlying OS.
Proof of Concept
Security Issues In Compiled PLC Logic (CoDeSys & ProConOs) - Reid Wightman (Dragos) (at S4x23)
Researcher Reid Wightman demonstrated that it is possible to compromise a given feature of a controller, in this example the network protocol handler, and leverage that to overwrite memory in other critical portions of the CoDeSys and ProConOs runtime environments.
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
If a threat actor has access to a valid OS account, they can utilize existing OS tools and system calls to install malicious code or manipulate device operations. If the account and privileges are not sufficiently restricted, the threat actor may be able to add their own tools, modify other application layer programs, or even execute commands with elevated privileges (e.g., setuid/setgid). Further, threat actors can perform a living-off-the-land attack, where they choose to only use pre-installed functionality and install nothing else on the device. These types of attacks can be hard to detect because malicious behavior may be implemented using tools and functions with legitimate purposes.
Observed Adversarial Behavior
ATT&CK Technique: Graphical User Interface (T0823)
Procedure Example: 2015 Ukraine Electric Power Attack (C0028)
“During the 2015 Ukraine Electric Power Attack, Sandworm Team utilized HMI GUIs in the SCADA environment to open breakers.”
Volt Typhoon targets US critical infrastructure with living-off-the-land techniques
“To achieve their objective, the threat actor puts strong emphasis on stealth in this campaign, relying almost exclusively on living-off-the-land techniques and hands-on-keyboard activity. “
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
If a threat actor has access to a valid OS account, they can utilize existing OS tools and system calls to install malicious code or manipulate device operations. If the account and privileges are not sufficiently restricted, the threat actor may be able to add their own tools, modify other application layer programs, or even execute commands with elevated privileges (e.g., setuid/setgid). Further, threat actors can perform a living-off-the-land attack, where they choose to only use pre-installed functionality and install nothing else on the device. These types of attacks can be hard to detect because malicious behavior may be implemented using tools and functions with legitimate purposes.
Observed Adversarial Behavior
ATT&CK Technique: Graphical User Interface (T0823)
Procedure Example: 2015 Ukraine Electric Power Attack (C0028)
“During the 2015 Ukraine Electric Power Attack, Sandworm Team utilized HMI GUIs in the SCADA environment to open breakers.”
Volt Typhoon targets US critical infrastructure with living-off-the-land techniques
“To achieve their objective, the threat actor puts strong emphasis on stealth in this campaign, relying almost exclusively on living-off-the-land techniques and hands-on-keyboard activity. “
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
While the use of memory permissions, such as non-executable stack and heap memory, can prevent threat actors from injecting and executing malicious code, it is still possible to leverage a process’s existing code to perform a malicious function. For example, Return Oriented Programming (ROP) is a technique used by threat actors where once a process’s stack can be overwritten, a series of “returns” to portions of code within the process can be leveraged to cause an intended malicious function. This can include “returns” to existing libraries (e.g., libc), or other instruction sequences already in memory of that process.
The exploitation of this threat may be possible through TID-219, and may also be enabled by the exploitation of TID-219.
Known Exploitable Weakness
ATT&CK Technique: Process Injection: Proc Memory (T1055.09)
“Proc memory injection involves enumerating the memory of a process via the /proc filesystem (/proc/[pid]) then crafting a return-oriented programming (ROP) payload with available gadgets/instructions.”
CVE-2024-28115
“FreeRTOS is a real-time operating system for microcontrollers. FreeRTOS Kernel versions through 10.6.1 do not sufficiently protect against local privilege escalation via Return Oriented Programming techniques should a vulnerability exist that allows code injection and execution. These issues affect ARMv7-M MPU ports, and ARMv8-M ports with Memory Protected Unit (MPU) support enabled (i.e. configENABLE_MPU
set to 1). These issues are fixed in version 10.6.2 with a new MPU wrapper.”
While the use of memory permissions, such as non-executable stack and heap memory, can prevent threat actors from injecting and executing malicious code, it is still possible to leverage a process’s existing code to perform a malicious function. For example, Return Oriented Programming (ROP) is a technique used by threat actors where once a process’s stack can be overwritten, a series of “returns” to portions of code within the process can be leveraged to cause an intended malicious function. This can include “returns” to existing libraries (e.g., libc), or other instruction sequences already in memory of that process.
The exploitation of this threat may be possible through TID-219, and may also be enabled by the exploitation of TID-219.
Known Exploitable Weakness
ATT&CK Technique: Process Injection: Proc Memory (T1055.09)
“Proc memory injection involves enumerating the memory of a process via the /proc filesystem (/proc/[pid]) then crafting a return-oriented programming (ROP) payload with available gadgets/instructions.”
CVE-2024-28115
“FreeRTOS is a real-time operating system for microcontrollers. FreeRTOS Kernel versions through 10.6.1 do not sufficiently protect against local privilege escalation via Return Oriented Programming techniques should a vulnerability exist that allows code injection and execution. These issues affect ARMv7-M MPU ports, and ARMv8-M ports with Memory Protected Unit (MPU) support enabled (i.e. configENABLE_MPU
set to 1). These issues are fixed in version 10.6.2 with a new MPU wrapper.”
Container environments, such as Docker and Kubernetes, share the same underlying kernel as the host operating system. Therefore, a kernel or container vulnerability that allows the execution of unauthorized code could be used to escape the container. Further, container environments with incorrect configurations or excessive privileges could also allow a container escape. By escaping the container, the threat actor could manipulate the underlying OS or applications/data within other containers hosted on that device.
Known Exploitable Weakness
ATT&CK Technique: Escape to Host (T1611)
“Adversaries may break out of a container to gain access to the underlying host. This can allow an adversary access to other containerized resources from the host level or to the host itself. In principle, containerized resources should provide a clear separation of application functionality and be isolated from the host environment.”
Proof of Concept
Breaking out of Docker via runC – Explaining CVE-2019-5736
“A vulnerability in runc allows a malicious container to overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command… as root within a container in two possible contexts.”
Crowdstrike: CVE-2022-0185: Kubernetes Container Escape Using Linux Kernel Exploit
“On Jan. 18, 2022, researchers found a heap base buffer overflow flaw (CVE-2022-0185) in the Linux kernel (5.1-rc1+) function “legacy_parse_param” of filesystem context functionality, which allows an out-of-bounds write in kernel memory. Using this primitive, an unprivileged attacker can escalate its privilege to root, bypassing any Linux namespace restrictions.” Threat actors can then leverage this namespace restriction bypass and root level privilege to break out of the Kubernetes container.
CVE-2019-5736
“runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.”
CVE-2022-0185
“A heap-based buffer overflow flaw was found in the way the legacy_parse_param function in the Filesystem Context functionality of the Linux kernel verified the supplied parameters length. An unprivileged (in case of unprivileged user namespaces enabled, otherwise needs namespace CAP_SYS_ADMIN privilege) local user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to legacy handling) could use this flaw to escalate their privileges on the system.”
Container environments, such as Docker and Kubernetes, share the same underlying kernel as the host operating system. Therefore, a kernel or container vulnerability that allows the execution of unauthorized code could be used to escape the container. Further, container environments with incorrect configurations or excessive privileges could also allow a container escape. By escaping the container, the threat actor could manipulate the underlying OS or applications/data within other containers hosted on that device.
Known Exploitable Weakness
ATT&CK Technique: Escape to Host (T1611)
“Adversaries may break out of a container to gain access to the underlying host. This can allow an adversary access to other containerized resources from the host level or to the host itself. In principle, containerized resources should provide a clear separation of application functionality and be isolated from the host environment.”
Proof of Concept
Breaking out of Docker via runC – Explaining CVE-2019-5736
“A vulnerability in runc allows a malicious container to overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command… as root within a container in two possible contexts.”
Crowdstrike: CVE-2022-0185: Kubernetes Container Escape Using Linux Kernel Exploit
“On Jan. 18, 2022, researchers found a heap base buffer overflow flaw (CVE-2022-0185) in the Linux kernel (5.1-rc1+) function “legacy_parse_param” of filesystem context functionality, which allows an out-of-bounds write in kernel memory. Using this primitive, an unprivileged attacker can escalate its privilege to root, bypassing any Linux namespace restrictions.” Threat actors can then leverage this namespace restriction bypass and root level privilege to break out of the Kubernetes container.
CVE-2019-5736
“runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.”
CVE-2022-0185
“A heap-based buffer overflow flaw was found in the way the legacy_parse_param function in the Filesystem Context functionality of the Linux kernel verified the supplied parameters length. An unprivileged (in case of unprivileged user namespaces enabled, otherwise needs namespace CAP_SYS_ADMIN privilege) local user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to legacy handling) could use this flaw to escalate their privileges on the system.”
Virtualized environments will oftentimes share the same underlying hardware as the hypervisor. A hypervisor or virtualized environment vulnerability that allows the execution of unauthorized code could be used to escape the virtualized environments. By escaping the environment, a threat actor could manipulate the underlying hypervisor, operating system, or application/data within other environments hosted on that device.
Known Exploitable Weakness
VMWare Security Advisory (VMSA-2024-0006.1)
“A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine’s VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.” “A malicious actor with privileges within the VMX process may trigger an out-of-bounds write leading to an escape of the sandbox.”
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
Implementing Hypervisor-Specific Mitigations for Microarchitectural Data Sampling (MDS) Vulnerabilities (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091) in vSphere (67577)
“Intel has disclosed details on a new wave of speculative-execution vulnerabilities known collectively as “Microarchitectural Data Sampling (MDS)” that can occur on Intel microarchitecture prior to 2nd Generation Intel® Xeon® Scalable Processors (formerly known as Cascade Lake). These issues may allow a malicious user who can locally execute code on a system to infer the values of data otherwise protected by architectural mechanisms.”
Patch now! VMWare escape flaws are so serious even end-of-life software gets a fix
VMware ESXi, Workstation, and Fusion updates address multiple security vulnerabilities (CVE-2024-22252, CVE-2024-22253, CVE-2024-22254, CVE-2024-22255)
“VMWare’s decision to offer fixes for end-of-life software is because the vulnerabilities patched in these updates are escape flaws that allow a computer program to breack of the confines of a VM and affect the host operating system. Specifically, an attacker with privileged access, such as root or administrator, on a guest VM can access the hypervisor on the host.”
Virtualized environments will oftentimes share the same underlying hardware as the hypervisor. A hypervisor or virtualized environment vulnerability that allows the execution of unauthorized code could be used to escape the virtualized environments. By escaping the environment, a threat actor could manipulate the underlying hypervisor, operating system, or application/data within other environments hosted on that device.
Known Exploitable Weakness
VMWare Security Advisory (VMSA-2024-0006.1)
“A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine’s VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox whereas, on Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.” “A malicious actor with privileges within the VMX process may trigger an out-of-bounds write leading to an escape of the sandbox.”
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
Implementing Hypervisor-Specific Mitigations for Microarchitectural Data Sampling (MDS) Vulnerabilities (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091) in vSphere (67577)
“Intel has disclosed details on a new wave of speculative-execution vulnerabilities known collectively as “Microarchitectural Data Sampling (MDS)” that can occur on Intel microarchitecture prior to 2nd Generation Intel® Xeon® Scalable Processors (formerly known as Cascade Lake). These issues may allow a malicious user who can locally execute code on a system to infer the values of data otherwise protected by architectural mechanisms.”
Patch now! VMWare escape flaws are so serious even end-of-life software gets a fix
VMware ESXi, Workstation, and Fusion updates address multiple security vulnerabilities (CVE-2024-22252, CVE-2024-22253, CVE-2024-22254, CVE-2024-22255)
“VMWare’s decision to offer fixes for end-of-life software is because the vulnerabilities patched in these updates are escape flaws that allow a computer program to breack of the confines of a VM and affect the host operating system. Specifically, an attacker with privileged access, such as root or administrator, on a guest VM can access the hypervisor on the host.”
If a threat actor can access a hypervisor’s host infrastructure, such as through existing management interfaces, they could use that access to manipulate associated guest/virtualized systems. Since the hypervisor runs underneath the virtual machines, this threat will go undetected by the individual guest environments.
Observed Adversary Behavior
Sandworm Disrupts Power in Ukraine Using a Novel Attack Against Operational Technology
“Sandworm gained access to the OT environment through a hypervisor that hosted a supervisory control and data acquisition (SCADA) management instance for the victim’s substation environment… On October 10, the actor leveraged an optical disc (ISO) image named “a.iso” to execute a native MicroSCADA binary in a likely attempt to execute malicious control commands to switch off substations.”
Bad VIB(E)s Mandiant Discoveries
Researchers at Mandiant discovered adversarial usage of malware that runs on VM hosting machines. The malware is able to “1) maintain persistent administrative access to the hypervisor; 2) send commands to the hypervisor that will be routed to the guest VM for execution; 3) transfer files between the ESXi hypervisor and guest machines running beneath it; 4) tamper with logging services on the hypervisor; 5) execute arbitrary commands from one guest VM to another guest VM running on the same hypervisor”
VMware ESXi Zero-Day Used by Chinese Espionage Actor to Perform Privileged Guest Operations on Compromised Hypervisors
“Exploiting a zero-day vulnerability (CVE-2023-20867) that enabled the execution of privileged commands across Windows, Linux, and PhotonOS (vCenter) guest VMs without authentication of guest credentials from a compromised ESXi host and no default logging on guest VMs”
CWE-306: Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CVE-2023-20867
“A fully compromised ESXi host can force VMware Tools to fail to authenticate host-to-guest operations, impacting the confidentiality and integrity of the guest virtual machine.”
If a threat actor can access a hypervisor’s host infrastructure, such as through existing management interfaces, they could use that access to manipulate associated guest/virtualized systems. Since the hypervisor runs underneath the virtual machines, this threat will go undetected by the individual guest environments.
Observed Adversary Behavior
Sandworm Disrupts Power in Ukraine Using a Novel Attack Against Operational Technology
“Sandworm gained access to the OT environment through a hypervisor that hosted a supervisory control and data acquisition (SCADA) management instance for the victim’s substation environment… On October 10, the actor leveraged an optical disc (ISO) image named “a.iso” to execute a native MicroSCADA binary in a likely attempt to execute malicious control commands to switch off substations.”
Bad VIB(E)s Mandiant Discoveries
Researchers at Mandiant discovered adversarial usage of malware that runs on VM hosting machines. The malware is able to “1) maintain persistent administrative access to the hypervisor; 2) send commands to the hypervisor that will be routed to the guest VM for execution; 3) transfer files between the ESXi hypervisor and guest machines running beneath it; 4) tamper with logging services on the hypervisor; 5) execute arbitrary commands from one guest VM to another guest VM running on the same hypervisor”
VMware ESXi Zero-Day Used by Chinese Espionage Actor to Perform Privileged Guest Operations on Compromised Hypervisors
“Exploiting a zero-day vulnerability (CVE-2023-20867) that enabled the execution of privileged commands across Windows, Linux, and PhotonOS (vCenter) guest VMs without authentication of guest credentials from a compromised ESXi host and no default logging on guest VMs”
CWE-306: Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CVE-2023-20867
“A fully compromised ESXi host can force VMware Tools to fail to authenticate host-to-guest operations, impacting the confidentiality and integrity of the guest virtual machine.”
Threat actors will frequently target device components, like firmware, that have already known vulnerabilities instead of expending the effort to discover new ones. If a device cannot update its firmware, especially upon the discovery of a vulnerability, threat actors may be able to target these vulnerabilities. This is because a vulnerability that is found once will be exploitable on all devices running that firmware in perpetuity. Threat actors’ ability to achieve their goals will depend on the nature of the unpatched vulnerability.
If identified threats cannot be mitigated due to the inability to disable or update vulnerable components, the device will remain vulnerable. This may also be the result of the device reaching its End-of-Service/Support date, where it is no longer being supported by the vendor.
Known Exploitable Weakness
Regarding Unit 42 New Mirai Variant Targeting Network Security Devices
Some of the IoT devices targeted by the Mirai botnet could not be patched because the device had reached the vendor stated End of Service/Support date.
CWE-1277: Firmware Not Updateable
“The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.”
CWE-1329: Reliance on Component That is Not Updateable
“The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.”
Threat actors will frequently target device components, like firmware, that have already known vulnerabilities instead of expending the effort to discover new ones. If a device cannot update its firmware, especially upon the discovery of a vulnerability, threat actors may be able to target these vulnerabilities. This is because a vulnerability that is found once will be exploitable on all devices running that firmware in perpetuity. Threat actors’ ability to achieve their goals will depend on the nature of the unpatched vulnerability.
If identified threats cannot be mitigated due to the inability to disable or update vulnerable components, the device will remain vulnerable. This may also be the result of the device reaching its End-of-Service/Support date, where it is no longer being supported by the vendor.
Known Exploitable Weakness
Regarding Unit 42 New Mirai Variant Targeting Network Security Devices
Some of the IoT devices targeted by the Mirai botnet could not be patched because the device had reached the vendor stated End of Service/Support date.
CWE-1277: Firmware Not Updateable
“The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.”
CWE-1329: Reliance on Component That is Not Updateable
“The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.”
If a device does not have a mechanism to authenticate firmware updates, a threat actor may be able to install malicious or corrupt firmware on the device. In such cases, an adversary may craft a customized or maliciously modified firmware update package that, if properly formed, the device will install it without challenge. The unauthorized firmware could then be used to (i) “brick” the device and prevent it from being reset, (ii) install malicious logic on the device, including to gain persistence, or (iii) enable access to ease reverse engineering the device to identify remotely exploitable vulnerabilities, depending on how the firmware was formed and how the target device responds to it. Devices that perform only error checking of update packages prior to installation (e.g., parity checks, hash checks without a cryptographic signature, etc.) will be susceptible to this threat.
This threat also includes any firmware authentication mechanisms that are not enforced on the device. If devices don’t check firmware integrity/download command authenticity on-device, threat actors may be able to falsely attest that their firmware is secure, thereby bypassing firmware integrity checks. One mechanism through which threat actors could perform this action is by taking advantage of a device’s reliance on a separate management device or service to check firmware. Threat actors may be able to spoof the management device firmware check and successfully initiate a malicious firmware download.
Observed Adversary Behavior
EQUATION GROUP: QUESTIONS AND ANSWERS
“Although the implementation of their malware systems is incredibly complex, surpassing even Regin in sophistication, there is one aspect of the EQUATION group’s attack technologies that exceeds anything we have ever seen before. This is the ability to infect the hard drive firmware… The plugin supports two main functions: reprogramming the HDD firmware with a custom payload from the EQUATION group, and providing an API into a set of hidden sectors (or data storage) of the hard drive. This achieves several important things:
ATT&CK Technique: System Firmware (T0857)
Procedure Example: 2015 Ukraine Electric Power Attack (C0028)
“During the 2015 Ukraine Electric Power Attack, Sandworm Team overwrote the serial-to-ethernet gateways with custom firmware to make systems either disabled, shutdown, and/or unrecoverable.”
Proof of Concept
On the recent vulnerability in Diebold Nixdorf ATMs
Researchers from Positive Technologies were able to demonstrate that it was possible to exploit a vulnerability that allowed them to upload valid firmware without a valid encryption key. From there, attackers or researchers would be able to modify the ATM firmware however they like.
CWE-306: Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
Rockwell Automation Micrologix Remote Code Execution - CVE-2015-6492
Researchers at CyberX Threat Intelligence developed custom firmware that allowed them to perform memory dumps. Through these memory dumps, they were able to find memory vulnerabilities that allowed them to develop remote code execution exploits for Rockwell Automatic Micrologix controllers. They were then able to upload malicious firmware to the device.
If a device does not have a mechanism to authenticate firmware updates, a threat actor may be able to install malicious or corrupt firmware on the device. In such cases, an adversary may craft a customized or maliciously modified firmware update package that, if properly formed, the device will install it without challenge. The unauthorized firmware could then be used to (i) “brick” the device and prevent it from being reset, (ii) install malicious logic on the device, including to gain persistence, or (iii) enable access to ease reverse engineering the device to identify remotely exploitable vulnerabilities, depending on how the firmware was formed and how the target device responds to it. Devices that perform only error checking of update packages prior to installation (e.g., parity checks, hash checks without a cryptographic signature, etc.) will be susceptible to this threat.
This threat also includes any firmware authentication mechanisms that are not enforced on the device. If devices don’t check firmware integrity/download command authenticity on-device, threat actors may be able to falsely attest that their firmware is secure, thereby bypassing firmware integrity checks. One mechanism through which threat actors could perform this action is by taking advantage of a device’s reliance on a separate management device or service to check firmware. Threat actors may be able to spoof the management device firmware check and successfully initiate a malicious firmware download.
Observed Adversary Behavior
EQUATION GROUP: QUESTIONS AND ANSWERS
“Although the implementation of their malware systems is incredibly complex, surpassing even Regin in sophistication, there is one aspect of the EQUATION group’s attack technologies that exceeds anything we have ever seen before. This is the ability to infect the hard drive firmware… The plugin supports two main functions: reprogramming the HDD firmware with a custom payload from the EQUATION group, and providing an API into a set of hidden sectors (or data storage) of the hard drive. This achieves several important things:
ATT&CK Technique: System Firmware (T0857)
Procedure Example: 2015 Ukraine Electric Power Attack (C0028)
“During the 2015 Ukraine Electric Power Attack, Sandworm Team overwrote the serial-to-ethernet gateways with custom firmware to make systems either disabled, shutdown, and/or unrecoverable.”
Proof of Concept
On the recent vulnerability in Diebold Nixdorf ATMs
Researchers from Positive Technologies were able to demonstrate that it was possible to exploit a vulnerability that allowed them to upload valid firmware without a valid encryption key. From there, attackers or researchers would be able to modify the ATM firmware however they like.
CWE-306: Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
Rockwell Automation Micrologix Remote Code Execution - CVE-2015-6492
Researchers at CyberX Threat Intelligence developed custom firmware that allowed them to perform memory dumps. Through these memory dumps, they were able to find memory vulnerabilities that allowed them to develop remote code execution exploits for Rockwell Automatic Micrologix controllers. They were then able to upload malicious firmware to the device.
Some devices utilize a shared secret authentication scheme to verify firmware updates. This is an improvement over unauthenticated updates (as in TID-211) and can be coupled with or implemented as symmetric key encryption for added confidentiality. This process requires the shared secret to be present on the device for verification (or decryption). Often the same shared secret will be used across many or all examples of that model device, therefore if the secret is compromised on one device it makes all others vulnerable. A threat actor may extract the secret via various means then use it to fabricate a malicious firmware update that is accepted by all devices that use the same integrity mechanism and shared secret.
Malicious firmware or software could then be installed to (i) “brick” the device and prevent it from being reset, (ii) install malicious logic on the device, including to gain persistence, or (iii) enable access to ease reverse engineering the device to identify remotely exploitable vulnerabilities on the device.
Proof of Concept
Siemens SIMATIC S7-1500 Series Allow for Bypass of All Protected Boot Features
“The Siemens S7-1500 series PLCs implement a boot-time firmware validation scheme using a combination of hardware-enabled firmware decryption and binary integrity validation in the Siemens ADONIS operating system. Multiple architectural vulnerabilities exist which allow attackers to bypass all protected boot features, resulting in persistent arbitrary modification of operating code and data. With physical access to a single device, attackers can exploit the vulnerabilities to generate valid AES keys for most of the S7-1500 series firmwares, including the one modified by attackers. The custom-modified firmware can be authenticated and decrypted by the original boot process. By flashing this malicious firmware on a target device, either physically or by exploiting an existing remote code execution vulnerability, attackers could persistently gain arbitrary code execution and potentially circumvent any official security and firmware updates, without the user’s knowledge.”
CVE-2022-38773
“Affected devices do not contain an Immutable Root of Trust in Hardware. With this the integrity of the code executed on the device can not be validated during load-time. An attacker with physical access to the device could use this to replace the boot image of the device and execute arbitrary code.”
Some devices utilize a shared secret authentication scheme to verify firmware updates. This is an improvement over unauthenticated updates (as in TID-211) and can be coupled with or implemented as symmetric key encryption for added confidentiality. This process requires the shared secret to be present on the device for verification (or decryption). Often the same shared secret will be used across many or all examples of that model device, therefore if the secret is compromised on one device it makes all others vulnerable. A threat actor may extract the secret via various means then use it to fabricate a malicious firmware update that is accepted by all devices that use the same integrity mechanism and shared secret.
Malicious firmware or software could then be installed to (i) “brick” the device and prevent it from being reset, (ii) install malicious logic on the device, including to gain persistence, or (iii) enable access to ease reverse engineering the device to identify remotely exploitable vulnerabilities on the device.
Proof of Concept
Siemens SIMATIC S7-1500 Series Allow for Bypass of All Protected Boot Features
“The Siemens S7-1500 series PLCs implement a boot-time firmware validation scheme using a combination of hardware-enabled firmware decryption and binary integrity validation in the Siemens ADONIS operating system. Multiple architectural vulnerabilities exist which allow attackers to bypass all protected boot features, resulting in persistent arbitrary modification of operating code and data. With physical access to a single device, attackers can exploit the vulnerabilities to generate valid AES keys for most of the S7-1500 series firmwares, including the one modified by attackers. The custom-modified firmware can be authenticated and decrypted by the original boot process. By flashing this malicious firmware on a target device, either physically or by exploiting an existing remote code execution vulnerability, attackers could persistently gain arbitrary code execution and potentially circumvent any official security and firmware updates, without the user’s knowledge.”
CVE-2022-38773
“Affected devices do not contain an Immutable Root of Trust in Hardware. With this the integrity of the code executed on the device can not be validated during load-time. An attacker with physical access to the device could use this to replace the boot image of the device and execute arbitrary code.”
To avoid the weaknesses of a shared secret verification (see TID-212), devices may utilize a digital signature verification scheme based on asymmetric public key cryptography. However, if the device does not correctly verify a firmware/software signature correctly, a threat actor can bypass the device’s authenticity checking mechanisms to upload malicious or corrupt version. The unauthorized firmware could “brick” the device, preventing it from being reset. This could also be used to install malicious logic on the device.
NOTE: firmware/software signature here refers to processes that use cryptographic keys to verify firmware integrity and origin. These can include keyed hashes and/or asymmetric key signing. This does not include encrypting firmware with no other integrity verification mechanisms in-place.
Known Exploitable Weakness
KEV - CVE-2023-41991
“Apple iOS, iPadOS, macOS, and watchOS contain an improper certificate validation vulnerability that can allow a malicious app to bypass signature validation.”
CWE-347: Improper Verification of Cryptographic Signature
“The product does not verify, or incorrectly verifies, the cryptographic signature for data.”
CVE-2021-43394
“STMicroelectronics STSAFE-J 1.1.4, J-SAFE3 1.2.5, and J-SIGN sometimes allow attackers to abuse signature verification. This is associated with the ECDSA signature algorithm on the Java Card J-SAFE3 and STSAFE-J platforms exposing a 3.0.4 Java Card API…”
CVE-2023-33768
“Incorrect signature verification of the firmware during the Device Firmware Update process of Belkin Wemo Smart Plug WSP080 v1.2 allows attackers to cause a Denial of Service (DoS) via a crafted firmware file.”
Cisco IOS XE Software Digital Signature Verification Bypass Vulnerability - CVE-2020-3209
“A vulnerability in software image verification in Cisco IOS XE Software could allow an unauthenticated, physical attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability is due to an improper check on the area of code that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. A successful exploit could allow the attacker to install and boot a malicious software image or execute unsigned binaries on the targeted device.”
CVE-2023-41991
“A certificate validation issue was addressed. This issue is fixed in macOS Ventura 13.6, iOS 16.7 and iPadOS 16.7. A malicious app may be able to bypass signature validation. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.”
To avoid the weaknesses of a shared secret verification (see TID-212), devices may utilize a digital signature verification scheme based on asymmetric public key cryptography. However, if the device does not correctly verify a firmware/software signature correctly, a threat actor can bypass the device’s authenticity checking mechanisms to upload malicious or corrupt version. The unauthorized firmware could “brick” the device, preventing it from being reset. This could also be used to install malicious logic on the device.
NOTE: firmware/software signature here refers to processes that use cryptographic keys to verify firmware integrity and origin. These can include keyed hashes and/or asymmetric key signing. This does not include encrypting firmware with no other integrity verification mechanisms in-place.
Known Exploitable Weakness
KEV - CVE-2023-41991
“Apple iOS, iPadOS, macOS, and watchOS contain an improper certificate validation vulnerability that can allow a malicious app to bypass signature validation.”
CWE-347: Improper Verification of Cryptographic Signature
“The product does not verify, or incorrectly verifies, the cryptographic signature for data.”
CVE-2021-43394
“STMicroelectronics STSAFE-J 1.1.4, J-SAFE3 1.2.5, and J-SIGN sometimes allow attackers to abuse signature verification. This is associated with the ECDSA signature algorithm on the Java Card J-SAFE3 and STSAFE-J platforms exposing a 3.0.4 Java Card API…”
CVE-2023-33768
“Incorrect signature verification of the firmware during the Device Firmware Update process of Belkin Wemo Smart Plug WSP080 v1.2 allows attackers to cause a Denial of Service (DoS) via a crafted firmware file.”
Cisco IOS XE Software Digital Signature Verification Bypass Vulnerability - CVE-2020-3209
“A vulnerability in software image verification in Cisco IOS XE Software could allow an unauthenticated, physical attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability is due to an improper check on the area of code that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. A successful exploit could allow the attacker to install and boot a malicious software image or execute unsigned binaries on the targeted device.”
CVE-2023-41991
“A certificate validation issue was addressed. This issue is fixed in macOS Ventura 13.6, iOS 16.7 and iPadOS 16.7. A malicious app may be able to bypass signature validation. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7.”
Some device have mutable or immutable secure Roots of Trust (ROTs) that may store keys or secrets. If the device has a ROT mechanism to validate the authenticity of the firmware/software, the ROT can be either a software or hardware mechanisms, such as a Trusted Platform Module (TPM), firmware TPM (fTPM), Secure Element, or similar security module. If a threat actor can access authentication material on the ROT, such as the keys or other secrets, they can potentially use them to sign a malicious version of firmware/software which can then be installed on the device.
Proof of Concept
Uprooting Trust: Learnings from an Unpatchable Hardware Root-of-Trust Vulnerability in Siemens S7-1500 PLCs
“Specifically, this assessment is conducted by uncovering novel vulnerabilities related to the discrete RoT implementation on the Siemens S7-1500 series Programmable Logic Controllers (PLCs). Our findings are cautionary evidence of how flawed assumptions related to RoT implementation may allow malicious actors to spoof authentication credentials, re-encrypt firmware, and ultimately gain covert, privileged control over these devices without invasive or destructive practices.”
100 Seconds of Solitude: Defeating Cisco Trust Anchor With FPGA Bitstream Shenanigans
“A vulnerability in the logic that handles access control to one of the hardware components in Cisco’s proprietary Secure Boot implementation could allow an authenticated, local attacker to write a modified firmware image to the component. This vulnerability affects multiple Cisco products that support hardware-based Secure Boot functionality.”
faulTPM: Exposing AMD fTPMs’ Deepest Secrets
“In this paper, we show that AMD’s fTPMs are vulnerable to physical attacks against their execution environment: the AMD-SP. Our attack utilizes the AMD-SP’s vulnerability to voltage fault injection attacks to extract a chip-unique secret from the targeted CPU. This secret is subsequently used to derive the storage and integrity keys protecting the fTPM’s non-volatile (NV) data stored on the Basic Input/Output System (BIOS) flash chip.”
CWE-1326: Missing Immutable Root of Trust in Hardware
“A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.”
CVE-2022-38773
“Affected devices do not contain an Immutable Root of Trust in Hardware. With this the integrity of the code executed on the device can not be validated during load-time. An attacker with physical access to the device could use this to replace the boot image of the device and execute arbitrary code.”
Some device have mutable or immutable secure Roots of Trust (ROTs) that may store keys or secrets. If the device has a ROT mechanism to validate the authenticity of the firmware/software, the ROT can be either a software or hardware mechanisms, such as a Trusted Platform Module (TPM), firmware TPM (fTPM), Secure Element, or similar security module. If a threat actor can access authentication material on the ROT, such as the keys or other secrets, they can potentially use them to sign a malicious version of firmware/software which can then be installed on the device.
Proof of Concept
Uprooting Trust: Learnings from an Unpatchable Hardware Root-of-Trust Vulnerability in Siemens S7-1500 PLCs
“Specifically, this assessment is conducted by uncovering novel vulnerabilities related to the discrete RoT implementation on the Siemens S7-1500 series Programmable Logic Controllers (PLCs). Our findings are cautionary evidence of how flawed assumptions related to RoT implementation may allow malicious actors to spoof authentication credentials, re-encrypt firmware, and ultimately gain covert, privileged control over these devices without invasive or destructive practices.”
100 Seconds of Solitude: Defeating Cisco Trust Anchor With FPGA Bitstream Shenanigans
“A vulnerability in the logic that handles access control to one of the hardware components in Cisco’s proprietary Secure Boot implementation could allow an authenticated, local attacker to write a modified firmware image to the component. This vulnerability affects multiple Cisco products that support hardware-based Secure Boot functionality.”
faulTPM: Exposing AMD fTPMs’ Deepest Secrets
“In this paper, we show that AMD’s fTPMs are vulnerable to physical attacks against their execution environment: the AMD-SP. Our attack utilizes the AMD-SP’s vulnerability to voltage fault injection attacks to extract a chip-unique secret from the targeted CPU. This secret is subsequently used to derive the storage and integrity keys protecting the fTPM’s non-volatile (NV) data stored on the Basic Input/Output System (BIOS) flash chip.”
CWE-1326: Missing Immutable Root of Trust in Hardware
“A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.”
CVE-2022-38773
“Affected devices do not contain an Immutable Root of Trust in Hardware. With this the integrity of the code executed on the device can not be validated during load-time. An attacker with physical access to the device could use this to replace the boot image of the device and execute arbitrary code.”
If the firmware/software update is not encrypted at rest in storage it can be reverse engineered to identify potential vulnerabilities or extract other information needed to protect devices (e.g., passwords, cryptographic keys). Firmware/software updates can often be directly downloaded from the Internet and reverse engineered, however, firmware/software updates that are unencrypted in transit may also be intercepted and analyzed over-the-wire.
Proof of Concept
Reverse Engineering Obfuscated Firmware for Vulnerability Analysis
Nozomi researchers demonstrated how the ability to reverse engineer firmware gives attackers the ability to find novel vulnerabilities, or the presence of older vulnerabilities, on a given device.
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
If the firmware/software update is not encrypted at rest in storage it can be reverse engineered to identify potential vulnerabilities or extract other information needed to protect devices (e.g., passwords, cryptographic keys). Firmware/software updates can often be directly downloaded from the Internet and reverse engineered, however, firmware/software updates that are unencrypted in transit may also be intercepted and analyzed over-the-wire.
Proof of Concept
Reverse Engineering Obfuscated Firmware for Vulnerability Analysis
Nozomi researchers demonstrated how the ability to reverse engineer firmware gives attackers the ability to find novel vulnerabilities, or the presence of older vulnerabilities, on a given device.
CWE-311: Missing Encryption of Sensitive Data
“The product does not encrypt sensitive or critical information before storage or transmission.”
Firmware updates will oftentimes include fixes to security vulnerabilities, meaning that past versions will contain security threats to the devices. If a threat actor can initiate a firmware update on the device, they may be able to “upgrade” to a previous firmware version with known vulnerabilities. By completing an “upgrade” to a version with vulnerabilities, the threat actor could then potentially exploit that device to gain additional access or privileges.
Known Exploitable Weakness
China APT Cracks Cisco Firmware in Attacks Against the US and Japan
Threat group BlackTech (Palmerworm, Temp.Overboard, Circuit Panda, and Radio Panda) has been performing firmware downgrade attacks. Once the firmware is downgraded, BlackTech can leverage older vulnerabilities to “hot patch old firmware in memory” with custom firmware code. They then can achieve persistence and pivot from “smaller, international subsidiaries to headquarters of affected organizations.”
Proof of Concept
PT-2021-01: Encryption bypass when downloading a firmware update in Diebold-Nixdorf CMDv5
“With access to the dispenser controller USB port, an attacker can install an outdated or modified firmware version (with malicious content) to bypass the encryption and withdraw cash.”
CVE-2018-9099
“Encryption bypass when downloading a firmware update in Diebold-Nixdorf CMDv5” The researches demonstrated this exploit by loading outdated and vulnerable firmware.
Firmware updates will oftentimes include fixes to security vulnerabilities, meaning that past versions will contain security threats to the devices. If a threat actor can initiate a firmware update on the device, they may be able to “upgrade” to a previous firmware version with known vulnerabilities. By completing an “upgrade” to a version with vulnerabilities, the threat actor could then potentially exploit that device to gain additional access or privileges.
Known Exploitable Weakness
China APT Cracks Cisco Firmware in Attacks Against the US and Japan
Threat group BlackTech (Palmerworm, Temp.Overboard, Circuit Panda, and Radio Panda) has been performing firmware downgrade attacks. Once the firmware is downgraded, BlackTech can leverage older vulnerabilities to “hot patch old firmware in memory” with custom firmware code. They then can achieve persistence and pivot from “smaller, international subsidiaries to headquarters of affected organizations.”
Proof of Concept
PT-2021-01: Encryption bypass when downloading a firmware update in Diebold-Nixdorf CMDv5
“With access to the dispenser controller USB port, an attacker can install an outdated or modified firmware version (with malicious content) to bypass the encryption and withdraw cash.”
CVE-2018-9099
“Encryption bypass when downloading a firmware update in Diebold-Nixdorf CMDv5” The researches demonstrated this exploit by loading outdated and vulnerable firmware.
When firmware/software update process is initiated on a device, it may enter a different operational mode where it stops performing key functions, including networking, data collection, or control functions. Therefore a threat actor could remotely initiate the firmware/software update to cause a denial of service on the device.
Observed Adversary Behavior
ATT&CK Technique: Activate Firmware Update Mode (T0800)
Procedure Example: Industroyer (S0604)
“The Industroyer SIPROTEC DoS module places the victim device into firmware update mode. This is a legitimate use case under normal circumstances, but in this case is used the adversary to prevent the SIPROTEC from performing its designed protective functions. As a result the normal safeguards are disabled, leaving an unprotected link in the electric transmission.”
CWE-400: Uncontrolled Resource Consumption
“The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.”
CRASHOVERRIDE - CVE-2015-5374
“Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device. A manual reboot may be required to recover the service of the device.”
“The DoS condition places the victim SIPROTEC device in “firmware update” mode. The effect triggered is practical and useful in legitimate firmware update instances given the limited resources available to legacy SIPROTEC devices (especially for memory).”
When firmware/software update process is initiated on a device, it may enter a different operational mode where it stops performing key functions, including networking, data collection, or control functions. Therefore a threat actor could remotely initiate the firmware/software update to cause a denial of service on the device.
Observed Adversary Behavior
ATT&CK Technique: Activate Firmware Update Mode (T0800)
Procedure Example: Industroyer (S0604)
“The Industroyer SIPROTEC DoS module places the victim device into firmware update mode. This is a legitimate use case under normal circumstances, but in this case is used the adversary to prevent the SIPROTEC from performing its designed protective functions. As a result the normal safeguards are disabled, leaving an unprotected link in the electric transmission.”
CWE-400: Uncontrolled Resource Consumption
“The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.”
CRASHOVERRIDE - CVE-2015-5374
“Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device. A manual reboot may be required to recover the service of the device.”
“The DoS condition places the victim SIPROTEC device in “firmware update” mode. The effect triggered is practical and useful in legitimate firmware update instances given the limited resources available to legacy SIPROTEC devices (especially for memory).”
A threat actor may be able to install a rootkit that can manipulate the operating system (OS). Rootkits can evade OS protections by installing themselves at the same privilege-level as the OS. A threat actor can use a rootkit to maintain persistence on the device, evade detection, or execute malicious programs/logic.
Known Exploitable Weakness
ATT&CK Technique: Rootkit (T0851)
Procedure Example: Stuxnet (S0603)
“One of Stuxnet’s rootkits is contained entirely in the fake s7otbxdx.dll. In order to continue existing undetected on the PLC it needs to account for at least the following situations: read requests for its own malicious code blocks, read requests for infected blocks (OB1, OB35, DP_RECV), and write requests that could overwrite Stuxnets [sic] own code. Stuxnet contains code to monitor and intercept these types of requests. The rootkit modifies these requests so that Stuxnets [sic] PLC code is not discovered or damaged.”
Proof of Concept
Ghost in the PLC
Researchers Abbasi and Hasemi were able to create the Ghost in the PLC rootkit. This rootkit is able to embed itself in a PLC with detection evasion mechanisms. It is then able to achieve arbitrary read/write in registers with/without root access.
Air Force Institute of Technology (AFIT)
“Researchers with the U.S. Air Force Institute of Technology (AFIT) have created a prototype rootkit that can sit undetected in the firmware of a programmable logic controller (PLC) device and corrupt utility and plant floor operations.”
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
A threat actor may be able to install a rootkit that can manipulate the operating system (OS). Rootkits can evade OS protections by installing themselves at the same privilege-level as the OS. A threat actor can use a rootkit to maintain persistence on the device, evade detection, or execute malicious programs/logic.
Known Exploitable Weakness
ATT&CK Technique: Rootkit (T0851)
Procedure Example: Stuxnet (S0603)
“One of Stuxnet’s rootkits is contained entirely in the fake s7otbxdx.dll. In order to continue existing undetected on the PLC it needs to account for at least the following situations: read requests for its own malicious code blocks, read requests for infected blocks (OB1, OB35, DP_RECV), and write requests that could overwrite Stuxnets [sic] own code. Stuxnet contains code to monitor and intercept these types of requests. The rootkit modifies these requests so that Stuxnets [sic] PLC code is not discovered or damaged.”
Proof of Concept
Ghost in the PLC
Researchers Abbasi and Hasemi were able to create the Ghost in the PLC rootkit. This rootkit is able to embed itself in a PLC with detection evasion mechanisms. It is then able to achieve arbitrary read/write in registers with/without root access.
Air Force Institute of Technology (AFIT)
“Researchers with the U.S. Air Force Institute of Technology (AFIT) have created a prototype rootkit that can sit undetected in the firmware of a programmable logic controller (PLC) device and corrupt utility and plant floor operations.”
CWE-693: Protection Mechanisms Failure (Pillar)
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
Operating Systems and Kernels frequently run at the highest levels of permissions. If processes with lower permissions are able to exploit a vulnerability in the OS or Kernel (such as a vulnerability enabled by TID-206), they may be able to raise the privileges of their process. If a threat actor were to exploit this vulnerability, they may be able to raise the permissions of a malicious process, thereby granting themselves greater access to the device.
Observed Adversary Behavior
ATT&CK Technique: Exploitation for Privilege Escalation (T0890)
Procedure Example: Triton (S1009)
“Triton leverages a previously-unknown vulnerability affecting Tricon MP3008 firmware versions 10.010.4 allows an insecurely-written system call to be exploited to achieve an arbitrary 2-byte write primitive, which is then used to gain supervisor privileges.”
CWE-250: Execution with Unnecessary Privileges
“The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.”
Operating Systems and Kernels frequently run at the highest levels of permissions. If processes with lower permissions are able to exploit a vulnerability in the OS or Kernel (such as a vulnerability enabled by TID-206), they may be able to raise the privileges of their process. If a threat actor were to exploit this vulnerability, they may be able to raise the permissions of a malicious process, thereby granting themselves greater access to the device.
Observed Adversary Behavior
ATT&CK Technique: Exploitation for Privilege Escalation (T0890)
Procedure Example: Triton (S1009)
“Triton leverages a previously-unknown vulnerability affecting Tricon MP3008 firmware versions 10.010.4 allows an insecurely-written system call to be exploited to achieve an arbitrary 2-byte write primitive, which is then used to gain supervisor privileges.”
CWE-250: Execution with Unnecessary Privileges
“The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.”
Hardware roots of trust can be used to support many desirable device security functions, such as secure key and secret storage, secure boot, and firmware integrity measurement. These functions often rely on the root of trust being immutable, preventing a threat actor from making changes to code or data in the root of trust that would undermine the security functions built atop them. However, if the root of trust implementation is flawed, immutability prevents the revocation and replacement of compromised keys, and prevents patching vulnerable code. Therefore, if threat actors have access to a mechanism to obtain the secret data or code, and/or those secrets and code are shared over multiple devices and threat actors can obtain them, then devices will remain vulnerable past threat disclosure and may have to be removed from operation and replaced with new patched versions.
Known Exploitable Weakness
Glitching the Switch
The researchers show how they identified an exploitable flaw in the immutable 1st stage boot ROM code of the Nvidia Tegra X1 SoC, which the Nintendo Switch game console is built upon. The secret boot ROM code serves as the root of trust for secure verified boot on the Tegra X1 platform. A buffer overflow vulnerability in the recovery mode of the boot ROM allows a threat actor to bypass firmware verification and execute unauthorize custom or modified firmware on the device. Because the flawed code is stored in unmodifiable memory within the X1 system-on-chip, this vulnerability cannot be patched in hardware revisions that contain it and could only be fixed on newly manufactured Switch consoles.
Proof of Concept
Uprooting Trust: Learnings from an Unpatchable Hardware Root-of-Trust Vulnerability in Siemens S7-1500 PLCs
“The vulnerable ATECC-based RoT hardware implementation is deployed across the Siemens S7-1500 series product line. Because each device is loaded with the exact same cryptographic material used to generate decryption seeds and keys, adversaries may abuse the hardware RoT to decrypt, modify, and re-encrypt firmware for all devices within this family. For example, an ATECC RoT chip may be removed or instrumented from one specific S7-1500 series device, and used to generate valid tampered firmware for a separate device.”
CWE-1329: Reliance on Component That is Not Updateable
“The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.”
Hardware roots of trust can be used to support many desirable device security functions, such as secure key and secret storage, secure boot, and firmware integrity measurement. These functions often rely on the root of trust being immutable, preventing a threat actor from making changes to code or data in the root of trust that would undermine the security functions built atop them. However, if the root of trust implementation is flawed, immutability prevents the revocation and replacement of compromised keys, and prevents patching vulnerable code. Therefore, if threat actors have access to a mechanism to obtain the secret data or code, and/or those secrets and code are shared over multiple devices and threat actors can obtain them, then devices will remain vulnerable past threat disclosure and may have to be removed from operation and replaced with new patched versions.
Known Exploitable Weakness
Glitching the Switch
The researchers show how they identified an exploitable flaw in the immutable 1st stage boot ROM code of the Nvidia Tegra X1 SoC, which the Nintendo Switch game console is built upon. The secret boot ROM code serves as the root of trust for secure verified boot on the Tegra X1 platform. A buffer overflow vulnerability in the recovery mode of the boot ROM allows a threat actor to bypass firmware verification and execute unauthorize custom or modified firmware on the device. Because the flawed code is stored in unmodifiable memory within the X1 system-on-chip, this vulnerability cannot be patched in hardware revisions that contain it and could only be fixed on newly manufactured Switch consoles.
Proof of Concept
Uprooting Trust: Learnings from an Unpatchable Hardware Root-of-Trust Vulnerability in Siemens S7-1500 PLCs
“The vulnerable ATECC-based RoT hardware implementation is deployed across the Siemens S7-1500 series product line. Because each device is loaded with the exact same cryptographic material used to generate decryption seeds and keys, adversaries may abuse the hardware RoT to decrypt, modify, and re-encrypt firmware for all devices within this family. For example, an ATECC RoT chip may be removed or instrumented from one specific S7-1500 series device, and used to generate valid tampered firmware for a separate device.”
CWE-1329: Reliance on Component That is Not Updateable
“The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.”
Some devices will allow for authentication over the network, but do not implement mechanisms (i.e. nonces, timestamps) to ensure that messages containing credentials cannot be reused. Devices like these are potentially vulnerable to replay attacks. In these attacks, threat actors may be able to take legitimate packets that were sent over the network, capture them, and send them again to the device. If the device accepts these packets, threat actors may be able to initiate unauthorized actions. Additionally, if threat actors are able to edit the contents of those packets, they can potentially control the device remotely.
Observed Adversary Behavior
ATT&CK T1212 Exploitation for Credential Access
“Another example of this is replay attacks, in which the adversary intercepts data packets sent between parties and then later replays these packets. If services don’t properly validate authentication requests, these replayed packets may allow an adversary to impersonate one of the parties and gain unauthorized access or privileges.”
CWE-294: Authentication Bypass by Capture-replay
“A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).”
Some devices will allow for authentication over the network, but do not implement mechanisms (i.e. nonces, timestamps) to ensure that messages containing credentials cannot be reused. Devices like these are potentially vulnerable to replay attacks. In these attacks, threat actors may be able to take legitimate packets that were sent over the network, capture them, and send them again to the device. If the device accepts these packets, threat actors may be able to initiate unauthorized actions. Additionally, if threat actors are able to edit the contents of those packets, they can potentially control the device remotely.
Observed Adversary Behavior
ATT&CK T1212 Exploitation for Credential Access
“Another example of this is replay attacks, in which the adversary intercepts data packets sent between parties and then later replays these packets. If services don’t properly validate authentication requests, these replayed packets may allow an adversary to impersonate one of the parties and gain unauthorized access or privileges.”
CWE-294: Authentication Bypass by Capture-replay
“A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).”
Various devices and associated services are necessary to support communications and connections on a network. If a key service is disabled, terminated, or reconfigured, a threat actor can disrupt or disable communications on a network. This could occur on various network equipment, such as switches, firewalls, or routers, along with other devices which may have dedicated processes to facilitate communication with specific protocols or physical mediums (e.g., serial).
Observed Adversary Behavior
ATT&CK Technique: Service Stop (T0881)
Procedure Example: Industroyer (S0604)
“Industroyer has the capability to stop a service itself, or to login as a user and stop a service as that user.”
Procedure Example: Industroyer2 (S1072)
“Industroyer2 has the capability to terminate specified processes (i.e., PServiceControl.exe and PService_PDD.exe) and rename each process to prevent restart. These are defined through a hardcoded configuration.”
CWE-306 Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CWE-15: External Control of System or Configuration Setting
“One or more system settings or configuration elements can be externally controlled by a user.”
Various devices and associated services are necessary to support communications and connections on a network. If a key service is disabled, terminated, or reconfigured, a threat actor can disrupt or disable communications on a network. This could occur on various network equipment, such as switches, firewalls, or routers, along with other devices which may have dedicated processes to facilitate communication with specific protocols or physical mediums (e.g., serial).
Observed Adversary Behavior
ATT&CK Technique: Service Stop (T0881)
Procedure Example: Industroyer (S0604)
“Industroyer has the capability to stop a service itself, or to login as a user and stop a service as that user.”
Procedure Example: Industroyer2 (S1072)
“Industroyer2 has the capability to terminate specified processes (i.e., PServiceControl.exe and PService_PDD.exe) and rename each process to prevent restart. These are defined through a hardcoded configuration.”
CWE-306 Missing Authentication for Critical Function
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CWE-15: External Control of System or Configuration Setting
“One or more system settings or configuration elements can be externally controlled by a user.”
If the threat actor can obtain sufficient privileges on the devices, they may be able to install runtime tools to directly extract the contents of some or all of the system RAM. This can grant the actor access to the internal state of other applications executing on the device as they process potentially sensitive data (e.g., password, keys, credentials, financial data, PII, etc.) even if that data is never committed to storage in a file or database. If the access extends to physical RAM, this can enable the threat actor to bypass other inter-process security boundaries created by the operating system.
Known Exploitable Weakness
How RAM Scrapers Work: The Sneaky Tools Behind the Latest Credit Card Hacks
“There are more than a dozen RAM scrapers sold in the underground market these days. There’s Dexter, Soraya, ChewBacca and BlackPOS to name a few… Once on a targeted system, RAM scrapers work by examining the list of processes that are running on the system and inspecting the memory for data that matches the structure of credit card data, such as the account number, expiration date, and other information stored on a card’s magnetic stripe. Some scrapers are efficient and grab only the golden numbers the attackers seek; others are more sloppy and grab a lot of dirt with their gold.”
If the threat actor can obtain sufficient privileges on the devices, they may be able to install runtime tools to directly extract the contents of some or all of the system RAM. This can grant the actor access to the internal state of other applications executing on the device as they process potentially sensitive data (e.g., password, keys, credentials, financial data, PII, etc.) even if that data is never committed to storage in a file or database. If the access extends to physical RAM, this can enable the threat actor to bypass other inter-process security boundaries created by the operating system.
Known Exploitable Weakness
How RAM Scrapers Work: The Sneaky Tools Behind the Latest Credit Card Hacks
“There are more than a dozen RAM scrapers sold in the underground market these days. There’s Dexter, Soraya, ChewBacca and BlackPOS to name a few… Once on a targeted system, RAM scrapers work by examining the list of processes that are running on the system and inspecting the memory for data that matches the structure of credit card data, such as the account number, expiration date, and other information stored on a card’s magnetic stripe. Some scrapers are efficient and grab only the golden numbers the attackers seek; others are more sloppy and grab a lot of dirt with their gold.”
If a device has debugging capabilities (e.g., diagnostic tools, debug logs, etc.) that are not authenticated or can be accessed in unintended ways, it may be possible for a threat actor to attach to these debuggers. Debuggers frequently have privileged access, which would give the threat actors increased access over the device.
Observed Adversary Behavior
ATT&CK T1623 Command and Scripting Interpreter
“Most systems come with some built-in command-line interface and scripting capabilities, for example, Android is a UNIX-like OS and includes a basic Unix Shell that can be accessed via the Android Debug Bridge (ADB)”
Proof of Concept
ATM logic attacks: scenarios, 2018
“Starting the ATM operating system in a special mode can offer a way to bypass security… After starting the ATM in debug mode and connecting to the COM ports, an attacker can seize full control of the ATM by using the WinDbg utility.”
CWE-1295: Debug Messages Revealing Unnecessary Information
“The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.”
If a device has debugging capabilities (e.g., diagnostic tools, debug logs, etc.) that are not authenticated or can be accessed in unintended ways, it may be possible for a threat actor to attach to these debuggers. Debuggers frequently have privileged access, which would give the threat actors increased access over the device.
Observed Adversary Behavior
ATT&CK T1623 Command and Scripting Interpreter
“Most systems come with some built-in command-line interface and scripting capabilities, for example, Android is a UNIX-like OS and includes a basic Unix Shell that can be accessed via the Android Debug Bridge (ADB)”
Proof of Concept
ATM logic attacks: scenarios, 2018
“Starting the ATM operating system in a special mode can offer a way to bypass security… After starting the ATM in debug mode and connecting to the COM ports, an attacker can seize full control of the ATM by using the WinDbg utility.”
CWE-1295: Debug Messages Revealing Unnecessary Information
“The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.”
A threat actor could modify application-level binaries or libraries on the device to introduce unauthorized code, maintain persistence, or evade detection. This could also include the modification of runtime libraries used to support the execution of programs, along with key PLC function blocks used to structure the execution of application function blocks, such as organizational blocks.
Observed Adversarial Technique
ATT&CK Technique: Modify Controller Tasking (T0821)
Procedure Example: Stuxnet (S0603)
“Stuxnet infects OB1 so that its malicious code sequence is executed at the start of a cycle. It also infects OB35. OB35 acts as a watchdog, and on certain conditions, it can stop the execution of OB1.”
CWE-862: Missing Authorization
“The product does not perform an authorization check when an actor attempts to access a resource or perform an action.”
A threat actor could modify application-level binaries or libraries on the device to introduce unauthorized code, maintain persistence, or evade detection. This could also include the modification of runtime libraries used to support the execution of programs, along with key PLC function blocks used to structure the execution of application function blocks, such as organizational blocks.
Observed Adversarial Technique
ATT&CK Technique: Modify Controller Tasking (T0821)
Procedure Example: Stuxnet (S0603)
“Stuxnet infects OB1 so that its malicious code sequence is executed at the start of a cycle. It also infects OB35. OB35 acts as a watchdog, and on certain conditions, it can stop the execution of OB1.”
CWE-862: Missing Authorization
“The product does not perform an authorization check when an actor attempts to access a resource or perform an action.”
A threat actor can install a malicious program to the device to manipulate its operations or prevent the device from operating as expected. Devices can utilize a variety of different approaches to support the download, modification, and execution of programs/logic. For example, some devices might support program downloads through traditional operating system interfaces (e.g., Telnet, SSH, RDP), while other devices, such as PLCs, often use proprietary interfaces to deploy and execute IEC 61131 based logic programs. Devices are often dependent on a remote system, such as a Windows workstations, with a vendor-specific application program or IDE to develop and transfer the programs to the device. However, devices often assume that all code originates from that trusted program/IDE, and therefore do not perform any integrity checking of the code before downloading or executing it.
Observed Adversarial Technique
ATT&CK Technique: Program Download (T0843)
Procedure Example: Triton (S1009)
“Triton leveraged the TriStation protocol to download programs onto Triconex Safety Instrumented System”.
Procedure Example: Incontroller (S1045)
“The Incontroller software was able to perform program downloads to a controller through a self-contained API.”
CWE-494: Download of Code Without Integrity Check
“The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.”
A threat actor can install a malicious program to the device to manipulate its operations or prevent the device from operating as expected. Devices can utilize a variety of different approaches to support the download, modification, and execution of programs/logic. For example, some devices might support program downloads through traditional operating system interfaces (e.g., Telnet, SSH, RDP), while other devices, such as PLCs, often use proprietary interfaces to deploy and execute IEC 61131 based logic programs. Devices are often dependent on a remote system, such as a Windows workstations, with a vendor-specific application program or IDE to develop and transfer the programs to the device. However, devices often assume that all code originates from that trusted program/IDE, and therefore do not perform any integrity checking of the code before downloading or executing it.
Observed Adversarial Technique
ATT&CK Technique: Program Download (T0843)
Procedure Example: Triton (S1009)
“Triton leveraged the TriStation protocol to download programs onto Triconex Safety Instrumented System”.
Procedure Example: Incontroller (S1045)
“The Incontroller software was able to perform program downloads to a controller through a self-contained API.”
CWE-494: Download of Code Without Integrity Check
“The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.”
If device management is intended to be performed by a dedicated engineering software platform or integrated development environment (IDE), the threat actor could potentially modify the software platform, such as by manipulating key .dlls, to install malicious code or manipulate the operation of the device. This can provide the threat actor with a mechanism to bypass protections/countermeasures.
Observed Adversarial Technique
ATT&CK Technique: Rootkit (T0851)
Procedure Example: Stuxnet (S0603)
“Stuxnet has the capability, through malicious .DLLs, to intercept read requests and write requests, include those the could overwrite code on the device”
Proof of Concept
Applying a Stuxnet Type Attack to a Modicon PLC
“Implementing Stuxnet type attacks on PLC’s from other manufacturers is possible. In the case of the Modicon M340, this porting is easier because the PLC executes ARM bytecode natively (and not proprietary assembly code).
This exercise gives us the opportunity to extend M340 functionality by developing automation code directly in C. Now we can perform low level actions which are very difficult to do with other languages (e.g Ladder, Grafcet).
We developed a program that allows the changing of logical programs on the fly (no need for recompilation – stop – upload – start steps in Unity)”
The Old Switcheroo: Hiding Code on Rockwell Automation PLCs
“Team82 decided to test for these Stuxnet-type of attacks on the Rockwell Automation PLC platform. Our research uncovered two vulnerabilities that expose the company’s Logix Controllers and Logix Designer application for engineering workstations to attacks that allow threat actors to stealthily modify automation processes.
Programmable logic and predefined variables drive these processes, and changes to either will alter normal operation of the PLC and the process it manages. An attacker with the ability to modify PLC logic could cause physical damage to factories that affect the safety of manufacturing assembly lines, the reliability of robotic devices, or in a much more dramatic example, as we saw with Stuxnet, attackers could damage centrifuges at the core of uranium enrichment at a nuclear facility.”
CWE-114: Process Control (Class)
“Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.”
CVE-2022-1159
“Rockwell Automation Studio 5000 Logix Designer (all versions) are vulnerable when an attacker who achieves administrator access on a workstation running Studio 5000 Logix Designer could inject controller code undetectable to a user.”
If device management is intended to be performed by a dedicated engineering software platform or integrated development environment (IDE), the threat actor could potentially modify the software platform, such as by manipulating key .dlls, to install malicious code or manipulate the operation of the device. This can provide the threat actor with a mechanism to bypass protections/countermeasures.
Observed Adversarial Technique
ATT&CK Technique: Rootkit (T0851)
Procedure Example: Stuxnet (S0603)
“Stuxnet has the capability, through malicious .DLLs, to intercept read requests and write requests, include those the could overwrite code on the device”
Proof of Concept
Applying a Stuxnet Type Attack to a Modicon PLC
“Implementing Stuxnet type attacks on PLC’s from other manufacturers is possible. In the case of the Modicon M340, this porting is easier because the PLC executes ARM bytecode natively (and not proprietary assembly code).
This exercise gives us the opportunity to extend M340 functionality by developing automation code directly in C. Now we can perform low level actions which are very difficult to do with other languages (e.g Ladder, Grafcet).
We developed a program that allows the changing of logical programs on the fly (no need for recompilation – stop – upload – start steps in Unity)”
The Old Switcheroo: Hiding Code on Rockwell Automation PLCs
“Team82 decided to test for these Stuxnet-type of attacks on the Rockwell Automation PLC platform. Our research uncovered two vulnerabilities that expose the company’s Logix Controllers and Logix Designer application for engineering workstations to attacks that allow threat actors to stealthily modify automation processes.
Programmable logic and predefined variables drive these processes, and changes to either will alter normal operation of the PLC and the process it manages. An attacker with the ability to modify PLC logic could cause physical damage to factories that affect the safety of manufacturing assembly lines, the reliability of robotic devices, or in a much more dramatic example, as we saw with Stuxnet, attackers could damage centrifuges at the core of uranium enrichment at a nuclear facility.”
CWE-114: Process Control (Class)
“Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.”
CVE-2022-1159
“Rockwell Automation Studio 5000 Logix Designer (all versions) are vulnerable when an attacker who achieves administrator access on a workstation running Studio 5000 Logix Designer could inject controller code undetectable to a user.”
A threat actor can manipulate the runtime environments on a device to maintain persistence on the device and overwrite various functionalities, such as protocol handlers. If the application program (which the threat actor can deploy on the device through a program download) has access to memory where the runtime environment and libraries are located, they could overwrite these libraries with malicious code. This is especially risky because runtime environments often must allow the dynamic addition of modules/functions to support user-specific customization or configuration of devices, which may require that the runtime support writeable memory.
NOTE: This differs from TID-305 because this threat has a focus on code being used to manipulate the device runtime environment itself. TID-305 on the other hand pertains to a malicious program itself being used to perform device actions.
Proof of Concept
Security Issues In Compiled PLC Logic (CoDeSys & ProConOs)
At S4x23, Reid Wightman demonstrated that if memory space is shared between program runtime, program logic, and other device functions such as network handling, it is possible to create malicious programs that can manipulate a device’s runtime environment from the application program.
CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
“The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.”
CODESYS Security Advisory 2023-04 (CVE-2022-4046, CVE-2023-28355)
“The CODESYS Control V3 runtime system does not restrict the memory accesses of the PLC application code to the PLC application data and does not sufficiently check the integrity of the application code by default. This could be exploited by authenticated PLC programmers.”
A threat actor can manipulate the runtime environments on a device to maintain persistence on the device and overwrite various functionalities, such as protocol handlers. If the application program (which the threat actor can deploy on the device through a program download) has access to memory where the runtime environment and libraries are located, they could overwrite these libraries with malicious code. This is especially risky because runtime environments often must allow the dynamic addition of modules/functions to support user-specific customization or configuration of devices, which may require that the runtime support writeable memory.
NOTE: This differs from TID-305 because this threat has a focus on code being used to manipulate the device runtime environment itself. TID-305 on the other hand pertains to a malicious program itself being used to perform device actions.
Proof of Concept
Security Issues In Compiled PLC Logic (CoDeSys & ProConOs)
At S4x23, Reid Wightman demonstrated that if memory space is shared between program runtime, program logic, and other device functions such as network handling, it is possible to create malicious programs that can manipulate a device’s runtime environment from the application program.
CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
“The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.”
CODESYS Security Advisory 2023-04 (CVE-2022-4046, CVE-2023-28355)
“The CODESYS Control V3 runtime system does not restrict the memory accesses of the PLC application code to the PLC application data and does not sufficiently check the integrity of the application code by default. This could be exploited by authenticated PLC programmers.”
If the device allows the downloading and execution of native binaries on the device, a threat actor can deploy a malicious program that leverages the environment’s privileges to gain unwanted or excessive access to the device, such as through “dangerous” system calls. These system calls could be used to manipulate the device’s firmware, maintain persistence, execute unwanted logic, or obtain a C2 channel.
Additionally, the device may assume the program comes from a trusted integrated development environment (IDE), and therefore does not restrict the privileges or system calls the program can access. However, if the threat actor compiles the program without the IDE, they can violate this assumption.
NOTE: This differs from TID-304 because this threat has a focus on a malicious program itself being used to perform device actions. TID-304 on the other hand pertains to code being used to manipulate the device runtime environment itself.
Observed Adversarial Technique
ATT&CK Technique: Exploitation for Privilege Escalation (T0890)
Procedure Example: Triton (S1009)
“Triton leverages a previously-unknown vulnerability affecting Tricon MP3008 firmware versions 10.010.4 allows an insecurely-written system call to be exploited to achieve an arbitrary 2-byte write primitive, which is then used to gain supervisor privileges.”
ATT&CK Technique: Native API (T0834)
Procedure Example: Stuxnet (S0603)
“Stuxnet calls system function blocks which are part of the operating system running on the PLC. They’re used to execute system tasks, such as reading the system clock (SFC1) and generating data blocks on the fly.”
[CWE-250: Execution with Unnecessary Privileges (Base)]
“The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.”
CVE-2018-8872
“In Schneider Electric Triconex Tricon MP model 3008 firmware versions 10.0-10.4, system calls read directly from memory addresses within the control program area without any verification. Manipulating this data could allow attacker data to be copied anywhere within memory.”
If the device allows the downloading and execution of native binaries on the device, a threat actor can deploy a malicious program that leverages the environment’s privileges to gain unwanted or excessive access to the device, such as through “dangerous” system calls. These system calls could be used to manipulate the device’s firmware, maintain persistence, execute unwanted logic, or obtain a C2 channel.
Additionally, the device may assume the program comes from a trusted integrated development environment (IDE), and therefore does not restrict the privileges or system calls the program can access. However, if the threat actor compiles the program without the IDE, they can violate this assumption.
NOTE: This differs from TID-304 because this threat has a focus on a malicious program itself being used to perform device actions. TID-304 on the other hand pertains to code being used to manipulate the device runtime environment itself.
Observed Adversarial Technique
ATT&CK Technique: Exploitation for Privilege Escalation (T0890)
Procedure Example: Triton (S1009)
“Triton leverages a previously-unknown vulnerability affecting Tricon MP3008 firmware versions 10.010.4 allows an insecurely-written system call to be exploited to achieve an arbitrary 2-byte write primitive, which is then used to gain supervisor privileges.”
ATT&CK Technique: Native API (T0834)
Procedure Example: Stuxnet (S0603)
“Stuxnet calls system function blocks which are part of the operating system running on the PLC. They’re used to execute system tasks, such as reading the system clock (SFC1) and generating data blocks on the fly.”
[CWE-250: Execution with Unnecessary Privileges (Base)]
“The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.”
CVE-2018-8872
“In Schneider Electric Triconex Tricon MP model 3008 firmware versions 10.0-10.4, system calls read directly from memory addresses within the control program area without any verification. Manipulating this data could allow attacker data to be copied anywhere within memory.”
While restricting the execution of external programs within a sandboxed execution environment can mitigate the threat of programs having excessive privileges or memory access, vulnerabilities within that environment could be exploited to escape the sandbox. This would allow the threat actor to escalate their privileges to more broadly manipulate the device’s operation and evade detections.
Proof of Concept
The Race to Native Code Execution in PLCs
Claroty demonstrated in their research that it was possible to break out of the runtime environment on a PLC and execute code natively in protected areas of memory. “Escaping the sandbox means an attacker would be able to read and write from anywhere on the PLC, and could patch an existing VM opcode in memory with malicious code to root the device.”
CWE-693: Protection Mechanism Failure
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
“A vulnerability has been identified in [Siemens devices]… Affected devices are vulnerable to a memory protection bypass through a specific operation. A remote unauthenticated attacker with network access to port 102/tcp could potentially write arbitrary data and code to protected memory areas or read sensitive data to launch further attacks.”
While restricting the execution of external programs within a sandboxed execution environment can mitigate the threat of programs having excessive privileges or memory access, vulnerabilities within that environment could be exploited to escape the sandbox. This would allow the threat actor to escalate their privileges to more broadly manipulate the device’s operation and evade detections.
Proof of Concept
The Race to Native Code Execution in PLCs
Claroty demonstrated in their research that it was possible to break out of the runtime environment on a PLC and execute code natively in protected areas of memory. “Escaping the sandbox means an attacker would be able to read and write from anywhere on the PLC, and could patch an existing VM opcode in memory with malicious code to root the device.”
CWE-693: Protection Mechanism Failure
“The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.”
“A vulnerability has been identified in [Siemens devices]… Affected devices are vulnerable to a memory protection bypass through a specific operation. A remote unauthenticated attacker with network access to port 102/tcp could potentially write arbitrary data and code to protected memory areas or read sensitive data to launch further attacks.”
Many devices that allow the execution of custom application programs, such as IEC 61131 based programs, also support “program uploads” to extract the running code from the device for various diagnostic functions. To support the program upload function, the device must provide the IDE with machine readable and human-presentable source code, rather than the executable compiled code. Therefore, the device must store two copies of the code, the source code (used to inform program upload function) and the executed compiled code. If a threat actor can modify the source code in memory, it will prevent the program upload function from accurately uploading/reporting the actual code executing on the device and allow any later downloaded malicious code to stay undetected.
Proof of Concept
The Old Switcheroo: Hiding Code on Rockwell Automation PLCs
Claroty researchers were able to edit the code representation that gets uploaded to the EWS during a program upload without having their malicious machine-code also getting uploaded. This resulted in operators seeing code after the program upload that wasn’t the actual code on the machine, which was the Claroty malicious machine code.
CWE-829: Inclusion of Functionality from Untrusted Control Sphere
“The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.”
CVE-2022-1161
“An attacker with the ability to modify a user program may change user program code on some ControlLogix, CompactLogix, and GuardLogix Control systems. Studio 5000 Logix Designer writes user-readable program code to a separate location than the executed compiled code allowing an attacker to change one and not the other.”
Many devices that allow the execution of custom application programs, such as IEC 61131 based programs, also support “program uploads” to extract the running code from the device for various diagnostic functions. To support the program upload function, the device must provide the IDE with machine readable and human-presentable source code, rather than the executable compiled code. Therefore, the device must store two copies of the code, the source code (used to inform program upload function) and the executed compiled code. If a threat actor can modify the source code in memory, it will prevent the program upload function from accurately uploading/reporting the actual code executing on the device and allow any later downloaded malicious code to stay undetected.
Proof of Concept
The Old Switcheroo: Hiding Code on Rockwell Automation PLCs
Claroty researchers were able to edit the code representation that gets uploaded to the EWS during a program upload without having their malicious machine-code also getting uploaded. This resulted in operators seeing code after the program upload that wasn’t the actual code on the machine, which was the Claroty malicious machine code.
CWE-829: Inclusion of Functionality from Untrusted Control Sphere
“The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.”
CVE-2022-1161
“An attacker with the ability to modify a user program may change user program code on some ControlLogix, CompactLogix, and GuardLogix Control systems. Studio 5000 Logix Designer writes user-readable program code to a separate location than the executed compiled code allowing an attacker to change one and not the other.”
The threat actor can overwrite a previously deployed/installed malicious program with a dummy program in order to evade the detection of the malicious program. This can be used to prevent detection by monitoring tools or engineering software that performs periodic “Program Uploads” to inspect the contents of a program on the device.
While some devices utilize error detection codes, such as CRCs or Checksums, these are not cryptographically strong and a threat actor can easily generate a program with the same CRC/Checksum (i.e., by simply padding the program).
Observed Adversarial Technique
ATT&CK Technique: Indicator Removal on Host (T0872)
Procedure Example: Triton (S1009)
“Triton would reset the controller to the previous state over TriStation and if this failed it would write a dummy program to memory in what was likely an attempt at anti-forensics.”
CWE-223: Omission of Security-relevant Information
“The product does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.”
CWE-778: Insufficient Logging
“When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.”
The threat actor can overwrite a previously deployed/installed malicious program with a dummy program in order to evade the detection of the malicious program. This can be used to prevent detection by monitoring tools or engineering software that performs periodic “Program Uploads” to inspect the contents of a program on the device.
While some devices utilize error detection codes, such as CRCs or Checksums, these are not cryptographically strong and a threat actor can easily generate a program with the same CRC/Checksum (i.e., by simply padding the program).
Observed Adversarial Technique
ATT&CK Technique: Indicator Removal on Host (T0872)
Procedure Example: Triton (S1009)
“Triton would reset the controller to the previous state over TriStation and if this failed it would write a dummy program to memory in what was likely an attempt at anti-forensics.”
CWE-223: Omission of Security-relevant Information
“The product does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.”
CWE-778: Insufficient Logging
“When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.”
If the integrated development environment (IDE) or vendor software that is used to manage a device is not sufficiently secure, it could be exploited or crashed when it connects to the device, such as during a file transfer or program upload. A threat actor could use a compromised device, such as a PLC, to exploit a vulnerability within the engineering software/IDE used to manage that device. This could be used to (i) gain unauthorized access to the workstation, (ii) perform a DoS on the workstation, or (iii) propagate to other devices managed by that workstation.
Proof of Concept
EVIL PLC ATTACK: WEAPONIZING PLCS
Claroty was able to install a malicious program on the PLC that would infect a connected EWS upon a program upload. In some cases, they were able to achieve arbitrary code execution on the EWS.
Denial of Engineering Operations Attacks in Industrial Control Systems
“Specifcally, the attacker can deceive the engineering software during attempts to retrieve the ladder logic program from a programmable logic controller (PLC) by manipulating the ladder logic on the PLC, such that the software is unable to process it while the PLC continues to execute it successfully. This attack vector can provide sufficient cover for the attacker’s actual scenario to play out while the owner tries to understand the problem and reestablish positive operational control.”
CWE-20: Improper Input Validation
“The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.”
CVE-2021-22289
“Improper Input Validation vulnerability in the project upload mechanism in B&R Automation Studio version >4.0 may allow an unauthenticated network attacker to execute code.”
If the integrated development environment (IDE) or vendor software that is used to manage a device is not sufficiently secure, it could be exploited or crashed when it connects to the device, such as during a file transfer or program upload. A threat actor could use a compromised device, such as a PLC, to exploit a vulnerability within the engineering software/IDE used to manage that device. This could be used to (i) gain unauthorized access to the workstation, (ii) perform a DoS on the workstation, or (iii) propagate to other devices managed by that workstation.
Proof of Concept
EVIL PLC ATTACK: WEAPONIZING PLCS
Claroty was able to install a malicious program on the PLC that would infect a connected EWS upon a program upload. In some cases, they were able to achieve arbitrary code execution on the EWS.
Denial of Engineering Operations Attacks in Industrial Control Systems
“Specifcally, the attacker can deceive the engineering software during attempts to retrieve the ladder logic program from a programmable logic controller (PLC) by manipulating the ladder logic on the PLC, such that the software is unable to process it while the PLC continues to execute it successfully. This attack vector can provide sufficient cover for the attacker’s actual scenario to play out while the owner tries to understand the problem and reestablish positive operational control.”
CWE-20: Improper Input Validation
“The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.”
CVE-2021-22289
“Improper Input Validation vulnerability in the project upload mechanism in B&R Automation Studio version >4.0 may allow an unauthenticated network attacker to execute code.”
If an application does not authenticate all connections from a remote device or system, a threat actor can remotely establish a connection to the device to access confidential data or make unwanted changes to device status or configuration.
Observed Adversary Technique
ATT&CK Technique: Unauthorized Command Message (T0855)
Procedure Example: Industroyer (S0604)
“Using its protocol payloads, Industroyer sends unauthorized commands to RTUs to change the state of equipment.”
Procedure Example: Industroyer2 (S1072)
“Industroyer2 is capable of sending command messages from the compromised device to target remote stations to open data channels, retrieve the location and values of Information Object Addresses (IOAs), and modify the IO state values through Select Before Operate I/O, Select/Execute, and Invert Default State operations.”
CWE-285: Improper Authorization
“The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.”
If an application does not authenticate all connections from a remote device or system, a threat actor can remotely establish a connection to the device to access confidential data or make unwanted changes to device status or configuration.
Observed Adversary Technique
ATT&CK Technique: Unauthorized Command Message (T0855)
Procedure Example: Industroyer (S0604)
“Using its protocol payloads, Industroyer sends unauthorized commands to RTUs to change the state of equipment.”
Procedure Example: Industroyer2 (S1072)
“Industroyer2 is capable of sending command messages from the compromised device to target remote stations to open data channels, retrieve the location and values of Information Object Addresses (IOAs), and modify the IO state values through Select Before Operate I/O, Select/Execute, and Invert Default State operations.”
CWE-285: Improper Authorization
“The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.”
Devices often include default credentials from the vendor. Default credentials can be changed, but are often overlooked when devices are commissioned. If left unchanged, a threat actor may discover and use these credentials to gain unauthorized access to the device. Non-unique or predictable default credentials can lead to device compromise.
Observed Adversarial Technique
IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including U.S. Water and Wastewater Systems Facilities
“Since at least November 22, 2023, these IRGC-affiliated cyber actors have continued to compromise default credentials in Unitronics devices.”
CWE-1392: Use of Default Credentials (Base)
“The product uses default credentials (such as passwords or cryptographic keys) for potentially critical functionality.”
CWE-1393: Use of Default Password (Base)
“The product uses default passwords for potentially critical functionality.”
ICEFALL - CVE-2022-29962
“The Emerson DeltaV Distributed Control System (DCS) controllers and IO cards through 2022-04-29 misuse passwords. FTP has hardcoded credentials (but may often be disabled in production).”
CVE-2021-22681, CISA Alert
A hardcoded key in the Studio 5000 Logix Designer software and related PLCs would allow actors who can extract the key from the software to authenticate to controllers without going through the software or normal authentication process.
Devices often include default credentials from the vendor. Default credentials can be changed, but are often overlooked when devices are commissioned. If left unchanged, a threat actor may discover and use these credentials to gain unauthorized access to the device. Non-unique or predictable default credentials can lead to device compromise.
Observed Adversarial Technique
IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including U.S. Water and Wastewater Systems Facilities
“Since at least November 22, 2023, these IRGC-affiliated cyber actors have continued to compromise default credentials in Unitronics devices.”
CWE-1392: Use of Default Credentials (Base)
“The product uses default credentials (such as passwords or cryptographic keys) for potentially critical functionality.”
CWE-1393: Use of Default Password (Base)
“The product uses default passwords for potentially critical functionality.”
ICEFALL - CVE-2022-29962
“The Emerson DeltaV Distributed Control System (DCS) controllers and IO cards through 2022-04-29 misuse passwords. FTP has hardcoded credentials (but may often be disabled in production).”
CVE-2021-22681, CISA Alert
A hardcoded key in the Studio 5000 Logix Designer software and related PLCs would allow actors who can extract the key from the software to authenticate to controllers without going through the software or normal authentication process.
A device’s credential change mechanisms can be abused to lock out users from their own devices by changing credentials to something unknown to the legitimate user. This could impair the legitimate user from accessing the device and may also render the device permanently inoperable. This could also be coupled with unwanted device configuration changes before the user is locked out.
Observed Adversarial Technique
ATT&CK Technique: Change Credential (T0892)
“A chain of incidents occurred in Germany, where adversaries locked operators out of their building automation system (BAS) controllers by enabling a previously unset BCU key.”
ATT&CK Technique: Account Access Removal (T1531)
“Accounts may be deleted, locked, or manipulated (ex: changed credentials) to remove access to accounts.”
CWE-645: Overly Restrictive Account Lockout Mechanism (Base)
“The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.”
Kunbus PR100088 Modbus Gateway (Update B) | CISA, CVE-2019-6527
“PR100088 Modbus gateway versions prior to Release R02 (or Software Version 1.1.13166) may allow an attacker to be able to change the password for an admin user who is currently or previously logged in, provided the device has not been restarted.”
A device’s credential change mechanisms can be abused to lock out users from their own devices by changing credentials to something unknown to the legitimate user. This could impair the legitimate user from accessing the device and may also render the device permanently inoperable. This could also be coupled with unwanted device configuration changes before the user is locked out.
Observed Adversarial Technique
ATT&CK Technique: Change Credential (T0892)
“A chain of incidents occurred in Germany, where adversaries locked operators out of their building automation system (BAS) controllers by enabling a previously unset BCU key.”
ATT&CK Technique: Account Access Removal (T1531)
“Accounts may be deleted, locked, or manipulated (ex: changed credentials) to remove access to accounts.”
CWE-645: Overly Restrictive Account Lockout Mechanism (Base)
“The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.”
Kunbus PR100088 Modbus Gateway (Update B) | CISA, CVE-2019-6527
“PR100088 Modbus gateway versions prior to Release R02 (or Software Version 1.1.13166) may allow an attacker to be able to change the password for an admin user who is currently or previously logged in, provided the device has not been restarted.”
A threat actor can change or reset a password or credential without being authenticated. This can be used by a threat actor to set the credential to a known value and then use this to authenticate to the device.
Known Exploitable Weakness
ATT&CK Technique: Create Account: Local Account (T1136.001)
“Adversaries may create a local account to maintain access to victim systems. Local accounts are those configured by an organization for use by users, remote support, services, or for administration on a single system or service.”
CWE-287: Improper Authentication
“When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.”
Kunbus PR100088 Modbus Gateway (Update B) | CISA, CVE-2019-6527
“An attacker may be able change the password for an admin user who is currently or previously logged in, provided the device has not been restarted.”
A threat actor can change or reset a password or credential without being authenticated. This can be used by a threat actor to set the credential to a known value and then use this to authenticate to the device.
Known Exploitable Weakness
ATT&CK Technique: Create Account: Local Account (T1136.001)
“Adversaries may create a local account to maintain access to victim systems. Local accounts are those configured by an organization for use by users, remote support, services, or for administration on a single system or service.”
CWE-287: Improper Authentication
“When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.”
Kunbus PR100088 Modbus Gateway (Update B) | CISA, CVE-2019-6527
“An attacker may be able change the password for an admin user who is currently or previously logged in, provided the device has not been restarted.”
A threat actor could gain unauthorized access by continually guessing passwords. This could be because the device allows passwords with insufficient entropy, short password lengths, or does not have a mechanism to increase the time it takes to randomly guess passwords, such as password lockouts or cooldowns between guesses.
Observed Adversary Behavior
APT Cyber Tools Targeting ICS/SCADA Devices
“Brute-force Schneider Electric PLC passwords using CODESYS and other available device protocols via UDP port 1740 against defaults or a dictionary word list (Note: this capability may work against other CODESYS-based devices depending on individual design and function, and this report will be updated as more information becomes available);”
CWE-334: Small Space of Random Values
“The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.”
CWE-307: Improper Restriction of Excessive Authentication Attempts
“The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks.”
A threat actor could gain unauthorized access by continually guessing passwords. This could be because the device allows passwords with insufficient entropy, short password lengths, or does not have a mechanism to increase the time it takes to randomly guess passwords, such as password lockouts or cooldowns between guesses.
Observed Adversary Behavior
APT Cyber Tools Targeting ICS/SCADA Devices
“Brute-force Schneider Electric PLC passwords using CODESYS and other available device protocols via UDP port 1740 against defaults or a dictionary word list (Note: this capability may work against other CODESYS-based devices depending on individual design and function, and this report will be updated as more information becomes available);”
CWE-334: Small Space of Random Values
“The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.”
CWE-307: Improper Restriction of Excessive Authentication Attempts
“The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks.”
If the device includes a password retrieval mechanism, a threat actor could use that mechanism to retrieve a valid credential and then access the device. Password retrieval functions are typically intended to be used to support access from dedicated device management tools, but these functions may be reverse engineered and then initiated by the threat actor to gain valid credentials on a device.
Proof of Concept
AutomationDirect DirectLOGIC with Serial Communication - CVE-2022-2003, Research By Sam Hanson of Dragos
“The product is vulnerable to a specifically crafted serial message to the CPU serial port that will cause the PLC to respond with the PLC password in cleartext. This could allow an attacker to access and make unauthorized changes.”
CWE-319: Cleartext Transmission of Sensitive Information
“The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.”
CVE-2022-2003
“The product is vulnerable to a specifically crafted serial message to the CPU serial port that will cause the PLC to respond with the PLC password in cleartext. This could allow an attacker to access and make unauthorized changes.”
CVE-2022-31205
“The password to access the Web UI can be read from memory using the Omron FINS protocol without any further authentication.”
If the device includes a password retrieval mechanism, a threat actor could use that mechanism to retrieve a valid credential and then access the device. Password retrieval functions are typically intended to be used to support access from dedicated device management tools, but these functions may be reverse engineered and then initiated by the threat actor to gain valid credentials on a device.
Proof of Concept
AutomationDirect DirectLOGIC with Serial Communication - CVE-2022-2003, Research By Sam Hanson of Dragos
“The product is vulnerable to a specifically crafted serial message to the CPU serial port that will cause the PLC to respond with the PLC password in cleartext. This could allow an attacker to access and make unauthorized changes.”
CWE-319: Cleartext Transmission of Sensitive Information
“The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.”
CVE-2022-2003
“The product is vulnerable to a specifically crafted serial message to the CPU serial port that will cause the PLC to respond with the PLC password in cleartext. This could allow an attacker to access and make unauthorized changes.”
CVE-2022-31205
“The password to access the Web UI can be read from memory using the Omron FINS protocol without any further authentication.”
Certificate-based authentication depends on the correct parsing and validation of an X.509 certificate. However, if the certificate is not properly parsed and all fields are not validated, a threat actor could potentially bypass authentication using a fraudulent certificate.
Known Exploitable Weakness
CVE-2020-0601
“Microsoft Windows CryptoAPI (Crypt32.dll) contains a spoofing vulnerability in the way it validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. A successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software. The vulnerability is also known under the moniker of CurveBall.”
CVE-2023-41991
“Apple iOS, iPadOS, macOS, and watchOS contain an improper certificate validation vulnerability that can allow a malicious app to bypass signature validation.”
Vulnerability Spotlight: WolfSSL library X.509 Certificate Text Parsing Code Execution Vulnerability
“Talos is disclosing TALOS-2017-0293 / CVE 2017-2800, a code execution vulnerability in WolfSSL. WolfSSL is a lightweight SSL/TLS library targeted specifically for embedded and RTOS (Real-Time Operating System) environments, due largely to its small size and performance. WolfSSL is used in a wide range of products including ICS and IoT devices.”
Siemens RuggedCom ROX-based Devices Certificate Verification Vulnerability and GnuTLS Certificate Error handling Vulnerability, CVE-2014-0092
“lib/x509/verify.c in GnuTLS before 3.1.22 and 3.2.x before 3.2.12 does not properly handle unspecified errors when verifying X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers via a crafted certificate.”
Certificate-based authentication depends on the correct parsing and validation of an X.509 certificate. However, if the certificate is not properly parsed and all fields are not validated, a threat actor could potentially bypass authentication using a fraudulent certificate.
Known Exploitable Weakness
CVE-2020-0601
“Microsoft Windows CryptoAPI (Crypt32.dll) contains a spoofing vulnerability in the way it validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. A successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software. The vulnerability is also known under the moniker of CurveBall.”
CVE-2023-41991
“Apple iOS, iPadOS, macOS, and watchOS contain an improper certificate validation vulnerability that can allow a malicious app to bypass signature validation.”
Vulnerability Spotlight: WolfSSL library X.509 Certificate Text Parsing Code Execution Vulnerability
“Talos is disclosing TALOS-2017-0293 / CVE 2017-2800, a code execution vulnerability in WolfSSL. WolfSSL is a lightweight SSL/TLS library targeted specifically for embedded and RTOS (Real-Time Operating System) environments, due largely to its small size and performance. WolfSSL is used in a wide range of products including ICS and IoT devices.”
Siemens RuggedCom ROX-based Devices Certificate Verification Vulnerability and GnuTLS Certificate Error handling Vulnerability, CVE-2014-0092
“lib/x509/verify.c in GnuTLS before 3.1.22 and 3.2.x before 3.2.12 does not properly handle unspecified errors when verifying X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers via a crafted certificate.”
If the device does not generate sufficiently random cryptographic primitives, a threat actor could predict or brute-force guess a key to either gain unauthorized access to the device or decrypt a connection. Cryptographic keys that are not generated with random “seed” information, including from Pseudo-Random Number Generators (PRNG), will lack sufficient entropy. For example, researchers have demonstrated that a large number of Internet exposed devices with TLS or SSH services utilized the same RSA moduli, which could be then used to determine the device’s private key and then used to remotely authenticate with the device.
Proof of Concept
Heninger, N. et al. “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices”
Researchers demonstrated that many internet connected devices had insufficient randomness in their TLS certificates. Additionaly, many of these devices had the same key as other devices. Lastly, for some of these keys, it was possible for researchers to derive private keys.
CWE-331: Insufficient Entropy (Base)
“The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.”
CWE-338: Use of Cryptographically Weak
Pseudo-Random Number Generator (PRNG) (Base) “The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG’s algorithm is not cryptographically strong.”
Honeywell OneWireless Wireless Device Manager | CISA - CVE-2022-43485
“Use of Insufficiently Random Values in Honeywell OneWireless. This vulnerability may allow attacker to manipulate claims in client’s JWT token. This issue affects OneWireless version 322.1”
Tropos Wireless Mesh Routers | CISA - CVE-2012-4898
“Mesh OS before 7.9.1.1 on Tropos wireless mesh routers does not use a sufficient source of entropy for SSH keys, which makes it easier for man-in-the-middle attackers to spoof a device or modify a client-server data stream by leveraging knowledge of a key from a product installation elsewhere.”
If the device does not generate sufficiently random cryptographic primitives, a threat actor could predict or brute-force guess a key to either gain unauthorized access to the device or decrypt a connection. Cryptographic keys that are not generated with random “seed” information, including from Pseudo-Random Number Generators (PRNG), will lack sufficient entropy. For example, researchers have demonstrated that a large number of Internet exposed devices with TLS or SSH services utilized the same RSA moduli, which could be then used to determine the device’s private key and then used to remotely authenticate with the device.
Proof of Concept
Heninger, N. et al. “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices”
Researchers demonstrated that many internet connected devices had insufficient randomness in their TLS certificates. Additionaly, many of these devices had the same key as other devices. Lastly, for some of these keys, it was possible for researchers to derive private keys.
CWE-331: Insufficient Entropy (Base)
“The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.”
CWE-338: Use of Cryptographically Weak
Pseudo-Random Number Generator (PRNG) (Base) “The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG’s algorithm is not cryptographically strong.”
Honeywell OneWireless Wireless Device Manager | CISA - CVE-2022-43485
“Use of Insufficiently Random Values in Honeywell OneWireless. This vulnerability may allow attacker to manipulate claims in client’s JWT token. This issue affects OneWireless version 322.1”
Tropos Wireless Mesh Routers | CISA - CVE-2012-4898
“Mesh OS before 7.9.1.1 on Tropos wireless mesh routers does not use a sufficient source of entropy for SSH keys, which makes it easier for man-in-the-middle attackers to spoof a device or modify a client-server data stream by leveraging knowledge of a key from a product installation elsewhere.”
The device uses a cryptographic library or implementation that either introduces an additional software vulnerability within the library. A threat actor can exploit these weaknesses or vulnerablities to gain unauthorized access to the device or bypass the protections provided by the cryptographic protocol.
Observed Adversary Use
Attackers Exploit the Heartbleed OpenSSL Vulnerability to Circumvent Multi-factor Authentication on VPNs
“Beginning on April 8, an attacker leveraged the Heartbleed vulnerability against a VPN appliance and hijacked multiple active user sessions. Specifically, the attacker repeatedly sent malformed heartbeat requests to the HTTPS web server running on the VPN device, which was compiled with a vulnerable version of OpenSSL, to obtain active session tokens for currently authenticated users. With an active session token, the attacker successfully hijacked multiple active user sessions and convinced the VPN concentrator that he/she was legitimately authenticated. The attack bypassed both the organization’s multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software.”
Heartbleed Bug and Subsequent Exploitation
CVE-2014-0160
“The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.”
Siemens RuggedCom ROX-based Devices Certificate Verification Vulnerability and GnuTLS Certificate Error handling Vulnerability
CVE-2014-0092
“lib/x509/verify.c in GnuTLS before 3.1.22 and 3.2.x before 3.2.12 does not properly handle unspecified errors when verifying X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers via a crafted certificate.”
The device uses a cryptographic library or implementation that either introduces an additional software vulnerability within the library. A threat actor can exploit these weaknesses or vulnerablities to gain unauthorized access to the device or bypass the protections provided by the cryptographic protocol.
Observed Adversary Use
Attackers Exploit the Heartbleed OpenSSL Vulnerability to Circumvent Multi-factor Authentication on VPNs
“Beginning on April 8, an attacker leveraged the Heartbleed vulnerability against a VPN appliance and hijacked multiple active user sessions. Specifically, the attacker repeatedly sent malformed heartbeat requests to the HTTPS web server running on the VPN device, which was compiled with a vulnerable version of OpenSSL, to obtain active session tokens for currently authenticated users. With an active session token, the attacker successfully hijacked multiple active user sessions and convinced the VPN concentrator that he/she was legitimately authenticated. The attack bypassed both the organization’s multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software.”
Heartbleed Bug and Subsequent Exploitation
CVE-2014-0160
“The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.”
Siemens RuggedCom ROX-based Devices Certificate Verification Vulnerability and GnuTLS Certificate Error handling Vulnerability
CVE-2014-0092
“lib/x509/verify.c in GnuTLS before 3.1.22 and 3.2.x before 3.2.12 does not properly handle unspecified errors when verifying X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers via a crafted certificate.”
The device does not properly restrict, filter, or validate the content of web-based requests or outputs, especially content used to construct HTTP or JavaScript elements within a web page. A threat actor can add malicious JavaScript to an HTTP request, including through a GET/POST parameter or HTTP header fields, which then executes on the browser of an unsuspecting user. The malicious JavaScript can then be used to steal session tokens or send malicious requests (especially leveraging XMLHttpRequest) to change device configurations or data.
Known Exploitable Weakness
ATT&CK Technique: Drive-by Compromise (T1189)
“Multiple ways of delivering exploit code to a browser exist (i.e., Drive-by Target), including: A legitimate website is compromised where adversaries have injected some form of malicious code such as JavaScript, iFrames, and cross-site scripting.”
CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) (Base)
“The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.”
NetComm Wireless 4G LTE Light Industrial M2M Router - CVE-2018-14784
“The device is vulnerable to several cross-site scripting attacks, allowing a remote attacker to run arbitrary code on the device.”
Siemens SIMATIC S7-1500 CPU Firmware Vulnerabilities, CISA
“The integrated web server may … be vulnerable to cross-site request forgery (CSRF), cross-site scripting (XSS), header injection, and open redirect attacks as well as privilege escalation.”
The device does not properly restrict, filter, or validate the content of web-based requests or outputs, especially content used to construct HTTP or JavaScript elements within a web page. A threat actor can add malicious JavaScript to an HTTP request, including through a GET/POST parameter or HTTP header fields, which then executes on the browser of an unsuspecting user. The malicious JavaScript can then be used to steal session tokens or send malicious requests (especially leveraging XMLHttpRequest) to change device configurations or data.
Known Exploitable Weakness
ATT&CK Technique: Drive-by Compromise (T1189)
“Multiple ways of delivering exploit code to a browser exist (i.e., Drive-by Target), including: A legitimate website is compromised where adversaries have injected some form of malicious code such as JavaScript, iFrames, and cross-site scripting.”
CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) (Base)
“The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.”
NetComm Wireless 4G LTE Light Industrial M2M Router - CVE-2018-14784
“The device is vulnerable to several cross-site scripting attacks, allowing a remote attacker to run arbitrary code on the device.”
Siemens SIMATIC S7-1500 CPU Firmware Vulnerabilities, CISA
“The integrated web server may … be vulnerable to cross-site request forgery (CSRF), cross-site scripting (XSS), header injection, and open redirect attacks as well as privilege escalation.”
The device does not property restrict, filter, or validate the content of web-based requests, especially content used to construct SQL commands or HTTP pages. A threat actor can add malicious content to these messages to cause unwanted code to execute on the device. SQL injection can be used to execute unauthorized commands (e.g., xp_cmdshell), or to manipulate or extract sensitive data within the database.
Known Exploitable Weakness
ATT&CK Technique: Server Software Component: SQL Stored Procedures (T1505.001)
Procedure Example: Stuxnet (S0603)
“Stuxnet used xp_cmdshell to store and execute SQL code.”
ATT&CK Technique: Exploit Public-Facing Application (T1190)
Various threat actors have leveraged SQL injection to gain initial access to publicly facing web applications, including APT28, APT 39, and DragonFly.
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
“The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.”
CSWorks Software SQL Injection Vulnerability, CISA - CVE-2014-2351
“The CSWorks software does not properly sanitize or validate the data used to construct read and write paths, which may make applications built with the affected product to be susceptible to an SQL injection attack. Depending on the intended use of the application, an attacker may be able to exploit this vulnerability to achieve remote code execution.”
Navis WebAccess SQL Injection Vulnerability, CISA
“The WebAccess application does not properly sanitize input that may allow a remote attacker to read, modify, and affect availability of data in the SQL database.”
The device does not property restrict, filter, or validate the content of web-based requests, especially content used to construct SQL commands or HTTP pages. A threat actor can add malicious content to these messages to cause unwanted code to execute on the device. SQL injection can be used to execute unauthorized commands (e.g., xp_cmdshell), or to manipulate or extract sensitive data within the database.
Known Exploitable Weakness
ATT&CK Technique: Server Software Component: SQL Stored Procedures (T1505.001)
Procedure Example: Stuxnet (S0603)
“Stuxnet used xp_cmdshell to store and execute SQL code.”
ATT&CK Technique: Exploit Public-Facing Application (T1190)
Various threat actors have leveraged SQL injection to gain initial access to publicly facing web applications, including APT28, APT 39, and DragonFly.
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
“The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.”
CSWorks Software SQL Injection Vulnerability, CISA - CVE-2014-2351
“The CSWorks software does not properly sanitize or validate the data used to construct read and write paths, which may make applications built with the affected product to be susceptible to an SQL injection attack. Depending on the intended use of the application, an attacker may be able to exploit this vulnerability to achieve remote code execution.”
Navis WebAccess SQL Injection Vulnerability, CISA
“The WebAccess application does not properly sanitize input that may allow a remote attacker to read, modify, and affect availability of data in the SQL database.”
A threat actor can hijack an insufficiently protected HTTP session token to gain unauthorized access to a device. HTTP session tokens can be obtained by a threat actor if they’re sent unencrypted over the network or if the site is vulnerable to cross-site scripting (XSS).
Known Exploitable Weakness
ATT&CK T1539 Steal Web Session Cookie
“An adversary may steal web application or service session cookies and use them to gain access to web applications or Internet services as an authenticated user without needing credentials.”
CWE-384: Session Fixation (Composite)
“Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.”
Siemens SICAM Q100 - CVE-2022-43398
Siemens SICAM Q100 devices does not renew session tokens/cookies between logins.
MOXA NPort IAW5000A-I/O Series - CVE-2020-25198
The built-in WEB server for MOXA NPort IAW5000A-I/O firmware version 2.1 or lower has incorrectly implemented protections from session fixation, which may allow an attacker to gain access to a session and hijack it by stealing the user’s cookies.
A threat actor can hijack an insufficiently protected HTTP session token to gain unauthorized access to a device. HTTP session tokens can be obtained by a threat actor if they’re sent unencrypted over the network or if the site is vulnerable to cross-site scripting (XSS).
Known Exploitable Weakness
ATT&CK T1539 Steal Web Session Cookie
“An adversary may steal web application or service session cookies and use them to gain access to web applications or Internet services as an authenticated user without needing credentials.”
CWE-384: Session Fixation (Composite)
“Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.”
Siemens SICAM Q100 - CVE-2022-43398
Siemens SICAM Q100 devices does not renew session tokens/cookies between logins.
MOXA NPort IAW5000A-I/O Series - CVE-2020-25198
The built-in WEB server for MOXA NPort IAW5000A-I/O firmware version 2.1 or lower has incorrectly implemented protections from session fixation, which may allow an attacker to gain access to a session and hijack it by stealing the user’s cookies.
If a threat actor can include malicious JavaScript within a page viewed by a legitimate device user, that script can send malicious authenticated HTTP requests (using XMLHttpRequest) to the device. Due to the Same Origin Policy defined by most web browsers, the HTTP requests sent to the device will include any valid session tokens the user/browser has previously established for that device. Therefore, this could be used to send malicious requests to a device to change key functions or configurations, including changing device credentials. This requires that the threat actor tricks the user into viewing another page while they have an authenticated session with the device.
Observed Adversarial Technique
Router Exploit Kits: An overview of RouterCSRF attacks and DNS hijacking in Brazil
“From February 1 until March 30, 2019, Avast’s Web Shield blocked more than 4.6 million cross-site request forgery (CSRF) web-based attacks in Brazil, attempting to silently modify DNS settings on routers.”
Web-based attack targeting home routers, the Brazilian way
“We spotted an interesting attack from Brazilian bad guys aiming to change the DNS settings of home routers by using a web-based attack, some social engineering, and malicious websites. In these attacks the malicious DNS servers configured in the user’s network device are pointed towards phishing pages of Brazilian Banks, programmed to steal financial credentials.”
CWE-352: Cross-Site Request Forgery (CSRF) (Compound)
“The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.”
XZERES 442SR Wind Turbine CSRF Vulnerability - CVE-2015-3950 “The 442SR OS recognizes both the POST and GET methods for data input. By using the GET method, an attacker may retrieve the ID from the browser and will allow the default user ID to be changed. The default user has admin rights to the entire system.”
Fox DataDiode Proxy Server CSRF Vulnerability - CVE-2014-2358
“The administrative web interface of the Fox DataDiode proxy server is vulnerable to CSRF. By changing the configuration, the attacker can effectively disrupt the flow of information through the Fox DataDiode, resulting in a DoS.”
Siemens SIMATIC S7-1200 CSRF Vulnerability - CVE-2015-5698
“The integrated web server (Port 80/TCP and Port 443/TCP) of the affected programmable logic controllers (PLCs) could allow remote attackers to perform actions with the permissions of a victim user, provided the victim user has an active session and is induced to trigger the malicious request.”
Schneider Electric ION Power Meter CSRF Vulnerability
“NCCIC/ICS-CERT is aware of a public report of a cross site request forgery (CSRF) vulnerability with proof-of-concept (PoC) exploit code affecting Schneider Electric’s ION Power Meter products. According to this report, exploitation of this vulnerability can allow unauthorized actions on the device, such as configuration parameter changes and saving modified configuration.”
NetComm Wireless 4G LTE Light Industrial M2M Router - CVE-2018-14783
“A cross-site request forgery condition can occur, allowing an attacker to change passwords of the device remotely.”
If a threat actor can include malicious JavaScript within a page viewed by a legitimate device user, that script can send malicious authenticated HTTP requests (using XMLHttpRequest) to the device. Due to the Same Origin Policy defined by most web browsers, the HTTP requests sent to the device will include any valid session tokens the user/browser has previously established for that device. Therefore, this could be used to send malicious requests to a device to change key functions or configurations, including changing device credentials. This requires that the threat actor tricks the user into viewing another page while they have an authenticated session with the device.
Observed Adversarial Technique
Router Exploit Kits: An overview of RouterCSRF attacks and DNS hijacking in Brazil
“From February 1 until March 30, 2019, Avast’s Web Shield blocked more than 4.6 million cross-site request forgery (CSRF) web-based attacks in Brazil, attempting to silently modify DNS settings on routers.”
Web-based attack targeting home routers, the Brazilian way
“We spotted an interesting attack from Brazilian bad guys aiming to change the DNS settings of home routers by using a web-based attack, some social engineering, and malicious websites. In these attacks the malicious DNS servers configured in the user’s network device are pointed towards phishing pages of Brazilian Banks, programmed to steal financial credentials.”
CWE-352: Cross-Site Request Forgery (CSRF) (Compound)
“The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.”
XZERES 442SR Wind Turbine CSRF Vulnerability - CVE-2015-3950 “The 442SR OS recognizes both the POST and GET methods for data input. By using the GET method, an attacker may retrieve the ID from the browser and will allow the default user ID to be changed. The default user has admin rights to the entire system.”
Fox DataDiode Proxy Server CSRF Vulnerability - CVE-2014-2358
“The administrative web interface of the Fox DataDiode proxy server is vulnerable to CSRF. By changing the configuration, the attacker can effectively disrupt the flow of information through the Fox DataDiode, resulting in a DoS.”
Siemens SIMATIC S7-1200 CSRF Vulnerability - CVE-2015-5698
“The integrated web server (Port 80/TCP and Port 443/TCP) of the affected programmable logic controllers (PLCs) could allow remote attackers to perform actions with the permissions of a victim user, provided the victim user has an active session and is induced to trigger the malicious request.”
Schneider Electric ION Power Meter CSRF Vulnerability
“NCCIC/ICS-CERT is aware of a public report of a cross site request forgery (CSRF) vulnerability with proof-of-concept (PoC) exploit code affecting Schneider Electric’s ION Power Meter products. According to this report, exploitation of this vulnerability can allow unauthorized actions on the device, such as configuration parameter changes and saving modified configuration.”
NetComm Wireless 4G LTE Light Industrial M2M Router - CVE-2018-14783
“A cross-site request forgery condition can occur, allowing an attacker to change passwords of the device remotely.”
A threat actor can send requests for files or content that resides in different directories from those intended to be accessible by the a web server. This can be used to gain access to data that is not intended to be remotely accessible through the web servers, such as files from the operating system or other applications. This threat is primarily a result of the web server having excessive privileges regarding files and directories on the device
Observed Adversary Behavior
Fortinet FortiOS SSL VPN Path Traversal Vulnerability
“Fortinet FortiOS SSL VPN web portal contains a path traversal vulnerability that may allow an unauthenticated attacker to download FortiOS system files through specially crafted HTTP resource requests.”
CWE-22: Path Traversal
“The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.”
CVE-2018-13379
“An Improper Limitation of a Pathname to a Restricted Directory (“Path Traversal”) in Fortinet FortiOS 6.0.0 to 6.0.4, 5.6.3 to 5.6.7 and 5.4.6 to 5.4.12 and FortiProxy 2.0.0, 1.2.0 to 1.2.8, 1.1.0 to 1.1.6, 1.0.0 to 1.0.7 under SSL VPN web portal allows an unauthenticated attacker to download system files via special crafted HTTP resource requests.”
CVE-2023-39810
“An issue in the CPIO command of Busybox v1.33.2 allows attackers to execute a directory traversal.”
IDS RTU 850 Directory Traversal Vulnerability - CVE-2015-3939
“Using this vulnerability, an attacker is able to access some files from the internal service interface of the communication module. One of the accessible files contains the credentials (passwords) to access the internal service interface via telnet.”
Honeywell XL Web Controller Directory Traversal Vulnerability - CVE-2015-0984
“By using a directory traversal vulnerability in the FTP server, it is possible to gain access to the web root directory.”
A threat actor can send requests for files or content that resides in different directories from those intended to be accessible by the a web server. This can be used to gain access to data that is not intended to be remotely accessible through the web servers, such as files from the operating system or other applications. This threat is primarily a result of the web server having excessive privileges regarding files and directories on the device
Observed Adversary Behavior
Fortinet FortiOS SSL VPN Path Traversal Vulnerability
“Fortinet FortiOS SSL VPN web portal contains a path traversal vulnerability that may allow an unauthenticated attacker to download FortiOS system files through specially crafted HTTP resource requests.”
CWE-22: Path Traversal
“The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.”
CVE-2018-13379
“An Improper Limitation of a Pathname to a Restricted Directory (“Path Traversal”) in Fortinet FortiOS 6.0.0 to 6.0.4, 5.6.3 to 5.6.7 and 5.4.6 to 5.4.12 and FortiProxy 2.0.0, 1.2.0 to 1.2.8, 1.1.0 to 1.1.6, 1.0.0 to 1.0.7 under SSL VPN web portal allows an unauthenticated attacker to download system files via special crafted HTTP resource requests.”
CVE-2023-39810
“An issue in the CPIO command of Busybox v1.33.2 allows attackers to execute a directory traversal.”
IDS RTU 850 Directory Traversal Vulnerability - CVE-2015-3939
“Using this vulnerability, an attacker is able to access some files from the internal service interface of the communication module. One of the accessible files contains the credentials (passwords) to access the internal service interface via telnet.”
Honeywell XL Web Controller Directory Traversal Vulnerability - CVE-2015-0984
“By using a directory traversal vulnerability in the FTP server, it is possible to gain access to the web root directory.”
If a device does not properly authenticate all HTTP requests, a threat actor can directly send a request to a specific URL to access data or initiate a device function. This could be used to access/download sensitive data or perform unwanted changes to settings or functions on a device. This typically requires that the threat actor directly knows the URL of the specific file/object/page, rather than depending on the existing links provided by the web application. This is especially problematic for files hosted on a web server (e.g., txt, pdf) since the authentication mechanisms provided by the web application framework may not enforce access controls on those files.
Known Exploitable Weakness
Telerik UI for ASP.NET AJAX Insecure Direct Object Reference Vulnerability
“Telerik UI for ASP.NET AJAX contains an insecure direct object reference vulnerability in RadAsyncUpload that can result in file uploads in a limited location and/or remote code execution.”
CWE-639: Authorization Bypass Through User-Controlled Key
“The system’s authorization functionality does not prevent one user from gaining access to another user’s data or record by modifying the key value identifying the data.”
Iagona ScrutisWeb - CVE-2023-38257
“Iagona ScrutisWeb versions 2.1.37 and prior are vulnerable to an insecure direct object reference vulnerability that could allow an unauthenticated user to view profile information, including user login names and encrypted passwords.”
If a device does not properly authenticate all HTTP requests, a threat actor can directly send a request to a specific URL to access data or initiate a device function. This could be used to access/download sensitive data or perform unwanted changes to settings or functions on a device. This typically requires that the threat actor directly knows the URL of the specific file/object/page, rather than depending on the existing links provided by the web application. This is especially problematic for files hosted on a web server (e.g., txt, pdf) since the authentication mechanisms provided by the web application framework may not enforce access controls on those files.
Known Exploitable Weakness
Telerik UI for ASP.NET AJAX Insecure Direct Object Reference Vulnerability
“Telerik UI for ASP.NET AJAX contains an insecure direct object reference vulnerability in RadAsyncUpload that can result in file uploads in a limited location and/or remote code execution.”
CWE-639: Authorization Bypass Through User-Controlled Key
“The system’s authorization functionality does not prevent one user from gaining access to another user’s data or record by modifying the key value identifying the data.”
Iagona ScrutisWeb - CVE-2023-38257
“Iagona ScrutisWeb versions 2.1.37 and prior are vulnerable to an insecure direct object reference vulnerability that could allow an unauthenticated user to view profile information, including user login names and encrypted passwords.”
The device uses HTTP headers that are unencrypted, not-validated, and/or unauthenticated. This means that the device may accept and process arbitrary data coming to the receiving web-server over the network. Threat actors may therefore be able to inject their own information into the header, possibly using their input to get more information than they should have access to or exploiting a vulnerability on the receiving device.
Proof of Concept
“Divide and Conquer”: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics White paper
This white paper describes the outlines of how an HTTP Response Splitting attack can take place, the follow-up attacks that are possible, and the impact they can have on machines. He conducts sample attacks in a lab environment.
Cogent DataHub XSS and CRLF - CVE-2012-0310
“An HTTP header injection vulnerability (also known as carriage return line feed) exists in the Cogent DataHub application as the product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.”
The device uses HTTP headers that are unencrypted, not-validated, and/or unauthenticated. This means that the device may accept and process arbitrary data coming to the receiving web-server over the network. Threat actors may therefore be able to inject their own information into the header, possibly using their input to get more information than they should have access to or exploiting a vulnerability on the receiving device.
Proof of Concept
“Divide and Conquer”: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics White paper
This white paper describes the outlines of how an HTTP Response Splitting attack can take place, the follow-up attacks that are possible, and the impact they can have on machines. He conducts sample attacks in a lab environment.
Cogent DataHub XSS and CRLF - CVE-2012-0310
“An HTTP header injection vulnerability (also known as carriage return line feed) exists in the Cogent DataHub application as the product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.”
Many object oriented languages use serialization to convert class objects into byte strings for more efficient storage or transmission. However, if an untrusted byte string is deserialized without properly validating its contents, it could be used to exploit a vulnerability in the associated library. A threat actor could send a maliciously crafted serialized object to a device to exploit a deserialization vulnerability within a device.
Observed Adversary Behavior
Now You Serial, Now You Don’t — Systematically Hunting for Deserialization Exploits
Mandiant has reported that between the years 2019-2021 APT41 used .NET ViewState and Java deserialization vulnerabilities in their campaigns.
Known Exploited Vulnerability
Kentico Xperience Deserialization of Untrusted Data Vulnerability
“An issue was discovered in Kentico 12.0.x before 12.0.15, 11.0.x before 11.0.48, 10.0.x before 10.0.52, and 9.x versions. Due to a failure to validate security headers, it was possible for a specially crafted request to the staging service to bypass the initial authentication and proceed to deserialize user-controlled .NET object input. This deserialization then led to unauthenticated remote code execution on the server where the Kentico instance was hosted.”
CWE-502: Deserialization of Untrusted Data (Base)
“The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.”
Rockwell Automation ISaGRAF - CVE-2022-1118
“Connected Components Workbench, ISaGRAF Workbench, and Safety Instrumented System Workstation do not limit the objects that can be deserialized. This allows attackers to craft a malicious serialized object that, if opened by a local user in Connected Components Workbench, may result in arbitrary code execution. This vulnerability requires user interaction to be successfully exploited.”
Medtronic Paceart Optima System - CVE-2023-31222
“Deserialization of untrusted data in Microsoft Messaging Queuing Service in Medtronic’s Paceart Optima versions 1.11 and earlier on Windows allows an unauthorized user to impact a healthcare delivery organization’s Paceart Optima system cardiac device causing data to be deleted, stolen, or modified, or the Paceart Optima system being used for further network penetration via network connectivity.”
CVE-2021-4104
“JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228.”
Many object oriented languages use serialization to convert class objects into byte strings for more efficient storage or transmission. However, if an untrusted byte string is deserialized without properly validating its contents, it could be used to exploit a vulnerability in the associated library. A threat actor could send a maliciously crafted serialized object to a device to exploit a deserialization vulnerability within a device.
Observed Adversary Behavior
Now You Serial, Now You Don’t — Systematically Hunting for Deserialization Exploits
Mandiant has reported that between the years 2019-2021 APT41 used .NET ViewState and Java deserialization vulnerabilities in their campaigns.
Known Exploited Vulnerability
Kentico Xperience Deserialization of Untrusted Data Vulnerability
“An issue was discovered in Kentico 12.0.x before 12.0.15, 11.0.x before 11.0.48, 10.0.x before 10.0.52, and 9.x versions. Due to a failure to validate security headers, it was possible for a specially crafted request to the staging service to bypass the initial authentication and proceed to deserialize user-controlled .NET object input. This deserialization then led to unauthenticated remote code execution on the server where the Kentico instance was hosted.”
CWE-502: Deserialization of Untrusted Data (Base)
“The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.”
Rockwell Automation ISaGRAF - CVE-2022-1118
“Connected Components Workbench, ISaGRAF Workbench, and Safety Instrumented System Workstation do not limit the objects that can be deserialized. This allows attackers to craft a malicious serialized object that, if opened by a local user in Connected Components Workbench, may result in arbitrary code execution. This vulnerability requires user interaction to be successfully exploited.”
Medtronic Paceart Optima System - CVE-2023-31222
“Deserialization of untrusted data in Microsoft Messaging Queuing Service in Medtronic’s Paceart Optima versions 1.11 and earlier on Windows allows an unauthorized user to impact a healthcare delivery organization’s Paceart Optima system cardiac device causing data to be deleted, stolen, or modified, or the Paceart Optima system being used for further network penetration via network connectivity.”
CVE-2021-4104
“JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228.”
If an application does not properly restrict data writes to allocated memory locations, a threat actor could send an input or message that writes data outside of intended or allowed memory locations. By overwriting memory locations, an attacker can possibly hijack the control-flow of the program to remotely execute their own code or cause a DoS on the device.
Known Exploitable Weakness
Tenda AC11 Router Stack Buffer Overflow Vulnerability
“Tenda AC11 devices contain a stack buffer overflow vulnerability in /goform/setmac which allows attackers to execute code via a crafted post request.”
Tenda AC11 Router Stack Buffer Overflow Vulnerability
“An issue was discovered on Tenda AC11 devices with firmware through 02.03.01.104_CN. A stack buffer overflow vulnerability in /goform/setmac allows attackers to execute arbitrary code on the system via a crafted post request.”
Amcrest Cameras and NVR Stack-based Buffer Overflow Vulnerability
“Amcrest cameras and NVR contain a stack-based buffer overflow vulnerability through port 37777 that allows an unauthenticated, remote attacker to crash the device and possibly execute code.”
CWE 1218: Memory Buffer Errors
This a weakness category related to the handling of memory buffers within a software system. It is possible that any of these weaknesses can lead to the development of a vulnerability to exploit in a given device.
Siemens ICS Switches Hit With Buffer Overflow, Authentication Bugs
A buffer overflow present on Siemens ICS switches could allow threat actors to gain the ability to take administrative actions on switches.
If an application does not properly restrict data writes to allocated memory locations, a threat actor could send an input or message that writes data outside of intended or allowed memory locations. By overwriting memory locations, an attacker can possibly hijack the control-flow of the program to remotely execute their own code or cause a DoS on the device.
Known Exploitable Weakness
Tenda AC11 Router Stack Buffer Overflow Vulnerability
“Tenda AC11 devices contain a stack buffer overflow vulnerability in /goform/setmac which allows attackers to execute code via a crafted post request.”
Tenda AC11 Router Stack Buffer Overflow Vulnerability
“An issue was discovered on Tenda AC11 devices with firmware through 02.03.01.104_CN. A stack buffer overflow vulnerability in /goform/setmac allows attackers to execute arbitrary code on the system via a crafted post request.”
Amcrest Cameras and NVR Stack-based Buffer Overflow Vulnerability
“Amcrest cameras and NVR contain a stack-based buffer overflow vulnerability through port 37777 that allows an unauthenticated, remote attacker to crash the device and possibly execute code.”
CWE 1218: Memory Buffer Errors
This a weakness category related to the handling of memory buffers within a software system. It is possible that any of these weaknesses can lead to the development of a vulnerability to exploit in a given device.
Siemens ICS Switches Hit With Buffer Overflow, Authentication Bugs
A buffer overflow present on Siemens ICS switches could allow threat actors to gain the ability to take administrative actions on switches.
Hardcoded credentials typically cannot be changed by end-users and are often undocumented, leaving the end-user unaware of the risk. If a threat actor is able to discover the credentials for a device (or family of devices with the same password), they may be able to exploit multiple devices with no known device-level mitigation. Hardcoded credentials are often intended for vendor-specific diagnostic functions or to authenticate components designed to communicate together (e.g., a PLC and associated IED), but can be abused by threat actors when discovered.
Observed Adversary Behavior
ATT&CK Technique: Hardcoded Credentials (T0891)
Procedure Example: Incontroller (S1045)
“INCONTROLLER can login to Omron PLCs using hardcoded credentials, which is documented in CVE-2022-34151”
Known Exploitable Weakness
Zyxel Multiple Products Use of Hard-Coded Credentials Vulnerability
“Zyxel firewalls (ATP, USG, VM) and AP Controllers (NXC2500 and NXC5500) contain a use of hard-coded credentials vulnerability in an undocumented account (“zyfwp”) with an unchangeable password.”
CWE-798: Use of Hard-coded Credentials
“The product contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.”
Hardcoded credentials typically cannot be changed by end-users and are often undocumented, leaving the end-user unaware of the risk. If a threat actor is able to discover the credentials for a device (or family of devices with the same password), they may be able to exploit multiple devices with no known device-level mitigation. Hardcoded credentials are often intended for vendor-specific diagnostic functions or to authenticate components designed to communicate together (e.g., a PLC and associated IED), but can be abused by threat actors when discovered.
Observed Adversary Behavior
ATT&CK Technique: Hardcoded Credentials (T0891)
Procedure Example: Incontroller (S1045)
“INCONTROLLER can login to Omron PLCs using hardcoded credentials, which is documented in CVE-2022-34151”
Known Exploitable Weakness
Zyxel Multiple Products Use of Hard-Coded Credentials Vulnerability
“Zyxel firewalls (ATP, USG, VM) and AP Controllers (NXC2500 and NXC5500) contain a use of hard-coded credentials vulnerability in an undocumented account (“zyfwp”) with an unchangeable password.”
CWE-798: Use of Hard-coded Credentials
“The product contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.”
If a device stores passwords in an unsafe manner (e.g., in a cleartext file with no read restrictions) it may be possible for threat actors to retrieve system or user account passwords for that device. Threat actors can then use obtained passwords to increase their privileges and perform actions on the device or move laterally to other systems. Unsafe storage techniques can include storing passwords in cleartext, encrypting instead of hashing passwords, using weak hashing algorithms, or not using salted hashes.
Known Exploitable Weakness
D-Link DIR-300 Router Cleartext Storage of a Password Vulnerability “The D-Link DIR-300 router stores cleartext passwords, which allows context-dependent attackers to obtain sensitive information.”
CWE-257: Storing Passwords in a Recoverable Format
“The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.”
Siemens S7-1200 Insecure Storage of HTTPS CA Certificate - CVE-2012-3037
“The certificate authority (CA) for HTTPS connections, which is installed on Siemens SIMATIC S7-1200 PLC, stores its private key insecurely. This key is used for signing certificates. Once this key is obtained, an attacker may create a forged certificate. This can then be used to complete a Man-in-the-Middle attack on a browser that already trusts this device’s CA.”
If a device stores passwords in an unsafe manner (e.g., in a cleartext file with no read restrictions) it may be possible for threat actors to retrieve system or user account passwords for that device. Threat actors can then use obtained passwords to increase their privileges and perform actions on the device or move laterally to other systems. Unsafe storage techniques can include storing passwords in cleartext, encrypting instead of hashing passwords, using weak hashing algorithms, or not using salted hashes.
Known Exploitable Weakness
D-Link DIR-300 Router Cleartext Storage of a Password Vulnerability “The D-Link DIR-300 router stores cleartext passwords, which allows context-dependent attackers to obtain sensitive information.”
CWE-257: Storing Passwords in a Recoverable Format
“The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.”
Siemens S7-1200 Insecure Storage of HTTPS CA Certificate - CVE-2012-3037
“The certificate authority (CA) for HTTPS connections, which is installed on Siemens SIMATIC S7-1200 PLC, stores its private key insecurely. This key is used for signing certificates. Once this key is obtained, an attacker may create a forged certificate. This can then be used to complete a Man-in-the-Middle attack on a browser that already trusts this device’s CA.”
Algorithms or code implementations of cryptographic processes will sometimes leak information by ending operations early or late based on, and correlated with, the input/key.
If a threat actor is able to execute code on a processor performing a cryptographic operation, they may be able to infer the resulting key from that operation by measuring the timing it takes to perform the various functions.
For example, if a function like memcpy (which performs byte-by byte comparison) is used to check an HMAC value, by measuring the time it takes for the function to execute, the length of time needed to brute force guess a key can be significantly reduced.
Known Exploitable Weakness
XBOX 360 HMAC Comparison
“A memcmp function is used to check the CB-auth HMAC-hash value. The value is 16-bytes long and is done byte-by-byte wise. By changing one byte at a time it’s possible to determine if a byte is the valid (true) by measuring the time to compare a false and a true value. Measuring each byte will in the end reveal the correct hash and the boot process can continue.
The time differences for a valid and false value is about 2200 microseconds.
Possibilities: 16 bytes * 256 different possibility for each byte, total 4096 tries. Statistically only half has to be tried, 2048 tries.”
CWE-208: Observable Timing Discrepancy (Base)
“Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.”
CWE-1254: Incorrect Comparison Logic Granularity (Base)
“The product’s comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.”
Algorithms or code implementations of cryptographic processes will sometimes leak information by ending operations early or late based on, and correlated with, the input/key.
If a threat actor is able to execute code on a processor performing a cryptographic operation, they may be able to infer the resulting key from that operation by measuring the timing it takes to perform the various functions.
For example, if a function like memcpy (which performs byte-by byte comparison) is used to check an HMAC value, by measuring the time it takes for the function to execute, the length of time needed to brute force guess a key can be significantly reduced.
Known Exploitable Weakness
XBOX 360 HMAC Comparison
“A memcmp function is used to check the CB-auth HMAC-hash value. The value is 16-bytes long and is done byte-by-byte wise. By changing one byte at a time it’s possible to determine if a byte is the valid (true) by measuring the time to compare a false and a true value. Measuring each byte will in the end reveal the correct hash and the boot process can continue.
The time differences for a valid and false value is about 2200 microseconds.
Possibilities: 16 bytes * 256 different possibility for each byte, total 4096 tries. Statistically only half has to be tried, 2048 tries.”
CWE-208: Observable Timing Discrepancy (Base)
“Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.”
CWE-1254: Incorrect Comparison Logic Granularity (Base)
“The product’s comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.”
Some devices may support proprietary protocols, or may add proprietary functionality to open protocols. Many of the custom functions or commands may not be sufficiently documented. If users aren’t aware of these functions/commands, they cannot be expected to properly configure the device to remove unwanted functionality. Further, they are limited in their ability to monitor the device for any potential malicious use of these functions/commands to exploit devices.
Proof of Concept
The Vulnerability Can Lead to Native Remote-Code-Execution on Vulnerable PLCs
“Armis researchers discovered a new vulnerability (CVE-2021-22779) in Schneider Electric (SE) Modicon PLCs that bypasses security mechanisms added to these PLCs to prevent abuse of undocumented Modbus commands. These undocumented commands can allow full control over the PLC — overwriting critical memory regions, leaking sensitive memory content, or invoking internal functions.”
CWE-1371: ICS Supply Chain: Poorly Documented or Undocumented Features
“Undocumented capabilities and configurations pose a risk by not having a clear understanding of what the device is specifically supposed to do and only do. Therefore possibly opening up the attack surface and vulnerabilities.”
CWE-912: Hidden Functionality (Class)
“The product contains functionality that is not documented, not part of the specification, and not accessible through an interface or command sequence that is obvious to the product’s users or administrators.”
CWE-1059: Insufficient Technical Documentation
“The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.”
Sixnet Universal Protocol Undocumented Function Codes - CVE-2013-2802
Sixnet devices use a universal protocol with 6 undocumented opcodes that can perform remote management functions (e.g., code execution) without authentication
Schneider Electric Modicon Controllers and Software - CVE-2021-22779
“An authentication bypass by spoofing vulnerability exists that could cause unauthorized access in read and write mode to the controller by spoofing the Modbus communication between the engineering software and the controller.”
Some devices may support proprietary protocols, or may add proprietary functionality to open protocols. Many of the custom functions or commands may not be sufficiently documented. If users aren’t aware of these functions/commands, they cannot be expected to properly configure the device to remove unwanted functionality. Further, they are limited in their ability to monitor the device for any potential malicious use of these functions/commands to exploit devices.
Proof of Concept
The Vulnerability Can Lead to Native Remote-Code-Execution on Vulnerable PLCs
“Armis researchers discovered a new vulnerability (CVE-2021-22779) in Schneider Electric (SE) Modicon PLCs that bypasses security mechanisms added to these PLCs to prevent abuse of undocumented Modbus commands. These undocumented commands can allow full control over the PLC — overwriting critical memory regions, leaking sensitive memory content, or invoking internal functions.”
CWE-1371: ICS Supply Chain: Poorly Documented or Undocumented Features
“Undocumented capabilities and configurations pose a risk by not having a clear understanding of what the device is specifically supposed to do and only do. Therefore possibly opening up the attack surface and vulnerabilities.”
CWE-912: Hidden Functionality (Class)
“The product contains functionality that is not documented, not part of the specification, and not accessible through an interface or command sequence that is obvious to the product’s users or administrators.”
CWE-1059: Insufficient Technical Documentation
“The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.”
Sixnet Universal Protocol Undocumented Function Codes - CVE-2013-2802
Sixnet devices use a universal protocol with 6 undocumented opcodes that can perform remote management functions (e.g., code execution) without authentication
Schneider Electric Modicon Controllers and Software - CVE-2021-22779
“An authentication bypass by spoofing vulnerability exists that could cause unauthorized access in read and write mode to the controller by spoofing the Modbus communication between the engineering software and the controller.”
Some devices will have operating modes that put the device in an inoperable state. Devices may also have network parsing or protocol vulnerabilities that can put the device in a deadlocked or otherwise unresponsive state. A threat actor may therefore be able to send a message to a device that causes it to enter one of these deadlocked or unresponsive states, rendering the device non-functional or leaving it in an otherwise degraded state. Additionally, if the device does not have a mechanism to reset or recover from this state, it may remain unavailable until it is reset or rebooted, which may require physical operator presence.
Observed Adversary Technique
ATT&CK Technique: Denial of Service (T0814)
Procedure Example: Industroyer (S0604)
“The Industroyer SIPROTEC DoS module exploits the CVE-2015-5374 vulnerability in order to render a Siemens SIPROTEC device unresponsive. Once this vulnerability is successfully exploited, the target device stops responding to any commands until it is rebooted manually. Once the tool is executed it sends specifically crafted packets to port 50,000 of the target IP addresses using UDP. The UDP packet contains the following 18 byte payload: 0x11 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 9E.”
Procedure Example: Backdoor.Oldrea (S0093)
“The Backdoor.Oldrea payload has caused multiple common OPC platforms to intermittently crash. This could cause a denial of service effect on applications reliant on OPC communications.”
CWE-833: Deadlock
“The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.”
CVE-2015-5374
“Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device. A manual reboot may be required to recover the service of the device.”
Some devices will have operating modes that put the device in an inoperable state. Devices may also have network parsing or protocol vulnerabilities that can put the device in a deadlocked or otherwise unresponsive state. A threat actor may therefore be able to send a message to a device that causes it to enter one of these deadlocked or unresponsive states, rendering the device non-functional or leaving it in an otherwise degraded state. Additionally, if the device does not have a mechanism to reset or recover from this state, it may remain unavailable until it is reset or rebooted, which may require physical operator presence.
Observed Adversary Technique
ATT&CK Technique: Denial of Service (T0814)
Procedure Example: Industroyer (S0604)
“The Industroyer SIPROTEC DoS module exploits the CVE-2015-5374 vulnerability in order to render a Siemens SIPROTEC device unresponsive. Once this vulnerability is successfully exploited, the target device stops responding to any commands until it is rebooted manually. Once the tool is executed it sends specifically crafted packets to port 50,000 of the target IP addresses using UDP. The UDP packet contains the following 18 byte payload: 0x11 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 9E.”
Procedure Example: Backdoor.Oldrea (S0093)
“The Backdoor.Oldrea payload has caused multiple common OPC platforms to intermittently crash. This could cause a denial of service effect on applications reliant on OPC communications.”
CWE-833: Deadlock
“The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.”
CVE-2015-5374
“Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device. A manual reboot may be required to recover the service of the device.”
Remote connections and communications can consume various device resources (e.g., network stack buffers, packet processing, socket connections) that, if exhausted, could lead to the device entering an unresponsive state. A threat actor may attempt to intentionally cause this by sending either repetitive or specially crafted messages to a device to consume resources and cause the device to become unresponsive. The unresponsive state will typically continue for at least the duration of the attack. In some cases it may persist until the device is reset or rebooted, which may require physical operator presence.
Observed Adversary Technique
ATT&CK Technique: Service Stop (T0881)
Procedure Example: Industroyer2 (S1072)
”Killing the ‘PService_PDD.exe’ service causes the interruption of any existing communication with target IEC-104 servers, which usually supports at most one active connection at a time. Having interrupted existing connections, Industroyer2 is free to connect to the targets.” This action will prevent other devices from connecting to the IEC-104 servers for as long as the Industroyer2 connection is active.
Cisco IOS XR Software DVMRP Memory Exhaustion Vulnerability
“Cisco IOS XR Distance Vector Multicast Routing Protocol (DVMRP) incorrectly handles Internet Group Management Protocol (IGMP) packets. Exploitation could allow an unauthenticated, remote attacker to immediately crash the IGMP process or make it consume available memory and eventually crash.”
CWE-400: Uncontrolled Resource Consumption
“The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.”
CWE-410: Insufficient Resource Pool
“The product’s resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.”
Remote connections and communications can consume various device resources (e.g., network stack buffers, packet processing, socket connections) that, if exhausted, could lead to the device entering an unresponsive state. A threat actor may attempt to intentionally cause this by sending either repetitive or specially crafted messages to a device to consume resources and cause the device to become unresponsive. The unresponsive state will typically continue for at least the duration of the attack. In some cases it may persist until the device is reset or rebooted, which may require physical operator presence.
Observed Adversary Technique
ATT&CK Technique: Service Stop (T0881)
Procedure Example: Industroyer2 (S1072)
”Killing the ‘PService_PDD.exe’ service causes the interruption of any existing communication with target IEC-104 servers, which usually supports at most one active connection at a time. Having interrupted existing connections, Industroyer2 is free to connect to the targets.” This action will prevent other devices from connecting to the IEC-104 servers for as long as the Industroyer2 connection is active.
Cisco IOS XR Software DVMRP Memory Exhaustion Vulnerability
“Cisco IOS XR Distance Vector Multicast Routing Protocol (DVMRP) incorrectly handles Internet Group Management Protocol (IGMP) packets. Exploitation could allow an unauthenticated, remote attacker to immediately crash the IGMP process or make it consume available memory and eventually crash.”
CWE-400: Uncontrolled Resource Consumption
“The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.”
CWE-410: Insufficient Resource Pool
“The product’s resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.”
Some devices operate using protocols that have no capacity for network-level authentication, connection, or creation of sessions on-device, therefore allowing a threat actor to establish malicious connections or send malicious data to the device. Authentication mechanisms include passwords and cryptographic keys/certificates.
Observed Adversary Technique
ATT&CK T0860 Wireless Compromise
“During the Polish Train incident, a teenager was able to program a remote with commands to operate and change junctions on the tracks. The teenager was able to then send those commands, without authentication, to operate the junctions.”
ATT&CK Technique: Unauthorized Command Message (T0855)
Procedure Example: INCONTROLLER (S1045)
“INCONTROLLER can send custom Modbus commands to write register values on Schneider PLCs.”
CWE-306: Missing Authentication for Critical Function (Base)
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CWE-287: Improper Authentication (Class)
“When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.”
CVE-2022-30266 / CVE-2022-33139 / CVE-2019-18250 (OT-ICEFALL)
Many devices in the OT-ICEFALL report had authentication on the client-side, but not for the protocol. What this means is that while users may think actions are authenticated, actors who are able to send/receive traffic over the network may be able to issue commands without proper authentication.
CVE-2019-6533
“Registers used to store Modbus values can be read and written from the web interface without authentication in the PR100088 Modbus gateway versions prior to Release R02 (or Software Version 1.1.13166).”
Some devices operate using protocols that have no capacity for network-level authentication, connection, or creation of sessions on-device, therefore allowing a threat actor to establish malicious connections or send malicious data to the device. Authentication mechanisms include passwords and cryptographic keys/certificates.
Observed Adversary Technique
ATT&CK T0860 Wireless Compromise
“During the Polish Train incident, a teenager was able to program a remote with commands to operate and change junctions on the tracks. The teenager was able to then send those commands, without authentication, to operate the junctions.”
ATT&CK Technique: Unauthorized Command Message (T0855)
Procedure Example: INCONTROLLER (S1045)
“INCONTROLLER can send custom Modbus commands to write register values on Schneider PLCs.”
CWE-306: Missing Authentication for Critical Function (Base)
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CWE-287: Improper Authentication (Class)
“When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.”
CVE-2022-30266 / CVE-2022-33139 / CVE-2019-18250 (OT-ICEFALL)
Many devices in the OT-ICEFALL report had authentication on the client-side, but not for the protocol. What this means is that while users may think actions are authenticated, actors who are able to send/receive traffic over the network may be able to issue commands without proper authentication.
CVE-2019-6533
“Registers used to store Modbus values can be read and written from the web interface without authentication in the PR100088 Modbus gateway versions prior to Release R02 (or Software Version 1.1.13166).”
Threat actors may be able to replay a message to a device to cause an unwanted function, send an unwanted command, or gain access to privileged data. Message replaying can be used to bypass non-existant or poorly designed authentication mechanisms lacking proper protections, such as a nonce or timestamp.
Observed Adversary Technique
ATT&CK T0887 Wireless Sniffing
“In the Dallas Siren incident, adversaries were able to send command messages to activate tornado alarm systems across the city without an impending tornado or other disaster.”
“In Dallas’ case, there are a number of ways that the attack could have been carried out, but the most likely is that someone carried out a “radio replay” attack, which involves recording the radio signal that was broadcast during the latest monthly test of the emergency siren system and playing it back repeatedly on Friday, according to Bastille, a security firm specializing in finding and remediating radio frequency vulnerabilities.”
CWE-294: Authentication Bypass by Capture-replay (Base)
“A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).”
Schneider Electric Modicon Modbus Protocol - CVE-2017-6034
“Sensitive information is transmitted in cleartext in the Modicon Modbus protocol, which may allow an attacker to replay the following commands: run, stop, upload, and download.”
Sierra Wireless AirLink Raven X EV-DO Vulnerabilities - CVE-2013-2820
“The AirLink Raven X EV-DO is vulnerable to replay attacks that bypass authentication. By sending a series of crafted packets to Port 17336/UDP and Port 17388/UDP, an attacker could reprogram the device’s firmware image. This could allow the attacker to affect the availability of the firmware.”
Threat actors may be able to replay a message to a device to cause an unwanted function, send an unwanted command, or gain access to privileged data. Message replaying can be used to bypass non-existant or poorly designed authentication mechanisms lacking proper protections, such as a nonce or timestamp.
Observed Adversary Technique
ATT&CK T0887 Wireless Sniffing
“In the Dallas Siren incident, adversaries were able to send command messages to activate tornado alarm systems across the city without an impending tornado or other disaster.”
“In Dallas’ case, there are a number of ways that the attack could have been carried out, but the most likely is that someone carried out a “radio replay” attack, which involves recording the radio signal that was broadcast during the latest monthly test of the emergency siren system and playing it back repeatedly on Friday, according to Bastille, a security firm specializing in finding and remediating radio frequency vulnerabilities.”
CWE-294: Authentication Bypass by Capture-replay (Base)
“A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).”
Schneider Electric Modicon Modbus Protocol - CVE-2017-6034
“Sensitive information is transmitted in cleartext in the Modicon Modbus protocol, which may allow an attacker to replay the following commands: run, stop, upload, and download.”
Sierra Wireless AirLink Raven X EV-DO Vulnerabilities - CVE-2013-2820
“The AirLink Raven X EV-DO is vulnerable to replay attacks that bypass authentication. By sending a series of crafted packets to Port 17336/UDP and Port 17388/UDP, an attacker could reprogram the device’s firmware image. This could allow the attacker to affect the availability of the firmware.”
Some devices do not adequately encrypt communications that includes operational or management information. Without adequate encryption, a threat actor can eavesdrop on the communications to gain access to device operational information, management information, or authentication information such as credentials or keys.
Known Exploitable Weakness
ATT&CK T0842 Network Sniffing
“Network sniffing is the practice of using a network interface on a computer system to monitor or capture information regardless of whether it is the specified destination for the information.”
ATT&CK T0887 Wireless Sniffing
“Adversaries may seek to capture radio frequency (RF) communication used for remote control and reporting in distributed environments.”
Sierra Wireless AirLink Raven X EV-DO Vulnerabilities
“The AirLink Raven X EV-DO does not use encryption in the update and reprogramming process. By using the passwords and user names that are stored in plain text, an attacker could reprogram the firmware.”
OT-ICEFALL - CVE-2022-29954 “The BSAP/IP protocol transmits passwords in plaintext”
OT-ICEFALL - CVE-2022-30261 “The ROC protocol transmits passwords in plaintext.”
OT-ICEFALL - CVE-2022-30266 “The SRTP protocol transmits passwords in plaintext”
OT-ICEFALL - CVE-2022-30312 “The Inter-controller (IC) protocol transmits PINs, usernames and passwords in plaintext”
OT-ICEFALL - CVE-2022-31204 “The password used to restrict engineering operations is transmitted in plaintext”
OT-ICEFALL - CVE-2022-29519 The ResConf protocol transmits usernames, passwords and session tokens in plaintext.”
Some devices do not adequately encrypt communications that includes operational or management information. Without adequate encryption, a threat actor can eavesdrop on the communications to gain access to device operational information, management information, or authentication information such as credentials or keys.
Known Exploitable Weakness
ATT&CK T0842 Network Sniffing
“Network sniffing is the practice of using a network interface on a computer system to monitor or capture information regardless of whether it is the specified destination for the information.”
ATT&CK T0887 Wireless Sniffing
“Adversaries may seek to capture radio frequency (RF) communication used for remote control and reporting in distributed environments.”
Sierra Wireless AirLink Raven X EV-DO Vulnerabilities
“The AirLink Raven X EV-DO does not use encryption in the update and reprogramming process. By using the passwords and user names that are stored in plain text, an attacker could reprogram the firmware.”
OT-ICEFALL - CVE-2022-29954 “The BSAP/IP protocol transmits passwords in plaintext”
OT-ICEFALL - CVE-2022-30261 “The ROC protocol transmits passwords in plaintext.”
OT-ICEFALL - CVE-2022-30266 “The SRTP protocol transmits passwords in plaintext”
OT-ICEFALL - CVE-2022-30312 “The Inter-controller (IC) protocol transmits PINs, usernames and passwords in plaintext”
OT-ICEFALL - CVE-2022-31204 “The password used to restrict engineering operations is transmitted in plaintext”
OT-ICEFALL - CVE-2022-29519 The ResConf protocol transmits usernames, passwords and session tokens in plaintext.”
While encrypting data can prevent a threat actor from directly obtaining the plaintext communication, a threat actor may be able to infer information about the device or communicated data through side-channel and metadata analysis of encrypted communication sessions. For example, a threat actor could use information about message lengths, sequences, and frequency to infer some or all of the plaintext content of messages.
Proof of Concept
Classifying IoT devices in smart environments using network traffic characteristics
“This paper shows that IoT devices can be identified with high accuracy based on their network behavior, and sets the stage for future work in detecting misbehaviors resulting from security breaches in teh [sic] smart environment.”
Traffic Fingerprinting Attacks on Internet of Things using Machine Learning
“However, even if encryption was in place, characteristics of the traffic, such as packet sizes and traffic rates, may expose the user’s current activities”
Privacy Attacks to the 4G and 5G Cellular Paging Protocols Using Side Channel Information
“Our paper sheds light on an inherent design weakness of the 4G/5G cellular paging protocol which can be exploited by an attacker to not only obtain the victim’s paging occasion but also to identify the victim’s presence in a particular cell area just from the victim’s soft-identity (e.g., phone number, Twitter handle) with a novel attack called ToRPEDO.”
CWE-1230: Exposure of Sensitive Information Through Metadata
“The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.”
While encrypting data can prevent a threat actor from directly obtaining the plaintext communication, a threat actor may be able to infer information about the device or communicated data through side-channel and metadata analysis of encrypted communication sessions. For example, a threat actor could use information about message lengths, sequences, and frequency to infer some or all of the plaintext content of messages.
Proof of Concept
Classifying IoT devices in smart environments using network traffic characteristics
“This paper shows that IoT devices can be identified with high accuracy based on their network behavior, and sets the stage for future work in detecting misbehaviors resulting from security breaches in teh [sic] smart environment.”
Traffic Fingerprinting Attacks on Internet of Things using Machine Learning
“However, even if encryption was in place, characteristics of the traffic, such as packet sizes and traffic rates, may expose the user’s current activities”
Privacy Attacks to the 4G and 5G Cellular Paging Protocols Using Side Channel Information
“Our paper sheds light on an inherent design weakness of the 4G/5G cellular paging protocol which can be exploited by an attacker to not only obtain the victim’s paging occasion but also to identify the victim’s presence in a particular cell area just from the victim’s soft-identity (e.g., phone number, Twitter handle) with a novel attack called ToRPEDO.”
CWE-1230: Exposure of Sensitive Information Through Metadata
“The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.”
The device utilizes a weak or insecure cryptographic protocol or algorithm that can be broken or undermined. This could allow the threat actor to extract plaintext information from encrypted communications, extract cryptographic keys, or bypass authentication mechanisms.
A threat actor can utilize various techniques to manipulate these protocols, including brute-force guessing of keys or using cryptanalysis to decipher the text.
Known Exploitable Weakness
Wi-Fi hack caused TK Maxx security breach
“TK Maxx’s parent company, TJX, had secured its wireless network using Wired Equivalent Privacy (WEP) — one of the weakest forms of security for wireless LANs… hackers cracked the WEP encryption protocol used to transmit data between price-checking devices, cash registers and computers at a store in Minnesota.”
Empirical Study of PLC Authentication Protocols in Industrial Control Systems
Researchers Adeen Ayub, Hyunguk Yoo, and Irfan Ahmed discovered eight protocol level authentication vulnerabilities between 5 PLCs. One of the classes of vulnerabilities they discovered was weak encryption schemes.
OT-ICEFALL - CVE-2022-30273
“The MDLC protocol offers a legacy encryption mode that encrypts traffic using the Tiny Encryption Algorithm (TEA) block-cipher in ECB mode, which offers no message integrity and reduced confidentiality.”
OT-ICEFALL - Weak Cryptography on CODESYS V3
“The encryption scheme uses an insecure mode of operation. The code is encrypted in ECB mode without additional cryptographic authentication and integrity over the ciphertext as a whole.”
OT-ICEFALL - CVE-2022-29955
“The BSAP/IP protocol uses weak encryption to transmit passwords.”
OT-ICEFALL - CVE-2022-29960
“DES with hardcoded cryptographic keys is used to protect system credentials, engineering files, and sensitive utilities.”
The device utilizes a weak or insecure cryptographic protocol or algorithm that can be broken or undermined. This could allow the threat actor to extract plaintext information from encrypted communications, extract cryptographic keys, or bypass authentication mechanisms.
A threat actor can utilize various techniques to manipulate these protocols, including brute-force guessing of keys or using cryptanalysis to decipher the text.
Known Exploitable Weakness
Wi-Fi hack caused TK Maxx security breach
“TK Maxx’s parent company, TJX, had secured its wireless network using Wired Equivalent Privacy (WEP) — one of the weakest forms of security for wireless LANs… hackers cracked the WEP encryption protocol used to transmit data between price-checking devices, cash registers and computers at a store in Minnesota.”
Empirical Study of PLC Authentication Protocols in Industrial Control Systems
Researchers Adeen Ayub, Hyunguk Yoo, and Irfan Ahmed discovered eight protocol level authentication vulnerabilities between 5 PLCs. One of the classes of vulnerabilities they discovered was weak encryption schemes.
OT-ICEFALL - CVE-2022-30273
“The MDLC protocol offers a legacy encryption mode that encrypts traffic using the Tiny Encryption Algorithm (TEA) block-cipher in ECB mode, which offers no message integrity and reduced confidentiality.”
OT-ICEFALL - Weak Cryptography on CODESYS V3
“The encryption scheme uses an insecure mode of operation. The code is encrypted in ECB mode without additional cryptographic authentication and integrity over the ciphertext as a whole.”
OT-ICEFALL - CVE-2022-29955
“The BSAP/IP protocol uses weak encryption to transmit passwords.”
OT-ICEFALL - CVE-2022-29960
“DES with hardcoded cryptographic keys is used to protect system credentials, engineering files, and sensitive utilities.”
Some devices will allow for the forwarding of packets to other connected devices (e.g., routing, port forwarding, tunneling, VPN). If the device is used to forward or route communications, a threat actor could change the forwarding rules or routes. This feature could be used by the threat actor to either (i) disable required forwarding rules to prevent authorized communications or (ii) add new rules that allow unauthorized access to other devices. The threat actor could potentially use this to gain access to devices that are within protected networks or zones.
Observed Adversary Technique
ATT&CK Technique: Connection Proxy (T0884)
Procedure Example: Incontroller (S1045)
“The INCONTROLLER PLCProxy module can add an IP route to the CODESYS gateway running on Schneider PLCs to allow it to route messages through the PLC to other devices on that network. This allows the malware to bypass firewall rules that prevent it from directly communicating with devices on the same network as the PLC.”
CWE-306: Missing Authentication for Critical Function (Base)
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CWE-15: External Control of System or Configuration Setting
“One or more system settings or configuration elements can be externally controlled by a user.”
Some devices will allow for the forwarding of packets to other connected devices (e.g., routing, port forwarding, tunneling, VPN). If the device is used to forward or route communications, a threat actor could change the forwarding rules or routes. This feature could be used by the threat actor to either (i) disable required forwarding rules to prevent authorized communications or (ii) add new rules that allow unauthorized access to other devices. The threat actor could potentially use this to gain access to devices that are within protected networks or zones.
Observed Adversary Technique
ATT&CK Technique: Connection Proxy (T0884)
Procedure Example: Incontroller (S1045)
“The INCONTROLLER PLCProxy module can add an IP route to the CODESYS gateway running on Schneider PLCs to allow it to route messages through the PLC to other devices on that network. This allows the malware to bypass firewall rules that prevent it from directly communicating with devices on the same network as the PLC.”
CWE-306: Missing Authentication for Critical Function (Base)
“The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.”
CWE-15: External Control of System or Configuration Setting
“One or more system settings or configuration elements can be externally controlled by a user.”