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).

A Complete OWASP Checklist

As I wandered throughout the Internet looking for why NETCAT was not working on my laptop, I ran into a spreadsheet that potentially can help me in the future. This checklist has three worksheets.
The first worksheet serves as checklist of all the tests one must do to make sure a website is secure. The checklist is extremely interactive and can help me keep track of everything. The second worksheet summarizes all the categories of testing, the names of each test per category, a description of each test, and lastly the tools used for testing. Finally, the third worksheet provides a list and description of various testing tools.

The spreadsheet was last updated in October of 2011 and can freely be downloaded from its Google Code Site.

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.

CMT - Testing for HTTP Methods and XST

The HTTP protocol has a bunch of methods used for interacting with the web server. Most people only know of the POST (parameters values are hidden in the HTTP request) and GET (parameter values can be seen in the URL) methods. However, there are  6 more methods in existence.  These include  HEAD, PUT, DELETE, TRACE, OPTIONS,  & CONNECT.

The PUT (allows clients to upload files), DELETE (allows client to delete files) , CONNCT (allows clients to use the web server as a proxy server to connect to other servers)  and TRACE methods should be disabled by all web servers unless it is specially needed.

For a hacker to take advantage of this, he or she must first know which methods the server supports. OWASP Testing guide states that this can be done through a program called NETCAT . Once this program is downloaded and installed, one simply has to run the following command: nc -v www.domain.com 80.  Unfourenelty, this method did not work for me and I kept running into the following error.

DNS fwd/rev mismatch: www.domain.com  hostname.domain.com
www.domain.com [xxx.xxx.xxx.xx] xx (http) open.

The next couple of days, one of my goals will be to try to get this this working since it seems like a valuable tool.  Lastly, the guide provides more information on cross site scripting using the TRACE method, but due to the NETCAT not cooperating with my computer,  trying this out will have to wait a few days.

CMT - Infrastructure and Application Admin Infrastructure

A lot of web applications have an administrators area/panel for easier managing and control of the application.  Ideally,  this area should only be accessed by people with the right privileges, however, there are situations where unauthorized or standard users are able to access the area and perform undesired actions.

Some times, when accessing the admin area, no authentication takes place. In other words,  access is given to anyone who access the supposed "private" URL.  Hackers can guess the location of this area through various methods. These includes trying common directories such as /admin and /administrator or  viewing the comments and html code of a public page for administrator specific code.

The best way to prevent unauthorized access is to both force authorization/authentication upon logging in and also limited the area to specific users/IP address/network range.