Spécial Conficker : des vers, des dégâts, des débats

Sommaire

- 1 - Des vers, des dégâts, des débats 

- 2 - « Enregistrer sous… », le dernier fléau de Kroll

1) Des vers, des dégâts, des débats

En bref, le florilège quotidien des choses à lire absolument à propos de Conficker : Silvain Sarmejeanne du Cert Lexsi revient sur les utilitaires de détection et d’éradication du virus… comme nous le faisons remarquer dans notre précédente édition mentionnant la « solution du honeynet », à ne mettre qu’entre des mains expertes.

Du même Cert Lexsi, Fabien Perigaud décrit par le menu l’infernal mécanisme de communication peer to peer utilisé par les fonctions de « mise à niveau » de Conficker. Les deux chercheurs publient leur texte – travail de romain - à la fois en français et en anglais.

Vinay Mahadik et Ravi Balupari de l’Avert plongent eux aussi dans le dump réseau du virus, notamment sur les mécanismes de vérification de date courante et les systèmes de détection de présence d’un « pair » également infecté. Le « passage à l’an 2009 » de ce premier avril est dénué de bug chez les auteurs de virus.

F-Secure traite le sujet de manière humoristique… dommage, en ce premier avril, de n’avoir lu encore aucun article sur les dangers de Conficker dans les noyaux CP/M ou les ZX81

Impressionnant travail de bénédictin effectué par le Sans, qui dresse un tableau de toutes les ressources pouvant servir à lutter contre l’infection.

Tout aussi impressionnant référentiel sur le sujet tenu par l’Université de Bonn, émaillé d’outils à télécharger pour détecter et éradiquer le ver. Certains passages sont directement inspirés par l’inévitable…

… Analyse du Honeynet Project par Felix Leder et Tillmann Werner

Travail récapitulatif également du côté du « Conficker Working Group » «  Know Your Enemy: Containing Conficker, To Tame A Malware », un wiki truffé de conseils s’adressant aux personnes de tous niveaux techniques, du débutant à l’administrateur confirmé. A noter, cette remarque postée par les administrateurs du wiki, en date du premier avril : « No one is sure its purpose or mission ».

Richard Bejtlich se penche plus particulièrement sur le moteur de génération de noms de domaines intégré au virus, ainsi qu’aux dépôts de noms effectifs. Toujours selon Bejtlich, OpenDNS serait toujours capable de bloquer les quelque 50 000 noms de domaine générés chaque jour par Downadup.

Brian Krebs, qui fête les 4 ans de sa rubrique « Security Fix », commente les statistiques de répartition du botnet dans le monde. A lire également le papier « premier avril » de Krebs, toujours à propos des ravages de Conficker. On y parle de missiles nucléaires qui passent automatiquement en position d’attaque Defcon 3, de distributeurs de billets devenus fous dans la banlieue de Reykjavik, d’une panne brutale de Big Ben à Londres…

Il s’est produit, en l’espace de 48 heures, plus de littérature et d’analyses de qualité que n’en ont jamais généré durant toute leur vie les virus les plus destructeurs connus à ce jour. Il a également été émis, depuis le 30 mars, un nombre incalculable de « chaînes » d’e-mails clamant à qui voulait bien l’entendre qu’un « déclenchement imminent de la charge d’attaque d’un virus destructeur » allait survenir au début du mois. Pour peu, les mots downadup et conficker mériteraient d’être ajoutés aux filtres bayesiens des clients de messagerie, à côté des termes Viagra, Lottery et «  Your account has been suspended »

2) « Enregistrer sous… », le dernier fléau de Kroll

Héritiers des grands poètes Vogons, les enquêteurs et sondeurs de Kroll Ontrack, spécialistes de la récupération de données, viennent une nouvelle fois de publier un rapport dénonçant les attitudes aussi catastrophiques qu’irresponsables du pire ennemi de la sécurité informatique : nous avons nommé l’utilisateur.

« … 40% des personnes interrogées ont déclaré que leurs entreprises respectives avaient instauré des directives bien définies pour stocker les données dans des espaces clairement définis. Cependant, les résultats de l'étude révèlent également que 61 % des sondés effectuent la plupart de leurs enregistrements sur un disque local au détriment du réseau de l'entreprise. Les risques liés à un enregistrement sur un disque local pourraient être minimisés au moyen d’une sauvegarde sur un disque externe ou un logiciel spécifique. Cependant, 44 % des sondés avouent que leur système de stockage est dépourvu de sauvegarde efficace. »

Il faut avouer qu’en cas de crash disque, la récupération de données est plus simple si tout a été enregistré sur une seule et même unité et qu’une politique de backup « centralisée » est bien plus facile à conduire qu’une sauvegarde poste à poste, assurée soit par le biais d’une procédure de type « protocole basket », soit par le truchement d’un agent logiciel.

Mais ce que semble surtout nous apprendre cette constatation tirée par les spécialistes de Kroll, c’est que les administrateurs, plus que les usagers, sont responsables de cet état de fait. Responsables, mais pas nécessairement coupables. En général, une sauvegarde de document locale est motivée par deux raisons. Soit parce que, par le passé, le « service informatique » a, par inadvertance, détruit de façon répétitive le travail d’un administré… L’aventure est fréquente, généralement couverte par une réaction de défense du genre « Mais on avait envoyé un mail d’avertissement, on avait des opérations de maintenance à faire… ». Soit – et c’est généralement le cas le plus fréquent - parce que les automatismes de déploiement d’applications ne forcent pas le chemin par défaut des répertoires d’enregistrement. L’intégration d’une UNC dans un fichier INI ou un script MSI n’est pourtant pas quelque chose de compliqué. Cela n’a généralement rien à voir avec les nécessités d’une « communication » ou d’une « sensibilisation » particulière.