Base · Medium

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.

CWE-319 · Base Level ·13 CVEs ·5 Mitigations

Description

The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

Potential Impact

Integrity, Confidentiality

Read Application Data, Modify Files or Directories

Integrity, Confidentiality

Read Application Data, Modify Files or Directories, Other

Demonstrative Examples

The following code attempts to establish a connection to a site to communicate sensitive information.
Bad
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.
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.
The following Azure CLI command lists the properties of a particular storage account:
Informative
az storage account show -g {ResourceGroupName} -n {StorageAccountName}
The JSON result might be:
Bad
{
		   
		     "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
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
{
		   
		     "name": "{StorageAccountName}",
		     "enableHttpsTrafficOnly": true,
		     "type": "Microsoft.Storage/storageAccounts"
		   
		   }

Mitigations & Prevention

Architecture and Design

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

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.

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.

Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.

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 wea
  • Automated Static Analysis High — 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 sea

Real-World CVE Examples

CVE IDDescription
CVE-2022-29519Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
CVE-2022-30312Building Controller uses a protocol that transmits authentication credentials in plaintext.
CVE-2022-31204Programmable Logic Controller (PLC) sends password in plaintext.
CVE-2002-1949Passwords transmitted in cleartext.
CVE-2008-4122Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
CVE-2008-3289Product sends password hash in cleartext in violation of intended policy.
CVE-2008-4390Remote management feature sends sensitive information including passwords in cleartext.
CVE-2007-5626Backup routine sends password in cleartext in email.
CVE-2004-1852Product transmits Blowfish encryption key in cleartext.
CVE-2008-0374Printer sends configuration information, including administrative password, in cleartext.
CVE-2007-4961Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
CVE-2007-4786Product sends passwords in cleartext to a log server.
CVE-2005-3140Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.

Taxonomy Mappings

  • 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

Frequently Asked Questions

What is CWE-319?

CWE-319 (Cleartext Transmission of Sensitive Information) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

How can CWE-319 be exploited?

Attackers can exploit CWE-319 (Cleartext Transmission of Sensitive Information) to read application data, modify files or directories. This weakness is typically introduced during the Architecture and Design, Architecture and Design, Operation, System Configuration phase of software development.

How do I prevent CWE-319?

Key mitigations include: Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

What is the severity of CWE-319?

CWE-319 is classified as a Base-level weakness (Medium abstraction). It has been observed in 13 real-world CVEs.