Monthly Archives: May 2022

CWE

CWE-61 – UNIX Symbolic Link (Symlink) Following

Read Time:1 Minute, 44 Second

Description

The software, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the software to operate on unauthorized files.

A software system that allows UNIX symbolic links (symlink) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The symbolic link can permit an attacker to read/write/corrupt a file that they originally did not have permissions to access.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-59
CWE-362
CWE-340
CWE-386
CWE-732

 

Consequences

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

 

Potential Mitigations

Phase: Implementation

Description: 

Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.

Phase: Architecture and Design

Description: 

CVE References

  • CVE-1999-1386
    • Some versions of Perl follows symbolic links when running with the -e option, which allows local users to overwrite arbitrary files via a symlink attack.
  • CVE-2000-1178
    • Text editor follows symbolic links when creating a rescue copy during an abnormal exit, which allows local users to overwrite the files of other users.
  • CVE-2004-0217
    • Antivirus update allows local users to create or append to arbitrary files via a symlink attack on a logfile.
  • CVE-2003-0517
    • Symlink attack allows local users to overwrite files.
  • CVE-2000-0972
    • Setuid product allows file reading by replacing a file being edited with a symlink to the targeted file, leaking the result in error messages when parsing fails.
CWE

CWE-609 – Double-Checked Locking

Read Time:1 Minute, 6 Second

Description

The program uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.

Double-checked locking refers to the situation where a programmer checks to see if a resource has been initialized, grabs a lock, checks again to see if the resource has been initialized, and then performs the initialization if it has not occurred yet. This should not be done, as is not guaranteed to work in all languages and on all architectures. In summary, other threads may not be operating inside the synchronous block and are not guaranteed to see the operations execute in the same order as they would appear inside the synchronous block.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-667
CWE-367

 

Consequences

Integrity, Other: Modify Application Data, Alter Execution Logic

 

Potential Mitigations

Phase: Implementation

Description: 

While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the “volatile” keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references.

CVE References

CWE

CWE-608 – Struts: Non-private Field in ActionForm Class

Read Time:26 Second

Description

An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668

 

Consequences

Integrity, Confidentiality: Modify Application Data, Read Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

Make all fields private. Use getter to get the value of the field. Setter should be used only by the framework; setting an action form field from other actions is bad practice and should be avoided.

CVE References

CWE

CWE-607 – Public Static Final Field References Mutable Object

Read Time:20 Second

Description

A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-471

 

Consequences

Integrity: Modify Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

Protect mutable objects by making them private. Restrict access to the getter and setter as well.

CVE References

CWE

CWE-606 – Unchecked Input for Loop Condition

Read Time:21 Second

Description

The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1284
CWE-834

 

Consequences

Availability: DoS: Resource Consumption (CPU)

 

Potential Mitigations

Phase: Implementation

Description: 

Do not use user-controlled data for loop conditions.

Phase: Implementation

Description: 

Perform input validation.

CVE References

CWE

CWE-605 – Multiple Binds to the Same Port

Read Time:41 Second

Description

When multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed.

On most systems, a combination of setting the SO_REUSEADDR socket option, and a call to bind() allows any process to bind to a port to which a previous process has bound with INADDR_ANY. This allows a user to bind to the specific address of a server bound to INADDR_ANY on an unprivileged port, and steal its UDP packets/TCP connection.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-675
CWE-666

 

Consequences

Confidentiality, Integrity: Read Application Data

Packets from a variety of network services may be stolen or the services spoofed.

 

Potential Mitigations

Phase: Policy

Description: 

Restrict server socket address to known local addresses.

CVE References

CWE

CWE-603 – Use of Client-Side Authentication

Read Time:42 Second

Description

A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.

Client-side authentication is extremely weak and may be breached easily. Any attacker may read the source code and reverse-engineer the authentication mechanism to access parts of the application which would otherwise be protected.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-602
CWE-287
CWE-300
CWE-656

 

Consequences

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

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Do not rely on client side data. Always perform server side authentication.

CVE References

  • CVE-2006-0230
    • Client-side check for a password allows access to a server using crafted XML requests from a modified client.
CWE

CWE-602 – Client-Side Enforcement of Server-Side Security

Read Time:2 Minute, 9 Second

Description

The software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.

When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-669
CWE-693
CWE-471
CWE-290
CWE-300

 

Consequences

Access Control, Availability: Bypass Protection Mechanism, DoS: Crash, Exit, or Restart

Client-side validation checks can be easily bypassed, allowing malformed or unexpected input to pass into the application, potentially as trusted data. This may lead to unexpected states, behaviors and possibly a resulting crash.

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

Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Description: 

If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.

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-2006-6994
    • ASP program allows upload of .asp files by bypassing client-side checks.
  • CVE-2007-0163
    • steganography products embed password information in the carrier file, which can be extracted from a modified client.
  • CVE-2007-0164
    • steganography products embed password information in the carrier file, which can be extracted from a modified client.
  • CVE-2007-0100
    • client allows server to modify client’s configuration and overwrite arbitrary files.
CWE

CWE-601 – URL Redirection to Untrusted Site (‘Open Redirect’)

Read Time:2 Minute, 59 Second

Description

A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.

An http parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.

Phishing is a general term for deceptive attempts to coerce private information from users that will be used for identity theft.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-610
CWE-610

 

Consequences

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

The user may be redirected to an untrusted page that contains malware which may then compromise the user’s machine. This will expose the user to extensive risk and the user’s interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.

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

The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user’s credentials and then use these credentials to access the legitimate web site.

 

Potential Mitigations

Phase: Implementation

Description: 

Phase: Architecture and Design

Description: 

Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Description: 

Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).

Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design, Implementation

Description: 

Phase: Operation

Effectiveness: Moderate

Description: 

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

CVE References

  • CVE-2005-4206
    • URL parameter loads the URL into a frame and causes it to appear to be part of a valid page.
  • CVE-2008-2951
    • An open redirect vulnerability in the search script in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL as a parameter to the proper function.
  • CVE-2008-2052
    • Open redirect vulnerability in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the proper parameter.
CWE

CWE-600 – Uncaught Exception in Servlet

Read Time:38 Second

Description

The Servlet does not catch all exceptions, which may reveal sensitive debugging information.

When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-248
CWE-209
CWE-390

 

Consequences

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

 

Potential Mitigations

Phase: Implementation

Description: 

Implement Exception blocks to handle all types of Exceptions.

CVE References