Je me suis fait pirater – lol !

A force de déceler des failles à droite à gauche (je n’en poste que très peu ici finalement par rapport à tout ce que je peux détecter…) ça devait arriver : I got hacked !

Je vais donc en profiter pour vous expliquer comment l’attaquant, @BoiteAWeb, s’y est pris, comment j’ai réagi et corrigé.

Version courte, @BoiteAWeb a utilisé un CSRF présent dans l’extension lightbox2 pour WordPress et injecté un XSS persistant qui mettait en place une iframe de hadopi.fr sur mon blog. Ce site ayant un script empêchant la mise en iframe, toute personne visitant mon blog était automatiquement redirigée vers hadopi.fr – Bien joué l’artiste, j’ai beaucoup ri !

Me supposant connecté à l’administration de mon blog il m’a invité, via Twitter à visiter son site. Sur celui-ci était présent le code suivant :

Pour les plus néophytes d’entre vous, le code créé un formulaire qui va se soumettre tout seul et répondre à la page de configuration de l’extension pour y changer la valeur lightbox_2_theme par la valeur « ><iframe src=http://hadopi.fr height=1500 width=1900></iframe><a a= »

Ceci ayant pour effet de stocker cette valeur comme thème à utiliser dans les options de l’extension on se retrouvait avec le code source suivant (j’ai ajouté des retours à la ligne pour la lisibilité) pour tous les utilisateurs visitant mon blog :

Résultat : une belle iframe Hadopi et une redirection vers le site en question… Oups !

Passé un gros fou-rire j’ai demandé à @BoiteAWeb dans quoi il avait injecté son XSS persistant et vu qu’il n’était plus devant son ordi ai du investiguer moi-même. Ayant constaté qu’il s’agissait d’une redirection javascript je l’ai désactivé et ai regardé la source de mon blog. En cherchant « hadopi.fr » dans le source j’ai rapidement constaté que cela venait de l’extension lightbox2 que j’ai désactivé le temps de la patcher.

Je me suis ensuite penché sur les infos stockées en base de données pour trouver que c’était la variable lightbox_2_theme qui avait été modifiée.

Dans le source de l’extension (qui n’est plus maintenue) j’ai vite compris le problème : il n’y a aucune protection anti-CSRF sur l’administration et la variable de thème est affichée sans aucune vérification ou assainissement.

J’ai donc rajouté les deux comme ceci :

Dans le fichier lightbox2.php, chercher la ligne suivante :

document.write(‘<link rel=\ »stylesheet\ » href=\ » ».$lightbox_style. »lightbox.css\ » type=\ »text/css\ » media=\ »screen\ » />’);

Et remplacer par :

document.write(‘<link rel=\ »stylesheet\ » href=\ » ».esc_html($lightbox_style). »lightbox.css\ » type=\ »text/css\ » media=\ »screen\ » />’);

Dans le fichier options.php, chercher la ligne suivante :

