Le moteur de recherche Google utilisé pour des injections SQL

Un expert en sécurité présente un scénario d'attaque

Le 2013-11-06 16:59:43, par Hinault Romaric, Responsable .NET

Les pirates ne manquent pas d’idées pour parvenir à leur fin. Les robots d’indexation du moteur Google auraient été exploités par certains pour effectuer des attaques par injection SQL.

Qu’allez-vous faire si un robot d’indexation légitime de Google a été utilisé pour attaquer votre site ? Devrez-vous bloquer le bot (bloquant par la même occasion l’indexation de votre site), ou autoriser le trafic malveillant ?

C’est l’épineuse question à laquelle a été confronté le cabinet de sécurité Sucuri, suite à des activités louches sur le site d’un client. Après des investigations, Sucuri s’est rendu compte que le bot Google était à l’origine du problème.

Dans un billet de blog, Daniel Cid, PDG de Sucuri, présente de façon détaillée un scénario d’injection SQL (SQLI) en utilisant le bot Google. « Supposons que nous avons un hacker, son nom est John », écrit Cid.

John parcourt internet et retrouve suffisamment de données pour créer une attaque en direction du site B. John, qui n’est pas un novice dans le piratage, sait que pour mener une attaque réussie, vous devez effacer vos traces et empêcher qu’on remonte jusqu’à vous.

Très futé, plutôt que de lancer lui-même des requêtes vers le site B, John se contente de créer sur son site un lien comportant des attaques SQLI. Ensuite, il laisse la sale besogne aux robots d’indexation Google, ainsi qu'à ceux utilisés par les autres moteurs de recherche (Bing, Yahoo, etc.), car ils n’ont aucun moyen de savoir si le lien est mal-formé ou s’il est légitime.

Code :

1
2
3
66.249.66.138 - - [05/Nov/2013:00:28:40 -0500] "GET /url.php?variable=")%20declare%20@q%
20varchar(8000(%20select%20@q%20=%200x527%20exec(@q)%20-- HTTP/1.1" 403 4439 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Lorsque le responsable du site affecté se rendra compte de l’attaque, l’analyse de ses logs permettra de constater que l’injection SQL provient du bot Google.

Code :

1
2
3
4
5
6
7
8
$ host 66.249.66.138
138.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-138.googlebot.com.

NetRange:       66.249.64.0 - 66.249.95.255
CIDR:           66.249.64.0/19
OriginAS:       
NetName:        GOOGLE

Daniel Cid affirme dans son billet de blog avoir informé Google à ce sujet. Le géant de la recherche n’a pas encore fourni de réponse.

Source : Sucuri

Et vous ?

Qu'en pensez-vous ? Et si vous êtes face à une telle situation, comment allez-vous procéder ?

Discussion forum

11 commentaires

dahtah
Membre éclairé

C'est une tres vieille attaque connue depuis 2001, voir phrack.

Encore des gars qui decouvre l'eau chaude.

le 06/11/2013 à 18:31
DelphiManiac
Membre émérite

Envoyé par Hinault Romaric

Et vous ?

Qu'en pensez-vous ? Et si vous êtes face à une telle situation, comment allez procéder ?

Que la faille soit mise en évidence par un robot de google (ou n'importe quel robot) ou que l'exploitation de la faille provienne d'une adresse IP lambda, faille il y a.

La seule solution, corriger la faille !!

le 06/11/2013 à 17:40
TNT89
Membre confirmé

Question très bête : les bots de Google ne trimbalent pas un HTTP_REFERER comme tous les autres clients?

le 06/11/2013 à 21:15
grunk
Modérateur

Qu’allez-vous faire si un robot d’indexation légitime de Google a été utilisé pour attaquer votre site ? Devrez-vous bloquer le bot (entraînant par la même occasion l’indexation de votre site), ou autoriser le trafic malveillant ?

Dans la logique on corrige la faille. Le danger c'est pas la source de l'attaque c'est qu'il y'ai une faille exploitable.

le 07/11/2013 à 12:47
Dominik94
Membre habitué

euh, un cabinet de sécurité qui n'a même pas testé, dès le début de l'audit, la sécurité des applis

le 06/11/2013 à 18:14
atha2
Membre éprouvé

Malin comme attaque, après j'imagine qu'on ne peux pas récupérer de donnée à part en spécifiant un serveur de réception mais dans ce cas là, il n'y a plus de masquage des traces. Mais ça reste suffisant pour faire un drop database.

@TNT89 : d'après ce que je viens de lire, c'est le serveur source (de l'attaquant ici) qui spécifie cette propriété (ou pas). Donc à part demander à Google, quel site son bot visitait avant, il n'y a pas vraiment de moyen de trouver l'attaquant.

le 06/11/2013 à 22:46
Zefling
Expert confirmé

C'est comme ça que je me retrouve aussi avec un nombre important d'erreur 404 sur des adresses bizarres avec des jsessionid (mon site est en PHP), script ou autres trucs qui ne peuvent pas passer (ça ne vise visiblement pas du PHP) ressemblant à de l'injection XSS ou SQL, mais qui me pourrissent bien mes logs d'erreurs.

Ce qui m'étonnent c'est qu'il découvre ça que maintenant... Ça fait des années que je vois ça dans mes logs.

le 07/11/2013 à 0:16
Zefling
Expert confirmé

Envoyé par grunk

Dans la logique on corrige la faille. Le danger c'est pas la source de l'attaque c'est qu'il y'ai une faille exploitable.

Je pense que certains n’ont pas bien compris l'article. Pour trouver des failles, les types utilisent GoogleBot pour ne pas se faire repérer. Bien sûr que s’il y a une faille il faut le corriger, mais on n'est jamais à l’abri d'en avoir une surtout quand le code du site fait des centaines de milliers de lignes. Là, c'est juste que les types qui les cherchent ne seront pas démasqués, vu qu'il passe par un tiers que l'on ne peut bloquer. De toute façon, Google ne pourra rien faire, rien n’indique qu'il s'agit d'injection ou d'une requête légitime, surtout dans le cas de XSS.

En tout cas, il est toujours utile d'aller voir le log d’erreur 404, ça permet de voir les choses étranges qui y sont requêtées et vérifier qu'il n'y a pas de problème sur les cas suspects.

le 07/11/2013 à 13:33
Ottakar
Membre régulier

Sans dire de bêtise, si le Google bot a fait sont travail, il a du référencer le site de John avec les fameux liens, du coup avec les infos dans les log de la cible, en faisant une recherche Google, on devrait retrouver le site John, non?

le 15/11/2013 à 10:48
TotemRajal
Nouveau membre du Club

C'est une trés vieille attaque connue depuis 2001, voir phrack.
Encore des gars qui découvre l'eau chaude.

Bah faut bien justifier le salaire de ceux qui ne servent a rien

le 20/11/2013 à 23:38

Poster une réponse