CWE-1300: Improper Protection of Physical Side Channels (Base)

CWE-1255: Comparison Logic is Vulnerable to Power Side-Channel Attacks (Variant)

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.


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.


CWE-1037: Processor Optimization Removal or Modification of Security-critical Code

CWE-1264: Hardware Logic with Insecure De-Synchronization between Control and Data Channels

Operating system memory safety models rely on processor hardware to enforce separation between different virtual memory spaces. Failures of processor architectures to properly deliver these security guarantees can lead to sensitive information being disclosed across the boundaries between different kernel and process memory spaces. The performance optimization features in modern processors have been shown to be a source of such data leakage vulnerabilities. Data leakage through timing-based side channels introduced by the behavior of processor features such as memory caches have long been known to be effective against cryptographic implementations. The Spectre and Meltdown vulnerabilities announced in 2018 brought attention to weaknesses in certain microarchitectural performance features that could be manipulated in conjunction with memory cache timing techniques to leak data across OS virtual memory bounds. Spectre / Meltdown, and subsequent research work, demonstrated that speculative execution features (e.g., branch prediction, speculative memory loads/stores, out-of-order execution, etc.) could lead to memory locations being read into the CPU’s cache in violation of virtual memory permissions. Malicious code could then utilize a subsequent cache timing side channel attack to extract the data stored in those memory locations.


CWE-1247: Improper Protection Against Voltage and Clock Glitches (Base)

CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI) (Base)

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.


CWE-311: Missing Encryption of Sensitive Data (Class)

CWE-319: Cleartext Transmission of Sensitive Information (Base)

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.


CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges (Base)

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

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.


CWE-311: Missing Encryption of Sensitive Data

CWE-312: Cleartext Storage of Sensitive Information

CWE-1282: Assumed-Immutable Data is Stored in Writable Memory

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).


CWE-1384: Improper Handling of Physical or Environmental Conditions

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.


CWE-1256: Improper Restriction of Software Interfaces to Hardware Interfaces

Certain software-executed attacks can introduce a fault to the physical hardware of the device, leading to greater access or exploit opportunities. Typically, these kinds of attacks involve performing a software action that would necessitate a predictable and controllable reaction in hardware. If this hardware action contains properties that allow for some kind of fault to occur, then the threat actor can inject the fault through software and try to leverage it into an exploit. For example, the Rowhammer exploit demonstrates how repeated dynamic random access memory (DRAM) accesses can lead to a privilege escalation exploit. This exploit is possible through the combination of DRAM cells being placed very close together and attackers repeatedly accessing the same physical cells on the DRAM from software. This repeated access causes a leakage of electric charge within the memory, leading to a manipulation of the charge of nearby memory locations. This induced 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.


CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface (Base)

An untrusted storage peripheral (e.g., USB) could be connected to 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.


CWE-1316: Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges (Base)

A threat actor could manipulate the firmware associated with a device’s peripheral or other subcomponent. The threat actor 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.


CWE-319: Cleartext Transmission of Sensitive Information

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.


CWE-1299: Missing Protection Mechanism for Alternate Hardware Interface

CWE-1191: On-Chip Debug and Test Interface With Improper Access Control

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.


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.


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.


Hardware debugging ports (e.g., JTAG, SWD, etc.) 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 from 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.


CWE-693: Protection Mechanisms Failure (Pillar)

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.


CWE-20: Improper Input Validation (Class)

CWE-121: Stack-based Buffer Overflow (Simple)

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.


CWE-306 Missing Authentication for Critical Function

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.


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.


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.


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.


Container environments, such as Docker and Kubernetes, share the same underlying kernel as the host operating system. Malicious code that succeeds in executing within a container may attempt to exploit any vulnerabilities present in exposed OS system calls, container management system functions, excessive permissions in shared resources, or other misconfigurations in the environment. One or more of these can be sufficient for a threat actor to escape the container into the underlying host and then begin manipulating the host OS or the applications and data within other containers resident on the device.


Virtualization mechanisms allow multiple operating sytem instances to share the same underlying hardware. Hypervisor software is responsible for orchestrating and maintaining the separation between virtual machines (VMs) to ensure that failure or compromise within one VM does not affect others. However, vulnerabilities in APIs and services the hypervisor exposes to guest VMs, the implementation of virtualized hardware abstractions, or other hypervisor components could be used by an adversary 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.


