All posts by rocco

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-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-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-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-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-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-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-641 – Improper Restriction of Names for Files and Other Resources

Read Time:1 Minute, 30 Second

Description

The application constructs the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.

This may produce resultant weaknesses. For instance, if the names of these resources contain scripting characters, it is possible that a script may get executed in the client’s browser if the application ever displays the name of the resource on a dynamically generated web page. Alternately, if the resources are consumed by some application parser, a specially crafted name can exploit some vulnerability internal to the parser, potentially resulting in execution of arbitrary code on the server machine. The problems will vary based on the context of usage of such malformed resource names and whether vulnerabilities are present in or assumptions are made by the targeted technology that would make code execution possible.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-99

 

Consequences

Integrity, Confidentiality, Availability: Execute Unauthorized Code or Commands

Execution of arbitrary code in the context of usage of the resources with dangerous names.

Confidentiality, Availability: Read Application Data, DoS: Crash, Exit, or Restart

Crash of the consumer code of these resources resulting in information leakage or denial of service.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Do not allow users to control names of resources used on the server side.

Phase: Architecture and Design

Description: 

Perform allowlist input validation at entry points and also before consuming the resources. Reject bad file names rather than trying to cleanse them.

Phase: Architecture and Design

Description: 

Make sure that technologies consuming the resources are not vulnerable (e.g. buffer overflow, format string, etc.) in a way that would allow code execution if the name of the resource is malformed.

CVE References

CWE-642 – External Control of Critical State Data

Read Time:3 Minute, 42 Second

Description

The software stores security-critical state information about its users, or the software itself, in a location that is accessible to unauthorized actors.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-668

 

Consequences

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

An attacker could potentially modify the state in malicious ways. If the state is related to the privileges or level of authentication that the user has, then state modification might allow the user to bypass authentication or elevate privileges.

Confidentiality: Read Application Data

The state variables may contain sensitive information that should not be known by the client.

Availability: DoS: Crash, Exit, or Restart

By modifying state variables, the attacker could violate the application’s expectations for the contents of the state, leading to a denial of service due to an unexpected error condition.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Understand all the potential locations that are accessible to attackers. For example, some programmers assume that cookies and hidden form fields cannot be modified by an attacker, or they may not consider that environment variables can be modified before a privileged program is invoked.

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Description: 

Store state information on the server side only. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Description: 

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Operation, Implementation

Description: 

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Phase: Testing

Description: 

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing

Description: 

Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software’s operation may slow down, but it should not become unstable, crash, or generate incorrect results.

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.

CVE References

  • CVE-2005-2428
    • Mail client stores password hashes for unrelated accounts in a hidden form field.
  • CVE-2008-0306
    • Privileged program trusts user-specified environment variable to modify critical configuration settings.
  • CVE-1999-0073
    • Telnet daemon allows remote clients to specify critical environment variables for the server, leading to code execution.
  • CVE-2007-4432
    • Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
  • CVE-2006-7191
    • Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
  • CVE-2008-5738
    • Calendar application allows bypass of authentication by setting a certain cookie value to 1.
  • CVE-2008-5642
    • Setting of a language preference in a cookie enables path traversal attack.
  • CVE-2008-5125
    • Application allows admin privileges by setting a cookie value to “admin.”
  • CVE-2008-5065
    • Application allows admin privileges by setting a cookie value to “admin.”
  • CVE-2008-4752
    • Application allows admin privileges by setting a cookie value to “admin.”
  • CVE-2000-0102
    • Shopping cart allows price modification via hidden form field.
  • CVE-2000-0253
    • Shopping cart allows price modification via hidden form field.
  • CVE-2008-1319
    • Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.

CWE-643 – Improper Neutralization of Data within XPath Expressions (‘XPath Injection’)

Read Time:54 Second

Description

The software uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.

The net effect is that the attacker will have control over the information selected from the XML database and may use that ability to control application flow, modify logic, retrieve unauthorized data, or bypass important checks (e.g. authentication).

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-943
CWE-91

 

Consequences

Access Control: Bypass Protection Mechanism

Controlling application flow (e.g. bypassing authentication).

Confidentiality: Read Application Data

The attacker could read restricted XML content.

 

Potential Mitigations

Phase: Implementation

Description: 

Use parameterized XPath queries (e.g. using XQuery). This will help ensure separation between data plane and control plane.

Phase: Implementation

Description: 

Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XPath queries is safe in that context.

CVE References