WordPress : Plus de 90 000 sites et blogs seraient victimes d'attaques lancées par quatre groupes de hackers

WordPress : Plus de 90 000 sites et blogs seraient victimes d'attaques lancées par quatre groupes de hackers,
altérant ainsi leur contenu

Nous vous annoncions récemment que la version 4.7.2 de Wordpress a été libérée en urgence afin de corriger trois failles de sécurité dont une faille de type injection SQL et XSS (Cross-site scripting). En effet, cette nouvelle version est sortie juste deux semaines après que l'équipe de WordPress avait annoncé la disponibilité de la version 4.7.1 de son système de gestion de contenu (CMS en anglais) qui intègre la correction de huit (8) failles de sécurité et plusieurs bogues estimés à 62.

D'après les informations recueillies, la dernière version de WordPress en l'occurrence la version 4.7.2 n'a pas permis de corriger les failles de sécurité sur les versions antérieures au 4.7. Selon le cabinet de sécurité Sucuri, l'ensemble des sites et blogs qui n'ont pas encore fait l'objet de mise à jour sont exposés à une vaste campagne d'attaques par injection SQL qui seraient lancées par quatre groupes de hackers. Sucuri affirme qu'en exploitant les failles de sécurité, les hackers sont en mesure de changer le contenu des sites ou blogs infectés ainsi que le titre des pages, cela en y ajoutant des images et leur nom. Aujourd'hui, Google a déjà référencé plus de 90 000 sites déjà infectés via les attaques de l'un des groupes les plus actifs. Pour s'en assurer, il suffit de taper « by w4l3XzY3 » sur le moteur de recherche de la firme de Mountain View.

Pièce jointe 242661

Sucuri nous informe que les adresses IP utilisées par le groupe de hackers w4l3XzY3 sont les suivantes :

• 176.9.36.102 ;
• 185.116.213.71 ;
• 134.213.54.163 ;
• 2A00: 1a48: 7808: 104: 9b57: dda6: eb3c: 61e1.

Quant aux trois autres campagnes lancées par les groupes de hackers Cyb3r-Shia, By+NeT.Defacer et By+Hawleri_hackequi, Google a référencé près de 500 victimes pour chacune d'elles. Sucuri lui a identifié les adresses IP ci-après :

• 37.237.192.22 ;
• 144.217.81.160.

« WordPress dispose d'une fonctionnalité de mise à jour automatique activée par défaut, en même temps qu'une procédure de mise à jour manuelle en un clic. Malgré cela, plusieurs personnes ne sont pas au courant de ce problème qui affecte l'API REST ou ne sont pas en mesure de mettre à jour leur site. Cela conduit à un grand nombre de sites compromis et altérés », a déclaré Sucuri.

Face à ces menaces, le cabinet de sécurité Sucuri invite tous les utilisateurs à procéder à la mise à jour de leur système de gestion de contenu (CMS). Il est également recommandé de bloquer les adresses IP citées ci-dessus.

Source : Sucuri

Et vous ?

:fleche: Que pensez-vous de cette vulnérabilité ?
:fleche: Avez-vous déjà été infectés ?
:fleche: Avez-vous procédé à la mise à jour de votre version de WordPress ?

Voir aussi
:fleche: WordPress sort en urgence la mise à jour 4.7.2 pour corriger trois failles de sécurité incluant une faille de type injection SQL et XSS

Ca me fait pensé que récemment j'ai reçu un mail de Google Search Console me disant que mon site wordpress présentait une vulnérabilité lié au fait que je n'était pas en version 4.7.2 et me mettant a dispo des liens pour tester la sécurité et savoir comment s'en prémunir.

Ca faisait très pro, sauf que :

- mon site avait déjà ete mis a jour 2h avant
- l'adresse email d'ou cela vient est assez étrange : sc-noreply@google.com
- il n'y avait aucune relation entre mon mail sur lequel j'ai recu ce mail et mon site.

Il est très facile de générer une entête de mail pour usurper n'importe quel adresse mail, et j'imagine que si j'avais utiliser les liens j'aurais eu des souci.

donc gaffe aux mail de google search console :

voila ce qu'on trouve sur le web : https://blog.sucuri.net/2015/09/mali...fications.html au sujet de ce mail sc-noreply@google.com

Du coup ça concerne juste l'api XML rpc ?

Citation:

---

Envoyé par Aiekick

Ca me fait pensé que récemment j'ai reçu un mail de Google Search Console me disant que mon site wordpress présentait une vulnérabilité lié au fait que je n'était pas en version 4.7.2 et me mettant a dispo des liens pour tester la sécurité et savoir comment s'en prémunir.

Ca faisait très pro, sauf que :

