A brute force attack can manifest itself in many different ways, but primarily consists in an attacker configuring predetermined values, making requests to a server using those values, and then analyzing the response. For the sake of efficiency, an attacker may use a dictionary attack (with or without mutations) or a traditional brute-force attack (with given classes of characters e.g.: alphanumeric, special, case (in)sensitive). Considering a given method, number of tries, efficiency of the system which conducts the attack, and estimated efficiency of the system which is attacked the attacker is able to calculate approximately how long it will take to submit all chosen predetermined values.
Risk Factors
Examples
Brute-force attacks are often used for attacking authentication and discovering hidden content/pages within a web application. These attacks are usually sent via GET and POST requests to the server. In regards to authentication, brute force attacks are often mounted when an account lockout policy is not in place.
Example 1
A web application can be attacked via brute force by taking a word list of known pages, for instance from a popular content management system, and simply requesting each known page then analyzing the HTTP response code to determine if the page exists on the target server.
DirBuster is a tool that does exactly this.
Other tools for this type of attack are as follows:
dirb is capable of:
– setting cookies – adding any HTTP header – using PROXY – mutating objects which were found – testing http(s) connections – seeking catalogues or files using defined dictionaries and templates – and much much more
The simplest test to perform is:
rezos@dojo ~/d/owasp_tools/dirb $ ./dirb http://testsite.test/
-----------------
DIRB v1.9
By The Dark Raver
-----------------
START_TIME: Mon Jul 9 23:13:16 2007
URL_BASE: http://testsite.test/
WORDLIST_FILES: wordlists/common.txt
SERVER_BANNER: lighttpd/1.4.15
NOT_EXISTANT_CODE: 404 [NOT FOUND]
(Location: '' - Size: 345)
-----------------
Generating Wordlist...
Generated Words: 839
---- Scanning URL: http://testsite.test/ ----
FOUND: http://testsite.test/phpmyadmin/
(***) DIRECTORY (*)
In the output the attacker is informed that phpmyadmin/ directory was found. The attacker has now found a potential directory of interest within this application. In dirb’s templates there are, among others, a dictionary containing information about invalid httpd configurations. This dictionary will detect weaknesses of this kind.
The application WebRoot.pl, written by CIRT.DK, has embedded mechanisms for parsing server responses, and based on the phrase specified by the attacker, measures if the server response is expected.
For example:
Np.
./WebRoot.pl -noupdate -host testsite.test -port 80 -verbose -match "test" -url "/private/<BRUTE>" -incremental lowercase -minimum 1 -maximum 1
`oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00`
`o Webserver Bruteforcing 1.8 o`
`0 ************* !!! WARNING !!! ************ 0`
`0 ******* FOR PENETRATION USE ONLY ********* 0`
`0 ****************************************** 0`
`o (c)2007 by Dennis Rand - CIRT.DK o`
`oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00`
`[X] Checking for updates - NO CHECK`
`[X] Checking for False Positive Scan - OK`
`[X] Using Incremental - OK`
`[X] Starting Scan - OK`
` GET /private/b HTTP/1.1`
` GET /private/z HTTP/1.1`
`[X] Scan complete - OK`
`[X] Total attempts - 26`
`[X] Sucessfull attempts - 1`
`oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00`
WebRoot.pl found one file "/private/b" on testsite.test, which contains
phrase "test".
Another example is to examine ranges of the variable’s values:
./WebRoot.pl -noupdate -host testsite.test -port 80 -verbose -diff "Error" -url "/index.php?id=<BRUTE>" -incremental integer -minimum 1 -maximum 1
- Road Blocks:
One of the main issues with tools like dirb/dirbuster consist in the analysis of server responses. With more advanced server configuration (e.g. with mod_rewrite) automatic tools are sometimes unable to determine “File not found” errors due to the server response being an HTTP response code 200 but the page itself indicates “File not found”. This can lead to false positives if the brute force tool is only relying on HTTP response codes.
Burp Suite, can be used to parse specific parts of the page returned, looking for certain strings in an effort to reduce false positives.
Example 2
In regards to authentication, when no password policy is in place an attacker can use lists of common username and passwords to brute force a username or password field until successful authentication.
Defensive Tools
Php-Brute-Force-Attack Detector
Detect your web servers being scanned by brute force tools such as WFuzz, OWASP DirBuster and vulnerability scanners such as Nessus, Nikto, Acunetix, etc. This helps you quickly identify probable probing by bad actors who want to dig possible security holes.
How to Test for Brute Force Vulnerabilities
The Web Security Testing Guide (WSTG) Project produces the premier cybersecurity testing resource for web application developers and security professionals.
The WSTG is a comprehensive guide to testing the security of web applications and web services. Created by the collaborative efforts of cybersecurity professionals and dedicated volunteers, the WSTG provides a framework of best practices used by penetration testers and organizations all over the world.
Contributions
Any contributions to the guide itself should be made via the guide’s project repo.
Stable
View the always-current stable version at stable.
Latest
We are currently developing release version 5.0.
You can read the latest development documents in our official GitHub repository or view the bleeding-edge content at latest.
Versioned Releases
v4.2 is currently available as a web-hosted release and PDF. Previous releases are available as PDFs and in some cases web content via the Release Versions tab.
How To Reference WSTG Scenarios
Each scenario has an identifier in the format WSTG-<category>-<number>, where: ‘category’ is a 4 character upper case string that identifies the type of test or weakness, and ‘number’ is a zero-padded numeric value from 01 to 99. For example:WSTG-INFO-02 is the second Information Gathering test.
The identifiers may change between versions therefore it is preferable that other documents, reports, or tools use the format: WSTG-<version>-<category>-<number>, where: ‘version’ is the version tag with punctuation removed. For example: WSTG-v41-INFO-02 would be understood to mean specifically the second Information Gathering test from version 4.1.
If identifiers are used without including the <version> element then they should be assumed to refer to the latest Web Security Testing Guide content. Obviously as the guide grows and changes this becomes problematic, which is why writers or developers should include the version element.
Linking
Linking to Web Security Testing Guide scenarios should be done using versioned links not stable or latest which will definitely change with time. However, it is the project team’s intention that versioned links not change. For example: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server. Note: the v42 element refers to version 4.2.
