Des groupes de hackers défacent plus 67 000 sites WordPress

par Elaine Cordon, le 08 février 2017 16:16 

Les sites WordPress qui ne sont pas passés à la nouvelle version, disponible depuis deux semaines, sont potentiellement sous le coup d’une campagne d’attaques massives menée par quatre groupes de hackers.

La sortie de la version 4.7.2 de WordPress s’est accompagnée d’un communiqué de sécurité indiquant qu’une faille de sécurité importante avait été découverte dans l’API REST et résolue par la société de sécurité Sucuri.

Mais il semblerait que le problème n’ait pas été réglé pour les versions plus anciennes de WordPress. Ainsi, tous les sites qui n’ont pas été mis à jour s’exposent à une campagne d’attaques massives conduite par quatre groupes de hackers, selon Sucuri qui a cette fois révélé l’exploitation de la faille.

Security Risk: Severe
Exploitation Level: Easy/Remote
DREAD Score: 9/10
Vulnerability: Privilege Escalation / Content Injection
Patched Version: 4.7.2

Dans le cadre d’un projet de recherche sur la vulnérabilité de notre serveur Sucuri Firewall (WAF), nous avons audité plusieurs projets open source à la recherche de problèmes de sécurité. Tout en travaillant sur WordPress, nous avons découvert une vulnérabilité grave à l’injection de contenu (escalade des privilèges) affectant l’API REST. Cette vulnérabilité permet à un utilisateur non authentifié de modifier le contenu d’un article ou d’une page dans un site WordPress.

Nous avons révélé la vulnérabilité à l’équipe de sécurité WordPress qui l’a très bien gérée. Ils ont travaillé en étroite collaboration avec nous pour coordonner le calendrier de divulgation et obtenir autant d’hôtes et de fournisseurs de sécurité conscients et corrigés avant que cela devienne public.

Un correctif pour cela a été inclus silencieusement sur la version 4.7.2 ainsi que d’autres problèmes moins graves. Cela a été fait intentionnellement pour donner à tout le monde le temps de patch. Nous divulguons maintenant les détails parce que nous estimons qu’il y a eu suffisamment de temps pour la plupart des utilisateurs de WordPress pour mettre à jour leurs sites.

Êtes-vous à risque?

Cette vulnérabilité d’escalade de privilèges affecte l’API REST de WordPress récemment ajoutée et activée par défaut sur WordPress 4.7.0.

L’un de ces points de terminaison REST permet l’accès (via l’API) pour afficher, modifier, supprimer et créer des messages. Dans ce point d’extrémité particulier, un bogue subtil permet aux visiteurs de modifier n’importe quel post sur le site.

L’API REST est activée par défaut sur tous les sites utilisant WordPress 4.7.0 ou 4.7.1. Si votre site est sur ces versions de WordPress, il est actuellement vulnérable à ce bug.

Détails techniques

Notre voyage commence en ./wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php

Il ya quelques choses à noter ici. L’itinéraire enregistré est conçu pour remplir le paramètre de demande ID avec des chiffres. Par exemple, si vous envoyez une requête à / wp-json / wp / v2 / posts / 1234 – le paramètre ID est défini sur 1234.

Ce comportement seul pourrait être un bon moyen d’empêcher les attaquants d’élaborer des valeurs d’ID malveillantes, mais en examinant comment l’API REST gère l’accès, nous découvrons rapidement qu’elle donne la priorité aux valeurs $ _GET et $ _POST par rapport à celles générées par l’expression régulière de l’itinéraire. Cela permet à un attaquant d’envoyer une requête comme: / wp-json / wp / v2 / posts / 1234? Id = 12345helloworld – qui assignerait 12345helloworld au paramètre ID – qui contient maintenant plus que des chiffres.

En recherchant plus loin, nous avons regardé les différents rappels (dans la capture d’écran ci-dessus) et l’un d’entre eux a retenu notre attention: update_item et sa méthode de vérification d’autorisation update_item_permissions_check.

En bref, il passe notre valeur d’identification alphanumérique directement à la fonction get_post (). Cette fonction valide la requête en vérifiant si le message existe réellement et si notre utilisateur a la permission de modifier ce message. Nous avons trouvé que c’était une façon curieuse de désinfecter la demande. Si nous envoyons un ID qui n’a pas de poste correspondant, nous pouvons simplement passer par la vérification d’autorisation et être autorisés à continuer à exécuter des requêtes à la méthode update_item!

Curieux de ce qui pourrait causer get_post () à l’échec à la recherche d’un poste (autre qu’un ID inexistant), nous avons réalisé qu’il a utilisé la méthode statique get_instance () dans wp_posts pour saisir les messages.

Comme vous pouvez le voir à partir du code, il serait fondamentalement échouer sur toute entrée qui n’est pas tous composés de caractères numériques – donc 123ABC échouerait.

Pour un attaquant, cela signifie que WordPress (pensant que c’est un utilisateur avec suffisamment de privilèges pour éditer ce post) exécuterait la méthode update_item.

Nous avons pensé qu’il serait logique de vérifier ce que fait cette méthode.

Il ya un détail très subtil, mais important dans cette dernière capture d’écran – WordPress jette le paramètre ID à un entier avant de le passer à get_post!

C’est un problème en raison de la manière dont PHP fait comparaisons et conversions. Par exemple, on peut voir que l’extrait suivant renverrait 123:

Cela conduit à une situation très dangereuse où un attaquant pourrait soumettre une requête comme / wp-json / wp / v2 / posts / 123? Id = 456ABC pour changer le post dont l’ID est 456!

En raison de ce type de jonglage problème, il est alors possible pour un attaquant de modifier le contenu de n’importe quel post ou page sur le site d’une victime. De là, ils peuvent ajouter des raccourcis spécifiques au plugin pour exploiter les vulnérabilités (qui seraient autrement restreintes aux rôles des contributeurs), infecter le contenu du site avec une campagne de spam SEO, ou injecter des publicités, etc.

Selon les plugins activés sur le site, même le code PHP pourrait être exécuté très facilement.

En conclusion

Si vous n’avez pas activé les mises à jour automatiques sur votre site Web, mettez-les à jour dès que possible!

Il s’agit d’une vulnérabilité grave qui peut être utilisée de diverses manières pour compromettre un site vulnérable. Mettre à jour maintenant!