CWE-319: Cleartext Transmission of Sensitive InformationWeakness ID: 319 Vulnerability Mapping:
ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities Abstraction: BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. |
Description The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. Extended Description Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data. Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries. When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information. Common Consequences This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.Scope | Impact | Likelihood |
---|
Integrity Confidentiality
| Technical Impact: Read Application Data; Modify Files or Directories Anyone can read the information by gaining access to the channel being used for communication. | |
Potential Mitigations
Phase: Architecture and Design Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols. |
Phase: Implementation When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page. |
Phase: Implementation When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications. |
Phase: Testing Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. |
Phase: Operation Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols. |
Relationships This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000) Nature | Type | ID | Name |
---|
ChildOf | Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. | 311 | Missing Encryption of Sensitive Data | ParentOf | Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. | 5 | J2EE Misconfiguration: Data Transmission Without Encryption | ParentOf | Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. | 614 | Sensitive Cookie in HTTPS Session Without 'Secure' Attribute |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Software Development" (CWE-699) Nature | Type | ID | Name |
---|
MemberOf | Category - a CWE entry that contains a set of other entries that share a common characteristic. | 199 | Information Management Errors |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Hardware Design" (CWE-1194) Nature | Type | ID | Name |
---|
MemberOf | Category - a CWE entry that contains a set of other entries that share a common characteristic. | 1207 | Debug and Test Problems |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003) Nature | Type | ID | Name |
---|
ChildOf | Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. | 311 | Missing Encryption of Sensitive Data |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Architectural Concepts" (CWE-1008) Nature | Type | ID | Name |
---|
MemberOf | Category - a CWE entry that contains a set of other entries that share a common characteristic. | 1013 | Encrypt Data |
Modes Of Introduction The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.Phase | Note |
---|
Architecture and Design | OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase. | Architecture and Design | For hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device. | Operation | | System Configuration | |
Likelihood Of Exploit Demonstrative Examples Example 1 The following code attempts to establish a connection to a site to communicate sensitive information. (bad code) Example Language: Java
try { URL u = new URL("http://www.secret.example.org/"); HttpURLConnection hu = (HttpURLConnection) u.openConnection(); hu.setRequestMethod("PUT"); hu.connect(); OutputStream os = hu.getOutputStream(); hu.disconnect(); } catch (IOException e) {
//...
}
Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors. Example 2 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. Multiple vendors used cleartext transmission of sensitive information in their OT products. Example 3 A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed. Example 4 The following Azure CLI command lists the properties of a particular storage account: The JSON result might be: (bad code) Example Language: JSON
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"
}
The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.). Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as: (good code) Example Language: Shell
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true
The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true: (good code) Example Language: JSON
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"
}
Note: to enable secure transfer using Azure's Portal instead of the command line:
- Open the Create storage account pane in the Azure portal.
- In the Advanced page, select the Enable secure transfer checkbox.
Observed Examples Reference | Description |
| Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens. |
| Building Controller uses a protocol that transmits authentication credentials in plaintext. |
| Programmable Logic Controller (PLC) sends password in plaintext. |
| Passwords transmitted in cleartext. |
| Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP. |
| Product sends password hash in cleartext in violation of intended policy. |
| Remote management feature sends sensitive information including passwords in cleartext. |
| Backup routine sends password in cleartext in email. |
| Product transmits Blowfish encryption key in cleartext. |
| Printer sends configuration information, including administrative password, in cleartext. |
| Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay ( CWE-294). |
| Product sends passwords in cleartext to a log server. |
| Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes. |
Detection Methods
Black Box Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic. Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption. |
Automated Static Analysis Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) |
Memberships This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources. Vulnerability Mapping Notes Usage: ALLOWED (this CWE ID could be used to map to real-world vulnerabilities) | Reason: Acceptable-Use | Rationale: This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities. | Comments: Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction. |
Notes Maintenance The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions. Taxonomy Mappings Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
PLOVER | | | Plaintext Transmission of Sensitive Information |
The CERT Oracle Secure Coding Standard for Java (2011) | SEC06-J | | Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar |
The CERT Oracle Secure Coding Standard for Java (2011) | SER02-J | | Sign then seal sensitive objects before sending them outside a trust boundary |
Software Fault Patterns | SFP23 | | Exposed Data |
ISA/IEC 62443 | Part 3-3 | | Req SR 4.1 |
ISA/IEC 62443 | Part 4-2 | | Req CR 4.1B |
References
|
|
[REF-44] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
|
|
|
|
|
Content History Submissions |
---|
Submission Date | Submitter | Organization |
---|
2006-07-19 (CWE Draft 3, 2006-07-19) | PLOVER | | | Contributions |
---|
Contribution Date | Contributor | Organization |
---|
2023-01-24 | Accellera IP Security Assurance (IPSA) Working Group | Accellera Systems Initiative | Submitted original contents of CWE-1324 and reviewed its integration into this entry. | Modifications |
---|
Modification Date | Modifier | Organization |
---|
2008-07-01 | Eric Dalci | Cigital | updated Time_of_Introduction | 2008-09-08 | CWE Content Team | MITRE | updated Relationships, Taxonomy_Mappings | 2009-01-12 | CWE Content Team | MITRE | updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships | 2009-03-10 | CWE Content Team | MITRE | updated Potential_Mitigations | 2009-05-27 | CWE Content Team | MITRE | updated Related_Attack_Patterns | 2010-02-16 | CWE Content Team | MITRE | updated References | 2010-04-05 | CWE Content Team | MITRE | updated Applicable_Platforms, Common_Consequences, Time_of_Introduction | 2010-06-21 | CWE Content Team | MITRE | updated Detection_Factors, Relationships | 2010-12-13 | CWE Content Team | MITRE | updated Observed_Examples, Related_Attack_Patterns | 2011-03-29 | CWE Content Team | MITRE | updated Potential_Mitigations | 2011-06-01 | CWE Content Team | MITRE | updated Common_Consequences, Relationships, Taxonomy_Mappings | 2012-05-11 | CWE Content Team | MITRE | updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings | 2013-02-21 | CWE Content Team | MITRE | updated Applicable_Platforms, References | 2013-07-17 | CWE Content Team | MITRE | updated Relationships | 2014-02-18 | CWE Content Team | MITRE | updated Related_Attack_Patterns | 2014-06-23 | CWE Content Team | MITRE | updated Relationships | 2014-07-30 | CWE Content Team | MITRE | updated Relationships, Taxonomy_Mappings | 2017-05-03 | CWE Content Team | MITRE | updated Related_Attack_Patterns | 2017-11-08 | CWE Content Team | MITRE | updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships | 2018-01-23 | CWE Content Team | MITRE | updated Abstraction | 2018-03-27 | CWE Content Team | MITRE | updated References, Relationships, Type | 2019-01-03 | CWE Content Team | MITRE | updated Relationships, Taxonomy_Mappings | 2019-06-20 | CWE Content Team | MITRE | updated Relationships, Type | 2020-02-24 | CWE Content Team | MITRE | updated Applicable_Platforms, Related_Attack_Patterns, Relationships | 2021-10-28 | CWE Content Team | MITRE | updated Relationships | 2022-06-28 | CWE Content Team | MITRE | updated Relationships | 2022-10-13 | CWE Content Team | MITRE | updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References | 2023-01-31 | CWE Content Team | MITRE | updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings | 2023-04-27 | CWE Content Team | MITRE | updated Detection_Factors, References, Relationships | 2023-06-29 | CWE Content Team | MITRE | updated Description, Mapping_Notes, Relationships | 2024-02-29 (CWE 4.14, 2024-02-29) | CWE Content Team | MITRE | updated Demonstrative_Examples | Previous Entry Names |
---|
Change Date | Previous Entry Name |
---|
2009-01-12 | Plaintext Transmission of Sensitive Information | |
More information is available — Please edit the custom filter or select a different filter.
|