- mon site avait déjà ete mis a jour 2h avant
- l'adresse email d'ou cela vient est assez étrange : sc-noreply@google.com
- il n'y avait aucune relation entre mon mail sur lequel j'ai recu ce mail et mon site.

Il est très facile de générer une entête de mail pour usurper n'importe quel adresse mail, et j'imagine que si j'avais utiliser les liens j'aurais eu des souci.

donc gaffe aux mail de google search console :

voila ce qu'on trouve sur le web : https://blog.sucuri.net/2015/09/mali...fications.html au sujet de ce mail sc-noreply@google.com

---

Si t'as un compte sur Google Webmasters avec ton domaine associé, ça arrive que leur robot rapporte des erreurs : augmentation soudaine de 404, formulaire de connexion pas en HTTPS, pages mobiles foireuses, etc.

oui mais la apparemment c'était un faux mail pour phishing

J'inspecte toujours les liens avant de cliquer. Jamais trop prudent. :(

Apres recherche sur google, on est passé à 269 000 sites.

Les pirates commencent à exploiter la faille de l’API REST de WordPress pour arnaquer les utilisateurs,
plus d’un million de sites sont vulnérables

Au début du mois de février, plus d’un million de sites web WordPress ont fait les frais de plusieurs campagnes de défaçage. Des pirates ont exploité une faille de l’API REST présente dans les versions 4.7 et 4.7.1 du CMS WordPress afin de modifier les publications sur les sites gérés par le CMS, défigurant ainsi ces sites vulnérables. Ces campagnes de défaçage étaient si intenses qu’il a même été rapporté que plus de 90 000 pages web ont été défacées par seulement quatre groupes de hackers. Et dans plusieurs cas, l’on notait même que certains pirates écrasaient les défaçages effectués par d’autres pirates afin de laisser leurs propres empreintes sur ces sites exposés.

Pour mieux comprendre comment ces pirates sont parvenus à défigurer autant de sites avec succès, il faut savoir que l'API REST introduite dans les versions 4.7 et 4.7.1 permet d’afficher, de modifier, de supprimer ou de créer des publications. Vu qu’elle est activée par défaut dans ces deux versions, les pirates envoient simplement une charge utile (code malicieux) vers l’API REST, ce qui leur permet d’élever leurs privilèges et de modifier les publications sur les sites WordPress vulnérables. Selon Logan Kipp de l’entreprise de sécurité SiteLock, son « confort d’exécution est si faible et si facile que nous voyons des pirates amateurs prendre cet exploit et s’en donner à cœur joie ». Cette faille a même été exploitée en exécutant du code à distance sur ces sites ayant les plug-ins Insert PHP, Exec-PHP ainsi que d’autres plug-ins similaires. En principe ces plug-ins permettent aux utilisateurs d’insérer directement dans les publications du code PHP afin d’effectuer plus facilement des personnalisations. Aussi, en couplant cette faille à ces plug-ins, les attaquants sont en mesure d’exécuter du code PHP tout en injectant du contenu dans les bases de données.

Même si ces campagnes sont assez persistantes, certains experts expliquent qu’elles ne durent pas longtemps, car les pirates trouvent difficilement les moyens de tirer des avantages pécuniaires. Toutefois, depuis quelques jours, l’on note une escalade dans les pratiques de ces tiers malveillants. En effet, ces derniers ont commencé à chercher les voies et moyens pour se faire de l’argent en exploitant cette faille. La trouvaille qu’ils ont eu à faire est de mettre sous les mots laissés sur les sites défigurés des liens renvoyant vers un site de pharmacie en ligne proposant un médicament pour lutter contre le dysfonctionnement érectile. SiteLock qui en a fait la découverte explique que si un internaute venait à entrer ses identifiants de carte de crédit afin d’acheter ce produit, ses identifiants seraient enregistrés et utilisés par ces pirates pour faire des achats ou vendus à d’autres personnes dans le pire des cas.

Pour se prémunir contre ses attaques, il est fortement conseillé de faire la mise à jour de WordPress en passant à la version 4.7.2 disponible depuis le mois de janvier. En principe, les CMS WordPress des utilisateurs devraient être à jour, car la mise à jour automatique est activée par défaut dans le produit. Mais si, comme le souligne Kaspersky, plus de 1,5 million de sites web sont encore exposés à ces attaques, c’est que les utilisateurs ont certainement préféré désactiver cette fonctionnalité.

Pour celui qui fait face à ce cas de défaçage de son site ou un site tiers, il est recommandé, en attendant de faire la dernière mise à jour, de le traiter comme s’il avait affaire à une à l’exploitation d’une vulnérabilité de type XSS en faisant le ménage au niveau des valeurs pointant vers le contrôleur de l’API.

