Web Form Brute Force Methods

Abstract

This is web application penetration testing challenges hosted over pentesteracademylab.appspot.com, it reflects several challenges for web application security researchers to break in a safe environment. This is for Lab practice only and no part of this document were provided by the original authors. Having to pull out my old research on application security, I thought to give back to the community but not all releases are meant to be pushed here. This research is part of my private application security research and proudly serves as an opening opportunities for others to dwell and work further on the same as provided and as long as the original authors are credited.

Note: echo with ‘-e’ switch is used to ‘escape’ the ‘\n’ which is required for a line feed. Also, a [space] isn’t appended because of the same reason that it’d create a new line and start writing from the very first instance without any spaces involved.

Generating custom password list with 5 minimum and the 5 maximum size with xyz as the character set.

Crunch: We’d use crunch to generated our own custom password list, passwords could be fetched in case there were no hints provided, we could also later use Hydra to generate a username/password list prior to brute force attacks but here to keep things at ease, we’ve used crunch. Note that for web application which do not hint you anything, and you’d not expect any minimum or maximum length for characters, or either the ‘characters’ which are being used for the ‘password’ at the first place, use fuzzdb. This includes usernames and password files which were pre-generated by the community for the community of hackers. Use fuzzdb, for other injections as well, use if for dictionary attacks, if you wouldn’t want a hybrid based brute force for long years using a low-end spec system at your disposal.

To generate passwords using crunch, which has minimum 5 characters and maximum 5 characters as depicted by at the hint for this particular challenge, with the characters themselves restricted to ‘x’, ‘y’ and ‘z’, use the following command at the Linux command line, or do bash operations. Anything helps!

#crunch 5 5 xyz > passwords.txt

What we have is a list of users and the list of password set. Look at the URL and see if the parameters are being passed at the URL, if it is, it’s a GET based request. By default if the page source doesn’t describe any method, it’s taken as a GET method. To demonstrate this, input any dummy characters in the input fields:

The parameters as well as their values are reflected on the URL which conforms it’s a GET request which is sent by the client to access the resource:

Now, if this is verified from the source, after we try to login, we will see there is no method described at the source page, which means again that the default (if not specified by the source), the method would be GET request:

The username hints and the domain given were jack and admin as users and domain as pentesteracademy.com so possible username sets would be:

Now, that we have the valid usernames (before we used nick and admin to generate the username files as an example which were invalid), we need to go and brute force the login with these set of characters of usernames and the generated list for password taking ‘x’, ‘y’ and ‘z’ with minimum 5 characters and maximum 5 characters as our password list. For this, there are four methods we can accomplish the brute force on web applications:

1.) Use Hydra for Brute Forcing2.) Use Burp Suite as a web-client proxy for Brute Forcing with Intruder3.) Using python scripts and designing a python script which goes ahead and brute forces the login4.) Using WebSlayer with Hydra generated password lists5.) Using power of Nmap Scripting Engine to facilitate web form bruteforces.

Method 1: Using Hydra to Brute Force Web Logins:

About Hydra:

For web-based forms, you have to know much more information about the form you are attacking before you start the attack. Every web-based form is slightly different, different URLs and parameters, and different responses for success or failure.
You need to know:

The hostname/IP and URL

Whether it is a HTTPS or HTTP service

Whether the form supports GET or POST (or both)

The parameters of the request

The difference in response between success and failure

Whether any session cookies are required to be set or maintained

What lockout features and thresholds are enabled (if any)

Now for an example consider the form fields, described below in the image:

Here consider the following:

1.) Hostname: the hostname would be your target hostname, or an IP. Just that.

2.) URI: The Uniform Resource Locator would be the resource where the form could be located.

3.) Method: The method shown in the image is POST, but in pentesteracademylab.appspot.com/lab/webapp/1, the one we’re into, it’s GET, so we’d use GET rather than POST there.

4.) Also, the URI or the URL rather is cut out from the rest of the host information and kept subjective in enclosed double quotes.

5.) Hydra basically iterates through all the username/password combinations, until it gets a response that does not contain the text blacklisted text or it does contain a whitelist string if whitelist string is provided.

6.) The blacklist string would be the string that comes up if the user is not authenticated and throws out a ‘string’ which hydra can pick up and log, this would be the string which if Hydra does not find, will assume that it’s logged in and log the username and the password entry which were successful in bruiting the web-login

7.) The whitelist is a different scenario and if Hydra has to detect web-login authentication success proving the string by which hydra determines that it was a valid string, hydra will go ahead and if any such whitelist is found, hydra would log the credentials for that very request sent i.e.: username and the password for that request (POST or GET).

Not knowing or understanding the above information can be a big cause of failure.

The host is penesteracademylab.appspot.com

