OWASP - User contributions [en]

Brute force attack

2009-03-10T21:23:19Z

Sstroup: /* Description */ spelling

{{Template:Attack}}
<br>
[[Category:OWASP ASDR Project]]
[[ASDR Table of Contents]]

==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==

During this type of attack, the attacker is trying to bypass security mechanisms while having minimal knowledge about them. Using one or more accessible methods: dictionary attack (with or without mutations), brute-force attack (with given classes of characters e.g.: alphanumerical, special, case (in)sensitive) the attacker is trying to achieve 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 how long the attack will have to last. Non brute-force attacks, on the other hand, which includes all classes of characters, give no certainty of success.

==Risk Factors==
TBD

==Examples==

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

===Example 1===

In the first scenerio, where the goal of brute-forcing is to know the password in its decrypted form, it may appear that [http://www.openwall.com/john/ John the Ripper] is a very helpful tool. The 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:
<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.

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.

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:
<pre>
./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==

'''Php-Brute-Force-Attack Detector'''

http://yehg.net/lab/pr0js/files.php/php_brute_force_detect.zip

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 guys who's wanna dig possible security holes.

http://yehg.net/lab/pr0js/tools/php-brute-force-detector-readme.pdf

==Related [[Threat Agents]]==
* [[:Category:Authentication]]

==Related [[Attacks]]==
* [[Blind SQL Injection]]
* [[Blind XPath Injection]]

==Related [[Vulnerabilities]]==
* [[Insufficient Session-ID Length]]

==Related [[Controls]]==
* [[Authentication]]

==References==
TBD

[[Category:Probabilistic Techniques]]
[[Category: Attack]]

Brute force attack

2009-03-10T21:23:00Z

Sstroup: /* Description */ spelling/grammar

{{Template:Attack}}
<br>
[[Category:OWASP ASDR Project]]
[[ASDR Table of Contents]]

==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==

During this type of attack, the attacker is trying to bypass security mechanisms while having minimal knowledge about them. Using one or more 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 achieve 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 how long the attack will have to last. Non brute-force attacks, on the other hand, which includes all classes of characters, give no certainty of success.

==Risk Factors==
TBD

==Examples==

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

===Example 1===

In the first scenerio, where the goal of brute-forcing is to know the password in its decrypted form, it may appear that [http://www.openwall.com/john/ John the Ripper] is a very helpful tool. The 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:
<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.

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.

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:
<pre>
./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==

'''Php-Brute-Force-Attack Detector'''

http://yehg.net/lab/pr0js/files.php/php_brute_force_detect.zip

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 guys who's wanna dig possible security holes.

http://yehg.net/lab/pr0js/tools/php-brute-force-detector-readme.pdf

==Related [[Threat Agents]]==
* [[:Category:Authentication]]

==Related [[Attacks]]==
* [[Blind SQL Injection]]
* [[Blind XPath Injection]]

==Related [[Vulnerabilities]]==
* [[Insufficient Session-ID Length]]

==Related [[Controls]]==
* [[Authentication]]

==References==
TBD

[[Category:Probabilistic Techniques]]
[[Category: Attack]]

Blind XPath Injection

2009-03-10T21:13:53Z

Sstroup: /* Boolenization */

{{Template:Attack}}
<br>
[[Category:OWASP ASDR Project]]
[[ASDR Table of Contents]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

XPath is a type of query language that describes how to locate specific elements (including attributes, processing instructions,
etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath
can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries.

More information may be found in the article dedicated to [[XPATH Injection]]. Using an XPATH Injection attack the attacker is able to log in to the system without entering valid login and password. If he wants to know information about other users he must take one step further. When conducting a Blind XPath Injection attack, the attacker has no knowledge about the structure of the XML document. However his situation is better compared to [[Blind SQL Injection]], because there are functions which allow for performing tests (XML Crawling) and in the end getting to know the document structure.

==Risk Factors==

TBD

==Examples==
The attacker may be successful using two methods: Boolenization and XML Crawling. By adding to the XPath syntax, the attacker uses additional expressions (replacing what the attacker entered in the place of login to the specially crafted expression).

===Boolenization===
Using the "Boolenization" method the attacker may find out if the given XPath expression is True or False. Let's assume that the aim of the attacker is to log in to the account. Successfull log in would equal "True" and failed log in attempt would equal "False". Only a smart portion of the information is analyzed "character" or the number. When the attacker focuses on the string he may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to.

Using a ''string-length(S)'' function, where S is a string, the attacker may find out the length of this string. With the appropriate number of ''substring(S,N,1)'' function iterations, where S is a previously mentioned string, N is a start character, and "1" is a next character counting from N character, the attacker is able to find out the whole string.

Code:
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<data>
<user>
<login>admin</login>
<password>test</password>
<realname>SuperUser</realname>
</user>
<user>
<login>rezos</login>
<password>rezos123</password>
<realname>Simple User</realname>
</user>
</data>
</pre>
Function:

* ''string.stringlength(//user[position()=1]/child::node()[position()=2])'' returns the length of the second string of the first user (8),
* ''substring((//user[position()=1]/child::node()[position()=2),1,1)'' returns the first character of this user ('r').

===XML Crawling===

To get to know the XML document structure the attacker may use:

* count(expression)
<pre>
count(//user/child::node()
</pre>
This will return the number of nodes (in this case 2).

* stringlength(string)
<pre>
string-length(//user[position()=1]/child::node()[position()=2])=6
</pre>
Using this query the attacker will find out if the second string (password) of the first node (user 'admin') consists of 6 characters.

* substring(string, number, number)
<pre>
substring((//user[position()=1]/child::node()[position()=2]),1,1)="a"
</pre>
This query will confirm (True) or deny (False) that the first character of the user ('admin') password is an "a" character.

If the log in form would look like this:

C#:
<pre>
String FindUser;
FindUser = "//user[login/text()='" + Request("Username") + "' And
password/text()='" + Request("Password") + "']";
</pre>
then the attacker should inject the following code:
<pre>
Username: ' or substring((//user[position()=1]/child::node()[position()=2]),1,1)="a" or ''='
</pre>

The XPath syntax may remind you of common [[SQL Injection]] attacks but the attacker must consider that this language disallows commenting
out the rest of expresssion. To omit this limitation the attacker should use OR expressions to void all expressions, which may disrupt the attack.

Because of ''Boolenization'' the number of queries, even within a small XML document, may be very high (thousands, houndred of thousands and more). That is why this attack is not conducted manually. Knowing few basic XPath functions the attacker is able to write an application in a short time, which will rebuild the structure of the document and will fill it with data by itself.

==Related [[Threat Agents]]==
TBD

==Related [[Attacks]]==
* [[Blind_SQL_Injection]]
* [[XPATH_Injection]]

==Related [[Vulnerabilities]]==
* [[Injection_problem]]

==Related [[Controls]]==
* [[:Category:Input Validation]]

==References==
* http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
* http://www.ibm.com/developerworks/xml/library/x-xpathinjection.html

[[Category:Injection]]
[[Category:Attack]]