Authentication Testing - Testing for Vulnerable Remember Password & Password Reset

Most modern web application has a way for users to reset their password through "security questions". Apps also tends to have a "remember password" feature.  In this test, we check to see if these two features are properly implemented.

The main problem with using security questions for password resets is that often times, the security questions are really not that personal. For example, "your mother's main name" is a very common yet terrible question. A mother's maiden name can easily be retrieved by a hacker. A better question could be "What was your 2nd grade teacher's name".  The problem with saving passwords to the browser is that anyone who has access to that system can use the  account.

So, how does one exploit these features?  Well to exploit the password reset feature, we must first see if the reset process even requires a secret question. Sometimes, the reset password process just sends a new or the old password the e-mail address on file. This means that if the e-mail account is compromised, the password can easily be retrieved. If secure questions are used, we then must asses the strength of the questions. We do this by figuring out how many questions must be answered and also the strength of the question. A lot of times, a user is given the option of choosing 1 or 2 questions from a question "bank". We can take advantage of this by choosing the questions that can easily be answered with a little bit of research.  

Authentication Testing - Testing for Bypassing Authentication Schema

Although for most applications, authentication leads to access -  there are certain cases were an intruder can just bypass the login page and directly access the "private" information.   This can be done through four different ways. Direct Page Request, Parameter Modification, Session ID Prediction, & SQL Injection.  Direct page requests occurs when the code checks for authentication only on the login page. Every other page in the administrator's does not check user credentials and thus can be accessed by just putting in the URL in the browser.  The second way to bypass authentication is through a modification of the URL parameter.  Some times, web apps uses fixed value parameters to signify a successful authentication.  So for example, we can easily change http://domain.com/admin/index.php?authentication=no  to authentication=yes. Then after resubmitting the data to the server, we should be in the admin panel.  The third way of bypassing authentication is through predicting an admin's session ID. Some web apps uses Session ID's as a means to manage authentication. The problem with this is that sometimes these session ID's just increases linearly which means it is easy to predict. We can get the correct session ID by using a bruteforce attack. Lastly, SQL Injection is another way of bypassing authentication. Due to the popularity of the topic, this will be covered in a future post. 

Auth. Testing - Testing for Logout & Browser cache Management

This test ensures that once a user "logs out" - they are actually logged out and it is not possible to reuse the user's session.  Secondly, we check to see if there is a timeout feature where after X amount of idle activity - the user is automatically logged out. The application must work in a way where once logged out, all session tokens (cookies) are either erased or made unusable.  Usually, we just want to make it unusable by rejecting the use of the cookie on a server level.

To properly assess this type of exploit, we must first find out what happens after a user logs out. Are session cookies erased? Are they made unusable? The easiest way to do this is by logging out, and then clicking the browser's back button. Are we still authenticated? In that case the cookies are still being used and can be exploited. If after clicking the back button we can still see visited pages but not access any new pages - it means that the private information was cached. The page allowed the browser to cache the content by "not setting the cache-control header".

It is important to have some type of server side code that prevents the reusing of old cookies.  Since cookies exists client side and can be edited by users, simply changing the values of the cookies to make it unusable is bad practice. We need to completely disallow an inactive cookie from doing any type of authentication.

How to Edit Cookies in Chrome.

Authentication Testing - Testing for Brute Force

The topic of brute forcing has always interested me due to its simplicity.  The whole idea is that you have an enumerated set of "candidates" or options and then through simple trial and error see which of these candidates will solve the situation. So, let's say a hacker is trying to retrieve the username and password for the administrator's panel of a website.  Using bruteforcing tools, he or she can automatically try out all the credential candidates. If the candidate list is somewhat accurate, the hacker can get the correct username and password in a certain period of time.

There are different bruteforcing techniques in existence and a specific technique must be used depending on the "authentication method used by the application" (131).   The two most common authentication methods used by apps are HTTP Authentication and HTML Form-based Authentication.  Within HTTP Authentication, there are two sub methods which are called Basic Access Authentication and Digest Access Authentication.

With the Basic method, the client first sends a request (going to the protected site area via a browser). Then the server sends a response stating that the location is a protected and sends the client a HTTP 401 Authorization. 

The 401 Authorization response has the following header.

