Monthly Archives: May 2022

CWE

CWE-50 – Path Equivalence: ‘//multiple/leading/slash’

Read Time:1 Minute, 31 Second

Description

A software system that accepts path input in the form of multiple leading slash (‘//multiple/leading/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-161

 

Consequences

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

 

Potential Mitigations

CVE References

  • CVE-2002-1483
    • Read files with full pathname using multiple internal slash.
  • CVE-1999-1456
    • Server allows remote attackers to read arbitrary files via a GET request with more than one leading / (slash) character in the filename.
  • CVE-2004-0578
    • Server allows remote attackers to read arbitrary files via leading slash (//) characters in a URL request.
  • CVE-2002-0275
    • Server allows remote attackers to bypass authentication and read restricted files via an extra / (slash) in the requested URL.
  • CVE-2004-1032
    • Product allows local users to delete arbitrary files or create arbitrary empty files via a target filename with a large number of leading slash (/) characters.
  • CVE-2002-1238
    • Server allows remote attackers to bypass access restrictions for files via an HTTP request with a sequence of multiple / (slash) characters such as http://www.example.com///file/.
  • CVE-2004-1878
    • Product allows remote attackers to bypass authentication, obtain sensitive information, or gain access via a direct request to admin/user.pl preceded by // (double leading slash).
  • CVE-2005-1365
    • Server allows remote attackers to execute arbitrary commands via a URL with multiple leading “/” (slash) characters and “..” sequences.
  • CVE-2001-1072
    • Bypass access restrictions via multiple leading slash, which causes a regular expression to fail.
  • CVE-2004-0235
    • Archive extracts to arbitrary files using multiple leading slash in filenames in the archive.
CWE

CWE-5 – J2EE Misconfiguration: Data Transmission Without Encryption

Read Time:26 Second

Description

Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-319

 

Consequences

Confidentiality: Read Application Data

Integrity: Modify Application Data

 

Potential Mitigations

Phase: System Configuration

Description: 

The application configuration should ensure that SSL or an encryption mechanism of equivalent strength and vetted reputation is used for all access-controlled pages.

CVE References

CWE

CWE-499 – Serializable Class Containing Sensitive Data

Read Time:45 Second

Description

The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.

Serializable classes are effectively open classes since data cannot be hidden in them. Classes that do not explicitly deny serialization can be serialized by any other class, which can then in turn use the data stored inside it.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-668
CWE-200

 

Consequences

Confidentiality: Read Application Data

an attacker can write out the class to a byte stream, then extract the important data from it.

 

Potential Mitigations

Phase: Implementation

Description: 

In Java, explicitly define final writeObject() to prevent serialization. This is the recommended solution. Define the writeObject() function to throw an exception explicitly denying serialization.

Phase: Implementation

Description: 

Make sure to prevent serialization of your objects.

CVE References

CWE

CWE-498 – Cloneable Class Containing Sensitive Information

Read Time:42 Second

Description

The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.

Cloneable classes are effectively open classes, since data cannot be hidden in them. Classes that do not explicitly deny cloning can be cloned by any other class without running the constructor.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-668
CWE-200

 

Consequences

Access Control: Bypass Protection Mechanism

A class that can be cloned can be produced without executing the constructor. This is dangerous since the constructor may perform security-related checks. By allowing the object to be cloned, those checks may be bypassed.

 

Potential Mitigations

Phase: Implementation

Description: 

If you do make your classes clonable, ensure that your clone method is final and throw super.clone().

CVE References

CWE

CWE-497 – Exposure of Sensitive System Information to an Unauthorized Control Sphere

Read Time:37 Second

Description

The application does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the application does.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-200

 

Consequences

Confidentiality: Read Application Data

 

Potential Mitigations

Phase: Architecture and Design, Implementation

Description: 

Production applications should never use methods that generate internal details such as stack traces and error messages unless that information is directly committed to a log that is not viewable by the end user. All error message text should be HTML entity encoded before being written to the log file to protect against potential cross-site scripting attacks against the viewer of the logs

CVE References

CWE

CWE-496 – Public Data Assigned to Private Array-Typed Field

Read Time:19 Second

Description

Assigning public data to a private array is equivalent to giving public access to the array.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-664

 

Consequences

Integrity: Modify Application Data

The contents of the array can be modified from outside the intended scope.

 

Potential Mitigations

Phase: Implementation

Description: 

Do not allow objects to modify private members of a class.

CVE References

CWE

CWE-495 – Private Data Structure Returned From A Public Method

Read Time:31 Second

Description

The product has a method that is declared public, but returns a reference to a private data structure, which could then be modified in unexpected ways.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-664

 

Consequences

Integrity: Modify Application Data

The contents of the data structure can be modified from outside the intended scope.

 

Potential Mitigations

Phase: Implementation

Description: 

Declare the method private.

Phase: Implementation

Description: 

Clone the member data and keep an unmodified version of the data private to the object.

Phase: Implementation

Description: 

Use public setter methods that govern how a private member can be modified.

CVE References

CWE

CWE-494 – Download of Code Without Integrity Check

Read Time:2 Minute, 1 Second

Description

The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

An attacker can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-345
CWE-669
CWE-669
CWE-79

 

Consequences

Integrity, Availability, Confidentiality, Other: Execute Unauthorized Code or Commands, Alter Execution Logic, Other

Executing untrusted code could compromise the control flow of the program. The untrusted code could execute attacker-controlled commands, read or modify sensitive resources, or prevent the software from functioning correctly for legitimate users.

 

Potential Mitigations

Phase: Implementation

Description: 

Perform proper forward and reverse DNS lookups to detect DNS spoofing.

This is only a partial solution since it will not prevent your code from being modified on the hosting site or in transit.

Phase: Architecture and Design, Operation

Description: 

Phase: Architecture and Design

Description: 

Phase: Architecture and Design, Operation

Description: 

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Architecture and Design, Operation

Effectiveness: Limited

Description: 

The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

CVE References

  • CVE-2019-9534
    • Satellite phone does not validate its firmware image.
  • CVE-2021-22909
    • Chain: router’s firmware update procedure uses curl with “-k” (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (CWE-494).
  • CVE-2008-3438
    • OS does not verify authenticity of its own updates.
  • CVE-2008-3324
    • online poker client does not verify authenticity of its own updates.
  • CVE-2001-1125
    • anti-virus product does not verify automatic updates for itself.
  • CVE-2002-0671
    • VOIP phone downloads applications from web sites without verifying integrity.
CWE

CWE-493 – Critical Public Variable Without Final Modifier

Read Time:1 Minute, 34 Second

Description

The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.

If a field is non-final and public, it can be changed once the value is set by any function that has access to the class which contains the field. This could lead to a vulnerability if other parts of the program make assumptions about the contents of that field.

Mobile code, such as a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects’ state and behavior by adversaries who have access to the same virtual machine where your program is running.
Final provides security by only allowing non-mutable objects to be changed after being set. However, only objects which are not extended can be made final.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-668

 

Consequences

Integrity: Modify Application Data

The object could potentially be tampered with.

Confidentiality: Read Application Data

The object could potentially allow the object to be read.

 

Potential Mitigations

Phase: Implementation

Description: 

Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code.

CVE References

CWE

CWE-492 – Use of Inner Class Containing Sensitive Data

Read Time:1 Minute, 9 Second

Description

Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.

Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in its enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields.

Modes of Introduction:

– Implementation

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-668

 

Consequences

Confidentiality: Read Application Data

“Inner Classes” data confidentiality aspects can often be overcome.

 

Potential Mitigations

Phase: Implementation

Description: 

Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways.

Phase: Implementation

Description: 

Inner Classes do not provide security. Warning: Never reduce the security of the object from an outer class, going to an inner class. If an outer class is final or private, ensure that its inner class is private as well.

CVE References