Discussion :

[Idelways]

Sécurité : deux millions de mots de passe WordPress réinitialisés
Suite à la découverte de contributions malicieuses à trois plug-ins populaires



Automatic vient de lancer une dépêche de sécurité importante sur le blog officiel de WordPress, y notifiant tous les utilisateurs du Blogware/CMS de la découverte de plusieurs contributions malintentionnées au code de trois de ses plug-ins les plus populaires.

Des commits acceptés sur le code de AddThis, WPtouch, et W3 Total Cache, se révèlent contenir des portes dérobées soigneusement dissimulées, créées et propagées par un ou plusieurs pirates non encore identifiés.

Automatic assure que les contributions malicieuses ne proviennent pas des auteurs de ces extensions et qu'elles ont été annulées par la publication d'une mise à jour dont il recommande vivement l'installation aux administrateurs des installations individuelles de WordPress.

De son côté, la firme prend la décision radicale de réinitialiser les deux millions de mots de passe de tous les comptes de WordPress.org, mais aussi bbPress.org et BuddyPress.org.

En attendant de passer au crible le code des extensions concernées à la recherche de toute autre menace, leurs dépôts de code resteront fermés jusqu'à nouvel ordre.

Cette découverte rappelle encore une fois que l'ouverture du code open source n'est jamais un gage certain contre l'insertion de code malicieux.
Même pour les projets les plus populaires.


Source : WordPress.org

Et vous ?

Que pensez-vous de cette découverte ?

[nu_tango]

Cette découverte rappelle encore une fois que l'ouverture du code open source n'est jamais un gage certain contre l'insertion de code malicieux.
Même pour les projets les plus populaires.

C'est d'autant plus vrai qu'un projet de la taille de wordpress devrait effectivement montrer l'exemple en matière de sécurité de son ecosystême.

De son côté, la firme prend la décision radicale de réinitialiser les deux millions de mots de passe de tous les comptes de WordPress.org, mais aussi bbPress.org et BuddyPress.org.

C'est effectivement la meilleure réaction à adopter en ce cas bien que contraignante pour l'utilisateur final. On peut quand même mettre au crédit de Wordpress d'avoir réagit rapidement et dans la bon sens.

[squelos]

J'aurais plutot dit que les projets les plus populaires sont les plus susceptibles d'etre la cible d'intentions malicieuses.

[Franck Dernoncourt]

Ca me rappelle le Linux Kernel "Back Door" Attempt : http://kerneltrap.org/node/1584

Étrange que les commits aient été acceptés...

[jmini]

Étrange que les commits aient été acceptés...

De ce dont je me souviens, le repository SVN pour les extension Wordpress n'est pas tres surveillé/organisé... Je crois qu'à partir du moment ou tu es inscrit, tu peux commiter (peut être que sur ton extension, je ne sais plus).

Le fait est que Wordpress apprend à la dure, qu'ils vont devoir investir dans des process de gestion de code, au moins pour leur extension les plus populaires (Plus de chathédrale, moins de bazar).

[Franck Dernoncourt]

Ah oui, effectivement les extensions souvent c'est beaucoup moins sécurisées : ce sont les auteurs de l'extension qui doivent vérifier les commits. Sur MediaWiki ça marche ainsi, plus précisément les auteurs doivent vérifier les modifications de la page "officielle" de leurs extensions (e.g. http://www.mediawiki.org/wiki/Extension:W4G_Rating_Bar). Les extensions ne sont pas vérifiées systématiquement par les auteurs de MediaWiki, et on découvre régulièrement des failles dans certaines extensions, mais celles-ci ont été introduites par leurs auteurs (involontairement en général)

La meilleure solution que je vois est comme toi de distinguer les extensions "officielles" qui seront surveillées par les auteurs du framework des extensions "non officielles" dont l'utilisation sera aux risques et périls du webmaster... le problème étant que cela n'encourage ni les nouveaux arrivants ni les extensions non populaires mais utiles parfois.

[kdmbella]

je croyais que les commits était soigneusement testés avant d'être intégré au projet il doivent donc revoir leur politique de test

[Neko]

je croyais que les commits était soigneusement testés avant d'être intégré au projet il doivent donc revoir leur politique de test

Faut pas se leurrer non plus. Ca prendrait plus de temps pour examiner un code en profondeur qu'à le refaire soit-même directement...
Les commit sont probablement testés et vérifiés en surface. Mais pas à la loupe non plus.

[sebounet]

Moi, je dirais plus que les responsables communauté et automatic sont laxistes. Je ne veux pas m’étendre sur le sujet mais en observant quelques articles et quelques réflexions des responsables en question, on se dit que le hacking a des beaux jours devant lui.

[lemoussel]

Je ne suis pas plus surpris que les commits aient été acceptés. En effet le code malicieux était bien caché.

Ayant eu ce code malicieux j'en explique les principes dans cet article : Backdoor plugin WordPress: Explication du code PHP malicieux.

Mais on ne le dira jamais assez, chaque fois que vous installez un thème ou un plugin tiers, vous donnez potentiellement un accès total à votre blog.

[Franck Dernoncourt]

Super article, merci lemoussel

Néanmoins, si les auteurs originaux laissent du nouveau code apparaître sans le comprendre, je doute de la qualité du code... cela dit, je ne connais pas beaucoup WP, je me base juste de l'expérience en écriture d'extensions que j'ai sur MediaWiki notamment.

[lemoussel]

Je pense que le souci c'est que personnes ne s'est aperçu, pendant un certain temps, de l'ajout de cette seule ligne de code. C'est toute la subtilité de ce backdoor. Simple et futé.