It’s a GET method, so pick up the http-form-get because it’s web form as well.

The URL or more specifically the form fields situated in “/lab/webap/1” in this case.

·With the form fields been set, append the email (users for authentication) and the passwords with the appropriate user and password lists and note that this would be done in continuation of the form fields in order to complete the form itself. The form fields declaration in hydra would be enclosed in double quotes: “/lab/webapp/1:email=^USER^&password=^PASS^
We use ‘email’ and ‘password’ as our parameters here because the source code has the email and the password as its entry, if it were a different application, this might change!

Anything in-between ^_____^ specifies that hydra needs a feed into these places which turns out to be username files and the password files respectively. Notice that there are more parameters which hydra needs to brute force web login ‘forms’ which is the reason, the doubles quotes are not closed yet.

The parameters are separated by colons (:) and the next step is to let hydra know when the login goes success, for an instance while login, if a user fails to get authenticated, Hydra takes a blacklist string like “Failed” or “Authentication Failure” as the string and detects if these blacklist words do not appear, then it’s a successful login, so we’d have to append that as well along with the “/lab/webapp/1:email=^USER^&password=^PASS^; which could be done be appending yet another colon, for an example /lab/webapp/1:email=^USER^&password=^PASS^:’blacklist string’

·Notice that the query ends now with the doubles quotes in place, we also mentioned the black list string to be ‘Failed’ because in this web login, any failed login attempts generates the string ‘Failed! Please Try Again!’ which could be see below:

Alternatively we could also provide ‘whitelist’ strings in case we know the successful attempts would look like, and the application never throws any strings on unsuccessful logins on web forms. Now, if we are running Hydra from the directory where our users and password files which were generated are stored, we could provide the users and the passwords list as it or show the directory path for login users using the –L switch and password list using the –P switch, which is: -L users.txt –P passwords.txt

·Next, we would also add threading because hydra supports parallel brute force power and 20 is the maximum allowed integer for this with the –t switch

At last, we include –o switch to save the results in a text file called “results.txt”

This will fetch the valid logins and the passwords, if found using a blacklist string and store the results to a text file called “results.txt”.

#cat results.txt

And you’ll probably find the usernames and passwords. Try them all in-case hydra goes wrong. For me, the results looks like the following after Hydra went ahead and brute forced the web-login and hence one of the username and corresponding password worked in the scenario:

That was for Hydra, but as we look here that Hydra is efficient and could get number of results and could go wrong several times without any hints, there are some other ways we could accomplish this same task, we’ll use method 2 which includes using a client side proxy with Intruder attacks using these same files generated with Crunch at our disposal. Before we begin with Burp, we’ll go through some of the basics for Burp which an attacker might need to now beforehand. If you are looking for a detailed discussion on Burp Suite, refer to my other papers which goes deep into using Burp Suite as a Web Application Swiss Knife, or use the compiled book delivered by me which has a section on Burp Suite and using the tool to make most of the benefits.

Method 2: Using Burp Suite Intruder to Brute Force Web Logins:

About Burp Suite:

Burp Suite was designed by Portswigger to formulate a client side based web-proxy which assists interception of HTTP requests and responses along with support for intercepting web-services based traffic such as WSDL. Burp Suite has been written in Java Platform and provides extensions for various other script with the help of Jython based platform which includes using Python scripting written for Java. Most interestingly Burp Suite provides a framework for web security penetration testers to intercept HTTP traffic, debug application, as well as black-box test web applications with included tool-set like ‘Repeater’, ‘Intruder’, ‘Comparer’, ‘Decoder’, and much more. The scope of this section covers the Intruder, if you are interested in learning Burp Suite in details, there is a separate book written by me on it and you could use them to expand your knowledge on this framework which would be extremely helpful.

To use Burp Suite to the full extent, provided you have good VRAM storage, the following configuration via command line on Linux would help start Burp Suite, which is included in Kali Linux already. This version is the free edition of Portswigger Burp Suite. For Professional version, which penetration testers use, you’d require to buy a license. Go through the Portswigger FAQ to know more.

Launching Burp Suite from the Linux Terminal with known good configuration:

Locating Burp Suite on Linux if installed:

Launching Burp Suite JAR file with good known configuration allotting 2 GB of VRAM on Java Memory Settings on Linux:

Accepting the Burp Agreement and proceeding further:

The Intruder Tab is located after the ‘Scanner’ Tab, which we’d use for brute forcing the web-form, this will make use of the generated previous usernames and the password list via crunch. But before anything else, we’d require to setup the burp listener to listen on provided HTTP port and forward out HTTP packets through Burp Suite Proxy. This requires configuration on the browser because the HTTP packets requires to be forwarded to Burp via the browser, for this; go to: Firefox/Iceweasel Preferences > Select Advanced Tab and find the ‘Proxy Setting’, when this is done, the next step is to configure the browser to the below specified ports for Burp to intercept traffic:

