==Phrack Inc.==

               Volume 0x0b, Issue 0x39, Phile #0x0a of 0x12

|=------------=[ Contre le système : Les robots attaquent ]=-------------=|
|=-----------------------------------------------------------------------=|
|=-=[ (C)Copyright 2001 by Michal Zalewski <lcamtuf@bos.bindview.com> ]=-=|


-- [1] Introduction -------------------------------------------------------

"[...] la grande différence entre le Web et les moyens de communication
traditionnels est qu'il n'y a pratiquement aucun contrôle de qui met quoi
sur le Web. Couplez cette facilité de publication avec l'énorme influence
des moteurs de recherche dans le routage du trafic, et les sociétés qui
décident d'utiliser ceux-ci pour leur propre bénéfice peuvent poser un
problème sérieux."

                         -- Sergey Brin, Lawrence Page (cf références, [A])

Imaginez une faille exploitée à distance et permettant de compromettre un
système sans qu'aucune ligne de code ne soit directement envoyée à la
victime. Imaginez une exploit qui créerait simplement un fichier en local
afin de compromettre des milliers d'ordinateurs, et qui n'implique aucune
source spécifique dans l'attaque. Bienvenue dans le monde des techniques
d'exploitation de bug zéro-effort ! Bienvenue dans le monde de
l'automatisation, bienvenue dans le monde de l'attaque anonyme, d'autant
plus difficile à éviter que la complexité d'Internet augmente.

Les exploits zéro-effort créent une 'wishlist', et la déposent quelque
part dans le cyberespace - voire sur un serveur hébergé chez leur
créateur, bref dans un endroit où d'autres peuvent les trouver. Ces
"autres", ce sont les travailleurs invisibles de l'Internet (cf
références, [D]). Ils sont des centaines à ne jamais dormir, infatigables
chenilles parcourant sans fin la toile mondiale : agentsintelligents,
moteurs de recherche... Ils viennent pour sélectionner cette information,
et - à leur insu - pour attaquer des victimes. Vous pouvez arrêter l'un
d'eux, mais ne pouvez pas les arrêter tous. Vous pouvez découvrir ce que
sont leurs commandes, mais vous ne pouvez pas deviner ce que ces commandes
seront demain, cachés qu'ils sont dans l'abîme toujours inexploré du
cyberespace.

Ils sont votre armée privée, vous les avez sous la main, prêts à obéir aux
commandes que vous aurez pris la peine de laisser sur leur chemin. Vous
les exploiterez sans devoir les compromettre. Ils font ce pour quoi ils
ont été conçus, et ils le font du mieux qu'ils le peuvent.

Bienvenue dans une nouvelle réalité, où nos machines, à l'intelligence
plus que jamais artificielle, peuvent se lever contre nous.

Imaginez un ver. Un ver qui ne fait rien. Il est porté et injecté par
d'autres - mais sans les infecter. Ce ver crée une "wishlist" - wishlist
de, par exemple, 10.000 adresses aléatoires. Puis il attend. Les agents
intelligents indexent cette liste, unissant leurs forces pour toutes les
attaquer. Imaginez qu'ils y réussissent avec, au pire, un taux de succès
de 0,1%. Dix nouveaux serveurs infectés. Sur chacun d'entre eux, le ver
fait exactement la même chose - et les agents reviennent, infectant alors
100 machines. L'infection se poursuit - ou continue à ramper, si vous
préférez.

Les travail des agents intelligents est quasi-invisible, et les gens se
sont habitués à leur présence un peu partout. Ils progressent lentement,
dans une boucle interminable. Ils fonctionnent méthodiquement, ne génèrent
pas de transferts de données excessifs - ils rampent, sans explosion
soudaine de leur activité. Semaine après semaine après semaine, ils
inspectent des machines nouvelles, soigneusement, sans surcharger le
réseau, ne produisant jamais le moindre trafic suspect, repoussant sans
cesse les frontières de leur exploration. Et s'ils transmettaient un virus
de type "worm", un ver, vous en rendriez-vous compte ? Peut-être... ou
peut-être pas.

-- [2] Un exemple ---------------------------------------------------------

