Contre le système : Les robots attaquent
"[...] 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.

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.

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).

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.

Translated from the article "Against the System: Rise of the Robots" (C)Copyright 2001 by Michal Zalewski <lcamtuf@bos.bindview.com> Published with the kind authorization of the author. -- Traduction pour ZATAZ Magazine par ./n -- NDR : Extrait de Phrack #57, traduit et publié avec l'aimable autorisation de Michal Zalewski, que nous remercions.

:: Retour dans le le menu de ZATAZ Magazine ::