CWE-640 – Weak Password Recovery Mechanism for Forgotten Password

Read Time:1 Minute, 20 Second

Description

The software contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-287
CWE-287

 

Consequences

Access Control: Gain Privileges or Assume Identity

An attacker could gain unauthorized access to the system by retrieving legitimate user’s authentication credentials.

Availability: DoS: Resource Consumption (Other)

An attacker could deny service to legitimate system users by launching a brute force attack on the password recovery mechanism using user ids of legitimate users.

Integrity, Other: Other

The system’s security functionality is turned against the system by the attacker.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.

Phase: Architecture and Design

Description: 

Do not use standard weak security questions and use several security questions.

Phase: Architecture and Design

Description: 

Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses.

Phase: Architecture and Design

Description: 

Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record.

Phase: Architecture and Design

Description: 

Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism.

Phase: Architecture and Design

Description: 

Assign a new temporary password rather than revealing the original password.

CVE References

CWE-64 – Windows Shortcut Following (.LNK)

Read Time:1 Minute, 17 Second

Description

The software, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the software to operate on unauthorized files.

The shortcut (file with the .lnk extension) can permit an attacker to read/write a file that they originally did not have permissions to access.

Modes of Introduction:

– Operation

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-59

 

Consequences

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

 

Potential Mitigations

Phase: Architecture and Design

Description: 

CVE References

  • CVE-2000-0342
    • Mail client allows remote attackers to bypass the user warning for executable attachments such as .exe, .com, and .bat by using a .lnk file that refers to the attachment, aka “Stealth Attachment.”
  • CVE-2001-1042
    • FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
  • CVE-2001-1043
    • FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
  • CVE-2005-0587
    • Browser allows remote malicious web sites to overwrite arbitrary files by tricking the user into downloading a .LNK (link) file twice, which overwrites the file that was referenced in the first .LNK file.
  • CVE-2003-1233
    • Rootkits can bypass file access restrictions to Windows kernel directories using NtCreateSymbolicLinkObject function to create symbolic link

CWE-639 – Authorization Bypass Through User-Controlled Key

Read Time:1 Minute, 9 Second

Description

The system’s authorization functionality does not prevent one user from gaining access to another user’s data or record by modifying the key value identifying the data.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-863
CWE-863
CWE-284

 

Consequences

Access Control: Bypass Protection Mechanism

Access control checks for specific user data or functionality can be bypassed.

Access Control: Gain Privileges or Assume Identity

Horizontal escalation of privilege is possible (one user can view/modify information of another user).

Access Control: Gain Privileges or Assume Identity

Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Phase: Architecture and Design, Implementation

Description: 

Make sure that the key that is used in the lookup of a specific user’s record is not controllable externally by the user or that any tampering can be detected.

Phase: Architecture and Design

Description: 

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

CVE References

CWE-638 – Not Using Complete Mediation

Read Time:1 Minute, 3 Second

Description

The software does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity’s rights or privileges change over time.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-657
CWE-862

 

Consequences

Integrity, Confidentiality, Availability, Access Control, Other: Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Read Application Data, Other

A user might retain access to a critical resource even after privileges have been revoked, possibly allowing access to privileged functionality or sensitive information, depending on the role of the resource.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Invalidate cached privileges, file handles or descriptors, or other access credentials whenever identities, processes, policies, roles, capabilities or permissions change. Perform complete authentication checks before accepting, caching and reusing data, dynamic content and code (scripts). Avoid caching access control decisions as much as possible.

Phase: Architecture and Design

Description: 

Identify all possible code paths that might access sensitive resources. If possible, create and use a single interface that performs the access checks, and develop code standards that require use of this interface.

CVE References

  • CVE-2007-0408
    • Server does not properly validate client certificates when reusing cached connections.

CWE-637 – Unnecessary Complexity in Protection Mechanism (Not Using ‘Economy of Mechanism’)

Read Time:1 Minute, 34 Second

Description

The software uses a more complex mechanism than necessary, which could lead to resultant weaknesses when the mechanism is not correctly understood, modeled, configured, implemented, or used.

Security mechanisms should be as simple as possible. Complex security mechanisms may engender partial implementations and compatibility problems, with resulting mismatches in assumptions and implemented security. A corollary of this principle is that data specifications should be as simple as possible, because complex data specifications result in complex validation code. Complex tasks and systems may also need to be guarded by complex security checks, so simple systems should be preferred.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-657

 

Consequences

Other: Other

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Avoid complex security mechanisms when simpler ones would meet requirements. Avoid complex data models, and unnecessarily complex operations. Adopt architectures that provide guarantees, simplify understanding through elegance and abstraction, and that can be implemented similarly. Modularize, isolate and do not trust complex code, and apply other secure programming principles on these modules (e.g., least privilege) to mitigate vulnerabilities.

CVE References

  • CVE-2007-6067
    • Support for complex regular expressions leads to a resultant algorithmic complexity weakness (CWE-407).
  • CVE-2007-1552
    • Either a filename extension and a Content-Type header could be used to infer the file type, but the developer only checks the Content-Type, enabling unrestricted file upload (CWE-434).
  • CVE-2007-6479
    • In Apache environments, a “filename.php.gif” can be redirected to the PHP interpreter instead of being sent as an image/gif directly to the user. Not knowing this, the developer only checks the last extension of a submitted filename, enabling arbitrary code execution.
  • CVE-2005-2148
    • The developer cleanses the $_REQUEST superglobal array, but PHP also populates $_GET, allowing attackers to bypass the protection mechanism and conduct SQL injection attacks against code that uses $_GET.

