i Attacking Web Authentication – All things in moderation

Attacking Web Authentication

Hi guys, to day we will discuss attacking web authentication.
So, what is authentication mechanism?
Authentication is a process in which the credentials provided are compared to those on file in a database of authorized users’ information on a local operating system or within an authentication server. If the credentials match, the process is completed and the user is granted authorization for access.
Authentication plays a critical role in the security of a web application since all subsequent security decisions are typically made based on the identity established by the supplied credentials. This chapter covers threats to common web authentication mechanisms, as well as threats that bypass authentication controls entirely.


We’ve organized our discussion in this section loosely around the most common types of authentication prevalent on the Web at the time of this writing:
* Username/password
* Strong(er) authentication: Including token- and certificated-based authentication.
* Authentication services: Many web sites outsource their authentication to Internet services such as Windows Live ID (formerly known as Microsoft Passport), which implements a proprietary identity management and authentication protocol, and OpenID, which is an open standard for decentralized authentication service providers. Both services will be briefly covered at a high level in this chapter.

Username/Password Threats
Although there are numerous ways to implement basic username/password authentication, web implementations generally fall prey to the same types of attacks:
* Username enumeration
* Password guessing
* Eavesdropping

Username Enumeration
Username enumeration is primarily used to provide greater efficiency to a passwordguessing attack. This approach avoids wasting time on failed attempts using passwords for a user who doesn’t exist.
The following are some examples of functionality often used in web applications that may allow you to determine the username.
Profiling Results
We can review their profiling data because it’s often a rich source of such information (textual searches across the profiled information for strings like userid, username, user, usr, name, id, and uid often turn it up).
Error Messages in Login
A simple technique to determine if a username exists is to try to authenticate to a web application using invalid credentials and then examine the resulting error message.
You try authentication with username Bob and password 123456. You can likely to encounter one of three error messages similar to the ones listed here, unless you actually successfully guessed the password:
* You have entered a bad username.
* You have entered a bad password.
* You have entered a bad username/password combination.
If you receive the first error message, the user does not exist on the application.
If you received the second error message, you have identified a valid user on the system, and you can proceed to try to guess the password.
If you received the third message, it will be difficult to determine if Bob is actually a valid username.
Error Messages in Self-Service Password Reset Features Similar to the user enumeration vulnerabilities just discussed, self-service password reset (SSPR) functionality is also a common source of user enumeration disclosure vulnerabilities.
The e-mail address “authenticates” the user via an alternate mechanism, assuming only the user in question can access that e-mail account and retrieve the new password.
Registration Many web applications allow users to select their own usernames in the registration process. This presents another vector for determining the username. During the registration process, if you select a username of another user who already exists, you are likely to be presented with an error such as “Please choose another username.” As long as the username you have chosen follows the application guidelines and does not contain any invalid characters, this error message is likely an indication that the chosen username is already registered.
Account Lockout To mitigate the risk of a password-guessing attack, many applications lock out accounts after a certain number of failed login attempts. Depending on the risks inherent to the application, account lockout thresholds may be set to 3, 5, or more than 10 failed authentications.
Timing Attacks If all else fails, a timing attack may be the last resort of a frustrated attacker.
Keep in mind that this technique is prone to producing a large number of false positives.

Password Guessing
Not surprisingly, password guessing is the bane of username/password authentication schemes. Unfortunately, such schemes are common on the Web today and thus fall prey to this most basic attack techniques.
Manual Password Guessing Password-guessing attacks can be carried out via both manual and automated means. Manual password guessing is tedious, but we find human intuition frequently bests automated tools, especially when customized error pages are used in response to failed forms-based login attempts. When performing password guessing.
Common Usernames and Passwords Used in Guessing Attacks

Username Guesses

Password Guesses

root, administrator, admin [NULL], root, administrator, admin, password,[company_name]
operator, webmaster, backup [NULL], operator, webmaster, backup
guest, demo, test, trial [NULL], guest, demo, test, trial
member, private [NULL], member, private
[company_name] [NULL], [company_name], password
[known_username] [NULL], [known_username]

