Publié par Jerôme Clauzade, Qualys, Inc.

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’équipé 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 Qualys 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.

Qualys Web Application Firewall détecte les vulnérabilités de type XSS dans WordPress avec sa propre configuration : « confidence 80 and severity 60 » sur le paramètre XSS. En d’autres termes, ces paramètres permettent à Qualys WAF de protéger une instance WordPress non patchée contre les vulnérabilités décrites ci-dessus. Son moteur d’analyse qui s’actualise automatiquement peut reconnaître n’importe quelle forme de Cross-Site Scripting, d’injection SQL, ou autres. Les tentatives sont bloquées et consignées tandis que des alertes préviennent immédiatement les administrateurs.

Grâce aux fonctionnalités de patching virtuel et de gestion des exceptions offertes par Qualys WAF 2.0, il est possible de déployer des politiques de sécurité robustes sans perdre un temps précieux à gérer des faux positifs ou des configurations complexes.

La correction du code peut prendre des mois et, dans le cas présent, WordPress a mis 14 mois avant de diffuser son patch. Qualys WAF s’avère donc la méthode de remédiation et de prévention la plus rapide pour les applications Web. En effet, 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.

Déployé dans le réseau de l’entreprise, là où se trouvent les applications, Qualys WAF est intégré avec Qualys Web Applications Scanning (WAS) plus largement avec la plate-forme Cloud Qualys toute entière.