HTTP/1.1 401 Authorization Required
Date: Sat, 04 Nov 2006 12:52:40 GMT
WWW-Authenticate: Basic realm="User Realm" Content-Length: 401
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

 The "User Realm" is the protected area and the line also contains the word Basic which tells the potential hacker the type of authentication used.

The 401 Authorization response also opens a username and password window.  The username, colon, and password is base64 encoded and then sent to the server.  If the credentials are right, then the client has access to the web site.   The main problem with this method is that if an attacker gets a hold of that encoded string, he or she can easily decode it to reveal the username and password. This is the primary reason for the existence of the Digest method.  With Digest,  the password is hashed through MD5. The username is sent to the server in plaintext form.   

Although digest is relatively safe, a lot of web apps uses the html form-based authentication method.  Basically, this means the login process is done trough an HTML form.

Now it's time to talk about the different kinds of bruteforcing attacks. The first one is called a dictionary attack.  In this attack, a bruteforcing program uses a file containing possible usernames and passwords to repetivitly attempt to login to the app. The more detailed and concise the dictionary, the faster a sucessful login will take place. In search attacks,  the program attempts all possible combination of a given "character set and givven password range".  Lastly, in a rule-based search attack, the program uses certain rules to generate good login/password "candidates". For example, if we know the password is 5 characters, and the last three characters are "cat", can setup a rule that tries every possible combination of letters and numbers to get the full password.

Some tools used for bruteforcing:  John The Ripper, Brutus, THC Hydra

Authentication Testing - Default or Guessable (dictionary) user account

Nowadays, web applications used are open source and/or extremely popular and relatively well known.  They also require some type of minimal configuration by the user to be properly setup. Unfortunately, plenty of people misconfigure their web apps leading to certain security issues. For example, certain web applications come with a default username and password. Part of the configuration process is to delete this username and password and create another administrator account.  People don't like doing this and thus a lot of web applications exists with default usernames and password ready for some attacker to completely take control of it.

Some common usernames and passwords are listed below:

• Usernames
• Admin, administrator, root, system, guest, operator, super, qa, test, test1, testing.

• Passwords
• <completely blank password>, password, pass123, password123, admin, guest.

Some times, usernames are named after the application it self. So if we are trying to penetrate an application called "SystemKeeper"  - one should try systemkeeper as a username and perhaps also the password.  Another way to do find a password is looking at the source. Poorly programmed applications might have the username  visible in the source.

CIRT, GovermentSecurity.org, and virus.org provides the default usernames and password for various applications and devices.

Authentication Testing - Testing for Enumeration

The whole point of this phase is to see if can retrieve valid usernames. The usernames can help improve the effectiveness of other security attacks (bruteforcing, social engineering, etc…). Web applications tend to reveal existing usernames in different ways. For example, if I try to register and type 'martin' as the username, the application might sent out an error that states that the username already exists. If an attacker does this for a while, he or she can have a long list of valid usernames.  Another way to retrieve usernames is by trying to login to the system. If I try the username "martin", and a random password - the application might print out an error saying "Sorry, you entered the wrong password". This pretty much tells us the username is completely valid. Lastly, some other ways of looking for valid usernames includes :

• Analyzing Page titles - Invalid User and Invalid Authentication could mean two different issues.

• Analyzing Message for credential recovery facilities - basically, using the "forgot password" or "forgot username" parts of a website to figure out which usernames are valid or not.

• Guessing usernames - Sometimes, usernames are in sequential order (ex, LabUser1, LabUser2).

Authentication Testing - Credential Transport for an Encrypted Channel

We're moving from configuration management testing to authentication testing. In this scenario, we are trying to make sure the "right" person is sending/transmitting the "right" data. One way to make sure of the validity of data is sending through a secure channel. A practical example of the importance of data encryption is when we log in to various websites. Even if the website uses a POST method to "hide" the user name and password, the parameter values can still be retrieved through sniffer tools. How do we prevent this from happening? Through the use of the HTTPS protocol. When a site uses HTTPS, the login data is encrypted and assuming the encryption method is strong, this makes sniffing the account details much tougher.

Tools that can aid potential hacker retrieve account details include WireShark and WebScarber.
So to quickly summarize - if there is a login aspect to your site, make sure the POST method is used along with having an HTTPS connection.