Source : SiteLock, Kaspersky

Et vous ?

:fleche: Que pensez-vous de cette situation vu qu’un correctif est déjà disponible ?

:fleche: Est-ce de la négligence de la part des utilisateurs de WordPress ?

Voir aussi

:fleche: WordPress sort en urgence la mise à jour 4.7.2 pour corriger trois failles de sécurité incluant une faille de type injection SQL et XSS
:fleche: WordPress : Plus de 90 000 sites et blogs seraient victimes d'attaques lancées par quatre groupes de hackers altérant ainsi leur contenu
:fleche: WordPress est de loin le CMS le plus ciblé par les cyberattaques en grande partie en raison du mauvais entretien et la négligence des webmasters

:fleche: La Rubrique Web, Forum Sécurité Web, Cours et tutoriels Web, FAQ Web

Voila pourquoi j'évite autant que possible l'utilisation de CMS, toujours à la merci d'une faille que peut ne pas être comblée rapidement :?

371 000 résultat ce matin !


Je l'ai vu à mainte reprise, souvent des "développeur" propose la mise en place d'un site pour quelques centaine d'euros, en posant un wordpress, un thème gratuit et hop, c'est en place.
Au départ tout est à jours (et encore pas toujours), mais avec le temps, aucun suivi n'est fait et le propriétaire n'y connaissant rien, pense que tout est OK et ne se doute même pas que leur site n'est pas à jour et sécurisé.

Vrai question, un webmaster peut il est inquiété pour ce genre de chose ? Même si il n'est pas sous contrat, doit il avoir un devoir de morale envers ses clients ?

