Exploitation - Authentication

---

Authentication lies at the heart of an application’s protection against malicious attack. It is the front line of defense against unauthorized access.

Without robust authentication to rely on, none of the other core security mechanisms (such as session management and access control) can be effective.

In the typical case, a user supplies his username and password, and the application must verify that these items are correct. If so, it lets the user in. If not, it does not.

---

List authentication functionalities

Locate all the authentication-related functionalities where credentials are supplied:

• Login

• Account registration

• Login and password recovery

• Password change

• Password confirmation

• Two steps authentication

The BurpSuite engagement tool Search can be used to grep for username and password related string in parameters and HTML source code.

Account registration

If possible register an account on the web application. An account is needed in order to determine precisely if the application implements any brute force protection mechanisms.

Password policy

Upon registration, the password policy enforced by the web application can be reviewed. This review must be extended to the password change functionality if present on the web application.

If available, assess the application description of the minimum quality rules enforced on user passwords and try to establish the rules actually enforced.

Try:

• Short passwords (1 to 7 characters)

• Alphabetic lowercase/Alphabetic uppercase/numeric/symbol characters only

• Current username/web application name

Establish the range of values that a password guessing attack would need to employ to have a good probability of success.

Note: For long term use, the password policy should enforce:

• Length >= 8 characters.

• Use at least three of the four available characters types: lowercase, uppercase, numbers and symbols.

• Must not contains the username or part of the username.

Username enumeration

If self account registration is possible on the web application, username enumeration would de facto be possible and considered a required feature. However, in the absence of such functionality, being able to enumerate the user accounts of the web application can be considered a security threat as it unnecessarily increases brute force attacks chances of success.

For each authentication functions found, submit two requests, containing a valid and an invalid username. Review every detail and observe any differences of the server’s responses to each pair of requests, including:

• HTTP status code

• Information displayed on-screen

• Any redirects

• Any differences hidden in the HTML page source

• Byte response size as given by BurpSuite

If the application respond differently, username enumeration is possible.

Finally, check for any other sources of information leakage within the application that may enable you to compile a list of valid usernames. Examples are actual listings of registered users, direct mention of names or e-mail addresses in source code comments, etc.

Brute force attack

Custom wordlist generation

The Ruby script CeWL spiders a given URL to a specified depth, optionally following external links, and generates a list of words based on the content of the specified URL.

cewl -m 1 -d 10 -w <OUTPUT_FILE> <URL>

GET & POST requests brute force

The patator tool can be used to brute force HTTP GET or POST login form:

# apt-get install python-pycurl curl

# HTTP Basic Auth
patator http_fuzz auth_type=basic url=<URL> user=FILE0 password=FILE1 0=<WORDLIST_USER> 1=<WORDLIST_PASSWORD> -x ignore:code=401

# GET
patator http_fuzz -t 50 url="<URL>?username=FILE0&password=FILE1" method=GET 0=<WORDLIST_USER> 1=<WORDLIST_PASSWORD> accept_cookie=1 -x ignore:fgrep='<ERROR_MESSAGE>'

# POST
patator http_fuzz -t 50 url="<URL>" method=POST body='username=FILE0&password=FILE1' 0=<WORDLIST_USER> 1=<WORDLIST_PASSWORD> accept_cookie=1 -x ignore:fgrep='<ERROR_MESSAGE>'

Brute force protection mechanisms

If a captcha mechanisms is used by the application, check if the captcha validation is required for each login attempt and try to automate its guessing.

The following tools may be used to automate captcha guessing:

cintruder --gui

If the captcha validation can't be automated through OCR technics, the authentication is still not completely secure to brute force attack as more advanced technics are available.

In the absence of a captach mechanisms, if the captcha validation can be automated or on critical web application, an account lock out mechanisms must be implemented.

Fail to login 10 times, using BurpSuite Intruder, and, if possible, a controlled account. If the application returns a message about account lockout, username enumeration is possible on the web application.

Attempt to log in correctly with the tested account.

If this succeeds, there is probably no account lockout policy.

If the account is locked out, repeat the exercise using a different account, and, if the application issues any cookies, using a new cookie for each login attempt.

Auxiliary functionalities specifics

In addition to the points and issues raised above, the specific analysis of the auxiliary functionalities detailed below should be conducted.

Forgotten password

Understand how the forgotten password function works by doing a complete walk-through using an account you control.

Forgotten password functionality may involves presenting the user with a secondary challenge in place of the main login. If the mechanism uses a challenge, determine whether users can set or select their own challenge and response. If so, use a list of previously enumerated, or common usernames, to harvest a list of challenges, and review this for any that appear easily guessable. Note that the challenge may concern information that is publicly known.

The application may allow an attacker to take control of the account on completion of the forgotten password challenge.

Otherwise, if the function involves sending an e-mail to the user to complete the recovery process, look for any weaknesses that may enable you to take control of other users’ accounts.

Determine whether it is possible to control the address to which the e-mail is sent. If the message contains a unique recovery URL, obtain a number of messages using an e-mail address you control, and attempt to identify any patterns that may enable you to predict the URLs issued to other users. If the link issued is predictable or guessable, account theft could be undertaken this way.

Summary:

• The web application should not allow direct account takeover upon completion of a secondary challenge

• A temporary password, respecting the password policy and that must be changed upon login, or an unpredictable and guessable link allowing for password change, should be provided to the user email address associated to the username.

Password change

The password change functionality should be accessible only to authenticated user and should not allow for other accounts password change. The identification of the user should rely on current session elements.

If the password change form is accessible only by authenticated users and does not contain a username field, it may still be possible to supply an arbitrary username. The form may store the username in a hidden field, which can easily be modified. If not, try supplying an additional parameter containing the username, using the same parameter name as is used in the main login form.

Check that whether the “new password” and “confirm new password” fields validation takes place before validating the existing password. If not, an attacker could to succeed in discovering the existing password noninvasively.