|
|
|
|
Individual CAPEC Dictionary Definition (Release 1.1)
Individual CAPEC Dictionary Definition (Release 1.1)
| Attack Pattern ID | Pattern Abstraction: Standard 2 | | Typical Severity | Medium | | Description | Summary
An attacker leverages the security functionality of the system aimed at thwarting potential attacks to launch a denial of service attack against a legitimate system user. Many systems, for instance, implement a password throttling mechanism that locks an account after a certain number of incorrect log in attempts. An attacker can leverage this throttling mechanism to lock a legitimate user out of their own account. The weakness that is being leveraged by an attacker is the very security feature that has been put in place to counteract attacks.
Attack Execution Flow Experiment Investigate account lockout behavior of system:
Investigate the security features present in the system that may trigger an account lockout
|
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| Analyze system documentation to find list of events that could potentially cause account lockout | env-Web env-ClientServer env-Local env-Embedded | |
Obtain user account in system and attempt to lock it out by sending malformed or incorrect data repeatedly
| env-Web env-ClientServer env-Local env-Embedded | |
Determine another user's login ID, and attempt to brute force the password (or other credentials) for it a predetermined number of times, or until the system provides an indication that the account is locked out.
| env-Web env-ClientServer env-Local env-Embedded |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c2s1i1 | Positive |
System provides error message stating that account being attacked is locked out.
| env-Web env-ClientServer env-Local env-Embedded | | c2s1i2 | Positive |
After a certain number of login attempts with a given user ID, the amount of time it takes for system to respond to further login attempts changes noticably.
| env-Web env-ClientServer env-Local env-Embedded | | c2s1i3 | Negative |
System has no automatic signup mechanism, and system provides no indication as to whether the attacker is entering incorrect credentials or the account is locked out during the login process.
| env-Web env-ClientServer env-Local env-Embedded |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c2s1o1 | Success | Attacker determines at least one way to lock out accounts. | | c2s1o2 | Failure | System provides no indication that account lockouts are possible |
|
Security Controls |
|---|
| ID | Type | Description |
|---|
| c2s1sc1 | Detective | Repeated failed login attempts in application/system logs. | | c2s1sc2 | Preventative | Do not provide any indication to users that their accounts are locked out. Provide a simple error message such as: "Login failed. Try again or contact your administrator" regardless of why a login attempt fails. |
Obtain list of user accounts to lock out:
Generate a list of valid user accounts to lock out
|
Attack Step Techniques |
|---|
| Description | Environments |
|---|
|
Obtain list of authorized users using another attack pattern, such as SQL Injection.
| env-Web env-ClientServer env-Local env-Embedded | |
Attempt to create accounts if possible; system should indicate if a user ID is already taken.
| env-Web env-ClientServer env-Local env-Embedded | |
Attempt to brute force user IDs if system reveals whether a given user ID is valid or not upon failed login attempts.
| env-Web env-ClientServer env-Local env-Embedded |
|
Indicator of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c2s2i1 | Positive | System indicates which user IDs are valid and which are not to unauthenticated users. | env-Web env-ClientServer env-Local env-Embedded |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c2s2o1 | Success | Attacker gathers list of user IDs | | c2s2o2 | Inconclusive | Attacker is unable to gather list of valid user IDs; attacker may still be able to lock out accounts by blindly guessing user IDs and performing a lockout procedure with each one. |
|
Security Control |
|---|
| ID | Type | Description |
|---|
| c2s2sc1 | Preventative | Avoid providing any indication regarding the validity of user IDs upon failed login attempts. Provide a simple error message such as: "Login failed. Try again or contact your administrator" regardless of why a login attempt fails. |
Exploit Lock Out Accounts:
Perform lockout procedure for all accounts that the attacker wants to lock out.
|
Attack Step Technique |
|---|
| Description | Environments |
|---|
|
For each user ID to be locked out, perform the lockout procedure discovered in the first step.
| env-Web env-ClientServer env-Local env-Embedded |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c2s3i1 | Positive | Success outcome in first step | env-Web env-ClientServer env-Local env-Embedded | | c2s3i2 | Negative | Failure outcome in first step | env-Web env-ClientServer env-Local env-Embedded |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c2s3o1 | Success | Amount of work required by an attacker to lock out a large number of accounts is at least an order of magnitude smaller than the amount of work required to unlock the accounts thereafter. | | c2s3o2 | Failure | The large amount of work required by an attacker to lock out a large number of accounts makes this an unattractive attack. |
| | Attack Prerequisites |
The system has a lockout mechanism.
An attacker must be able to reproduce behavior that would result in an account being locked.
| | Typical Likelihood of Exploit |
High
| | Methods of Attack | - API Abuse
- Flooding
- Brute Force
| | Examples-Instances | Description
A famous example of this type an attack is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction.
Related Vulnerability | | Attacker Skill or Knowledge Required |
Low
| | Resources Required | Computer with access to the login portion of the target system | | Solutions and Mitigations |
Implement intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name.
When implementing security features, consider how they can be misused and made to turn on themselves.
| | Attack Motivation-Consequences | | | Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 400 | Resource Exhaustion | Secondary |
| | Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| Eugene Lebanidze | Cigital, Inc | 2007-02-26 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Sean Barnum | Cigital, Inc | 2007-03-01 | Review and revision of content | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name, Description and Solutions | | Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback | | Amit Sethi | Cigital, Inc. | 2007-10-29 | Added extended Attack Execution Flow |
|
|
