Accueil Plan du site Technique | Liens | Actualités | Formation | Emploi | Forums | Base  
logo CERIG NOUVELLE cerig.efpg.inpg.fr 
Vous êtes ici : Accueil > Actualités > Nouvelle > Code Red II au CERIG           Révision : 28 août 2001
Code Red - Les virus n'arrivent pas qu'aux autres

Nouvelle précédente Liste des nouvelles Nouvelle suivante
Le ver dénommé "Code Red", qui s'attaque aux serveurs web fonctionnant sous IIS, défraie la chronique. La version 2 se répand très rapidement, en Europe tout particulièrement. Cette version est plus difficile à éradiquer que la précédente. Elle est également plus dangereuse, et peut nécessiter la reconfiguration complète du serveur. En effet, elle permet aux personnes mal intentionnées de dresser des listes de serveurs web contaminés et d'en prendre le contrôle. Quelques mots sur la mésaventure de l'un des serveurs du CERIG, contaminé par le ver, alors que les autres sont indemnes.

Par Jean-Claude Sohm
(21 août 2001)

Introduction

En savoir plus sur...

Rappelons qu'on dénomme "ver" un programme malveillant qui se reproduit de lui-même, mais n'a pas besoin  -- comme un "virus" -- d'infecter un programme exécutable pour se propager. Personne n'ignore plus aujourd'hui qu'un ver empoisonne le web depuis quelque mois, qu'il s'appelle "Code Red", et qu'il vient peut-être de Chine (exotique, n'est-ce pas ?).