Quand cette idée m'est venue à l'esprit, j'ai décidé de faire un essai
très simple, simplement pour vérifier mon raisonnement. J'ai visé, si tant
est que le mot soit approprié, des moteurs de recherches et d'indexation
parmi les plus classiques et généraux sur le Web. J'ai créé une page HTML
très simple et je l'ai mise quelque part. Et puis j'ai attendu quelques
semaines. Et ils sont venus. Altavista, Lycos et des douzaines d'autres.
Ils ont trouvé ces nouveaux liens et les ont sélectionnés avec
enthousiasme, puis ont disparu pendant plusieurs jours.

  bigip1-snat.sv.av.com:   
    GET /indexme.html HTTP/1.0

  sjc-fe5-1.sjc.lycos.com: 
    GET /indexme.html HTTP/1.0

Ils sont revenus plus tard, pour voir ce que je leur avais donné à
analyser.

http://somehost/cgi-bin/script.pl?p1=../../../../attack
http://somehost/cgi-bin/script.pl?p1=;attack
http://somehost/cgi-bin/script.pl?p1=|attack
http://somehost/cgi-bin/script.pl?p1=`attack`
http://somehost/cgi-bin/script.pl?p1=$(attack)
http://somehost:54321/attack?`id`
http://somehost/AAAAAAAAAAAAAAAAAAAAA...

Les robots ont suivi les liens fournis, exploitant d'hypothétiques
vulnérabilités et compromettant ainsi des serveurs à distance :

  sjc-fe6-1.sjc.lycos.com: 
    GET /cgi-bin/script.pl?p1=;attack HTTP/1.0

  212.135.14.10:
    GET /cgi-bin/script.pl?p1=$(attack) HTTP/1.0

  bigip1-snat.sv.av.com:   
    GET /cgi-bin/script.pl?p1=../../../../attack HTTP/1.0

  [...]