S'il n'est pas sous contrat, que le client n'a pas payé pour de la maintenance, on ne peut rien reprocher au développeur. Il ne va pas bosser gratuit non plus...
Par contre il a un devoir de conseil, il doit avertir son client qu'il existe toujours un risque d'exploitation de failles, notamment si on n'est plus à jour, qui est plus répandu avec un CMS qu'avec une solution développée, au client de faire son choix (c'est pas le même tarif). Il y a certains clients qui demandent qu'on leur mette en place le site, et ensuite ils font eux-même les mises à jour, donc la maintenance n'est pas de la responsabilité du développeur.

Citation:

---

les pirates envoient simplement une charge utile vers l’API REST, ce qui leur permet d’élever leurs privilèges

---

Ca consite en quoi, quelqu'un sait m'expliquer ?

La charge utile ou "payload", c'est du code exécutable sous forme de texte qu'on fait passer par une faille de sécurité (un dépassement de tampon ou "overflow" la plupart du temps) et qui s’exécute sur la machine de la victime.
Comme le code n'est pas attendu par la machine, il est exécute sans contrôle de l'OS et obtient tous les droits sur le système.
La plupart du temps, les payloads sont très petits et permettent uniquement de créer une connexion avec la machine de l’attaquant qui reçoit un accès root par une connexion tcp.
Les firewalls standards n'aident pas car la demande de connexion vient de la machine de la victime et le firewall laisse passer les connexions dans ce sens là.

Pas la peine de jeter la pierre aux developpeurs du CMS. Combien d'entreprises ont des developpeurs qui comprennent techniquement a peine ce qu'ils font et autorisent ce genre de trous de securité.
J'ai tendance a croire que l'efficacité a resoudre ce probleme est meilleure sur des CMS que sur des applis "maisons" pour lesquelles toutes les securité de base sont souvent omises parce que codé a l'arrache. Au moins le CMS fait deja un minimum.
Ce sont souvent les logiciels les plus populaires qui sont attaqués; ca ne veut pas dire pour autant qu'ils sont codés avec les pieds. Bon ok ils en ont trouvé une qui sera patchée et basta. On a eu le cas recemment avec Mongodb ou là c'etait plus grave puisqu'il s'agissait de vidage de BDD complet ! Là c'est plus problématique.

Citation:

---

Envoyé par kilroyFR

Pas la peine de jeter la pierre aux developpeurs du CMS.

---

D'accord avec toi, quand j'entends le mot développeurs, je comprend quelqu'un qui maitrise, ou connait un minimum.
Je parlais plus précisément des personnes qui n'y connaissent strictement rien et qui utilisent ces CMS pensant cela sûre et utilisent moulte plugins pour faire "beau".

Après ce n'est que mon avis, mais j'ai tendance à penser que plus on utilise de plugins externe, plus le risque de faille est important.

Allez, voici un exemple que je donne sur l'opérateur ternaire à "utiliser avec parcimonie" = une seule fois à mes étudiants.
Le code source officiel de Wordpress, ligne 600 :
https://github.com/WordPress/WordPre...list-table.php

Code:

---

( ( ( 'approve' === $action || 'unapprove' === $action ) && 2 === $i ) || 1 === $i ) ? $sep = '' : $sep = ' | ';

---

Ce code est impossible à comprendre donc impossible à déboguer.
Oui oui c'est bien dans l'administration. Dossier wp-admin.

Sur les lignes qui suivent, une fois un if avec accolades, une fois sans, une fois l'utilisation des guillemets, une fois des côtes, les lignes suivants sont des aberrations.

Sérieusement, si on accepte de garder du code aussi pourri dans le coeur même de Wordpress, ne peut-on pas s'attendre au pire ?

La seule chose amusante en se balladant dans le code source, c'est qu'on peut presque voir le profil des développeurs : "tiens, là il y avait un bon", "tiens, là c'était un débutant", "tiens, là des gifles se perdent".

Isoler une ligne de code de son contexte la rend forcément incompréhensible pour ceux qui ont un peu de mal avec les raisonnements abstraits, même quand celle ci est extraite d'un "bon" code.

Je ne vois pas pourquoi l'opérateur ternaire devrait être utiliser avec parcimonie. C'est une structure simple qui tient sur une ligne et qui ne nécessite pas que l'on se ballade sur des dizaines de fichiers pour en comprendre l'utilité.
L'utilisation qui en est faite est peu orthodoxe de mon point de vue mais dans la mesure ou le code fonctionne il est évident qu'il s'agit d'un "if-else" sur une ligne de plus, allez comprendre pourquoi, les types qui conçoivent les tests d'embauche sont friand d'utilisation non orthodoxes de features... Le seul reproche que je pourrais faire à cette utilisation c'est que l'affectation de variable ne saute pas aux yeux quand on est pressé mais je tends à me concentrer assez vite sur les éléments de code qui posent problème et à négliger même les structures utilisée de façon classique. Sans regarder le reste du code (dois aller bosser), si d'aventure j'ai besoin de savoir à quoi sert la variable $sep qui l'affectation conditionnel à la valeur "|" m'indique qu'il s'agit probablement du $sep de "separator" probablement une construction de chaine qui compte, séparation présumée nécessaire quand la variable $i (incrément contextuelle ?) est égale à 2 ...

Bonjour,

La vulnérabilité de Wordpress est elle également effective pour une version du CMS plus ancienne que la 4.7 ou 4.7.1 (exemple 4.3.8) ?

Cordialement,

Citation:

---

Envoyé par psykokarl

Isoler une ligne de code de son contexte la rend forcément incompréhensible pour ceux qui ont un peu de mal avec les raisonnements abstraits, même quand celle ci est extraite d'un "bon" code.
Je ne vois pas pourquoi l'opérateur ternaire devrait être utiliser avec parcimonie.

---

Euh t'es vraiment en train de dire que un ternaire dans un ternaire dans un ternaire c'est pas gênant pour comprendre un code ? Sérieusement ? :pan:

T'es vraiment le genre de personnes qui disent "ah bah allez, fumer une cigarette de temps en temps c'est pas grave rôooooooooh"...

Je suis peut être un peu extrémiste et comme je n'ai jamais fumé de ma vie (véridique, je ne fais jamais quelque chose juste "pour faire comme tout le monde" (90% des fumeurs le font)), j'ai tendance à me comporter pareil pour le code : un ternaire dans un ternaire dans un ternaire est incompréhensible, et si un type met ça comme code c'est forcément que ça ne le dérange pas d'avoir du bordel. Et forcément, le bordel, tout le monde en pâtit, tôt ou tard. Mais là non seulement je suis un peu extrémiste mais aussi vieux, et c'est mon expérience qui parle.... ;)

@SurferIX : il n'y a qu'un seul ternaire dans cette chaîne, pas trois.
Et pour ma part, je comprend très bien la chaine, même sans avoir vu le code autour. Elle permet de ne pas afficher de séparateur suivant le compteur d'itération et l'action affichée ou demandée. Si tes étudiants ont du mal à comprendre cela, j'imagine le carnage quand tu abordes les expressions régulières ou les variables dynamiques.

La même chaîne avec des AND, OR et en remplaçant le seul opérateur ternaire

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

IF ( (( 'approve' === $action OR 'unapprove' === $action ) AND 2 === $i ) OR 1 === $i ) { $sep = ''; } ELSE { $sep = ' | '; }

---

Bref, y'a rien d'incompréhensible.


Pour n'importe quel CMS du marché, si tu parcoures le code tu trouveras des différences dans la manière de programmer, c'est humain.

Je ne vois effectivement pas du tout ce qu'il y a d'incompréhensible dans cette ligne. Et de savoir que c'est un "prof" qui dit ça, ça fait peur pour les étudiants !