Sam Craig
May 12, 2022
Authentication Cryptography Data Security Encryption Privacy

Exploring CWE-319: Cleartext Transmission of Sensitive Information

Introduction

A02:2021 – Cryptographic Failures is the second most common vulnerability on OWASP’s Top Ten List of web application vulnerabilities. Strong encryption is a fundamental component of data security and privacy, but it is easy to get wrong. Errors in data encryption can undermine or destroy its protections, leading to the exposure of sensitive information.

Data encryption can go wrong in many ways. CWE 319 addresses the transmission of sensitive data in cleartext or plaintext.

Accidentally Exposing Sensitive Information

Depending on the definition of “sensitive information,” this cryptographic failure could occur in a couple of different ways. These include:

  • Sending Data in Cleartext: Sensitive information may be exposed in cleartext if that data is not encrypted when being sent over the network. For example, the HTTP standard does not include encryption, so any data sent to or from a webserver using HTTP is potentially exposed to eavesdroppers.
  • Sending Encryption Keys in Plaintext: Data encryption provides no protection if the secret keys are exposed to an eavesdropper as well. Symmetric encryption algorithms require that a shared secret key be established over a secure channel. If a key is created or transmitted in cleartext, then an eavesdropper could use the intercepted key to decrypt any data protected using it.

Where Data Encryption in Transit Goes Wrong

Best practices state that encryption of data in transit is advisable regardless of the sensitivity of the data in question or whether it’s sent across internal or external networks. However, data can be transmitted in cleartext for a variety of different reasons, including:

  • HTTP vs. HTTPS: The HTTP standard for web traffic has no built-in security. It is designed to define the structure for communications between webservers and clients and nothing more. A failure to use HTTPS, which uses TLS to encapsulate and encrypt HTTP traffic, instead of HTTP can lead to the exposure of sensitive information to eavesdroppers.
  • Mobile Applications: In a web browser, whether a site is using secure HTTPS and insecure HTTP is easy to determine by checking for the lock icon in the address bar. Mobile apps, on the other hand, are much less transparent about how they are communicating with servers behind the scenes. A mobile application could be configured to use HTTP or another unencrypted and insecure protocol when communicating sensitive information to web applications and APIs.
  • Debug and Logging: Debugging and logging functionality is intended to provide information about how an application or website is behaving and to help with diagnosing any errors. Error logs and debugging information may contain sensitive data. This data may be transmitted to a remote computer using syslog or a similar protocol in plaintext, potentially exposing sensitive information.
  • Legacy Systems: Applications that interact with legacy systems may be constrained by the communications protocols supported by these systems. In these cases, an application may be forced to use an insecure and unencrypted protocol to send potentially sensitive data to these systems.
  • Protocol Fallbacks: While modern applications may use secure communications protocols, they often try to support backward compatibility. For example, when negotiating the parameters for a TLS session, a webserver and client may fall back to an insecure version if they both don’t support any secure version of the protocol. This could result in the use of an insecure and unencrypted protocol that can be broken by an attacker.

Case Study: NETGEAR Nighthawk R7800

A vulnerability was discovered in 2021 that affected the firmware update process of certain NETGEAR routers. Affected routers allowed fallbacks to an insecure protocol when delivering firmware updates.

This vulnerability could be exploited without authentication. Successful exploitation could allow an attacker to execute code on the vulnerable routers with root-level permissions.

Encrypting Internal Network Data

Few need convincing that data transmitted across external or public networks should be encrypted. However, the same can’t be said about internal network data. In fact, outside of some heavily regulated industries such as Financial Services (driven by things such as Payment Card Industry Data Security Standard (PCI), despite PCI not requiring internal network data be encrypted) or Critical Infrastructure, very few organizations encrypt internal network data. And with the traditional lines between internal and external networks being blurred, encryption is becoming increasingly important.

Ask any Digital Forensics and Incident Response (DFIR) expert, and they’ll tell you once an attacker has breached a company’s network, their reconnaissance efforts becoming increasingly easier, as most internal network data is not encrypted, making techniques like network sniffing and eavesdropping far more achievable.

Therefore, it’s critical for organizations to begin to include plans to introduce internal network encryption into their security roadmap.

Properly Encrypting Data in Transit

Websites and applications are increasingly moving to use HTTPS for all traffic regardless of whether or not they contain sensitive information. However, sensitive information can still be exposed over the network due to various issues. Best practices for protecting against the accidental exposure of sensitive data in cleartext include:

  • Use the HTTPS protocol by default for web and mobile app traffic
  • Disable fallbacks to insecure protocols
  • Always use a strong encryption algorithm to protect sensitive data
  • Use a key agreement protocol based on asymmetric cryptography to create secret keys
  • Do not include sensitive information in log messages or files
  • Encrypt data transmitted on internal networks

Up Next

To help build understanding of how cryptography can go wrong and how to fix it, we’ll continue to dive deep into prevention measures and most of the 29 CWEs related to OWASP’s A02:2021 – Cryptographic Failures vulnerability in a series of blogs. Each blog will describe the weakness, why it happens, a real-world case study, and recommended mitigations.

We’re very committed to improving the state of cryptography and data security by sharing knowledge and helping to correct common misconceptions about how cryptography works and how to use it properly. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog in the page footer below.

Get radically effective data-level protection. Get Ubiq.