Génération de pages malveillantes sans fin...

[Sly74]

Bonjour,

Depuis juin, je suis maintenant la cible d'une attaque massive.

Les urls ont ces formats (entre autres):
/jwxxb/b1227289.html
/tag/qeifz

Il semble s'agir de liens cloacking à priori. Sur mon site, il y a 21 pages et actuellement, GSC me donne 1'280 liens indexés (et la totalité mes 21 pages n'y figurent même pas) et 155'000 liens non indexés (2000 crées en l'espace de 2 jours...). Le trend de ces dernière est toujours en hausse pour les erreurs 404 (dernier crawl 29 octobre). Par contre, des pages réellement indexées, les dernières malveillante datent du 26 juin.

Afin de contrer la problème, j'ai filtrés les pages qui posent problème dans mon htaccess de cette manière:

RewriteEngine On
RewriteRule ^[a-zA-Z]{5}/[a-zA-Z0-9]{7}\.html$ - [G]
RewriteRule ^[a-zA-Z]{5}/[a-zA-Z0-9]{8}\.html$ - [G]
RewriteRule ^tag/[a-z]{5}$ - [G]
RewriteRule ^[a-zA-Z]{5}\.html$ - [G]
RewriteRule ^config/entry/review/add/product_id/ - [G]
RewriteRule ^a2f6product/product_id/ - [G]

J'ai également fournis un sitemap pour le français et l'anglais dont google semble ne pas tenir compte car depuis le 7 octobre, il n'a toujours pas indexés mes véritables pages. D'après mon access.log, google semble bien passer ces pages en 410:

66.249.72.232 - - [01/Nov/2024:00:35:05 +0100] "GET /kyewj/z1799181.html HTTP/1.1" 410 1104 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P)

Comme l'attaque semble continuer, j'aimerai savoir si c'est la une bonne méthode ? Est-ce mieux d'ajouter une règle de ce type pour ajouter noindex à ces pages ?

<IfModule mod_headers.c>
RewriteCond %{REQUEST_URI} ^/[a-zA-Z]{5}/[a-zA-Z0-9]{7}\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/[a-zA-Z]{5}/[a-zA-Z0-9]{8}\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/tag/[a-z]{5}$ [OR]
RewriteCond %{REQUEST_URI} ^/[a-zA-Z]{5}\.html$
Header set X-Robots-Tag "noindex"
</IfModule>

J'ai un peu de peine à trouver une solution pérenne, car j'imagine qu'avec ce code, google ne reviendra pas effacer toutes ces pages frauduleuses déjà indexées.

De plus, cela ne permet pas de trouver la source de spamming et de l'éliminer et il en arrive sans arrêt (2000 en 2 jours...)! Qu'elles ne soient pas indexées n'enlève rien au fait que google les détectes comme des 404 dans le gsc (non 410).

Quel intérêt de continuer cette attaque sachant que les liens ne sont plus indexés et que mon site est déjà aux pâquerettes ?

Merci pour votre aide,
Sylvain

 

[cthierry]

Ton site me fait penser à cela : https://www.eskimoz.fr/japanese-keyword-hack/ et je vois bien que tes pages renvoient un 410 gone. Déjà bien vérifier que tu n'as plus d'invités sur tes fichiers déjà pour commencer.

 

[emualliug]

Afin de contrer la problème, j'ai filtrés les pages qui posent problème dans mon htaccess

Il faut que tu identifies ce qui créée ces pages, leur exploration et indexation par Google n'est qu'un problème secondaire.

D'abord parce que tu as une faille de sécurité sur ton site, et qu'il ne faut pas la laisser béante et exploitée.

Mais ensuite parce que tu ne fais qu'envoyer un code d'erreur à qui viendra explorer la page. Ça implique que la page est consultée (donc potentiellement de la ressource consommée). Ça donne le site que le site est rempli d'URL abandonnées.

D'après mon access.log, google semble bien passer ces pages en 410

Le log te dit ce qui est envoyé au robot d'exploration, il ne t'assure pas de la façon dont Google appréhende ces pages. Il est toutefois probable que Google interprète bien l'URL en 410 (si c'est ce que lui dit le serveur), mais le log en lui-même ne permet pas de t'en assurer.

Quel intérêt de continuer cette attaque

La plupart des attaques reposent sur le nombre plutôt que sur la qualité. Rechercher comment ton site contourne la création de page supposerait d'y consacrer des ressources (checker le code HTTP de l'URL), ils n'y consacrent probablement pas de moyens.

 

[Sly74]

Bonsoir,

Merci à vous pour votre retour. Il m'est difficile de juger de l'efficacité de wordfence, malcare, ainsi qu'un antivirus de mon hébergeur; infomaniak, mais tous me disent que le site est propre et qu'il n'y a rien de suspect. Comment aller plus loin pour découvrir cette faille ?

