La semaine dernière, les développeurs de CMS Drupal ont fermé (l'
actualité , plus de détails
sur leur site web ) deux vulnérabilités critiques
à la fois. Les deux problèmes affectent les versions Drupal 7.x et 8.x. La vulnérabilité la plus grave a été découverte dans le système d'envoi d'e-mails intégré (DefaultMailSystem :: mail ()). Vous pouvez l'utiliser de telle manière que lors du traitement d'un message, il devient possible d'exécuter du code arbitraire. La raison en est, comme d'habitude, le manque de vérification appropriée d'un certain nombre de variables.
La deuxième vulnérabilité a été découverte dans le module Liens contextuels - elle vous permet de modifier les éléments des pages Web sans passer par le panneau de configuration. L'absence de vérification des paramètres passés lors de l'exécution d'une telle requête peut également conduire à l'exécution de code. Certes, contrairement à la première vulnérabilité, cela n'est exploité que si l'attaquant a déjà le droit de modifier le site.
De telles nouvelles ne tombent généralement pas dans le résumé: bien, trouvées, bien fermées, bien faites! Mais au moins une fois par an, il vaut la peine d'examiner les systèmes de gestion de contenu les plus populaires et de comprendre à l'avenir comment les choses évoluent en matière de sécurité. Existe-t-il une fragmentation des versions CMS, similaire, par exemple, à la fragmentation de la plateforme Android? La sécurité est-elle si mauvaise, comme, par exemple, dans l'industrie de ces appareils IoT, qui ne semblent pas du tout être des appareils IoT, mais des routeurs et des caméras? Voyons voir.
Vous devez d'abord comprendre où chercher. Des informations suffisamment détaillées sur l'utilisation d'un CMS particulier fournissent
des enquêtes de technologie Web . Les auteurs de la ressource analysent régulièrement les 10 millions de sites les plus visités sur Internet (selon la notation du service Alexa) et analysent les systèmes de gestion de contenu utilisés. Les résultats généraux de l'étude peuvent être consultés
sur cette page , voici un graphique à partir de là:
Eh bien, premièrement, il n'a pas été possible d'obtenir des informations sur le CMS pour 46,1% des sites, plus précisément, aucun des systèmes que ce service peut identifier de manière fiable n'est utilisé. Parmi les sites où le CMS a été déterminé, le leader incontesté est Wordpress, une sorte de marché CMS Android. Les deuxième et troisième places avec un décalage important sont occupées par Joomla et Drupal, puis dans Top10 il y a principalement des services qui offrent la création d'un site fini sur leur propre plate-forme, pour ceux qui ont besoin plus facilement et plus rapidement. Ensemble, Joomla, Drupal et Wordpress sont installés sur 68,8% des sites avec un CMS bien connu, soit 37,2% de tous les sites sur les 10 millions étudiés.
La fragmentation est déjà évidente au niveau du choix du CMS: Wordpress est le leader incontesté, mais il n'est installé que sur un tiers des ressources en ligne, et la moitié des sites en général fonctionnent pour une raison quelconque. Peut-être qu'un administrateur sombre télécharge toujours du HTML statique via FTP old-school. Il est difficile de tirer des conclusions de cette variété: d'une part, la fragmentation complique la vie de l'attaquant, d'autre part, personne ne sait vraiment comment sont les choses avec la sécurité d'environ la moitié d'Internet. En cryptographie, les algorithmes de chiffrement auto-écrits ont longtemps été assimilés à un râteau plus net. La gestion Web devrait-elle être différente?
Examinons la distribution des versions des trois CMS les plus populaires. Voici la distribution pour Wordpress. w3techs met à jour ses rapports quotidiennement afin que les informations soient les plus récentes.
Quelque part ennuyeux même. Examinons les détails de la version actuelle 4.x:
Un peu plus de 70% des sites Web Wordpress utilisent (à la date de publication) la version la plus récente (à l'exclusion des mises à jour régulières de la version principale). Il s'agit bien sûr d'une distribution plus agréable qu'Android, où la version actuelle 8.x est
utilisée par 19,2% des appareils, mais pas autant que nous le souhaiterions.
Y a-t-il quelque chose à craindre? Regardons l'
histoire des versions de Wordpress. La version 4.9 est sortie le 15 novembre 2017, c'est-à-dire que depuis presque un an Wordpress 4.8 et les versions antérieures sont obsolètes. Depuis la version 4.9, au moins quatre mises à jour du CMS visaient à corriger des vulnérabilités. La gravité du risque de chacun d'eux fait l'objet d'une étude plus détaillée, bien qu'il n'y ait eu aucun bogue absolument critique au cours de la dernière année. Néanmoins, la
version 4.9.7 de juillet ferme la vulnérabilité, sous certaines conditions, vous permettant de supprimer des fichiers en dehors du dossier Uploads.
Voyons comment va le héros de la semaine dernière - CMS Drupal.
De telles choses. La dernière version de Drupal 8.x est utilisée par 11,8% des sites qui utilisent généralement Drupal. La version la plus populaire est la précédente version 7.x (en toute équité, notons-le - prise en charge). W3techs ne fournit pas de détails sur des versions spécifiques au sein de la branche principale, alors supposez que tout le monde a déjà été mis à jour (c'est bien sûr une hypothèse audacieuse). Dans tous les cas, près de 10% des sites Drupal utilisent des versions non prises en charge 4.x - 6.x.
La situation de CMS Joomla est la suivante:
La version actuelle de Joomla 3.8.13 a été publiée récemment - le 9 octobre. Vous pouvez voir combien de sites ont été mis à jour vers la dernière version en si peu de temps.
14,1% de tous les utilisateurs de la succursale 3.8. Ou 5,8% de tous les utilisateurs de Joomla sont ceux qui ont réussi à mettre à niveau le site vers la dernière version en 13 jours. Quelles sont les conséquences si vous ne mettez pas à jour le CMS à temps? Je vais revenir à des exemples pour Wordpress, car il s'agit à la fois du système de gestion de contenu Web le plus populaire et le plus piraté. Donc (soudainement), les messages sur le détournement pratique de sites pour activités malveillantes ne mentionnent pour la plupart pas le code principal de Wordpress, mais ses plugins.
Par exemple, les
informations de l'année dernière sur les plugins vraiment attaqués, y compris, par exemple, le plugin Flickr Gallery. En décembre 2017, Wordpress a
bloqué trois autres plugins - tous ont été vendus par les créateurs, et les nouveaux propriétaires y ont implémenté des portes dérobées. Voici une autre
analyse de l' utilisation de plugins abandonnés depuis longtemps par les développeurs, présentant des vulnérabilités critiques et toujours utilisés sur des centaines de sites.
Et ce n'est pas seulement des plugins. À plusieurs reprises, un mot de passe bruteforce est mentionné comme méthode de travail pour attaquer les sites Wordpress (par exemple,
ici et
ici ). Et ce problème dépasse également les capacités des développeurs Wordpress. Compliquer la bruteforce et ne pas utiliser les mots de passe les plus simples est la tâche de l'administrateur et des utilisateurs des sites, pas des développeurs.
Que se passe-t-il lorsqu'un site est piraté avec succès? Ci-dessus, je me réfère aux nouvelles concernant l'installation de mineurs, bien que le plus souvent des scripts malveillants classiques apparaissent sur les sites. Un cas significatif s'est produit cet été: en juillet, la plateforme de trading CoinDash a d'ailleurs été
piratée lors de la levée de fonds dans le cadre de l'ICO. La manière exacte dont le site a été piraté n'est pas signalée, il ne peut pas nécessairement s'agir d'une vulnérabilité dans Wordpress. Mais le résultat est évident: dans la première phase de collecte de fonds auprès de participants privilégiés sur le site, ils ont simplement changé le numéro de portefeuille pour le transfert de fonds, à la suite de quoi 7,7 millions de dollars en équivalent de crypto-monnaie sont allés aux attaquants. Il y a une
discussion intéressante sur Reddit à ce sujet: ne sera-t-il pas plus fiable de créer une page statique dans les cas critiques? Oh, je ne sais pas ce qui est le plus fiable.
Sur la base des résultats de cette mini-étude, une question claire se pose: est-il vraiment nécessaire de mettre à jour le code CMS, si les vulnérabilités critiques ne sont pas toujours disponibles, les sites sont souvent piratés via des plugins, ou même par force brute de mot de passe? Comme dans le cas des
routeurs , un ensemble de mesures apporte de réels avantages: la mise à jour du CMS, la révision de la liste des plugins installés et la mise à jour régulière de ceux vraiment nécessaires, la modification de l'URL d'administration, des mots de passe forts, l'authentification multifacteur et juste l'audit des utilisateurs. La sécurité du site Web (et toute autre chose) est un processus, pas un résultat.
Ajouter à la liste des tâches une vérification régulière de la version CMS n'est pas si difficile. Si votre site est géré par une organisation tierce, il ne sera pas superflu de discuter séparément du problème de l'installation régulière des mises à jour. Si vous avez "créé un site" une fois et que, depuis, cela "fonctionne" sans aucune assistance, vous avez des problèmes. Comme nous l'avons vu aujourd'hui, même tout le monde n'utilise pas une mesure aussi simple pour améliorer la sécurité d'un site Web que la mise à jour d'un code.
Avis de non-responsabilité: les opinions exprimées dans ce recueil ne coïncident pas toujours avec la position officielle de Kaspersky Lab. Chers rédacteurs recommandent généralement de traiter toute opinion avec un scepticisme sain.