Une mise à jour WordPress (version de maintenance), apparemment passée inaperçue mais importante pour votre cybersécurité, du CMS le plus populaire au monde, WordPress, a été déployé mondialement fin de la semaine dernière.
Contrairement à ses concurrents, Drupal et Joomla, WordPress sait appliquer automatiquement les mises à jour de sécurité, de sorte que la version 4.7.2 a fait son apparition au niveau de millions de sites internet sans que les propriétaires ne s’en aperçoivent :
Le jeudi 26 janvier, nous avons déployé WordPress 4.7.2 au niveau mondial. La version a été diffusée via notre système autoupdate et, en quelques heures, des millions d’utilisateurs de WordPress 4.7.x en ont bénéficié, sans connaitre le problème, ni action à entreprendre.
Les responsables de sites internet qui ont découvert la mise à jour WordPress en prenant leur petit-déjeuner, auront vu que la version 4.7.2 concerne trois vulnérabilités importantes, sans être pour autant critiques.
Peut-être moins visible, une quatrième vulnérabilité a aussi été traitée : une vulnérabilité concernant l’augmentation de privilèges sans authentification, suffisamment sérieuse pour justifier la résolution de cette dernière très discrètement !
La 4ème vulnérabilité de cette mise à jour
Cette vulnérabilité, non mentionnée, affecte la version 4.7.0 et 4.7.1 de WordPress donc si, pour une raison quelconque, vous utilisez un site internet qui n’a pas installé automatiquement la mise à jour WordPress, arrêter de lire cet article immédiatement et effectuez cette mise à jour vous-même (c’est en effet très sérieux).
La vulnérabilité, qui affecte l’API REST de WordPress ajoutée dans la version 4.7, permet aux cybercriminels de modifier le contenu de n’importe quel site internet, et ce à distance.
Un bug comme celui-ci est une opportunité majeure pour les cybercriminels, et quand une vulnérabilité de la sorte est découverte au sein d’un CMS populaire, les attaques automatisées peuvent démarrer en quelques heures seulement !
Le problème a été découvert par Marc-Alexandre Montpas, de l’équipe securité web “Sucuri”, dans le cadre d’un projet de recherche sur les vulnérabilités.
Il a alerté l’équipe WordPress le 20 janvier et ils ont commencé à travailler sur un correctif, tout en surveillant bien évidemment l’activité du web en parallèle dans le monde entier, en alertant les éditeurs de logiciels de sécurité et les hébergeurs sur ce problème.
Une fois la mise à jour WordPress disponible, l’équipe WordPress a pris la décision de déployer le correctif sans communiquer sur les détails, dans un premier temps du moins, se donnant ainsi une longueur d’avance sur les cybercriminels qui auraient pu l’exploiter :
Le mercredi après-midi suivant, la plupart des hébergeurs avec lesquels nous avons travaillé avaient des protections en place. Les données en provenance des quatre WAF (Web Application Firewall) et des autres hébergeurs WordPress n’ont montré aucun signe d’une exploitation de cette vulnérabilité à un quelconque endroit du globe. Par conséquent, nous avons pris la décision de retarder la divulgation de ce problème particulier, afin de donner du temps aux mises à jour automatiques pour s’exécuter et garantir que le plus grand nombre possible d’utilisateurs soient protégés avant que cette vulnérabilité ne soit rendue publique.
Une fois le processus de déploiement automatique suffisamment implanté, le correctif a été divulgué à l’occasion d’une mise à jour WordPress de sécurité.
Alex de WPMarmite met en garde
Comment fonctionne l’attaque ?
Une API (Application Programming Interface) est l’interface d’un programme informatique qui est destiné à être utilisé par d’autres programmes plutôt que par des utilisateurs. Ils permettent aux applications sur votre téléphone de mettre à jour votre compte Twitter, à votre réfrigérateur de parler à votre supermarché, ou encore à votre logiciel gérant votre temps de signaler à vos différents comptes ce que vous avez fait.
Contrairement aux interfaces graphiques utilisées par les utilisateurs, les API se composent d’un ensemble de lignes de commandes. La mode, à l’heure actuelle, pour les systèmes basés sur le web est de mettre en œuvre ces API en utilisant le protocole HTTP simple et sans état, un concept connue sous le nom de REST (Representational state transfer).
L’API REST de WordPress permet aux programmes informatiques autorisés d’accéder aux données de votre site, afin d’effectuer des tâches telles que la création, la mise à jour ou la suppression de messages WordPress.
Il fonctionne en recherchant des requêtes HTTP spécialement conçues et envoyées à des URL spécifiques ou à des endpoints. Le endpoint pour la création, la mise à jour ou la suppression de messages WordPress est : /wp/v2/posts/.
N’importe qui dans le monde peut demander n’importe quelle URL publique à n’importe quel site web (qui est l’acteur majeur du web, après tout). Ainsi les sites web doivent vérifier que les internautes ou les programmes envoyant des demandes à leurs APIs sont correctement authentifiés et autorisés à exécuter de telles commandes.
Ce que Montpas a découvert était certes une technique subtile, mais potentiellement dévastatrice pour contourner ces contrôles de sécurité.
Pour faire la démonstration de ce subterfuge, imaginons que nous avons un blog WordPress avec des milliers de messages et de pages. Tous les messages et pages WordPress ont des ID numériques et nous allons utiliser 1337 dans notre exemple.
Pour indiquer à WordPress quel message nous voulons modifier, nous ajoutons son ID à la fin du endpoint de l’API REST, et nous envoyons les données que nous voulons modifier à l’URL, qui effectue alors la création.
L’URL ou le endpoint concernant la mise à jour du message 1337 est donc : /wp/v2/posts/1337.
Vous pouvez également indiquer à WordPress l’ID du message que vous souhaitez modifier en ajoutant un paramètre id à l’URL, et la première découverte importante de Montpas était qu’en utilisant un paramètre id, il pourrait inciter WordPress à accepter un ID de message non numérique.
Vous allez voir pourquoi, dans un instant, cette possibilité de transmettre des ID non numériques est importante, mais pour le moment, sachez que si nous envoyons notre demande de mise à jour à /wp/v2/posts/1337?id=1337ISMYREALTARGET, WordPress 4.7.0 et 4.7 .1 accepteront 1337ISMYREALTARGET comme l’ID d’un message.
Bien sûr, WordPress ne permet pas à n’importe qui de modifier un message. Ainsi, après avoir accepté votre fausse ID, il vérifie si nous sommes autorisés à le modifier. Malheureusement, un bug subtil dans ce contrôle de sécurité permet à notre attaque de progresser un peu plus loin encore.
Il s’avère que si le post 1337ISMYREALTARGET existe et que vous n’avez pas l’autorisation de le modifier, vous serez bloqué dans votre progression, mais si le message n’existe pas (ce qui est impossible car tous les messages WordPress ont des ID numériques), vous êtes alors libres de continuer.
Après avoir dupé le gatekeeper, vos données progresse grâce à la méthode update_item de WordPress qui, comme vous pouvez vous y attendre, est le code qui met à jour réellement le message. Vous pouvez également vous attendre à ce que notre attaque échoue à ce stade, car même si nous sommes autorisés à mettre à jour 1337ISMYREALTARGET, nous ne pouvons tout de même pas changer un message qui n’existe pas !
Ce n’est pas un hasard si notre fausse ID commence par l’ID d’un message qui existe bien : 1337.
En effet, juste avant que WordPress ne récupère notre faux message pour l’afficher, il convertit (ou “cast”) l’ID en un nombre entier.
WordPress est codé en langage PHP et la fonction cast PHP va convertir notre ID non-existante 1337ISMYREALTARGET en une ID on ne peut plus existante, à savoir 1337, et nos mises à jour seront alors appliquées au niveau de cette dernière.
Bien sûr, nous n’avons pas besoin de limiter notre attaque à un seul message. Nous pouvons facilement écrire un programme en boucle, qui balaie tous les numéros de 1 à 9999999, et met à jour chaque message et chaque page d’un site, afin d’intégrer par exemple un spam SEO, une publicité ou un malware de notre choix.
Nous pouvons également utiliser cette attaque comme un point de départ pour exploiter d’autres vulnérabilités, comme l’explique Montpas d’ailleurs :
A partir de là, ils peuvent ajouter des shortcodes spécifiques à des plugins, afin d’exploiter des vulnérabilités (qui autrement seraient limitées à des rôles secondaires) … Selon les plugins activés sur le site, même le code PHP peut être exécuté très facilement.
La prochaine étape ?
Si vous utilisez un site WordPress, vérifiez que vous exécutez la dernière mise à jour WordPress en vous connectant et en allant sur Tableau de bord/D’un coup d’œil.
Si vous voulez savoir comment WordPress a réglé le problème, et si la lecture de code ne vous impressionne pas, vous pouvez vous immerger dans le monde merveilleux du logiciel open-source en visualisant les modifications sur le site WordPress Trac.
En revanche, si vous n’êtes pas prêt pour ce genre de littérature, jetez un œil à 73% de sites WordPress vulnérables aux attaques.
Billet inspiré de Critical WordPress update fixes zero-day flaw unnoticed, par Mark Stockley, Sophos NakedSecurity.