C'est exactement du japanese-keyword.hack. Mais si les liens sont générés à la volée, comment identifier la source. Lorsque je check mon access.log, c'est quasiment toujours les googlebot qui tentent de crawler ces pages frauduleuses mais d'où lui proviennent elles ?

Dans la GSC, les back links sont propres également.

 

[pomination]

Bonjour,
Quelque chose que je ne comprends pas : si le log indique que le bot crawle la page, c'est donc qu'elle existe bien sur le serveur ?
Si on appelle une de ces URL bidons (non filtrées par .htaccess) elles répondent ?

 

[eldk]

Bonsoir,

Lis cela : https://web.dev/articles/fix-the-japanese-keyword-hack?hl=en - tu peux essayer avec hl=fr mais c'est traduit très approximativement.

Et suis les étapes une à une : je pense que tu n'y coupes pas. C'est fastidieux ... Voir également "additional ressources" en bas de page.

Pour ma part, si c'est possible, j'essaierai de bloquer l'accès au serveur/site avec une simple demande de mot de passe d'abord - genre mot de passe apache ou - carrément un "deny from all" sauf ta propre ip - pour être sur - voir avec ton hebergeur ou te faire aider. Parce que là, tu peux très bien nettoyer, et, te faire "hacker" de nouveau dans la foulée - sans idée du procédé utilisé tu peux tourner en rond longtemps.

Un simple :

```
require ip tonipv4 tonipv6
```

Placé au début de ton .htaccess devrait suffire - tout en haut - https://ip.lafibre.info/ - pour te protèger le temps d'éliminer les causes.

Si cela continu ... c'est que tu n'as pas trouvé ...

C'est peut-être un peu radical ? Qu'en pensez vous ?

Cordialement,

Eric

PS : tu peux aussi autoriser les bots Google à crawler : une liste figure ici : https://github.com/mitchellkrogza/a...pache_2.4/custom.d/globalblacklist.conf#L8445 ou leurs envoyer une 503.

 

[Sly74]

Bonjour à vous et merci pour votre aide!

Pour pomination, a vrai dire, c'est un des soucis de ce hack. Lorsque je check mon site avec screaming frog par exemple, il ne voit aucun erreurs 404 (ou 410).

Ces pages donnent, lorsque je les check, des erreurs 404 mais en réalité, c'est du cloaking (contenu caché) avec des produits généralement illégaux ou autres... Du coup, ces pages sont surement ailleurs, sur d'autres sites, peut-être des milliers... hyper complexe en fait!

Pour Eric, est-ce que ces pages sont générées par mon site ou d'autres ? C'est le gros point flou, je n'arrive pas à comprendre l'origine de cela. Donc, si je mets en place ta méthode, tu penses que ça permettra à 100% d'assurer que cela ne vient pas de mon site ? Je peux le faire en mutualisé et il me suffit de mettre "require ip monipv4 monipv6" au début de mon htaccess ?

Pour les nouvelles:

Je suis passé de 155'000 à 158'000 pages non indexées (grises) / de 1280 à 137 pages indexées (vert) ce weekend. Que dois-je en conclure ? L'infestation continue mais mes règles ont tendance à permettre la désindexation de pages frauduleuses...

Sinon question (bête), mes DNS étant gérés pas Cloudflare, j'ai plus vite fait d'étudier leurs logs que ceux de mon hébérgeur non ?

Merci et bonne journée à vous!
Sylvain

 

[emualliug]

est-ce que ces pages sont générées par mon site ou d'autres ?

Ce sont des pages de ton site, elles proviennent nécessairement de ton site (même si ton site peut appeler du contenu distant, ça reste produit par ton site).

Voici comment peut fonctionner ce type d'attaque : les fichiers de ton site sont modifiés de sorte à générer du contenu lorsqu'ils sont appelés avec une certaine URL. Derrière, ces URL sont diffusées sur d'autres site.

Mais le problème ce n'est pas la diffusion de ces URL, mais bien le fait que des fichiers aient été modifiés sur ton serveur pour permettre de répondre à ces URL.

 

[cthierry]

