Category Archives: CWE

CWE

CWE-353 – Missing Support for Integrity Check

Read Time:1 Minute, 15 Second

Description

The software uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.

If integrity check values or “checksums” are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. The lack of checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol’s checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-345
CWE-354

 

Consequences

Integrity, Other: Other

Data that is parsed and used may be corrupted.

Non-Repudiation, Other: Hide Activities, Other

Without a checksum it is impossible to determine if any changes have been made to the data after it was sent.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.

Phase: Implementation

Description: 

Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.

CVE References

CWE

CWE-354 – Improper Validation of Integrity Check Value

Read Time:1 Minute, 9 Second

Description

The software does not validate or incorrectly validates the integrity check values or “checksums” of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

Improper validation of checksums before use results in an unnecessary risk that can easily be mitigated. The protocol specification describes the algorithm used for calculating the checksum. It is then a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match. Improper verification of the calculated checksum and the received checksum can lead to far greater consequences.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-345
CWE-345
CWE-754
CWE-353

 

Consequences

Integrity, Other: Modify Application Data, Other

Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.

Integrity, Other: Other

Data that is parsed and used may be corrupted.

Non-Repudiation, Other: Hide Activities, Other

Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent.

 

Potential Mitigations

Phase: Implementation

Description: 

Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

CVE References

CWE

CWE-318 – Cleartext Storage of Sensitive Information in Executable

Read Time:36 Second

Description

The application stores sensitive information in cleartext in an executable.

Attackers can reverse engineer binary code to obtain secret data. This is especially easy when the cleartext is plain ASCII. 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.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-312

 

Consequences

Confidentiality: Read Application Data

 

Potential Mitigations

CVE References

  • CVE-2005-1794
    • Product stores RSA private key in a DLL and uses it to sign a certificate, allowing spoofing of servers and Adversary-in-the-Middle (AITM) attacks.
  • CVE-2001-1527
    • administration passwords in cleartext in executable
CWE

CWE-319 – Cleartext Transmission of Sensitive Information

Read Time:1 Minute, 49 Second

Description

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

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

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-311
CWE-311

 

Consequences

Integrity, Confidentiality: 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

Description: 

Encrypt the data with a reliable encryption scheme before transmitting.

Phase: Implementation

Description: 

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

Phase: Testing

Description: 

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

Description: 

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

CVE References

  • 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.
CWE

CWE-32 – Path Traversal: ‘…’ (Triple Dot)

Read Time:1 Minute, 3 Second

Description

The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize ‘…’ (triple dot) sequences that can resolve to a location that is outside of that directory.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-23

 

Consequences

Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories

 

Potential Mitigations

Phase: Implementation

Effectiveness: High

Description: 

Phase: Implementation

Description: 

Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CVE References

  • CVE-2001-0480
    • read of arbitrary files and directories using GET or CD with “…” in Windows-based FTP server.
  • CVE-2002-0288
    • read files using “.” and Unicode-encoded “/” or “” characters in the URL.
CWE

CWE-321 – Use of Hard-coded Cryptographic Key

Read Time:27 Second

Description

The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-798
CWE-798
CWE-798

 

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

If hard-coded cryptographic keys are used, it is almost certain that malicious users will gain access through the account in question.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Prevention schemes mirror that of hard-coded password storage.

CVE References

CWE

CWE-322 – Key Exchange without Entity Authentication

Read Time:1 Minute, 9 Second

Description

The software performs a key exchange with an actor without verifying the identity of that actor.

Performing a key exchange will preserve the integrity of the information sent between two entities, but this will not guarantee that the entities are who they claim they are. This may enable an attacker to impersonate an actor by modifying traffic between the two entities. Typically, this involves a victim client that contacts a malicious server that is impersonating a trusted server. If the client skips authentication or ignores an authentication failure, the malicious server may request authentication information from the user. The malicious server can then use this authentication information to log in to the trusted server using the victim’s credentials, sniff traffic between the victim and trusted server, etc.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-923
CWE-295

 

Consequences

Access Control: Bypass Protection Mechanism

No authentication takes place in this process, bypassing an assumed protection of encryption.

Confidentiality: Read Application Data

The encrypted communication between a user and a trusted host may be subject to sniffing by any actor in the communication path.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Ensure that proper authentication is included in the system design.

Phase: Implementation

Description: 

Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.

CVE References

CWE

CWE-323 – Reusing a Nonce, Key Pair in Encryption

Read Time:41 Second

Description

Nonces should be used for the present occasion and only once.

Nonces are often bundled with a key in a communication exchange to produce a new session key for each exchange.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-344

 

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.

 

Potential Mitigations

Phase: Implementation

Description: 

Refuse to reuse nonce values.

Phase: Implementation

Description: 

Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.

CVE References

CWE

CWE-324 – Use of a Key Past its Expiration Date

Read Time:54 Second

Description

The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.

While the expiration of keys does not necessarily ensure that they are compromised, it is a significant concern that keys which remain in use for prolonged periods of time have a decreasing probability of integrity. For this reason, it is important to replace keys within a period of time proportional to their strength.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-672
CWE-298

 

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

The cryptographic key in question may be compromised, providing a malicious user with a method for authenticating as the victim.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Adequate consideration should be put in to the user interface in order to notify users previous to the key’s expiration, to explain the importance of new key generation and to walk users through the process as painlessly as possible.

CVE References

CWE

CWE-325 – Missing Cryptographic Step

Read Time:21 Second

Description

The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-573
CWE-358

 

Consequences

Access Control: Bypass Protection Mechanism

Confidentiality, Integrity: Read Application Data, Modify Application Data

Accountability, Non-Repudiation: Hide Activities

 

Potential Mitigations

CVE References

  • CVE-2001-1585
    • Missing challenge-response step allows authentication bypass using public key.