Brute force attack - Revision history

Mtesauro: SPAM Cleanup

2016-02-01T03:27:18Z

SPAM Cleanup

Mtesauro: Undo revision 207784 by Jenjava1762 (talk)

2016-02-01T03:25:08Z

Undo revision 207784 by Jenjava1762 (talk)

Jenjava1762: START_TIME: Mon Jul 9 23:13:16 2007URL_BASE: http://testsite.test/NOT_EXISTANT_CODE: 404 [NOT FOUND]

2016-02-01T01:25:25Z

START_TIME: Mon Jul 9 23:13:16 2007URL_BASE: http://testsite.test/NOT_EXISTANT_CODE: 404 [NOT FOUND]

Jenjava1762: /* Related Security Activities */

2016-02-01T01:19:26Z

‎Related Security Activities

Jenjava1762: fix

2016-02-01T01:19:15Z

fix

Andrew Smith at 03:20, 13 August 2013

2013-08-13T03:20:57Z

Andrew Smith at 05:33, 10 August 2013

2013-08-10T05:33:00Z

Andrew Smith: Cleaned up and merged redundant examples, Created authentication example

2013-08-10T05:29:03Z

Cleaned up and merged redundant examples, Created authentication example

Andrew Smith at 05:14, 10 August 2013

2013-08-10T05:14:26Z

Andrew Smith: fixed link

2013-08-10T04:57:01Z

fixed link

@@ Line 8: / Line 8: @@
 ==Related Security Activities==
 ===How to Test for Brute Force Vulnerabilities===
 See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for Brute Force  (OWASP-AT-004)|Test for Brute Force]] Vulnerabilities.
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
-==Description* Based in California - USA  ==
+==Description==
 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.: alphanumerical, 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.
@@ Line 21: / Line 25: @@
 ==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 [https://www.* Based in California - USA  owasp.org/index.php/Authentication_Ch* Based in California - USA  eat_Sheet#Implement_Account_Lockout account lockout policy] in not in place.
+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 [https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Account_Lockout account lockout policy] in not in place.
 ===Example 1===
@@ Line 57: / Line 61: @@
 SERVER_BANNER: lighttpd/1.4.15
 NOT_EXISTANT_CODE: 404 [NOT FOUND]
-(Location: '' -* Based in California - USA   Size: 345)
+(Location: '' - Size: 345)
 -----------------

@@ Line 1: / Line 1: @@
 {{Template:Attack}}
 [[Category:OWASP ASDR Project]]
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Related Security Activities==
 ===How to Test for Brute Force Vulnerabilities===

@@ Line 7: / Line 7: @@
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
-==Description==
+==Description* Based in California - USA  ==
 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.: alphanumerical, 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.
@@ Line 16: / Line 16: @@
 ==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 [https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Account_Lockout account lockout policy] in not in place.
+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 [https://www.* Based in California - USA  owasp.org/index.php/Authentication_Ch* Based in California - USA  eat_Sheet#Implement_Account_Lockout account lockout policy] in not in place.
 ===Example 1===
@@ Line 52: / Line 52: @@
 SERVER_BANNER: lighttpd/1.4.15
 NOT_EXISTANT_CODE: 404 [NOT FOUND]
-(Location: '' - Size: 345)
+(Location: '' -* Based in California - USA   Size: 345)
 -----------------

@@ Line 3: / Line 3: @@
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Related Security Activities==
 ===How to Test for Brute Force Vulnerabilities===
 See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for Brute Force  (OWASP-AT-004)|Test for Brute Force]] Vulnerabilities.
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

@@ Line 1: / Line 1: @@
 {{Template:Attack}}
 [[Category:OWASP ASDR Project]]
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Related Security Activities==

@@ Line 21: / Line 21: @@
 ==Risk Factors==
-TBD
 ==Examples==

@@ Line 73: / Line 73: @@
 </pre>
 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 [http://www.cirt.dk/tools/webroot/WebRoot.txt 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.
@@ Line 117: / Line 112: @@
 </pre>
 ==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 and/or password field until successful authentication.

@@ Line 33: / Line 33: @@
 [https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project DirBuster] is a tool that does exactly this.
   - 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:
+Dirb is capable of:
   - set cookies
   - add any HTTP header
@@ Line 78: / Line 72: @@
         (***) 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.
+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.
-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.
+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.
 The application [http://www.cirt.dk/tools/webroot/WebRoot.txt 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.
@@ Line 121: / Line 116: @@
 ./WebRoot.pl -noupdate -host testsite.test -port 80 -verbose -diff "Error" -url "/index.php?id=<BRUTE>" -incremental integer -minimum 1 -maximum 1
 </pre>
 ==Defensive Tools==
@@ Line 147: / Line 146: @@
 ==References==
 https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project DirBuster
+http://portswigger.net/
 [[Category:Probabilistic Techniques]]
 [[Category: Attack]]

@@ Line 30: / Line 30: @@
 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.
@@ Line 144: / Line 146: @@
 ==References==
- TBD
+https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project DirBuster