Discussion :

[Coriolan]

Une vulnérabilité inhérente à PHP met à risque des millions de sites web WordPress
et l'équipe du CMS ne l'a toujours pas corrigée depuis 2017

WordPress peut être utilisé par plus de 30 % des sites web, cela n'empêche pas le champion des CMS d’être hanté par de nombreux problèmes de sécurité. Après que des chercheurs ont découvert une faille dans son noyau à laquelle l’équipe de WordPress n’a apporté aucune solution, des chercheurs en sécurité se sont rendu compte qu’une fois de plus, une vulnérabilité sévère de WordPress a été délaissée sans être corrigée et pourrait affecter les sites web utilisant le CMS.

La vulnérabilité en question est liée à un bogue PHP lié à la désérialisation des données (ou unmarshalling) a révélé un chercheur en sécurité. Le bogue a été rapporté à l’équipe de WordPress depuis le 28 février 2017 et n’a pas reçu de correctif pendant toute cette période (plus d’un an et demi).

Le bogue permet aux hackers de compromettre tout le système en exploitant le framework PHP de WordPress. À vrai dire, la vulnérabilité n’affecte pas seulement le CMS, elle concerne toutes les applications et bibliothèques PHP qui manipulent des données fournies par utilisateur. De ce fait, on peut dire que la vulnérabilité se trouve dans PHP et pas vraiment WordPress.

Lors de deux conférences de sécurité, le chercheur en sécurité Sam Thomas a révélé comment en utilisant le processus de désérialisation de PHP, il est possible d’exécuter du code à distance sur des serveurs et applications.

La manipulation consiste à téléverser des données déformées sur un serveur. Le but étant de lancer une opération de fichier faisant appel au paquetage « phar:// » de PHP. À son tour, cette manipulation va déclencher des failles dans le XXE -- XML (eXternal Entity) et SSRF (Server Side Request Forgery) qui sont la cause d’une désérialisation du code. Bien que ces failles ne sont pas à haut risque, elles peuvent servir de voie pour mener des attaques d’exécution de code plus sérieuses.

Lors de sa présentation, Sam Thomas a fait la démonstration de trois cas d’exploitation de ce bogue pour mener des attaques ciblant non seulement WordPress, mais aussi Typo3 et la bibliothèque TCPDF intégrée dans le CMS Contao.

Sur WordPress, le bogue de désérialisation affecte la fonctionnalité de traitement d’images miniatures, plus précisément la fonction wp_get_attachment_thumb_file se trouvant dans /wpincludes/post.php, avec la nécessité que le hacker ait la possibilité de téléverser une image déformée sur la plateforme. Toutefois, en raison des changements apportés à la version 4.9 de Wordpress, l’attaque requiert deux types différents de charges utiles (payload), une pour les versions antérieures et une pour les versions ultérieures (après 4.9).

Toute la technique peut être suivie comme décrite par le chercheur sur cette vidéo. Un document est disponible également pour plus de détails.

Le chercheur a informé que l’équipe de Typo3 a corrigé le bogue dans les versions récentes du CMS, la dernière version (corrigeant le problème) en date 9.3 a été publiée le 12 juillet 2018. En même temps, ni WordPress ni l’équipe de TCPDF n’ont encore publié de correctifs. À noter que même si le bogue réside dans PHP, il est impossible de le corriger au niveau du langage, tout correctif doit se faire au niveau des applications.

Les problèmes de désérialisation ne datent pas d’aujourd’hui. Depuis 2009, des vulnérabilités pouvant aider à compromettre la sécurité de systèmes PHP ont été trouvées comme CVE-2017-12934, CVE-2017-12933 et CVE-2017- 12932.

Thomas a noté dans le document que les problèmes de sérialisation affectent beaucoup de langages de programmation (comme Java, Ruby et .NET) et non pas seulement PHP. « La recherche continue sur cette tendance récente, en montrant que la (dé)sérialisation est une part intégrale des langages de programmation modernes, » écrit-il. « Nous devons être constamment conscients de l’impact sécurité de ces mécanismes s’ils sont exposés à des données contrôlées par des attaquants. »

Source : document

Et vous ?

Colmater cette brèche ne devrait-il pas être la priorité de l’équipe WordPress ?
Utilisez-vous WordPress pour monter vos sites web ? Si oui, quel autre moyen comptez-vous utiliser pour protéger les sites web de vos clients contre cette vulnérabilité ?

Voir aussi :

Des chercheurs découvrent une faille dans le noyau de WordPress qui pourrait être exploitée pour supprimer des fichiers système du CMS
WordPress est désormais utilisé sur plus de 30 % des sites web, le champion des CMS creuse encore l'écart avec la concurrence
Une faille dans WordPress permet de mettre les sites hors service, un poste de travail client suffit à accomplir la besogne
Comparatif entre WordPress, Joomla et Drupal avec une infographie sur les systèmes de gestion de contenu

[Asmodan]

Salut,

de là à dire que ce n'est volontairement pas corrigé...

[xillibit]

Bonjour,

le souci est présent sur certaines versions de Php ou sur toutes les versions de Php ?

[Zefling]

Bonjour,

le souci est présent sur certaines versions de Php ou sur toutes les versions de Php ?

Je dirais toutes, vu qu'il s'agit d'un mécanisme qui existe plus un moment et qui reste relativement compatible.
Je dirais que ça ressemble un peu à l'injection SQL (toujours sécuriser la requête avant de l'exécuter), sauf que ça me semble un peu plus compliquer à vérifier les données avant de les désérialiser.

[Invité]

J'ai regardé la conférence, et c'est une faille qui abuse des méthodes magiques de PHP qui sont appelées automatiquement lors d'une dé-sérialisation (__wakeup et __destruct). Du coup il doit y avoir moyen de contrôler l'input de fichiers (c'est comme ça qu'il envoi sur le fichier sur le serveur, genre upload de photo de profil) et de check pour des données sérialisées à l'intérieur des fichiers avant de les mettre dans le répertoire où elles seront accessibles par le reste de l'application.