Publié le : 20 Mai 2015

Le 21 avril, WordPress a émis un avis de sécurité critique et « vivement encouragé » ses utilisateurs à mettre à jour « immédiatement » leurs sites Web. En règle générale, l’utilisation de ces termes alarmants est symptomatique d’une menace majeure. Et c’était effectivement le cas.

WordPress domine tellement le marché des CMS que près de 50% de l’ensemble des sites Web s’appuient sur ce système de gestion de contenu. Ce récent avis de sécurité résout de nombreuses vulnérabilités dont certaines étaient critiques puisqu’un attaquant pouvait obtenir un accès administrateur pour n’importe lequel des millions de sites Web fonctionnant sous WordPress. La vulnérabilité la plus sensible affecte la version 4.1.1 de WordPress et les versions antérieures.

Pour commencer, MySQL prend des libertés avec UTF-8

Le chercheur Cedric Van Bockhaven a découvert que le jeu de caractères UTF-8 utilisé par MySQL ne supportait que des caractères encodés sur 3 octets, ce qui est plus que suffisant pour la plupart des langues modernes (BMP), mais pas assez pour les caractères supplémentaires (SMP) tels que le superbe cheval de manège (U+1F3A0) ou le joli petit poussin vu de face (U+1F425) …

Si vous tentez d’insérer une chaîne de caractères contenant l’un de ces magnifiques animaux dans une colonne de type UTF-8, MySQL tronquera la chaîne de caractères après le caractère encodé sur 4 octets et avertira l’administrateur de la présence d’une « Incorrect string value ». Le seul moyen de prévenir ce type d’insertion est de configurer MySQL en mode strict, ce qui n’est pas le cas par défaut.

Malheureusement, le fonctionnement de WordPress est basé sur MySQL et le CMS n’utilise pas le mode strict.

Ensuite, on exploite la faille

Lorsqu’on parle de troncation, le Cross-site Scripting (XSS) n’est jamais très loin. M. Van Bockhaven a découvert que le même comportement de troncation UTF-8 permettait d’exploiter la fonctionnalité de commentaires de WordPress et d’insérer des scripts, quel que soit le thème WP. Le chercheur a pu modifier les mots de passe, créer un nouveau profil administrateur et exécuter à peu près n’importe quelle action sur le CMS.

Un autre exploit a été révélé le lendemain à partir du même problème de troncation. Jouko Pynnönen a en effet découvert que la taille des entrées du type TEXT de MySQL est limitée à 64 kilo-octets. Un très long commentaire sera donc tronqué tout comme le caractère encodé sur 4 octets de M. Van Bockhaven et avec les mêmes conséquences. Pour résoudre cette deuxième vulnérabilité, WordPress a publié un nouvel avis de sécurité (4.2.1)

Ensuite, WordPress corrige

L’équipe chargée de la sécurité de WordPress a résolu le problème UTF-8 via la mise à jour 4.1.2 du 21 avril qui prend désormais pleinement en charge les caractères encodés sur 4 octets en modifiant le jeu de caractères MySQL utilisé par défaut dans WordPress en UTF-8MB4. Une semaine plus tard, une nouvelle mise à jour 4.2.1 réglait le problème de troncation lors de l’insertion de longs commentaires. Les vulnérabilités XSS liées à ces problèmes ne seront donc plus exploitables.

L’équipe a également résolu d’autres problèmes de sécurité concernant encore XSS dans une version plus ancienne de WordPress ainsi que celui de l’injection de codes SQL dans certains plug-ins vulnérables. Le 7 mai, l’équipe sécurité de WordPress publie une nouvelle version 4.2.2. Cette fois c’est une vulnérabilité de type DOM XSS qui cible le CMS…

Comment un Web Application Firewall gère les scripts XSS et l’injection de codes SQL

Cette suite d’incidents de sécurité, loin d’être propre à WordPress nous invite à ne pas baser entièrement la sécurité de nos applications web sur les épaules des seuls développeurs, si talentueux et réactifs soient-ils. Un pare-feu applicatif (WAF) convenablement configuré peut bloquer ce genre de tentatives car elles sont basées sur des techniques d’attaques éprouvées.
Un pare-feu applicatif correctement configuré permet de protéger une instance WordPress non patchée contre les vulnérabilités décrites ci-dessus. La correction du code peut prendre des mois et, dans le cas présent, WordPress a mis 14 mois avant de diffuser son patch. Un WAF s’avère donc la méthode de remédiation et de prévention la plus rapide pour les applications Web. Il garantit le maintien d’un environnement Web sûr en attendant la phase de correction ou entre les fenêtres de maintenance et de mise à jour des applications.

lire l'article