CWE-306: Missing Authentication for Critical Function

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.


CWE-1329: Reliance on Component That is Not Updateable

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.


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.


CWE-12326: Missing Immutable Root of Trust in Hardware

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.


CWE-347: Improper Verification of Cryptographic Signature

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.


CWE-1326: Missing Immutable Root of Trust in Hardware

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.


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.


CWE-1328: Security Version Number Mutable to Older Versions

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.


CWE-400: Uncontrolled Resource Consumption

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.


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.


CWE-250: Execution with Unnecessary Privileges

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.


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.


CWE-294: Authentication Bypass by Capture-replay

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.


CWE-15: External Control of System or Configuration Setting

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).


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.


CWE-1295: Debug Messages Revealing Unnecessary Information

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.


Threat actors may try to manipulate logs on the device to evade defenses, confuse incident responders, hide their access techniques, or keep their exploitation methods secret. Threat actors can do this by changing the timestamps on logs, deleting logs entirely, inserting or reporting false logs, restoring the device to a previous state, or factory resetting the device. All of these methods will prevent defenders from obtaining an accurate representation of the current or past state of the device and will make analysis of the device more difficult.


CWE-200 Exposure of Sensitive Information to an Unauthorized Actor

CWE-532 Insertion of Sensitive Information into Log File

Some devise will login information that can be exploited by attackers to further their attack against the device or the system in which the device resides. This data can vary, but in general if a device logs any secrets that would break it’s safety, confidentiality, integrity, or availability, a threat actor may be able to use that information to further their goals. For example, if a private key is printed in a debug or event log after generation, threat actors may be able to take the key and use it to decrypt network communications. Another instance is a threat actor being able to take information associated with a core-dump log of a failed process and turn it into an exploit.


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.


CWE-494: Download of Code Without Integrity Check

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.


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.


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.


CWE-250: Execution with Unnecessary Privileges (Base)

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.


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.


CWE-829: Inclusion of Functionality from Untrusted Control Sphere

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.


CWE-223: Omission of Security-relevant Information

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).


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.


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. Many popular protocols, such as FTP, Telnet, and HTTP, provide some support for authentication but are often implemented without enabling it. Authentication is critical for any remote services that supports configuration changes, enables access to sensitive data, or that can change operational functions.


CWE-1392: Use of Default Credentials (Base)

CWE-1393: Use of Default Password (Base)

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.


CWE-645: Overly Restrictive Account Lockout Mechanism (Base)

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.


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.


CWE-307: Improper Restriction of Excessive Authentication Attempts

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.


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.


CWE-295: Improper Certificate Validation

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.


CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) (Base)

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.


CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation

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 vulnerabilities to gain unauthorized access to the device or bypass the protections provided by the cryptographic protocol.


CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) (Base)

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.


CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

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.


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).


CWE-352: Cross-Site Request Forgery (CSRF) (Compound)

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.


A threat actor can send requests for files or content that resides in different directories from those intended to be accessible by the 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


CWE-639: Authorization Bypass Through User-Controlled Key

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.


CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (‘HTTP Request/Response Splitting’)

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.


CWE-502: Deserialization of Untrusted Data (Base)

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.


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.


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. Often hardcoded credentials are added to support debugging during a device’s development and are mistakenly left in production devices.


CWE-257: Storing Passwords in a Recoverable Format

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.


CWE-208: Observable Timing Discrepancy (Base)

CWE-1254: Incorrect Comparison Logic Granularity (Base)

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.


CWE-1371: ICS Supply Chain: Poorly Documented or Undocumented Features

CWE-1059: Insufficient Technical Documentation

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.


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.


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.


CWE-306: Missing Authentication for Critical Function (Base)

CWE-287: Improper Authentication (Class)

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.


CWE-294: Authentication Bypass by Capture-replay (Base)

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 nonexistent or poorly designed authentication mechanisms lacking proper protections, such as a nonce or timestamp.


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. Examples of popular protocols that lack encryption include FTP, Telnet, HTTP, Modbus, and DNP3.


CWE-1230: Exposure of Sensitive Information Through Metadata

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.


CWE-327: Use of a Broken or Risky Cryptographic Algorithm

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.


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.