CWE-654 Detail

CWE-654

Reliance on a Single Factor in a Security Decision
Draft
2008-01-30
00h00 +00:00
2023-10-26
00h00 +00:00
CWE Mitre.org
Notifications for a CWE
Stay informed of any changes for a specific CWE.
Notifications manage

Name: Reliance on a Single Factor in a Security Decision

A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality.

General Informations

Modes Of Introduction

Architecture and Design
Implementation
Operation

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Common Consequences

Scope Impact Likelihood
Access ControlGain Privileges or Assume Identity

Note: If the single factor is compromised (e.g. by theft or spoofing), then the integrity of the entire security mechanism can be violated with respect to the user that is identified by that factor.
Non-RepudiationHide Activities

Note: It can become difficult or impossible for the product to be able to distinguish between legitimate activities by the entity who provided the factor, versus illegitimate activities by an attacker.

Observed Examples

References Description

CVE-2022-35248

Chat application skips validation when Central Authentication Service (CAS) is enabled, effectively removing the second factor from two-factor authentication

Potential Mitigations

Phases : Architecture and Design
Use multiple simultaneous checks before granting access to critical operations or granting critical privileges. A weaker but helpful mitigation is to use several successive checks (multiple layers of security).
Phases : Architecture and Design
Use redundant access rules on different choke points (e.g., firewalls).

Vulnerability Mapping Notes

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Related Attack Patterns

CAPEC-ID Attack Pattern Name
CAPEC-16 Dictionary-based Password Attack

An attacker tries each of the words in a dictionary as passwords to gain access to the system via some user's account. If the password chosen by the user was a word within the dictionary, this attack will be successful (in the absence of other mitigations). This is a specific instance of the password brute forcing attack pattern.

Dictionary Attacks differ from similar attacks such as Password Spraying (CAPEC-565) and Credential Stuffing (CAPEC-600), since they leverage unknown username/password combinations and don't care about inducing account lockouts.
CAPEC-274 HTTP Verb Tampering
An attacker modifies the HTTP Verb (e.g. GET, PUT, TRACE, etc.) in order to bypass access restrictions. Some web environments allow administrators to restrict access based on the HTTP Verb used with requests. However, attackers can often provide a different HTTP Verb, or even provide a random string as a verb in order to bypass these protections. This allows the attacker to access data that should otherwise be protected.
CAPEC-49 Password Brute Forcing
An adversary tries every possible value for a password until they succeed. A brute force attack, if feasible computationally, will always be successful because it will essentially go through all possible passwords given the alphabet used (lower case letters, upper case letters, numbers, symbols, etc.) and the maximum length of the password.
CAPEC-55 Rainbow Table Password Cracking
An attacker gets access to the database table where hashes of passwords are stored. They then use a rainbow table of pre-computed hash chains to attempt to look up the original password. Once the original password corresponding to the hash is obtained, the attacker uses the original password to gain access to the system.
CAPEC-560 Use of Known Domain Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.
CAPEC-565 Password Spraying

In a Password Spraying attack, an adversary tries a small list (e.g. 3-5) of common or expected passwords, often matching the target's complexity policy, against a known list of user accounts to gain valid credentials. The adversary tries a particular password for each user account, before moving onto the next password in the list. This approach assists the adversary in remaining undetected by avoiding rapid or frequent account lockouts. The adversary may then reattempt the process with additional passwords, once enough time has passed to prevent inducing a lockout.
CAPEC-600 Credential Stuffing

An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.
CAPEC-652 Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
CAPEC-653 Use of Known Operating System Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.
CAPEC-70 Try Common or Default Usernames and Passwords
An adversary may try certain common or default usernames and passwords to gain access into the system and perform unauthorized actions. An adversary may try an intelligent brute force using empty passwords, known vendor default credentials, as well as a dictionary of common usernames and passwords. Many vendor products come preconfigured with default (and thus well-known) usernames and passwords that should be deleted prior to usage in a production environment. It is a common mistake to forget to remove these default login credentials. Another problem is that users would pick very simple (common) passwords (e.g. "secret" or "password") that make it easier for the attacker to gain access to the system compared to using a brute force attack or even a dictionary attack using a full dictionary.

NotesNotes

This entry is closely associated with the term "Separation of Privilege." This term is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (CWE-653) and using only one factor in a security decision (this entry). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion.

References

REF-196

The Protection of Information in Computer Systems
Jerome H. Saltzer, Michael D. Schroeder.
http://web.mit.edu/Saltzer/www/publications/protection/

REF-535

Separation of Privilege
Sean Barnum, Michael Gegick.
https://web.archive.org/web/20220126060047/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/separation-of-privilege

Submission

Name Organization Date Date release Version
Pascal Meunier Purdue University 2008-01-18 +00:00 2008-01-30 +00:00 Draft 8

Modifications

Name Organization Date Comment
Eric Dalci Cigital 2008-07-01 +00:00 updated Time_of_Introduction
CWE Content Team MITRE 2008-09-08 +00:00 updated Alternate_Terms, Common_Consequences, Relationships, Other_Notes, Weakness_Ordinalities
CWE Content Team MITRE 2009-01-12 +00:00 updated Description, Name
CWE Content Team MITRE 2009-05-27 +00:00 updated Relationships
CWE Content Team MITRE 2010-04-05 +00:00 updated Related_Attack_Patterns
CWE Content Team MITRE 2011-06-01 +00:00 updated Common_Consequences, Maintenance_Notes, Other_Notes
CWE Content Team MITRE 2012-05-11 +00:00 updated Relationships
CWE Content Team MITRE 2012-10-30 +00:00 updated Potential_Mitigations
CWE Content Team MITRE 2013-02-21 +00:00 updated Potential_Mitigations
CWE Content Team MITRE 2014-07-30 +00:00 updated Relationships
CWE Content Team MITRE 2017-11-08 +00:00 updated Applicable_Platforms, Causal_Nature
CWE Content Team MITRE 2020-02-24 +00:00 updated Relationships
CWE Content Team MITRE 2020-08-20 +00:00 updated Related_Attack_Patterns
CWE Content Team MITRE 2020-12-10 +00:00 updated Relationships
CWE Content Team MITRE 2021-03-15 +00:00 updated Alternate_Terms, Maintenance_Notes
CWE Content Team MITRE 2022-10-13 +00:00 updated References
CWE Content Team MITRE 2023-04-27 +00:00 updated References, Relationships, Taxonomy_Mappings
CWE Content Team MITRE 2023-06-29 +00:00 updated Mapping_Notes
CWE Content Team MITRE 2023-10-26 +00:00 updated Observed_Examples