After this has been done, anything that you browse via the browser will forward HTTP packets (requests and responses, if responses are set to be intercepted) via the Burp Proxy which is newly configured. To make sure of this, on Burp Suite, go to the ‘Proxy’ Tab and make sure Interception is set to ‘On’.

Click on forward and let the request be sent to the web-server and until the request is not forwarded, the browser will wait for the response from the web-server. In-case Burp is configured to intercept the responses as well, it’d go ahead and intercept the responses before forwarding it to the browser for web-page presentation. Now, that everything is ready, and the browser has the response, we will use a junk values on this target to capture the HTTP request and send it to Intruder when the proxy tab blinks next, for this enter any junk values in the web-login form fields and hit sign in to start sending the HTTP request:

Once, the sign-in is hit, the proxy tab will ask for any modifications if needed, here we’d need to right click the request headers and send it to the ‘Intruder’, so we could brute force the form fields:

· The Intruder Tab now blinks, and we’d need to navigate to the ‘Positions’ section for additional modifications like where our given payloads would land for the customized attacks:

Burp Auto-detects the form fields where the usernames and the password might be possibly injected, we can change this to our liking but the default payload set by the special characters in burp such as anything enclosed in $ an $ in this case is the suitable scenario; we’ll check the ‘cluster bomb’ attack type because we have two fields which we need to attack, first one being ‘email’ where our username payload would fit and the second being the ‘password’ where our generated password file from crunch will fit; the Sniper attack type is for one payload at one field at a time, which is false in this case:

Remember, we have two payloads, one for usernames and another for passwords. From here, we will go to the ‘Payloads’ section of ‘Intruder’ tab and use ‘Simple List’ as the ‘Payload Type’ and use ‘Load’ from the ‘Payload Options’ to load our user generated list file:

Click ‘open’ and Burp would set the users.txt file for payload 1 which corresponds to the ‘email’ field. Next, we also had second payload which needs to be set, the password.txt which were generated previously by Burp, for this, we’d select ‘Payload Set’ to ‘2’ and then choose appropriate operations which we did for Payload ‘1’ but here our file will be the generated password list via crunch:

All payloads which by far we went through were ‘Simple List’, because they are carriage-return separated files which contain usernames for the ‘email’ filed and passwords for the ‘password’ field which we previously enumerated looking at the form-fields from the source page.

When everything is set-up, we would require to navigate to the ‘Intruder’ option from the menu-bar and click on ‘Start Attack’, following which Burp Suite would go ahead using its own browser user-agent engine, parsers etc. and brute force the form fields:

As for now, we could see that the ‘Intruder’ had started and is brute forcing the web-form.

Next is detecting the successful logins, if any. By default any credentials you throw at this particular web application will fetch you a ‘200 OK’ response with the ‘Response Code’ being 200, and the ‘Reason’ being ‘OK’ (look at HTTP RFC’s for more details and at the given HTTP document by me). Now, unsuccessful logins will be given ‘200 OK’ response, but if we could somehow eliminate ‘200’ from the column tab, what would be left is the status code including 3xx which would be redirect responses, 4xx which would be bad client side errors, 5xx which would be any server side errors. Beyond that 2xx are informational, which in this case needs to be eliminated, we check with this approach first; to do this, we hover over the ‘Filter’ which currently says ‘Show All’, left click and de-select 2xx Responses, and now we’d be left with 3xx, 4xx and 5xx responses only:

Now, Intruder shows, it’s hiding any 2xx informational responses, and showing us 3xx, 4xx and 5xx responses:
But, we haven’t made still because we see there were no responses which included any redirection which could hint us with a successful login or anything which might hint a successful Brute force of the provided credentials for this attack.

What else could be possible scenarios to look for a successful login? This could be the received content-length header. Now, the next tactical concept is, we receive 2xx for all successful logins as well as unsuccessful logins, nothing is being redirected which is the reason there were no 3xx status codes on completion of brute force; but we see that the content-length for all the responses which were sent were same, this is provided by the Burp Intruder using the ‘Length’ column on ‘Intruder’ upon starting the attack :

The length remains constant and for a better focus, we remove all other columns which could potentially distract us right now. This could be done by navigating to the current ‘Intruder’ menu-bar, choosing ‘columns’ and de-selecting all the un-required columns for analysis and evaluation purposes:

Note: The column tab consists these: Cookies, Comments, Length, Error, Timeout, Request, Status and the payloads that were made for the original intercepted request. Additionally ‘Response Received’ and ‘Response Completed’ provides additional information which could be later used at different attack scenarios which might be useful.