C'est en effet ce que je lui ai dit plus haut avec le lien concernant le japanese keyword hack. Le plus simple est de faire le tour de tous les répertoires, fichiers, dossiers et voir ceux qui ont une date de modification/création qui date du début de ton hack. Voir aussi si des fichiers n'ont pas du code qui commence, par exemple, par : 'base6'.'4'.'_de'.'code'; (il y a bien longtemps qu'ils ne mettent plus base64_decode lol). Tu peux aussi faire un check avec Sucuri, même si ce n'est pas fiable à 100%.

 

[emualliug]

qui ont une date de modification/création qui date du début de ton hack

Regarder les dates de fichier suspectes oui, mais pas nécessairement à l'apparition du hack, ça peut rester dormant quelques temps, justement pour éviter qu'une restauration soit efficace : le site est piraté le 1er du mois, les pages apparaissent uniquement à partir du 15, on tente une récupération le 30 en rétablissant la version du 14 (que l'on croit antérieure au hack), mais en fait il s'agit déjà d'une version vérolée. Je donne les dates en jour mais ça peut rester dormant plus longtemps.

 

[Sly74]

Merci pour vos éclaircissements!

Thierry, je pense qu'effectivement, si je n'arrive pas à trouver les failles, il faudra m'y résigner. Par contre, la réinstallation de fichiers par défaut sur un site, le mien tourne avec avada, autant refaire le site à zéro car j'imagine le nombre de bugs à régler par la suite...

Mais avant, j'essaie de fermer le plus de portes possibles pour tenter d'enrailler l'infestation. Le scan manuel... par ou commencer, j'ai des masses de résultats impossibles à traiter avec un base64_decode classique (la tienne est malheureusement introuvable), faire le tri dans tout ca... que pourrais je chercher de bien spécifique et avec quelles restrictions pour éviter de scanner la ou il n'y a pas besoin ?

Sinon, hier, j'avais des pics d'activités sur mon site. 3 ips chinoises que généraient du trafic anormal (mon site étant mort cliniquement depuis le hack). Ce trafic, parmi celui de mon hébergeur et de cloudflare, donnait un code de réponse NOERROR. Est-ce qu'on peut en déduire qu'elles avaient accès à mon site ?

Merci encore!

 

[cthierry]

Tu as essayé de scanner tout le site avec Sucuri pour commencer ? Il y a sans doute d'autres plugins disponibles je pense.

 

[elji]

C'est là que je suis content d'avoir créé mon propre CMS, c'est tout simple, j'ai peu de fonctions, mais je sais au moins que s'il y a un problème, je saurais l'identifier. J'ai ainsi un répertoire d'administration que je peux effacer sur le serveur, et remplacer par les fichiers propres de mon ordinateur. Il n'y a pas cela, là ? Je peux aussi faire cela avec l'intégralité du site. Il n'y a que s'il y avait un code malicieux dans ma BDD que je serais vraiment ennuyé.

 

[emualliug]

le mien tourne avec avada

Avada, c'est du WP. Alors, c'est forcément un peu l'enfer de réinstaller WP avec tous ses plugins, mais ça peut se faire, sans perdre sa config. Enfin, en théorie du moins, après je ne suis pas connaisseur de WP.

que pourrais je chercher de bien spécifique et avec quelles restrictions pour éviter de scanner la ou il n'y a pas besoin

@cthierry a fourni de bonnes pistes.

Si tu as accès aux fichiers avec un ftp (j'espère que c'est la cas, c'est le minimum sur un hébergement sérieux), tu peux voir la date de modification des fichiers. Il faut se concentrer sur les fichiers PHP. En principe, les fichiers d'un même dossier devraient avoir la même date. Un fichier avec une date isolée devrait attirer l'attention (ce n'est toutefois qu'un indice, il a pu être modifié de façon légitime).
Si tu as accès à un terminal sur ton serveur, tu peux lister les fichiers php avec leur date de modif avec (ça peut prendre un peu de temps à s'exécuter, c'est normal) :

find $1 -type f -name "*.php" -exec stat --format '%Y :%y %n' "{}" \; | sort -nr | cut -d: -f2-

je suis content d'avoir créé mon propre CMS

C'est à double tranchant. D'un côté on évite les failles utilisées en série. Plus de 99,9 % des tentatives d'attaque que je vois sont des tentatives à l'aveugle sur /wp-login.php, /wp-2020.php, /wp-admin/setup-config.php, /google.php, /default.php, /admin/controller/extension/extension/Not_Found.php, /modules/mod_simplefileuploadv1.3/elements/udd.php, /mad.php, /clen.php, /wp-admin/dropdown.php, /.well-known/pki-validation/about.php, /webadmin.php, /atomlib.php, bref un nombre considérable de tentatives, beaucoup sur du wordpress ou des plugin wordpress, y compris pour des URL qui n'ont jamais eu de WP installé.

D'un autre côté, on s'expose à des failles béantes, d'injection en tout genre, ou d'autres maladresses, parce que tout vigilant que l'on puisse être, quelque simple que le site soit, je m'estime toujours moins compétent que les type de chez WP.

Bref, potentiellement plus de failles, mais dont l'exploitation est moins probable.

Je dis ça, mais je suis de la team "fait maison". Faut quand même avoir en tête les inconvénients, et être scrupuleux sur les bases de la sécu.

 

[elji]

Je n'utilise pas WP, mais j'ai tous les jours des requêtes vers des pages /wp-admin... wp-login, je suis content qu'ils ne trouvent rien.