Difference between revisions of "Brute force attack"

From OWASP
Jump to: navigation, search
(Common uses of the attack technique)
m (Examples)
(4 intermediate revisions by one user not shown)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
  
{{Template:Stub}}
+
==Description==
  
==What is a {{PAGENAME}}?==
+
During this type of attacks the attacker is trying to bypass security mechanisms having a minimal knowledge about them. Using one or more of accessible methods: dictionary attack (with or without mutations), brute-force attack (with given classes of characters e.g.: alphanuerical, special, case (in)sensitive) the attacker is trying to achive his/her goal. 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 for how long the attack will have to lasts. Non brute-force attacks in the other hand, which includes all classes of characters, gives no certeinty of success.
  
In a brute force attack, the attacker attempts to bypass a security check by attempting possible options until finding one that works. The attacker attempts to exhaust the search space as efficiently as possible. With knowledge of the size of the search space and the rate that attempts can be made, one can calculate the length of time the brute force attack is likely to take.
+
==Examples ==
  
==Common uses of the attack technique==
+
The brute-force attacks are mainly used in the context of guessing passwords and bypassing access control. However there are a lot of tools which uses this techinque to examinate the web service's catalogue structures and seeks interesting, from the attacker's point of view, information. Very often the target of an attack are data in forms (GET/POST) and user's Session-IDs.
  
Brute force attacks are frequently used to attempt bypass of password based authentication schemes and cryptographic protection.
 
  
This kind of attack can also be used in attempt to discover web directory structure and content, and is then said to be a URL brute force attack.
+
In the first scenerio, where the goal of brute-forcing is to get to know the password in its decrypted form, it may appear that john the ripper (http://www.openwall.com/john/) is a very helpfull tool. TOP10 tools for password cracking with different methods, including brute-force, may be found on
 +
http://sectools.org/crackers.html.
  
==Related vulnerabilities==
 
  
* [[Weak credentials]]
+
For testing web services there are tools like:
* [[J2EE Misconfiguration: Insufficient Session-ID Length]]
+
- dirb (http://sourceforge.net/projects/dirb/)
 +
- WebRoot (http://www.cirt.dk/tools/webroot/WebRoot.txt)
  
==Tools==
 
DIRB from http://sourceforge.net/projects/dirb/
 
  
==Related countermeasures==
+
dirb belongs to more advanced tools. With its help we are able to:
 +
- set cookies
 +
- add any HTTP header
 +
- use PROXY
 +
- mutate objects which were found
 +
- test http(s) connections
 +
- seek catalogues and/or files using defined dictionaries and templates
 +
- and much much more
  
[[Salted hashes]]
 
  
[[Password based authentication]]
+
The simplest test to perform is:
 +
<pre>
 +
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 (*)
 +
</pre>
 +
In the output the attacker is informed that phpmyadmin/ catalogue was found. The attacker who knows that, is now able to perform the attack on this application. In dirb's templates there is among others a dictionary containing information about invalid httpd configuration. This dictionary will detect weaknesses of this kind.
 +
 
 +
 
 +
One of the main problems with tools like dirb is recognition if the given response from the server is expected and reliable. With more advanced server configuration (e.g. with mod_rewrite) automatic tools are unable to determine if server response informs about an error or that the file, which the attacker is after, was found.
 +
 
 +
 
 +
Application WebRoot.pl written by CIRT.DK (http://www.cirt.dk/tools/webroot/WebRoot.txt) has embedded mechanisms for parsing server responses and basing on the phrase, wchich was specified by the attacker, it measures if the server response is expected.
 +
 
 +
E.g.:
 +
 
 +
 
 +
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:
 +
<pre>
 +
./WebRoot.pl -noupdate -host testsite.test -port 80 -verbose -diff "Error" -url "/index.php?id=<BRUTE>" -incremental integer -minimum 1 -maximum 1
 +
</pre>
 +
 
 +
==Related Threats==
 +
 
 +
*[[:Category:Authentication]]
 +
 
 +
==Related Attacks==
 +
 
 +
*[[Blind SQL Injection]]
 +
*[[Blind XPath Injection]]
 +
 
 +
==Related Vulnerabilities==
 +
 
 +
*[[Weak credentials]]
 +
*[[J2EE Misconfiguration: Insufficient Session-ID Length]]
 +
 
 +
==Related Countermeasures==
 +
 
 +
*[[Salted hashes]]
 +
*[[Password based authentication]]
 +
 
 +
==Categories==
  
 
[[Category:Attack]]
 
[[Category:Attack]]
 +
[[Category:Probabilistic Techniques]]

Revision as of 16:51, 24 October 2007

This is an Attack. To view all attacks, please see the Attack Category page.


Description

During this type of attacks the attacker is trying to bypass security mechanisms having a minimal knowledge about them. Using one or more of accessible methods: dictionary attack (with or without mutations), brute-force attack (with given classes of characters e.g.: alphanuerical, special, case (in)sensitive) the attacker is trying to achive his/her goal. 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 for how long the attack will have to lasts. Non brute-force attacks in the other hand, which includes all classes of characters, gives no certeinty of success.

Examples

The brute-force attacks are mainly used in the context of guessing passwords and bypassing access control. However there are a lot of tools which uses this techinque to examinate the web service's catalogue structures and seeks interesting, from the attacker's point of view, information. Very often the target of an attack are data in forms (GET/POST) and user's Session-IDs.


In the first scenerio, where the goal of brute-forcing is to get to know the password in its decrypted form, it may appear that john the ripper (http://www.openwall.com/john/) is a very helpfull tool. TOP10 tools for password cracking with different methods, including brute-force, may be found on http://sectools.org/crackers.html.


For testing web services there are tools like:

- dirb (http://sourceforge.net/projects/dirb/)
- WebRoot (http://www.cirt.dk/tools/webroot/WebRoot.txt)


dirb belongs to more advanced tools. With its help we are able to:

- set cookies
- add any HTTP header
- use PROXY
- mutate objects which were found
- test http(s) connections
- seek catalogues and/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/ catalogue was found. The attacker who knows that, is now able to perform the attack on this application. In dirb's templates there is among others a dictionary containing information about invalid httpd configuration. This dictionary will detect weaknesses of this kind.


One of the main problems with tools like dirb is recognition if the given response from the server is expected and reliable. With more advanced server configuration (e.g. with mod_rewrite) automatic tools are unable to determine if server response informs about an error or that the file, which the attacker is after, was found.


Application WebRoot.pl written by CIRT.DK (http://www.cirt.dk/tools/webroot/WebRoot.txt) has embedded mechanisms for parsing server responses and basing on the phrase, wchich was specified by the attacker, it measures if the server response is expected.

E.g.:


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

Related Threats

Related Attacks

Related Vulnerabilities

Related Countermeasures

Categories