Nimda : les difficultés du retour à la normale

Alors que les effets de Code Red II se faisaient encore sentir ... et ils ne sont sans doute pas terminés, le ver Nimda est apparu le 18 septembre et a montré une capacité de propagation inconnue à ce jour, qui a déjà pour conséquences :

• un délai de réparation et de retour à la "normale" (à savoir un éradication complète de Nimda sur les systèmes) sans commune mesure avec les infections passées,
• un coût de réparation et de retour à la "normale" beaucoup plus élevé pour les entreprises, et qui ne sera vraiment mesurable que ... dans quelque temps.

Nous essaierons dans cet article d'analyser la propagation, au travers des observations de terrain issues d'entreprises et aussi des actions du Cert-IST, en particulier dans la période d'activité intense du ver. Nous ne reviendrons pas sur les détails de l'alerte et de l'avis l'accompagnant, vous pourrez les retrouver sur le site du Cert-IST via les liens suivants : CERT-IST/AL-2001.008 et CERT-IST/AV-2001.248.

Comment cela s'est-il passé ?

Lorsque le Cert-IST a émis sa première alerte le 18 au soir, l'ensemble des techniques de propagation du ver Nimda n'avait pas encore été analysé de façon exhaustive, et la lecture de la première alerte pouvait laisser penser qu'en se protégeant contre les mails contenant en attachement un fichier "readme.exe", une entreprise pouvait être à l'abri de cette nouvelle menace.

Une fois les protections contre les infections par mail mises en oeuvre (soit au moyen d'anti-virus à jour, soit en mettant en oeuvre un filtrage adéquat au niveau des serveurs de messagerie ou sur les passerelles de filtrage de contenu), beaucoup de sites se sont aperçus que les infections perduraient.

L'analyse détaillée du virus a en effet mis en évidence par la suite d'autres modes de propagation, à savoir :

• les accès web à des serveurs web Microsoft IIS infectés, via le navigateur IE (et exploitant une faille de ce dernier), pour lesquels la parade pouvait être faite soit par le biais d'un anti-virus sur le poste client (à jour et correctement configuré), soit en filtrant les URL ou le contenu délictueux sur le relais http (quand l'architecture est à base de relais), soit enfin en corrigeant la vulnérabilité de IE.
• les partages réseau et l'utilisation de l'explorer de fichiers de Windows, et la seule parade pouvant être de supprimer, au moins temporairement lesdits partages,
• l'utilisation de la DLL infectée nécessaire au traitement des fichiers RTF, avec comme seule parade le remplacement de la DLL infectée par une DLL saine (et bien entendu une mise à jour de l'anti-virus).
• L'échange de fichiers exécutables infectés par Nimda; avec comme parade d'avoir un anti-virus à jour et correctement configuré.

Comme ces différents modes de propagation n'ont été "publiés" qu'au cours du temps, il est compréhensible que les mesures de confinement prises en fonction de la connaissance des modes de propagation se soient révélées inefficaces, jusqu'à ce qu'elles aient été toutes appliquées. Moyennant quoi, compte tenu de "l'agressivité" de Nimda dans sa propagation, en particulier dans les blocs d'adresse IP voisins du poste infecté, beaucoup de sites se sont retrouvés infectés dans des proportions bien plus importantes qu'avec Code Red II.

On pourra comparer cette agressivité sur la courbe comparative (https://wws.cert-ist.com/francais/alertes/CodeRedStat2.htm) des attaques reçues par le serveur public du Cert-IST.

Les leçons

Quelques leçons peuvent être tirées de cette attaque, tant dans le support que le Cert-IST peut apporter à ses partenaires et clients, qu'en terme de parades générales :

• une réaction rapide est la garantie que la situation reste contrôlée : dans le cas de Nimda, un premier sondage de nos correspondants virus nous a permis d'apprécier au plus tôt la gravité de la situation et d'émettre la première alerte. Cet échange d'information a permis d'apprécier l'importance de ce réseau qui a été le premier "averti", et il a depuis été étoffé dans sa composition,

• dans une situation de crise comme celle qu'a amenée Nimda, une réactivité du Cert-IST est attendue par les partenaires et clients, pour que soient communiqués au plus tôt les nouveaux risques (il s'agissait en l'occurrence de nouveaux moyens de propagation), et les parades à mettre en oeuvre. Le fait d'avoir fait une révision de l'avis , et donc de ne pas l'avoir renvoyée a pu entraîner un retard de diffusion de l'information, puisqu'il fallait consulter le site du Cert-IST pour prendre connaissance des derniers développements liés à l'attaque. Le Cert-IST, dans une situation de crise évitera à l'avenir ce genre de situation et est intéressé à étudier toute suggestion pour améliorer l'efficacité de son support (n'hésitez pas à nous faire part de vos suggestions à cert@cert-ist.com).

• pour ce qui est des parades "standards" à mettre en oeuvre :
  • pour faire du filtrage d'url et de contenu dans du trafic http, il faut impérativement mettre en oeuvre un relais (http) ; la mise en oeuvre de reverse proxies (relais entrant) aide aussi à un meilleur contrôle des accès sur les serveurs de l'entreprise,
  • l'ajout de filtres sur un serveur ou sur un scanner de messagerie , peut faire l'objet d'une mutualisation entre les partenaires et les clients, et le Cert-IST peut être sollicité pour aider à définir ou écrire (dans la mesure ou les outils sont connus) ce type de filtres.