Cleartext Transmission of Sensitive Information
|ID: 319||Date: (C)2012-05-14 (M)2020-01-16|
|Type: weakness||Status: DRAFT|
|Abstraction Type: Base|
The software transmits sensitive or security-critical data in
cleartext in a communication channel that can be sniffed by unauthorized
Extended DescriptionMany communication channels can be "sniffed" by attackers during data
transmission. For example, network traffic can often be sniffed by any
attacker who has access to a network interface. This significantly lowers
the difficulty of exploitation by attackers.
Likelihood of Exploit: Medium to High
Applicable PlatformsLanguage Class: Language-independent
Time Of Introduction
- Architecture and Design
- System Configuration
Related Attack Patterns
|IntegrityConfidentiality ||Read application
dataModify files or
directories ||Anyone can read the information by gaining access to the channel being
used for communication. |
|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. || || |
|Architecture and Design || ||Encrypt the data with a reliable encryption scheme before
transmitting. || || |
|Implementation || ||When using web applications with SSL, use SSL for the entire session
from login to logout, not just for the initial login page. || || |
|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. || || |
|CWE-319 ChildOf CWE-895 ||Category ||CWE-888 || |
Demonstrative Examples (Details)
- The following code attempts to establish a connection to a site to
communicate sensitive information. (Demonstrative Example Id DX-42)
- CVE-2002-1949 : Passwords transmitted in cleartext.
- CVE-2008-4122 : Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
- CVE-2008-3289 : Product sends password hash in cleartext in violation of intended policy.
- CVE-2008-4390 : Remote management feature sends sensitive information including passwords in cleartext.
- CVE-2007-5626 : Backup routine sends password in cleartext in email.
- CVE-2004-1852 : Product transmits Blowfish encryption key in cleartext.
- CVE-2008-0374 : Printer sends configuration information, including administrative password, in cleartext.
- CVE-2007-4961 : Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
- CVE-2007-4786 : Product sends passwords in cleartext to a log server.
- CVE-2005-3140 : Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
For more examples, refer to CVE relations in the bottom box.
White Box Definitions None
Black Box Definitions None
|PLOVER || ||Plaintext Transmission of Sensitive
Information || |
|CERT Java Secure Coding ||SEC06-J ||Do not rely on the default automatic signature verification
provided by URLClassLoader and java.util.jar || |
|CERT Java Secure Coding ||SER02-J ||Sign then seal sensitive objects before sending them outside a
trust boundary || |
- OWASP .Top 10 2007-Insecure Communications.
- M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 9, "Protecting Secret Data" Page
299'. Published on 2002.
- Michael Howard David LeBlanc John Viega .24 Deadly Sins of Software Security. McGraw-Hill. Section:'"Sin 22: Failing to Protect Network Traffic." Page
337'. Published on 2010.