Une chose que l’on sait quand on écrit des règles dans un pare-feu ou dans les fichiers .htaccess, c’est de ne pas bloquer les moteurs de recherche comme Google, Bing, Yahoo etc.
Parfois lors des possibles scénarios qu’on doit imaginer pour trouver d’où vient l’attaque, comment elle est arrivée, il faut éplucher les logs. Et en découvrant ce genre de scénario, on a de quoi se prendre la tête entre les mains et se dire “Dois-je le bloquer ? Pourquoi lui ?”
Les requêtes GET
Jusqu’à ces jours récents, ce scénario n’avait pas encore été trouvé, divulgué et c’est par hasard, en épluchant les logs qu’un consultant en sécurité (source) a découvert que Google faisait des attaques SQL sur le site de son client. Il a bien sûr bloqué l’adresse IP pensant que c’était une fausse adresse, mais finalement, il s’est rendu compte que non, il s’agit bien de la véritable adresse du bot du géant Google.
[pastacode provider=”manual” lang=”markup” manual=”66.249.66.138%20-%20-%20%5B05%2FNov%2F2013%3A00%3A28%3A40%20-0500%5D%20%22GET%20%2Furl.php%3Fvariable%3D%22)%2520declare%2520%40q%25%0A20varchar(8000(%2520select%2520%40q%2520%3D%25200×527%2520exec(%40q)%2520–%20HTTP%2F1.1%22%20403%204439%20%22-%22%20%22Mozilla%2F5.0%20(compatible%3B%20Googlebot%2F2.1%3B%20%2Bhttp%3A%2F%2Fwww.google.com%2Fbot.html)%22″/]
Il s’agit réellement du Google Bot et il a réellement aussi réalisé cette attaque SQL injection via une requête en GET.
Alors Google s’est-il fait pirater ? L’adresse IP a-t-elle été usurpée ? Est-ce un clone du bot créé par un hacker ? Non pas du tout ! Regardons de plus prêt l’IP :
[pastacode provider=”manual” lang=”markup” manual=”%24%20host%2066.249.66.138%0A138.66.249.66.in-addr.arpa%20domain%20name%20pointer%20crawl-66-249-66-138.googlebot.com.%0A%0ANetRange%3A%20%20%20%20%20%20%2066.249.64.0%20-%2066.249.95.255%0ACIDR%3A%20%20%20%20%20%20%20%20%20%20%2066.249.64.0%2F19%0AOriginAS%3A%20%20%20%20%20%20%20%0ANetName%3A%20%20%20%20%20%20%20%20GOOGLE”/]
Ca ne ment pas, c’est bien Google ça …
Que se passe-t-il ?
Google n’a pas d’intérêt à lancer ces attaques sur les sites, par contre un pirate en a. Il va utiliser les bots pour dégrossir le travail d’attaque sans utiliser ses ressources serveurs, sans perdre le temps de le faire lui même, sans être vu, tracé par son adresse IP.
Dans ce scénario le bot crawlait le site A, celui du pirate. Ce site a un certain nombres de liens, certains pointent vers le site B, celui de la victime. Le pirate a simplement posé des liens contenant les tentatives d’exploit de la faille SQL injection, il compte alors sur les bots de Google pour visiter ces liens et donc, faire le sale travail pour lui ! Difficile de dire si c’est déjà arrivé auparavant, surement que oui mais qui a fait attention à ça.
Exemple de lien :
http://exemple.com/url.php?variable=”)%20declare%20@q%20varchar(8000(%20select%20@q%20=%200×527%20exec(@q)%20–
Le responsable
On ne peut pas dire que Google soit le responsable de ses attaques, finalement il ne fait que son travail de crawler vos sites et visiter les liens. Le responsable reste la personne qui a mis en place le piège et non celui qui l’actionne par mégarde ou ignorance.
Comment protéger votre WordPress ?
Alors que faire contre ça, comment éviter de recevoir ces attaques de la part d’un site auquel on donne toute sa confiance. Je pense qu’il ne faut pas mettre une liste blanche de sites au premier niveau. Il faut d’abord vérifier que la requête ne contienne pas de mots clés étranges comme ici exec, ou d’autres comme UNION, base64 etc
Pour cela, il existe le plugin BBQ qui bloque ces requêtes considérées comme malicieuse. Je vous invite à le tester.