Caution Automatic password guessing can perform a denial-of-service attack against the application. There is always an increased load on the server and the risk of locking accounts. If you are an attacker, this may be intentional. If you are a tester, however, you should determine if there is an account lockout and proceed accordingly.

Tip If a password policy is in place and enforced, you can reduce the set of possible passwords to just those permitted by the password policy.

One of the most common authentication protocols used on the Internet today is HTTP Basic.
When we encounter a page protected by Basic authentication in our consulting work, we generally turn to Hydra to test account-credential strength. Hydra is a simple tool that takes text lists of usernames and passwords (or combinations of both) and uses them
as dictionaries to implement Basic authentication password guessing. It keys on “HTTP 302 Object Moved” responses to indicate a successful guess, and it will find all successful guesses in a given username/password file (that is, it won’t stop guessing once it finds
the first valid account).
Hydra supports http-head, http-get, https-head, https-get, and http-proxy for attacking web applications.

WebCracker is an older, Windows-based GUI application that is similar to Hydra but is not as customizable in our experience. It is an excellent tool for a novice, or for performing a quick assessment of account password strength.


Brutus is a generic password-guessing tool that comes with built-in routines for attacking HTTP Basic and Forms-based authentication, among other protocols like SMTP and POP3.


Forms-based Authentication Attacks
Bypassing SQL-backed Login Forms On web sites that perform Forms-based authentication with a SQL backend, SQL injection can be used to bypass authentication. Many web sites use databases to store passwords and use SQL to query the database to validate authentication credentials.
Bypassing LDAP-backed Login Forms Not all applications integrate the authentication component with a backend SQL database server. Many web applications, especially on corporate intranets, use servers based on the Lightweight Directory Access Protocol (LDAP) to provide similar authentication capabilities. If insecurely coded, these applications may expose LDAP injection vulnerabilities that could be exploited to bypass authentication controls. While the exact syntax used to exploit these vulnerabilities is different from that of SQL injection, the underlying concept is identical.
Bypassing XML-backed Login Forms Just as in the SQL and LDAP case, applications that fail to properly validate user-supplied credentials may expose a vulnerability that allows attackers to bypass normal authentication controls. The classic case of this is an application that uses the username supplied during authentication to construct an XPath query to query the appropriate record from the backend XML document. If the username is not properly validated for characters that have special meaning in XPath queries, then an attacker may be able to modify the query to return arbitrary records, regardless of whether a correct password is supplied.


Token replay

Security tokens are usually granted when a user logs in successfully helping them not to log in again when moving through the phases of application. Authentication can be bypassed by simply replaying maliciously captured tokens, a phenomenon sometimes called session hijacking.
Session ID Attacks
We have two techniques to obtain session ID are: Prediction and Frute-forcing.
Some web application often used easily pridictable, sometimes even sequential, session identifiers. Session IDs generated using insecure algorithms or pseudorandom number generators with insufficient entropy may be predictable using mathematical techniques such as statistical forecasting.
Brute-forcing the session IDs attacker will try to send multiple requests as possible in order to figure out the correct session ID. Likelihood of success will be based on the length of the session ID.
That attack is known as session fixation. Session fixation is a type of attack where an attacker is able to set, in advance, the session ID that an application server will use in a subsequent user authentication.
Hacking Cookies
Cookies often contain data associated with authentication. If the cookie contains passwords or session identifiers, stealing the cookie can be a very successful attack against a web site.
We have two techniques to obtain cookie are: Script injection and eavesdropping.
Reverse engineering the cookie offline can also prove to be a very lucrative attack. The best approach is to gather a sample of cookies using different input to see how the cookie changes. You can do this by using different accounts to authenticate at different times.
Developers typically use a number of encoding formats easily decompile sush as BASE64. An attacker can decode, modify, and re-encode the cookie value to potentially change his or her assigned role and gain unauthorized access to the application. Tools such as the Burp web proxy have great support for manipulating cookies and encoding, decoding, and hashing values using common algorithms.

Leave a Reply