User Impersonation Functionality
Some applications implement the facility for a privileged user of the application to impersonate other users, in order to access data and carry out actions within their user context. For example, some banking applications allow helpdesk operators to verbally authenticate a telephone user and then switch their application session into that user’s context in order to assist them.
Various design flaws commonly exist within impersonation functionality:
■ It may be implemented as a “hidden” function, which is not subject to proper access controls. For example, anyone who knows or guesses the URL /admin/ImpersonateUser.jsp may be able to make use of the function and impersonate any other user.
■ The application may trust user-controllable data when determining whether the user is performing impersonation. For example, in addition to a valid session token, a user may also submit a cookie specifying which account their session is currently using. An attacker may be able to modify this value and gain access to other user accounts without authentication, as shown in Figure -1.
Figure -1: A vulnerable user impersonation function
■ If an application allows administrative users to be impersonated, then any weakness in the impersonation logic may result in a vertical privilege escalation vulnerability — rather than simply gaining access to other ordinary users’ data, an attacker may gain full control of the application.
■ Some impersonation functionality is implemented as a simple “back-door” password that can be submitted to the standard login page along with any username in order to authenticate as that user. This design is highly insecure for many reasons, but the biggest opportunity for attackers is that they are likely to discover this password when performing standard attacks such as brute forcing of the login. If the back-door password is matched before the user’s actual password, then the attacker is likely to discover the function of the backdoor password and so gain access to every user’s account. Similarly, a brute-force attack might result in two different “hits,” thereby revealing the backdoor password as shown in Figure -2.
Figure -2: A password-guessing attack with two “hits,” indicating the presence of a backdoor password
Incomplete Validation of Credentials
Well-designed authentication mechanisms enforce various requirements on passwords, such as a minimum length or the presence of both uppercase and lowercase characters. Correspondingly, some poorly designed authentication mechanisms not only do not enforce these good practices but also do not take account of users’ own attempts to comply with them.
For example, some applications truncate passwords and so only validate the first n characters. Some applications perform a case-insensitive check of passwords. Some applications strip out unusual characters (sometimes on the pretext of performing input validation) before checking passwords.
Each of these limitations on password validation reduces by an order of magnitude the number of variations available in the set of possible passwords. Through experimentation, you can determine whether a password is being fully validated, or whether any limitations are in effect. You can then fine-tune your automated attacks against the login to remove unnecessary test cases, thereby massively reducing the number of requests necessary to compromise user accounts.
NEXT is..Non-Unique Usernames..,.,,
