![]() |
|||||||||||||
![]() |
|||||||||||||
|
|||||||||||||
1. Introduction
L'été 2001 aura été riche de nouveaux virus et vers, à peu près éradiqués à force de réinstallations massives et mise hors ligne des systèmes contaminés, plutôt que par une prévention rationnelle préalable. Parmi les vers, deux ont tout particulièrement retenu l'attention : Code Red, dans ses diverses déclinaisons multicolores, depuis le 19 juillet et, plus intéressant par la diversité de ses moyens de propagation, Nimda, depuis le 18 septembre. Nous nous intéresserons à ce dernier, lié à Code Red, dont il est de toute évidence inspiré, ce qui lui a valu son surnom de Code Rainbow. 2. Vecteurs de propagation
L'une des originalités de Nimda réside dans la diversité de ses techniques de propagation entre machines infectées et cibles. Effectivement, au contraire d'un Code Red ou Blue qui concentre ses attaques sur des vulnérabilités propres au serveur web de Microsoft, IIS, en se limitant à un mode de transmission de serveur à serveur, Nimda accélère considérablement son déploiement en mettant a profit de nombreuses failles d'IIS, du navigateur web Internet Explorer, du logiciel de courrier Microsoft Outlook, impliquant ainsi les postes des utilisateurs dans l'infection générale. L'auteur de Nimda a opté pour les modes suivants de transmission du ver :
Comme nous allons le voir, les conditions de chaque infection sont loin d'être novatrices, mais cette variété dans les méthodes de propagation garantit la rapidité de la généralisation du ver à tout le réseau, ainsi que la certitude de contaminer d'une manière ou d'une autre des environnements peu surveillés, rarement à jour, construits essentiellement autour de logiciels naturellement vulnérables, généralement ceux de Microsoft, qu'il est difficile de tenir vraiment à jour tant les problèmes sont fréquents. 3. Modalités d'infection
Les différentes formes d'attaques perpétrées depuis une machine infectée par Nimda vers ses cibles élues ayant été largement documentées dans tous les avis de veille en sécurité des organismes spécialisés, nous ne ferons que rappeler brièvement leurs caractéristiques, à titre d'information. Une machine infectée tentera systématiquement de contaminer une plage d'adresses plus ou moins aléatoire, sans se soucier de la nature de sa cible (client ou serveur, IIS ou autre). Ainsi, le ver peut engendrer malgré tout des situations de déni de service sur des réseaux sans produits vulnérables. 3.1. Infection des serveurs basés sur Microsoft IIS ou PWS
Pour s'assurer la prise de contrôle de nombreux serveurs connectés au réseau, Nimda utilise plusieurs failles connues du logiciel IIS, corrigées depuis plusieurs mois pour la plupart :
De plus, Nimda tente d'utiliser les accès dérobés éventuellement laissés par deux vers récents, Code Red et sadmind/IIS. Naturellement, tous les correctifs nécessaires à l'éradication de ces deux failles sont disponibles depuis longtemps. Concrètement, une tentative d'attaque laisse 16 requêtes HTTP sur les journaux du serveur web. Une fois un serveur infecté, le ver se renomme et se recopie à divers endroits de l'arborescence de stockage, sur les disques locaux, et sur les disques accessibles par partage réseau. Il automatise de plus sa réactivation au redémarrage de la machine. De plus, il modifie chaque page de contenu web (.htm, .html, .asp, etc.) et y ajoute une ligne de code Javascript forçant le téléchargement de l'exécutable du ver par les navigateurs web, rejoignant alors le mode suivant d'infection. 3.2. Infection des postes clients par courrier électronique
Outre les postes clients faisant fonctionner le Microsoft Personal Web Server, sujets aux attaques précédentes, le vecteur de propagation de Nimda le plus « conventionnel » reste le courrier électronique. Une machine infectée envoie (à l'aide d'un client SMTP autonome permettant la falsification de l'adresse émettrice) le code du ver par courrier électronique à tout le carnet d'adresses Outlook de l'utilisateur, ainsi qu'à toute adresse e-mail trouvée dans les pages web du cache d'Internet Explorer. Le ver est envoyé sous la forme d'une pièce jointe, généralement un fichier exécutable « readme.exe » dont le type MIME est incorrectement positionné à « audio/x-wav », et dont une simple prévisualisation (effectuée automatiquement par Internet Explorer) suffira à déclencher l'infection. 3.3. Infection des postes clients par navigation web
Les modifications faites aux pages de contenu web des serveurs sous IIS entraînent les navigateurs à télécharger et exécuter systématiquement le « readme.eml » offert, une copie de l'exécutable, entraînant le mécanisme de prévisualisation, sans même avoir besoin de double-cliquer, grâce à « l'aperçu rapide », et l'infection. Ce comportement est conditionné à l'activation de Javascript dans les paramètres du navigateur, ainsi qu'à la vulnérabilité précédente d'Internet Explorer. 3.4. Infection par partage de volumes sur le réseau
Sur une machine infectée, le ver examine les éventuels volumes accessibles partagés par le protocole NETBIOS sur le réseau local, repère tous les fichiers exécutables, et les remplace par sa propre copie. Naturellement, il en profite pour désactiver tout mécanisme de sécurité des partages réseau dans la base de registres de la machine locale, crée un compte « Guest » et lui confie les privilèges d'administration, partage le disque système, etc. Pour apprendre plus de détails sur les circonstances techniques d'une attaque, et des statistiques sur la propagation du ver, ainsi que pour avoir la liste des adresses où vous pourrez trouver les différents correctifs constructeurs pour vos logiciels vulnérables, nous vous renvoyons à l'excellente analyse de Nimda par SecurityFocus, à l'adresse 4. Se protéger
Les vulnérabilités exploitées par Nimda n'avaient ici rien d'innovant ou de particulièrement dévastateur (pas de destruction volontaire de contenu). Les vraies particularités de ce ver demeurent sa diversité de moyens d'infection, la rapidité de sa propagation, et son absence totale de discrétion, comme si l'auteur du ver avait voulu montrer la simplicité de mettre à mal une part immense des serveurs web sur Internet en utilisant des failles connues, mettant le doigt sur la négligence des administrateurs systèmes, et sur l'absence totale de mécanismes élémentaires de sécurité informatique dans les grandes infrastructures, qui affaiblissent leur environnement en privilégiant l'usage de logiciels peu fiables.
À titre d'exemple, voici une règle de configuration du logiciel Postfix permettant le bloquage systématique des messages contenant le ver Nimda :
/^X-Unsent: 1/ REJECT
/^Content-Type:.*boundary=\"====_ABC0987654321DEF/ REJECT
à rajouter à un fichier dont le nom est spécifié dans la configuration principale de Postfix, par exemple, dans le main.cf :
header_checks = regexp:/etc/postfix/reject-rules
Dans sendmail, il suffit d'ajouter le filtre suivant : Check_Content_Type_Header
SCheck_Content_Type_Header
R$*;$*;boundary="====_ABC1234567890DEF_====" $#error $: 553 Warning! This message may contain the Concept Virus(CV) V.5
5. Conclusion
Nimda continue d'infecter des machines, réactivant les envois de courriers électroniques vérolés tous les dix jours. Pourtant l'intérêt de la communauté diminue : les journalistes ont beaucoup parlé de l'attaque ; une fois la première vague passée, quelques machines réinstallées, peu de remise en question. Un certain fatalisme vis-à-vis des problèmes de vers Internet règne, insouciant du caractère nocif de ces attaques, dont on a constaté l'extrême rapidité de diffusion, le polymorphisme, et le comportement assez particulier, qui pourrait laisser penser qu'il ne s'agit dans les cas de Code Red et Nimda que de simples « expérimentations », présageant dans les mois à venir l'apparition de vers aussi efficaces, probablement plus virulents ou destructeurs, et, certainement, aussi ironiques dans leurs vecteurs d'infection. par Thomas Seyrat, avec la collaboration d'Hervé Schauer |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Dernière modification le 22 octobre 2002 à 15:58:55 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2010 Hervé Schauer Consultants |
|