Le serveur principal du CERIG faisant l'objet d'attaques variées et presque journalières, nous ne portons pas une attention particulière à cette information. C'est pourquoi nous tombons des nues lorsque le 20 août dernier, le service informatique de l'EFPG (l'École Française de Papeterie et des Industries Graphiques, dont nous faisons partie) nous annonce tout à trac : "votre serveur d'essais est infectée par Code Red. Allez sur le site de Microsoft et chargez le patch correspondant".

La surprise succède à l'émotion. La machine en question n'est pas notre serveur de production ; elle est utilisée pour des essais, et sert de PC le reste du temps. Elle pourrait être utilisée comme serveur de secours en cas de panne du serveur de principal. Elle fonctionne sous Windows 2000 Server et IIS version 5. Nous n'aurions jamais pensé qu'un serveur web au fonctionnement intermittent, vers lequel ne pointe aucun lien, et qui est ignoré des moteurs de recherche, puisse attirer l'attention des hackers. Le problème vient de ce que le ver, pour se reproduire, scannne des adresses générées de manière aléatoire.

L'alerte provient du CERT-RENATER. Un CERT (Computer Emergency Response Team) est un organisme de sécurité du web. La liste des principaux établissements de ce type figure sur le site FIRST (Forum of Incident Response and Security Teams). Il existe trois CERT en France :

    le Cert-IST : Computer Emergency Response Team - Industrie Services et Tertiaire ;
  le CERT-RENATER : CERT dédié à la communauté des membres du GIP RENATER (Réseau National de télécommunications pour la Technologie, l'Enseignement et la Recherche) ;
  le CERTA : c'est le CERT dédié au secteur de l'administration française.

Les CERT collectent toutes les informations relatives aux incidents de sécurité, les analysent, gèrent une base de données des vulnérabilités, et émettent des bulletins d'alerte. Le premier CERT fut créé aux États-Unis en 1988, après qu'un étudiant (Robert T. Morris, de Cornell University) eût lancé le premier ver sur Internet, et paralysé quelques milliers de serveurs pendant plusieurs jours. Il était curieux, déclara-t-il aux enquêteurs, de voir ce qui allait se passer... Depuis Internet s'est développé de façon considérable, et le nombre des personnes malveillantes a suivi. Lorsque les dégâts occasionnés par ces virus, vers et autres "chevaux de Troie" sont importants, la grande presse elle-même s'empare de l'incident -- un "succès" pour leurs créateurs bons en informatique (OS et communication), mais un peu dérangés du cerveau (comme le montre ce qu'ils écrivent sur les sites qu'ils défigurent).

Les serveurs du CERIG étant reliés à Renater (le réseau national de l'enseignement et de la recherche), l'alerte concernant notre machine infectée nous est parvenue du CERT-RENATER. C'est donc à cet organisme que nous avons rendu compte de la suite donnée à l'incident.
 

Historique

Depuis un à deux ans, les détraqués de l'underground Internet rêvent de submerger un site web en le bombardant de questions à un rythme infernal. Pour ce faire, il faut déposer dans un certain nombre de serveurs un programme qui se déclenchera automatiquement à l'heure prévue, et générera des requêtes à haut débit. Une telle attaque s'appelle DoS (Denial of Service). On se souvient que quelques attaques de ce type réussirent l'an dernier à paralyser des sites connus pendant plusieurs heures.

Les webmestres qui surveillent le journal de leur site savent, depuis le printemps de cette année 2001, que quelque chose se trame. Le nombre de requêtes suspectes augmente régulièrement, et des trous de sécurité sont découverts dans les répertoires "Scripts" et "msadc" du logiciel IIS. Mais pour les journalistes, toute l'histoire du ver "Code Red" commence lorsque la société eEye (spécialisée dans la sécurité, et éditeur d'un firewall soft dédié à IIS) découvre un nouveau trou de sécurité dans le logiciel serveur web de Microsoft au début du mois de juin, et signale la chose à l'éditeur. Le 18 du même mois, l'éditeur reconnaît le défaut dans le Microsoft Security Bulletin MS01-033, et met en ligne un patch destiné à protéger les serveurs web utilisant IIS. Le bulletin précise "Microsoft strongly urges all web server administrators to apply the patch immediately" (Microsoft exhorte très vivement tous les webmestres à appliquer immédiatement le correctif), mais l'appel ne semble guère être entendu... sauf des programmeurs malveillants, qui trouvent là un nouveau moyen de s'attaquer aux 6 à 7 millions de sites web mis en ligne grâce à IIS de par le monde.

Les premiers indices de la présence d'un ver apparaissent sur le web vers le 11 juillet, mais il faut plusieurs jours pour que le phénomène soit confirmé, le programme isolé, et son décodage entrepris. Le 18 juillet, la presse annonce que 12.000 serveurs web sont infectés par un nouveau ver utilisant le trou de sécurité découvert par eEye. Sous peu, le nombre des serveurs "compromis" (synonyme d'infectés) monte à 200.000, puis dépasse les 350.000 avant la fin du mois. La page d'accueil des sites utilisant la version anglaise de Windows est défigurée ; ailleurs le ver se contente de se reproduire à toute vitesse, chaque machine essayant d'en contaminer une centaine d'autres. L'auteur du ver semble avoir un double but :

    encombrer le réseau Internet au point de l'empêcher de fonctionner correctement ;
  créer une attaque de type DoS sur le site web de la Maison Blanche, résidence du Président des États-Unis.

Mais les choses ne vont pas aussi loin : le ver crée une augmentation du trafic d'Internet, mais pas au point de saturer le réseau. En effet, certains opérateurs de backbone, voyant croître dangereusement le trafic dû au ver, déconnectent les serveurs web qui sont contaminés. De plus, le site de la Maison Blanche est désormais protégé par reroutage, et le ver ne se révèle pas aussi efficace que prévu dans son attaque de type DoS. Enfin les spécialistes de la sécurité distribuent gratuitement des programmes destinés à éradiquer le ver et à en neutraliser les effets :

    CodeRed Scanner de la société eEye, qui permet de scanner une machine particulière, ou tous les serveurs d'un réseau donné ;
  CodeRed Removal Tool de la société Symantec ;
  CyberCop WormScan de la société McAfee (cet outil nécessite un enregistrement préalable de l'utilisateur).

Après avoir utilisé ces outils, on redémarre le serveur, et l'on est (en principe) débarrassé du ver. Il ne reste plus qu'à télécharger le patch de Microsoft pour se protéger contre une nouvelle infection. Fin juillet, 400.000 exemplaires dudit patch ont été téléchargés depuis le site de l'éditeur. La presse, alors, se fait rassurante : Code Red, c'est fini ou presque, les dégâts sont minimes, le ver s'est endormi, nous avons eu plus de peur que de mal. On notera qu'au CERIG, le ver se manifeste pour la première fois le 19 juillet, en attaquant le serveur Mac, lequel est immune aux virus conçus pour la plate-forme Windows.

Mais l'expérience montre que, lorsqu'un programme malveillant connaît le succès, il fait des émules ; de nombreuses variantes voient alors le jour, qui sont souvent pires que le modèle original. C'est pourquoi des représentants de Microsoft et des agences fédérales des États-Unis, ainsi que divers experts en sécurité, tiennent une conférence de presse le 30 juillet dernier, pour mettre en garde solennellement les webmestres contre le retour offensif d'une variante "améliorée" du ver. Cette démarche n'a pas le retentissement attendu. En France, fin juillet, on se préoccupe surtout des embouteillages sur la route des vacances, dont la longueur cumulée dépasse 300 km...

Patatras ! On achève à peine de recenser les dégâts créés par la première version du ver, qu'une seconde (baptisée Code Red II) apparaît sur le terrain le premier août ; la presse en fait mention dès le 3. Ce remake parait beaucoup plus nocif que l'original : il se reproduit encore plus vite, permet à un hacker un peu entraîné de dresser la liste des machines contaminées, et d'en prendre le contrôle (création d'une "backdoor"). Contrairement à la première version, qui avait surtout affecté les États-Unis, la seconde version frappe l'Europe de plein fouet, et le domaine ".fr" est largement touché. Il semble que le nouveau ver ne soit nocif que sur les machines équipées de Windows 2000. Il peut cependant mettre en crash un serveur utilisant NT4 lorsqu'une redirection est active au niveau de la page d'accueil.

Le 15 août dernier, Microsoft publie un second patch destiné à protéger du nouveau ver les serveurs IIS fonctionnant sous Windows 2000, mais ce programme ne convient qu'aux versions anglaises de Windows. L'éditeur corrige cette lacune le 17 août. Il publie également un CodeRedCleaner, censé éradiquer les effets de la version 2. En fait, on peut s'interroger sur l'efficacité de ces divers outils, car certains serveurs du site web de Microsoft semblent avoir été eux-mêmes contaminés.
 

Le serveur d'essais compromis

Le serveur principal du CERIG est l'objet, depuis le début du mois de mai, d'attaques du type Generic "../" Directory Traversal et Generic HTTP 'cmd.exe' Request (pour employer la terminologie du site ARIS). Ces attaques exploitent un trou de sécurité (security hole) des répertoires "Scripts" et "msadc", situés dans le répertoire racine de tout site web géré par IIS. En cas de succès, une telle attaque permet de prendre le contrôle du serveur, et d'y implanter un programme malveillant du type "cheval de Troie" (trojan horse). Au CERIG, des mesures sont prises pour protéger les deux répertoires sur le serveur principal, mais on oublie de les étendre au répertoire msadc du serveur d'essais. Un internaute malveillant découvre la chose le 7 juillet dernier, grâce à la requête suivante (type 1) :

/msadc/../../../../../../winnt/system32/cmd.exe

Il consulte le répertoire de la machine, et l'on perd sa trace dans le fichier journal. La même intrusion se reproduit le 25 juillet, et cette fois le cheval de Troie est en place. Ce type d'attaque ne réussit pas quand on prend la précaution de placer la racine du site web dans un volume distinct de celui occupé par le système d'exploitation,  mais -- bien que le sachant -- nous avons omis de le mettre en oeuvre au moment de configurer IIS 5.

À partir du premier août, notre serveur contaminé envoie à des machines dont l'URL est déterminée de manière aléatoire, des requêtes (type 2) ayant la forme suivante :

/default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u685
8%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801
%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%
u00=a 

Si le serveur visé fonctionne sous IIS 5, cette requête trop longue génère un débordement de mémoire tampon ; le système divague, ce qui permet son intrusion et sa contamination. La machine atteinte tente alors d'en contaminer d'autres à son tour. C'est ainsi que, le 6 août, le CERT-RENATER nous prévient : notre serveur d'essais est "compromis", il expédie des requêtes de type 2. Le message passe par trois boites aux lettres successives (le responsable du domaine, le responsable du sous-domaine, le webmestre du CERIG), et -- compte tenu des absences pour cause de vacances -- met deux semaines pour nous parvenir.

Réaction immédiate. Diagnostic : la machine est bien contaminée par la version 2 de Code Red. L'examen du fichier journal montre que l'implantation du ver n'a pu se faire que le 7 ou le 25 juillet, la deuxième de ces deux dates paraissant la plus probable. Recherche fébrile sur le web, application du premier patch de Microsoft, usage des nettoyeurs de Microsoft et de Symantec, correction du registre, suppression manuelle des fichiers du cheval de Troie... Rien n'y fait : dès que le serveur web est remis en marche, il est rapidement recontaminé par une requête de type 2. Conclusion : il ne reste plus qu'à reconfigurer la machine, après avoir reformaté le disque dur. Certes, c'est une opération que nous avions programmée pour des raisons diverses, mais dans l'immédiat nous avons autre chose à faire ! En attendant, nous filtrons sur IP, empêchant l'accès des internautes autres que ceux qui se connectent à l'aide d'une machine du sous-domaine. Pour l'usage que nous faisons de ce serveur, c'est OK. Désormais, les attaques génèrent en réponse un code 403 (accès interdit, allez vous faire f...). Tout bien réfléchi, nous aurions dû le faire plus tôt ; mais nous n'allons pas dire merci aux hackers, tout de même.

Quelques heures plus tard, nous découvrons le second patch de Microsoft, nous le téléchargeons en version française, et nous l'installons. Nous hésitons à enlever le filtre sur IP pour en tester l'efficacité... mais l'expérience se fait malgré nous, lorsqu'une machine infectée du sous-domaine nous envoie des requêtes de type 2. Bien que ces dernières génèrent un code 200, notre serveur n'est pas réinfecté (tests négatifs, absence des fichiers du cheval de Troie). Le second patch de Microsoft semble donc protéger les machines qui utilisent Windows 2000 Server et IIS5, même si elles ont subi une infection auparavant.

On notera au passage que le ver Code Red II se propage de deux façons différentes, ce que très peu d'observateurs ont signalé (à l'exception d'ARIS, dans son document PDF intitulé Code Red II Worm, Incident Analysis Report).
 

Les deux autres serveurs sont immunes

La première requête de type 2 reçue par le CERIG atteint le serveur Mac le 4 août, sans aucun danger pour lui bien entendu. Assez curieusement, ce serveur Mac est de beaucoup le plus visé : de 150 à 200 attaques par semaine actuellement.

Le 4 août, six requêtes de type 1 sont adressées à notre serveur principal (qui utilise NT4 et IIS4), suivies de deux requêtes de type 2 les 7 et 10 août. Toutes ces requêtes génèrent une réponse contenant le code 400, qui signifie : "le serveur ne peut pas traiter la requête parce que la syntaxe n'est pas valide". Nous vérifions également que serveur n'est pas contaminé. Et pourtant, début août, notre machine n'était pas encore patchée, et Index Server était installé (sa présence est réputée indispensable pour que les attaques de Code Red réussissent). La propagation du ver dépendrait-t-elle de facteurs qui n'ont pas encore été dévoilés, tels que le verrouillage des répertoires "Scripts" et "msadc" ?
 

Les PWS également ?

Il est généralement admis que les stations de travail ne sont pas menacées par le ver, même si elles utilisent un serveur web personnel (PWS : Personal Web Server). Pour l'instant, l'expérience du Cerig le confirme -- du moins en ce qui concerne les machines qui utilisent les systèmes d'exploitation Windows 98 et Millenium, avec PWS 3 ou 4. Par contre, la machine d'un collègue qui utilise NT 2000 Professional et le PWS correspondant a été contaminée, et les patchs de Microsoft ne semblent pas la protéger. Explication possible : le PWS qui convient aux stations de travail utilisant Windows 2000 est une version simplifiée et bridée de IIS ; il souffre donc des mêmes trous de sécurité.

On peut rapprocher ce fait de ce qui s'est produit sur certains réseaux câblés donnant accès à Internet. Bien que les abonnements résidentiels ne donnent pas le droit aux particuliers d'installer un serveur web, il semble bien qu'un certains nombre d'entre eux aient transgressé l'interdiction, et que les câblo-opérateurs ait fermé les yeux dans le mesure où l'excédent de trafic était modeste. Lorsque ces sites personnels ont été contaminés par le ver, les requêtes lancées tous azimuts ont surchargé les réseaux câblés (dont la bande passante doit être partagée par tous les utilisateurs), et les opérateurs ont dû déconnecter les machines compromises.
 

Le CERIG en bonne compagnie

Dans les requêtes de type 1, l'URL que l'on retrouve dans le fichier journal est toujours fausse ; le hacker qui pose une question pourrie à un serveur web ne lui indique pas sa vraie adresse ! Dans les requêtes de type 2, par contre, l'URL indiquée est exacte. À partir des journaux de nos trois serveurs, nous avons pu dresser une liste de plusieurs centaines de machines compromises, situées pour la plupart en Europe. Comme le CERT européen n'est plus en activité, il ne servirait à rien de lui transmettre cette liste. Cependant, par simple curiosité, nous avons cherché à savoir à quels sites correspondaient ces machines. À l'aide d'un annuaire DNS inverse tel que RIPE, nous avons analysé un échantillon de quelques dizaines de sites, et trouvé pêle-mêle : des sites en construction, des petits sites méconnus, des sites universitaires renommés, et même deux fournisseurs d'accès à Internet ! Grâce à Netcraft, nous avons pu vérifier que ces sites utilisaient tous Windows 2000 Server et IIS 5. Nous avons également pu constater que, quelques jours plus tard, la plupart de ces sites ne répondaient plus.
 

Conclusion

Il suffit de parcourir le web pour constater que, contre Code Red II, la lutte s'est organisée. Les organismes de sécurité préviennent les webmestres dont le serveur est compromis. Certains sites transmettent systématiquement leur journal à des organismes qui les analysent et émettent des bulletins d'alerte. Les opérateurs déconnectent les sites compromis. Des internautes compétents récupèrent les programmes malveillants et les analysent, comparant leurs résultats avec ceux des spécialistes. Des sites signalent les machines contaminées les plus virulentes : chacun peut introduire l'URL correspondante dans son navigateur, et apprendre quel est le webmestre négligent qui répugne à reconfigurer sa machine (car le ver n'empêche pas le serveur web de fonctionner). Quand on est ainsi montré du doigt, on se sent obligé de faire quelque chose !