(BigIP est un célèbre "load balancer (équilibreur de charge)", basé
sur l'observation, de F5Labs). Les robots se sont ensuite joyeusement
connectés aux ports non-http que j'avais préparés à leur intention :

  GET /attack?`id` HTTP/1.0
  Host: somehost
  Pragma: no-cache
  Accept: text/*
  User-Agent: Scooter/1.0
  From: scooter@pa.dec.com

  GET /attack?`id` HTTP/1.0
  User-agent: Lycos_Spider_(T-Rex)
  From: spider@lycos.com
  Accept: */*
  Connection: close
  Host: somehost:54321

  GET /attack?`id` HTTP/1.0
  Host: somehost:54321
  From: crawler@fast.no
  Accept: */*
  User-Agent: FAST-WebCrawler/2.2.6 (crawler@fast.no; [...])
  Connection: close
 
  [...]

La liste des moteurs de recherche pouvant servir d'agents ne se limite pas
à ceux qui sont connus et accessibles au public. Les moteurs d'alexa.com,
d'ecn.purdue.edu, de visual.com, de poly.edu, d'inria.fr, de
powerinter.net, de xyleme.com, et bien d'autres moteurs de recherche non
identifiés on trouvé cette page et l'ont appréciée. Certains robots n'ont
pas indexé toutes les URLs. Quelques agents, par exemple, n'indexent
absolument pas les scripts, d'autres n'utilisent pas les ports non
standard. Mais la majorité des moteurs, dont les plus puissants, le font
sans problème - et, dans le cas contraire, le filtrage insignifiant qui
est mis en place ne constitue pas une protection efficace : la plupart des
vulnérabilités de IIS peuvent être exploitées sans utiliser de script.

Que se passerait-il si la liste des serveurs à attaquer était choisie de
façon aléatoire parmi 10.000 IPs ou 10.000 noms de domaines en .com? Que
se passerait-il si le "script,pl" de mon exemple était remplacé par
l'utilisation de trois, quatre, cinq ou dix vulnérabilités de IIS ou de
célèbres scripts buggés sous Unixparmi plus populaires ? Et même si le
taux de succès n'était que d'1 machine compromise pour 2.000 tentatives ?

Et si le somehost:54321 de l'exemple ci-dessus était redirigé vers un
service vulnérable, exploitable par des variables utilisateur au sein de
requêtes HTTP ? (je considère que la majorité des services soi-disant
sécurisés qui ne déconnectent pas un utilisateur après la première
commande inexacte sont potentiellement vulnérables) Et si...

Il y a quelque part une veritable armée des robots, de différents types,
aux possibilités variables, plus ou moins intelligents. Et ces robots sont
prêts à faire tout ce que vous leur demanderez de faire. C'est effrayant.

--[3] Considérations sociales ---------------------------------------------

Qui est coupable lorsqu'un webcrawler compromet votre système ? La réponse
la plus évidente est : l'auteur de la page web que le moteur a visitée.
Mais il est difficile de tracer les auteurs de pages web, et le cycle
d'indexation d'un moteur de recherche prend des semaines. Il est difficile
de déterminer quand la page en question a été mise sur le Net - elles peut
avoir été indexée par différents moyens, avoir été modifiée par d'autres
robots plus tôt dans la chaine de selection; dans le protocole SMTP, comme
dans beaucoup d'autres, il n'y a pas de réelle possibilité de retrouver
une trace. D'ailleurs, beaucoup d'agents ne gardent pas la moindre trace
du cheminement suivi pour indéxer nouvelle URL. L'utilisation
d'indicateurs d'indexation, comme "noindex" sans l'option "nofollow", peut
causer quelques problèmes additionnels. Dans beaucoup de cas, l'identité
de l'auteur et l'origine de l'attaque ne seraient pas déterminées, alors
que de réelles intrusions auraient eu lieu.

Et si, pour finir, le but de l'auteur de la page n'était absolument pas de
la faire indéxer ? Pensez à tous ces articles à but "informatifs", etc.. -
les agents ne liraient pas l'avertissement et le message écrit en gras
"N'ESSAYEZ PAS CES LIENS"...

Par analogie avec d'autres cas, Napster par exemple, contraints de filtrer
leur contenu (ou de mettre fin à leur service) en raison d'informations
protégées par le CopyRight et distribuées par leurs utilisateurs, causant
ainsi des pertes économiques, il est raisonnable d'imaginer que des
responsables de moteurs de recherche soient forcés de mettre en
application des filtres spécifiques, ceci devant verser, dans le cas
contraire, d'énormes compensations aux victimes de l'utilisation abusive
de leurs robots.

D'un autre côté, il semble presque impossible de filtrer avec succès le
contenu du code malveillant, si on prend en compte nombre et la grande
variété des vulnérabilités connues. ...sans parler d'attaques qui
pourraient être tres ciblées (cf références, [B], pour plus d'information
sur les solutions propriétaires et leur insecurité). Ainsi le problème
demeurerait. Un autre paramètre à prendre en compte est que tous les
robots d'indexation ne sont pas forcément sous la juridiction des États
Unis, ce qui compléxifie encore les choses (dans beaucoup de pays,
l'approche de ce genre de problèmes est moins sujette à controverse qu'aux
des États-Unis).

-- [4] Défense ------------------------------------------------------------

Comme nous l'avons montré ci-dessus, les moyens de défense et les actions
possibles au niveau des moteurs de recherches sont très limitées, à cause
de la grande variété de vulnérabilités basées sur le Web. Une des défenses
les plus raisonnables consiste enl'utilisation de logiciels sécurisés et
correctement mis à jour, mais - évidemment - ce point de vue n'est pas
vraiment partagé de tous, et à raison : www.google.com avec le filtrage
de documents en place, retourne 62.100 enregistrements pour la requête :
"cgi vulnerability" (voir également : références, [D]).

Une autre ligne de défense possible contre les robots pourrait être
l'utilisation du mécanisme standard d'exclusion des robots / robots.txt
(voir références, [C], pour les caractéristiques). Le prix à payer étant
l'exclusion partielle ou complète de votre site des moteurs de recherche,
ce qui, dans la plupart des cas, ne peut être envisagé. En outre, quelques
robots sont mal développés et ne respectent pas le fichier robots.txt
quand ils suivent un lien direct vers un nouveau site web.

-- [5]  Références --------------------------------------------------------

[A] "The Anatomy of a Large-Scale Hypertextual Web Search Engine"
    Googlebot concept, Sergey Brin, Lawrence Page, Stanford University
    http://www7.scu.edu.au/programme/fullpapers/1921/com1921.htm

[B] Proprietary web solutions security, Michal Zalewski
    http://lcamtuf.coredump.cx/milpap.txt

[C] "A Standard for Robot Exclusion", Martijn Koster
    http://info.webcrawler.com/mak/projects/robots/norobots.html

[D] "The Web Robots Database"
    http://www.robotstxt.org/wc/active.html
    http://www.robotstxt.org/wc/active/html/type.html

[E] "Web Security FAQ", Lincoln D. Stein
    http://www.w3.org/Security/Faq/www-security-faq.html

-- [6] Notes du traducteur ------------------------------------------------

NDR : Extrait de Phrack #57, traduit et publié avec l'aimable autorisation
      de Michal Zalewski, que nous remercions.