User Tools

Site Tools


hack:brute_force_attack

brute_force_attack

inlinetoc

Pour évaluer les vulnérabilités de force brute, Voir l'article OWASP Testing Guide sur how to Test for Brute Force Vulnerabilities.

Description

Pendant ce type d'attaque, l'attaquant essaie d'éviter les mécanismes de sécurité en ayant la connaissance minimale d'eux. Utilisant une ou plus de méthodes plus accessibles : le de dictionnaire des attaques (avec ou sans mutations), l'attaque de force brute (avec des classes données de caractères par ex. : alphanumérique, special, casse (in) sensitive) l'attaquant essaie d'atteindre son but. En considérant une méthode donnée, le nombre d'essais, l'efficacité du système, qui conduit l'attaque a estimer l'efficacité du système qui est attaqué, l'attaquant est en mesure de calculer combien de temps l'attaque devra durer. Les attaques qui ne sont pas de force brute, d'autre part, et qui incluent toutes les classes de caractères, ne donnent aucune certitude de succès.

Exemples

Les attaques de force brute sont surtout utilisées pour deviner des mots-de-passe et éviter les contrôles d'accès. Pourtant il y a beaucoup d'outils qui utilisent cette technique pour examiner les structures du catalogue du service Web et les recherches intéressantes d'informations, du point de vue de l'attaquant. Très souvent la cible d'une attaque sont des données sous la forme (GET/POST) et les Session-IDs des utilisateurs.

Dans premier scenario, où le but de forçage brute est de savoir le mot-de-passe dans sa forme décryptée, il peut sembler que John the Ripper est un outils très utile. Les outils au TOP10 pour craquer le mot-de-passe avec différentes méthodes, incluant la force brute, peuvent être trouvés sur http://sectools.org/crackers.html

Pour tester les services Web il y a des outils comme :

dirb

dirb appartient aux outils plus avancés. Avec son aide nous sommes en mesure de :

- 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

Le test le plus simple à jouer est :

rezos@dojo ~/d/owasp_tools/dirb $ ./dirb <__yamdwe_nowiki>0</__yamdwe_nowiki>
-----------------
DIRB v1.9
By The Dark Raver
-----------------
START_TIME: Mon Jul  9 23:13:16 2007
URL_BASE: <__yamdwe_nowiki>1</__yamdwe_nowiki>
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: <__yamdwe_nowiki>2</__yamdwe_nowiki> ----
FOUND: <__yamdwe_nowiki>3</__yamdwe_nowiki>
       (***) DIRECTORY (*)

Dans la production l'attaquant est informé que le catalogue phpmyadmin/a été trouvé. L'attaquant sait que maintenant il est capable d'exécuter l'attaque sur cette application. Dans les modèles de dirb il y a, parmi d'autres, un dictionnaire contenant des informations sur la configuration httpd invalide. Ce dictionnaire découvrira des faiblesses de cette sorte.

Un des problèmes principaux avec les outils comme dirb est la reconnaissance si la réponse donnée du serveur est attendue et sûr. Avec une configuration de serveur plus avancée (par ex. avec mod_rewrite) les outils automatiques sont incapables de déterminer si la réponse du serveur informe d'une erreur ou que le dossier, après lequel est l'attaquant, a été trouvé.

L'application //WebRoot.pl//

L'application WebRoot.pl écrite par by CIRT.DK, a fixé des mécanismes pour analyser les réponses du serveur, et a basé sur l'expression spécifiée par l'attaquant, des mesures si la réponse du serveur est attendue.

Par exemple:

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 trouve un fichier “/private/b” sur testsite.test, qui contient la phrase “test”.

Un autre exemple est d'examiner les ranges des valeurs de la variable

./WebRoot.pl -noupdate -host testsite.test -port 80 -verbose -diff "Error" -url "/index.php?id=<BRUTE>" -incremental integer -minimum 1 -maximum 1>br>
Defensive Tools
Php-Brute-Force-Attack Detector 
<__yamdwe_nowiki>4</__yamdwe_nowiki>

Vous découvrez que vos serveurs web sont en train d'être scannés par un outils de force brute comme WFuzz, OWASP DirBuster et les scanners de vulnérabilité comme Nessus, Nikto, Acunetix .. etc. Cela vous aide à identifier rapidement qu'il est probable que vous êtes sondés par un attaquant qui veut profiter de vos possibles trous de sécurité.

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

hack/brute_force_attack.txt · Last modified: 2022/04/07 07:52 by 127.0.0.1