We de-select the ones we do not need, preferably, personally I’d de-select ‘request’, ‘error’, ‘status’, ‘timeout’, ‘comment’ and anything else except the payloads Burp made using the custom tailored payloads and the ‘Length’. Because ‘Length’ is what we need for focus, and ‘status’ isn’t the concern here and hence we remain only with the payloads and the content-length which came with the response header:

Now, closely looking at it, and scrolling down from the numerous requests made by Burp, we get an exceptional ‘Length’ value which has a different value from the other identical ones.

This is where we need to stop and inspect:

The length value is different, and the payloads which were the credentials for ‘email’ and ‘password’ were ‘admin@pentesteracademy.com’ and ‘zzzxy’ respectively. Upon inspection on the ‘response’ tab, and looking at the ‘Render’ tab, the Burp Browser Engine will render, and we can be presented with how would it look if an user submitted those credentials:

And that meant the challenge was cracked and we could use those credentials to verify that username as ‘email’ were ‘admin@penetsteracademy.com’ and password used for this particular email was ‘zzzxy’ as ‘password’ (as per the GET request parameter).

Go to Browser preferences, use the ‘no-proxy’ so you could normally browse all sites and press ‘OK’ for Burp not to intercept, or alternatively, go to Burp Suite ‘Proxy’ Tab, and click ‘Interception Off’ to disable interception of any traffic. Another alternative method is using an addon called ‘swap-proxy’ and other addons similar:

And, you’ll get the ‘congratulations’ which meant, the credentials were cracked and successfully bruited using Burp Suite Client Side Proxy using ‘Intruder’ and custom tailored payloads.

Alternative to using Crunch: If Crunch is too much pain and making dictionaries automated is the goal, Burp Suite as a framework could be used to make dictionary files automatically using the ‘Intruder’ tab, here’s how one could go ahead and automate the diction generation using ‘x’, ‘y’ and ‘z’ as characters and password complexity set to 5 minimum and 5 maximum for these characters:
On the payload tab, set payload 1 type t ‘simple list’ and manually add the usernames which here as an example would be ‘admin@pentesteracademy.com’ and ‘jack@pentesteracademy.com’:

Notice that previous usernames were added, now select ‘Payload Set’ to ‘2’ and select ‘Payload Type’ as ‘Bruteforce’:

We’ll use the character set as ‘xyz’ in this demonstration because that’s the set of password characters being used, make sure in any other scenario, you need to determine this and add these characters to the likely scenario, now if that’s been set, set the ‘Min. Length’ to ‘5’ and the ‘Max. Length’ to 5 because that’s the password complexity for this demonstration. Everything happens in the ‘Payload Options’ for ‘Brute Forcer’ set to the ‘Payload Set’ 2

After everything is set up and done, go to the ‘Intruder’ on the menu-bar discussed before and start the attack, the results would be the same. Check the content-length as discussed before and look for the responses which renders the granted access.

The method ‘for this was not included in this document because Fireforce freezes on ‘range’ operations on newer firefox web-browsers. As soon as Fireforce releases a stable version for newer versions of Firefox, it’d likely be included in this document. Next, we will look at developing a python script to break the password, using python libraries. For python, first step would be to learn python, because without knowing python libraries and how python works, one wouldn’t be able to automate all of this developing his/her own scripts. To be able to automate certain web application exploitation, penetration tester’s use python scripts which they develop out of their own expense of free time. This would be shown in the next method, but it is recommended, people learn python to be able to understand whole of it.

Contact Information and About the Author

Shritam Bhowmick is an application penetration tester professionally equipped with traditional as well as professional application penetration test experience adding value to Defencely Inc. Red Team and currently holds Technical Expertise at application threat reporting and coordination for Defencely Inc.’s global clients. At his belt of accomplishments, he has experience in identifying critical application vulnerabilities and add value to Defencely Inc. with his research work. The R&D sector towards application security is growing green at Defencely and is taken care by him. Professionally, he have had experiences with several other companies working on critical application penetration test engagement, leading the Red Team and also holds experience training curious students at his leisure time. The application security guy!

Out of professional expertise at Application Security, Shritam Bhowmick utilizes his knowledge for constructive Red Teaming Penetration Test Engagements for Indian Top Notch Clients and has a proven record for his excellence in the field of IT Security. A Google search with his name would suffice the eye. Shritam Bhowmick has been delivering numerous research papers which are mostly application security centric and loves to go beyond in the details. This approach has taken him into innovating stuff rather than re-inventing the wheel for others to harness old security concepts. In his spare time, which is barely a little; he blogs, brain-storms on web security concepts and prefers to stay away from the normal living. Apart from his professional living, he finds bliss in reading books, playing chess, philanthropy, and basket-ball for the sweat. He wildly loves watching horror movies for the thrill.