Wordpres et compromission de la chaîne de livraison
Comme Prestashop ou WordPress, les applications Web qui dépendent fortement de plugins sont particulièrement exposées aux attaques de la chaîne de livraison 🚨.
Qu’est-ce qu’une attaque de la chaîne de livraison ?
Ces attaques (supply chain attack, en anglais) consistent à compromettre un élément de la chaîne de livraison (sources, pipeline CI/CD, environnements applicatifs etc) afin d’injecter une charge malveillante qui affectera ceux qui utiliseront le logiciel.
Un plugin vérolé est diffusé sur le store et chaque site ayant installé le plugin reçoit une alerte de mise à jour. Si la mise à jour automatique est activée, celle-ci est faite automatiquement et de façon transparente.
Dans le cas d’une application OpenSource, les contributeurs sont souvent bénévoles et l’application n’a pas forcément de contrôle sur eux.
Exemple d’un plugin WordPress compromis
Le 24 juin 2024, cinq plugins populaires de WordPress ont été contaminés par du code malveillant1. L’équipe de développement utilisait le même mot de passe pour plusieurs services, y compris leurs accès au déploiement de leurs plugins. Ces mots de passe ont été compromis lors de fuites de données, permettant aux hackers de les réutiliser pour diffuser des versions modifiées des plugins sur le store officiel de WordPress.
A cause de cette négligence des développeurs, environ 35 000 sites ont été exposés à des risques de sécurité importants sans que les organisations en ait conscience. C’est d’autant plus grave que WordPress est souvent utilisé par des organisations disposant d’un faible niveau de maturité, et ne peuvent le plus souvent pas se permettre de faire une revue de code à chaque mise à jour.
En quoi est-ce un problème ?
Le problème majeur dans ce cas, c’est que tout le monde fait confiance à tout le monde. WordPress fait confiance aux auteurs de plugins. Les responsables de sites font confiance à WordPress et aux avis sur le plugin (surtout s’il est très populaire) et finalement le site est hacké sans que personne ne s’en sente responsable.
La sécurisation est une responsabilité partagée, mais in fine ce sont les organisations qui sont responsables de ce qu’il se passe sur leurs sites (même si elles n’en ont que rarement conscience).
Elles sont encore plus rares à apporter une réponse à la bonne hauteur. Par méconnaissance, elles se contentent souvent d’une simple mise à jour sans avoir conscience que l’attaquant a pu injecter une backdoor pour un usage ultérieur.
Comment se prémunir ?
Amis développeurs, continuez à contribuer aux projets OpenSource mais par pitié respectez les basiques de la sécurité informatique (notamment un mot de passe unique par service) : vous n’avez pas l’excuse de faible maturité.
Aux organisations peu matures : faites vous accompagner par un partenaire sérieux (scoop : souvent ce n’est pas le moins cher) ou formez-vous. Oui ça a un coût, mais toujours moins élevé que celui de traiter les conséquences d’une compromission.
Si votre prestataire actuel ne vous a pas encore précisé comment il gère les mises à jour, il est plus que temps de le questionner. Et si la réponse est « on clique », « on a activé les mises à jour automatiques » ou toute autre réponse indiquant qu’il ne fait pas de revue de code : fuyez !