Une course de vitesse est engagée, entre les hackers qui tentent de contrôler le plus grand nombre possible de serveurs pour monter une opération type DoS, et tous ceux qui font fonctionner le web, nettoient leurs machines et les remettent d'aplomb. L'auteur de ces lignes étant d'un naturel plutôt optimiste, pense que les seconds -- après avoir bien pesté -- l'emporteront largement sur les premiers.

Les financiers, enfin, font les comptes : si 100.000 sites doivent être reconfigurés, si l'opération prend 10 hommes-heures (des informaticiens surpayés à 100 $/heure), alors Code Red II coûte 100 M$ aux entreprises -- sans compter le préjudice subi, plus difficile à évaluer. À l'échelle mondiale, ce n'est pas un drame, même si certains avancent des chiffres dix fois plus élevés.

La morale de cette histoire : les petites négligences ruinent la sécurité. Si votre serviteur avait installé le site sur un volume distinct du serveur d'essais, et/ou s'il n'avait pas oublié de boucher le trou de sécurité du répertoire msadc, la contamination par le ver ne serait arrivée qu'aux autres.
 

Épilogue

Le ver Code Red ne fait pas du tort à tout le monde. La société Pepsi  a récemment lancé une nouvelle boisson qui s'appelle justement... Code Red. Les bouteilles se vendent comme des petits pains, et certains pensent que le bruit fait autour du programme malfaisant y est pour beaucoup ; on a même baptisé le phénomène "viral marketing". Que les sociétés spécialisées dans la sécurité Internet (et en particulier celles qui vendent des firewalls) fassent des affaires en or quand les virus informatiques cavalent sur le web, on le conçoit. Mais qu'il en soit de même pour un fabricant de boissons, montre que le net n'a pas fini de nous étonner.
 

 
 
Nouvelle précédente Liste des nouvelles Nouvelle suivante
  Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base 
 
Copyright © CERIG/EFPG 1996-2002