if (‘process’ == $_POST[‘stage’]){

Et remplacer par :

if (‘process’ == $_POST[‘stage’] && preg_match(‘`^[a-z ]+$`i’, $_POST[‘lightbox_2_theme’]) && is_dir(get_option(‘lightbox_2_theme_path’).’/’. $_POST[‘lightbox_2_theme’])) {

Pour être un peu plus complet on peut aussi changer la valeur de $_POST[‘stage’] par une valeur personnelle et faire de même dans le formulaire. Ainsi pour forger une requête il faudra que l’attaquant connaisse la valeur que vous aurez choisi… Ou essaye par bruteforce par exemple.

Une fois toutes les modifications apportées j’ai réactivé l’extension et remis le thème à White, ce qui a eu pour effet d’enlever le XSS persistant.

Grâce à @BoiteAWeb j’ai maintenant un site un peu plus sécurisé (il va falloir que j’audite le reste des extensions que j’utilise du coup !) et cela a surtout évité qu’une personne moins bien intentionnée s’en prenne à cette vulnérabilité et s’en serve pour commettre des actes de terrorisme numérique !

Je lui dédie donc cet article, un grand merci et, dès qu’il sera publié, je lui enverrai Piratons la démocratie !

17 réflexions sur « Je me suis fait pirater – lol ! »

  1. BoiteaWeb

    Merci à toi Paul 🙂

    Je n’ai pas pour habitude d’exploiter les failles que je trouve sans l’accord de son propriétaire. Mais ayant mis 3 fois un pied dans la porte avec toi le jour même afin de « tester » ta façon de penser à ce sujet, je me suis dit « allez je lui fait façon sympa » 😉

    Après un rapide coup d’oeil sur les plugins utilisés, j’ai audité rapidement le seul plugin que je ne connaissais pas « lightbox-2 ».

    BIM une CSRF menant à une XSS. je n’ai rien à ajouter au « comment j’ai fait », Paul a déjà tout dit (trop à mon gout mais c’est son blog, c’est lui la victime, je le laisse juge de tout montrer ou non).

    Je souhaite maintenant grâce à cet article faire passer un message pour tous les possesseurs d’un WordPress(.org) :
    Les plugins sont la première porte d’entrée vers un hacking. Malheureusement, même les plugins du repository WordPress (l’extend) ne sont pas vérifiés, et avec plus de 14000 plugins … wow à qui se fier ?
    J’ai la réponse : personne :] De mon côté j’audite des plugins, quelques fois gratuitement (plugin de mon choix), d’autres non (si le plugin est payant : je fais payer).
    J’ai réalisé un plugin 100% secure (lui) qui est capable de vous indiquer si le plugin est secure ou pas. Il s’agit de WPSC (http://wordpress.org/extend/plugins/baw-wordpress-plugin-security-checker/).
    Malheureusement, le nombre de plugin audité est loin des 14000 dispo.
    Courant juillet ce plugin passera en v2.0 et il y aura plus d’audits, vous aurez la possibilité de faire la demande d’audits (sans prix, un don est apprécié néanmoins).

    Je vous recommande dans tous les cas de vous tenir à jour sur 100% de vos plugins, de supprimer (pas juste désactiver) ceux que vous n’utilisez pas, et si vous doutez de la sécurité de l’un d’entre eux, contactez un professionnel sur le sujet (/me lève la main).

    Autre conseil d’ami : ne divulguez pas la liste de vos plugins, jamais, déjà que même sans ça, on peut en trouver (je vous invite à tester ce service http://secu.boiteaweb.fr/services/wordindisc/ vous en serez étonné et/ou dégoutés.

    Pour finir sachez que j’ai repris le plugin et suis en train d’en faire une v3.0, elle sort demain si tout va bien. Elle corrige évidemment les 2 failles, le code a été refondu et amélioré.

    Bonne route à tous !

    Julio – Consultant en Sécurité Web – Spécialisé WordPress
    Blog Sécurité WordPress – http://blog.boiteaweb.fr
    Site pro Sécurité Web – http://secu.boiteaweb.fr

  2. Siriru

    Si elle n’est plus maintenue ça ne sert plus à grand chose. À moins que ça le motive au contraire.

  3. Daniel Roch

    Excellent cas pratique du problème posé par la sécurisation trop faible ou inexistante d’un grand nombre de plugins WordPress.

    Et je ne peux qu’approuver le commentaire de BoiteAWeb : ce n’est pas parce que l’on trouve un plugin sur le site officiel de WordPress que celui-ci est sécurisé (ou qu’il est utile…).

  4. bzhmaddog

    c’est quand même très ciblé comme attaque. Il faut connaitre le responsable du site pour l’inciter à visiter le sien.

    Mais en tout cas ça me rassure je fais bien de ne pas utiliser le même browser pour surfer et pour éditer mon blog :p

  5. alex

    Ah, une csrf classique !
    Félicitations à Julio d’avoir repris le développement de ce plugin et aussi pour son excellent comméntaire; sauf peut-être la partie où il dit que sont plugin est 100% sûr ! J’imagine qu’il n’a jamais testé son plugin sur un WP multisite (ouais, le plugin n’est peut-être pas censé pour ce type de sites, mais ca rend fausse son affirmation). 🙂

  6. BoiteaWeb

    @bzhmaddog : C’est ciblé CAR c’est une attaque. Et non, pas obligé de connaitre le responsable, la preuve, je ne le connais pas Paul. On s’est parlé hier sur twitter, il a RT un de mes tweets et je ai exploit une faille sur son site.
    Combien de fois cliques-tu sur des liens bit.ly, goo.gl sans connaitre l’arrivée d’arrivée ? Qui ne cliquerait pas sur un lien twitter du genre « NAN ! Trop excellent, j’en veux ! http://superurl.quitue.com #lol »

    Et oui, tu peux utiliser le même navigateur pour surfer ET éditer ton blog. Cependant il faut séparer « Auteur » et « Admin ». L’auteur ne pourra que poster des articles, et pas modifier les plugins etc 😉

    @alex : CSRF classique qui reste la faille la plus répandue sur le net de nos jours… Il est vrai que je ne l’ai pas testé sur un MS, peux tu m’indiquer ce que ça change niveau sécu/code du plugin ? Je ne comprends pas bien 😮 Merci

  7. alex

    Ben je n’ai pas trop regardé ton code, mais il me semble que tu ne valides pas que la valeur de ta clé API a le format adéquat, ce qui permettrait de faire du XSS. Il ne faut jamais assumer que les valeurs provenant de la BD sont sûrs !
    J’ai trouvé ce type d’erreurs il y a longtemps dans le core. La version 3.1.3 va d’ailleurs en corriger aussi quelques uns.

  8. BoiteaWeb

    Oui c’est vrai que je ne sanitize pas et qu’une XSS est possible dans ce champ. Par contre, étant donné qu’il faut être admin pour pouvoir insérer cette clé, je me dit que si l’admin souhaite s’auto XSSer, c’est sa vie x)
    Allez, j’ajoute un sanitize_key() pour la v2.0, rien d’urgent.
    Tout ce qui s’affiche venant de l’ajax linké sur mon site est totalement secure, je ne fais pas de « echo » des données venant de mon site. Trop facile de balancer de belles infos au début puis de hack tout le monde d’un coup ensuite ;o
    Merci encore

  9. alex

    Dans un WP multisite, presque tous les utilisateurs ont le rôle administrateur ! C’est pour ca que j’avais mentionné ce cas là 😉

  10. Ping : Meilleurs plugins WordPress : la crème de la crème - Blogueur Marketeur

  11. Ping : Blogueur Marketeur – Meilleurs plugins WordPress : la crème de la crème

Les commentaires sont fermés.