Category Archives: CWE

CWE-512 – Spyware

Read Time:52 Second

Description

The software collects personally identifiable information about a human user or the user’s activities, but the software accesses this information using other resources besides itself, and it does not require that user’s explicit approval or direct input into the software.

“Spyware” is a commonly used term with many definitions and interpretations. In general, it is meant to software that collects information or installs functionality that human users might not allow if they were fully aware of the actions being taken by the software. For example, a user might expect that tax software would collect a social security number and include it when filing a tax return, but that same user would not expect gaming software to obtain the social security number from that tax software’s data.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-506

 

Consequences

Confidentiality: Read Application Data

 

Potential Mitigations

Phase: Operation

Description: 

Use spyware detection and removal software.

Phase: Installation

Description: 

Always verify the integrity of the software that is being installed.

CVE References

CWE-514 – Covert Channel

Read Time:20 Second

Description

A covert channel is a path that can be used to transfer information in a way not intended by the system’s designers.

Typically the system has not given authorization for the transmission and has no knowledge of its occurrence.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1229

 

Consequences

Confidentiality, Access Control: Read Application Data, Bypass Protection Mechanism

 

Potential Mitigations

CVE References

CWE-515 – Covert Storage Channel

Read Time:1 Minute, 22 Second

Description

A covert storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information.

Covert storage channels occur when out-of-band data is stored in messages for the purpose of memory reuse. Covert channels are frequently classified as either storage or timing channels. Examples would include using a file intended to hold only audit information to convey user passwords–using the name of a file or perhaps status bits associated with it that can be read by all users to signal the contents of the file. Steganography, concealing information in such a manner that no one but the intended recipient knows of the existence of the message, is a good example of a covert storage channel.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-514

 

Consequences

Confidentiality: Read Application Data

Covert storage channels may provide attackers with important information about the system in question.

Integrity, Confidentiality: Read Application Data

If these messages or packets are sent with unnecessary data contained within, it may tip off malicious listeners as to the process that created the message. With this information, attackers may learn any number of things, including the hardware platform, operating system, or algorithms used by the sender. This information can be of significant value to the user in launching further attacks.

 

Potential Mitigations

Phase: Implementation

Description: 

Ensure that all reserved fields are set to zero before messages are sent and that no unnecessary information is included.

CVE References

CWE-52 – Path Equivalence: ‘/multiple/trailing/slash//’

Read Time:42 Second

Description

A software system that accepts path input in the form of multiple trailing slash (‘/multiple/trailing/slash//’) without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-41
CWE-163
CWE-289

 

Consequences

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

 

Potential Mitigations

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-2002-1078
    • Directory listings in web server using multiple trailing slash

CWE-520 – .NET Misconfiguration: Use of Impersonation

Read Time:54 Second

Description

Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks.

.NET server applications can optionally execute using the identity of the user authenticated to the client. The intention of this functionality is to bypass authentication and access control checks within the .NET application code. Authentication is done by the underlying web server (Microsoft Internet Information Service IIS), which passes the authenticated token, or unauthenticated anonymous token, to the .NET application. Using the token to impersonate the client, the application then relies on the settings within the NTFS directories and files to control access. Impersonation enables the application, on the server running the .NET application, to both execute code and access resources in the context of the authenticated and authorized user.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-266

 

Consequences

Access Control: Gain Privileges or Assume Identity

 

Potential Mitigations

Phase: Operation

Description: 

Run the application with limited privilege to the underlying operating and file system.

CVE References

CWE-521 – Weak Password Requirements

Read Time:1 Minute, 0 Second

Description

The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.

Authentication mechanisms often rely on a memorized secret (also known as a password) to provide an assertion of identity for a user of a system. It is therefore important that this password be of sufficient complexity and impractical for an adversary to guess. The specific requirements around how complex a password needs to be depends on the type of system being protected. Selecting the correct password requirements and enforcing them through implementation are critical to the overall success of the authentication mechanism.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-287
CWE-287

 

Consequences

Access Control: Gain Privileges or Assume Identity

An attacker could easily guess user passwords and gain access user accounts.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Description: 

Consider a second
authentication factor beyond the password, which prevents the
password from being a single point of failure. See CWE-308 for
further information.

Phase: Implementation

Description: 

Consider implementing a password complexity meter to inform users when a chosen password meets the required attributes.

CVE References

CWE-522 – Insufficiently Protected Credentials

Read Time:58 Second

Description

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-287
CWE-287
CWE-668

 

Consequences

Access Control: Gain Privileges or Assume Identity

An attacker could gain access to user accounts and access sensitive data used by the user accounts.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use an appropriate security mechanism to protect the credentials.

Phase: Architecture and Design

Description: 

Make appropriate use of cryptography to protect the credentials.

Phase: Implementation

Description: 

Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).

CVE References

  • CVE-2007-0681
    • Web app allows remote attackers to change the passwords of arbitrary users without providing the original password, and possibly perform other unauthorized actions.
  • CVE-2000-0944
    • Web application password change utility doesn’t check the original password.
  • CVE-2005-3435
    • product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
  • CVE-2005-0408
    • chain: product generates predictable MD5 hashes using a constant value combined with username, allowing authentication bypass.

CWE-523 – Unprotected Transport of Credentials

Read Time:57 Second

Description

Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.

SSL (Secure Socket Layer) provides data confidentiality and integrity to HTTP. By encrypting HTTP messages, SSL protects from attackers eavesdropping or altering message contents.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-522
CWE-312

 

Consequences

Access Control: Gain Privileges or Assume Identity

 

Potential Mitigations

Phase: Operation, System Configuration

Description: 

Enforce SSL use for the login page or any page used to transmit user credentials or other sensitive information. Even if the entire site does not use SSL, it MUST use SSL for login. Additionally, to help prevent phishing attacks, make sure that SSL serves the login page. SSL allows the user to verify the identity of the server to which they are connecting. If the SSL serves login page, the user can be certain they are talking to the proper end system. A phishing attack would typically redirect a user to a site that does not have a valid trusted server certificate issued from an authorized supplier.

CVE References

CWE-524 – Use of Cache Containing Sensitive Information

Read Time:43 Second

Description

The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.

Applications may use caches to improve efficiency when communicating with remote entities or performing intensive calculations. A cache maintains a pool of objects, threads, connections, pages, financial data, passwords, or other resources to minimize the time it takes to initialize and access these resources. If the cache is accessible to unauthorized actors, attackers can read the cache and obtain this sensitive information.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668

 

Consequences

Confidentiality: Read Application Data

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Protect information stored in cache.

Phase: Architecture and Design

Description: 

Do not store unnecessarily sensitive information in the cache.

Phase: Architecture and Design

Description: 

Consider using encryption in the cache.

CVE References