CWE-636 – Not Failing Securely (‘Failing Open’)

Read Time:1 Minute, 14 Second

Description

When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.

By entering a less secure state, the product inherits the weaknesses associated with that state, making it easier to compromise. At the least, it causes administrators to have a false sense of security. This weakness typically occurs as a result of wanting to “fail functional” to minimize administration and support costs, instead of “failing safe.”

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-657
CWE-755
CWE-280

 

Consequences

Access Control: Bypass Protection Mechanism

Intended access restrictions can be bypassed, which is often contradictory to what the product’s administrator expects.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.

CVE References

  • CVE-2007-5277
    • The failure of connection attempts in a web browser resets DNS pin restrictions. An attacker can then bypass the same origin policy by rebinding a domain name to a different IP address. This was an attempt to “fail functional.”
  • CVE-2006-4407
    • Incorrect prioritization leads to the selection of a weaker cipher. Although it is not known whether this issue occurred in implementation or design, it is feasible that a poorly designed algorithm could be a factor.

CWE-628 – Function Call with Incorrectly Specified Arguments

Read Time:46 Second

Description

The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-573

 

Consequences

Other, Access Control: Quality Degradation, Gain Privileges or Assume Identity

This weakness can cause unintended behavior and can lead to additional weaknesses such as allowing an attacker to gain unintended access to system resources.

 

Potential Mitigations

Phase: Build and Compilation

Description: 

Once found, these issues are easy to fix. Use code inspection tools and relevant compiler features to identify potential violations. Pay special attention to code that is not likely to be exercised heavily during QA.

Phase: Architecture and Design

Description: 

Make sure your API’s are stable before you use them in production code.

CVE References

  • CVE-2006-7049
    • The method calls the functions with the wrong argument order, which allows remote attackers to bypass intended access restrictions.

CWE-627 – Dynamic Variable Evaluation

Read Time:1 Minute, 22 Second

Description

In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.

The resultant vulnerabilities depend on the behavior of the application, both at the crossover point and in any control/data flow that is reachable by the related variables or functions.

Many interpreted languages support the use of a “$$varname” construct to set a variable whose name is specified by the $varname variable. In PHP, these are referred to as “variable variables.” Functions might also be invoked using similar syntax, such as $$funcname(arg1, arg2).

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-914
CWE-183

 

Consequences

Confidentiality, Integrity, Availability: Modify Application Data, Execute Unauthorized Code or Commands

An attacker could gain unauthorized access to internal program variables and execute arbitrary code.

 

Potential Mitigations

Phase: Implementation

Description: 

Refactor the code to avoid dynamic variable evaluation whenever possible.

Phase: Implementation

Description: 

Use only allowlists of acceptable variable or function names.

Phase: Implementation

Description: 

For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments.

CVE References

  • CVE-2009-0422
    • Chain: Dynamic variable evaluation allows resultant remote file inclusion and path traversal.
  • CVE-2007-2431
    • Chain: dynamic variable evaluation in PHP program used to modify critical, unexpected $_SERVER variable for resultant XSS.
  • CVE-2006-4904
    • Chain: dynamic variable evaluation in PHP program used to conduct remote file inclusion.
  • CVE-2006-4019
    • Dynamic variable evaluation in mail program allows reading and modifying attachments and preferences of other users.

CWE-626 – Null Byte Interaction Error (Poison Null Byte)

Read Time:23 Second

Description

The product does not properly handle null bytes or NUL characters when passing data between different representations or components.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-147
CWE-436

 

Consequences

Integrity: Unexpected State

 

Potential Mitigations

Phase: Implementation

Description: 

Remove null bytes from all incoming strings.

CVE References

  • CVE-2005-3153
    • inserting SQL after a NUL byte bypasses allowlist regexp, enabling SQL injection

CWE-625 – Permissive Regular Expression

Read Time:57 Second

Description

The product uses a regular expression that does not sufficiently restrict the set of allowed values.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-185
CWE-187
CWE-184
CWE-183

 

Consequences

Access Control: Bypass Protection Mechanism

 

Potential Mitigations

Phase: Implementation

Description: 

When applicable, ensure that the regular expression marks beginning and ending string patterns, such as “/^string$/” for Perl.

CVE References

  • CVE-2002-2175
    • insertion of username into regexp results in partial comparison, causing wrong database entry to be updated when one username is a substring of another.
  • CVE-2006-4527
    • regexp intended to verify that all characters are legal, only checks that at least one is legal, enabling file inclusion.
  • CVE-2005-1949
    • Regexp for IP address isn’t anchored at the end, allowing appending of shell metacharacters.
  • CVE-2002-2109
    • Regexp isn’t “anchored” to the beginning or end, which allows spoofed values that have trusted values as substrings.
  • CVE-2006-6511
    • regexp in .htaccess file allows access of files whose names contain certain substrings
  • CVE-2006-6629
    • allow load of macro files whose names contain certain substrings.