pixel_dreams - Fotolia

Sept ans après, les leçons à tirer de Conficker

Exploitant une vulnérabilité corrigée fin 2008, Conficker a été à l’origine de l’une des plus importantes épidémies informatiques et reste présent sur de très nombreuses machines. L’expert Nick Lewis détaille ce que les entreprises peuvent en apprendre.

Conficker compte parmi les plus vastes réseaux de bots jamais rencontrés à travers le monde. Il a été à l’origine de nombreux incidents, dont l’annulation d’amendes d’automobilistes à Manchester, en 2009. Exploitant une vulnérabilité de Windows corrigée fin 2008, il se portait encore très bien début 2010, selon Akamai. Selon F-Secure, il aurait infecté près de 9 millions de machines, dont des postes de supervision industrielle. A l’automne 2012, Schneider Electric reconnaissait en avoir trouvé la trace dans son infrastructure à l’occasion du déploiement d’un système de gestion des informations et des événements de sécurité (SIEM).

Alors que les logiciels malveillants modernes le surpassent en termes de fonctionnalités et de sophistication, Conficker est parvenu à s’installer dans de nombreux recoins d’Internet, montrant l’ampleur des efforts nécessaires à son éradication. De quoi donner un aperçu des difficultés que devraient apporter des objets connectés au cycle de vie long.

Tirer les enseignements de l’épidémie Conficker, et de l’avancement actuel de son éradication s’avère critique pour se préparer à la survenue future d’un événement comparable.

Une éradication inachevée

Une fois que Conficker a cessé de faire les gros titres, beaucoup se sont tournés vers le logiciel malveillant suivant. En coulisse, toutefois, d’importants efforts ont été accomplis pour répondre à la menace qu’il continuait de constituer et tenter de l’éradiquer. L’infrastructure de commande et de contrôle a été démantelée, et des pièges ont été déployés en ligne pour collecter le trafic généré par les systèmes encore infectés et l’analyser. Tout un travail qui n’a rien de très glamour, mais qui est essentiel pour maintenir la confiance dans le fonctionnement d’Internet.

Cette année, des chercheurs de l’université technique de Delft ont justement analysé ces données pour évaluer l’efficacité de ces efforts. De quoi montrer que Conficker continue d’infecter près d’un million de machines connectées à Internet, en particulier dans les pays où l’usage des technologies de l’information est le moins mature, ou s’appuie le plus sur des logiciels piratés.

En outre, selon les chercheurs, « certains fournisseurs d’accès peuvent avoir jugé que Conficker, une fois neutralisé, ne constitue plus une menace suffisante pour mériter que l’on continue d’y remédier ». Ils n’ont donc pas consacré suffisamment de ressources à l’effort global de lutte contre le botnet, comme par exemple notifier leurs clients de la compromission de leurs machines.

Qui plus est, certaines machines encore infectés semblent être hors d’atteinte des spécialistes de la lutte contre les logiciels malveillants. Celles-ci risquent de rester infectées jusqu’à leur mise au rebut. Hélas, les machines infectées par Conficker sont plus susceptibles que les autres d’être compromises par d’autres logiciels malveillants.

Les enseignements de Conficker

De nombreux défis rencontrés pour l’éradication de Conficker sont survenus hors entreprises. Mais les mêmes leçons s’appliquent à cet univers-là, d’autant plus qu’un nombre croissant de systèmes grand publics accèdent aux réseaux des entreprises.

L’une des principales leçons de l’incident Conficker est que les entreprises doivent collecter des informations sur les terminaux afin de pouvoir notifier leurs utilisateurs d’une éventuelle compromission. Mais cela peut être difficile compte de la rotation des affections d’adresses IP par les serveurs DHCP ou encore des problèmes de visibilité sur les réseaux IPv6. L’adressage automatique est géré différemment avec IPv6, mais avec la multiplication des terminaux connectés aux réseaux et la pénurie croissante d’adresses IPv4, la visibilité sur les réseaux IPv6 sera critique pour lutter contre les botnets.

L’autre leçon est que fournir un accès facile aux outils de remédiation et déployer automatiquement les correctifs sans intervention de l’utilisateur constituent les méthodes les plus efficaces pour nettoyer des terminaux infectés. Ainsi, la réinfection a été un problème pour les systèmes qui ne pouvaient télécharger les mises à jour de sécurité, ou dont l’accès réseau était limité au point d’empêcher le téléchargement des outils de remédiation à partir de sources approuvées. Et compte tenu du grand nombre de systèmes infectés, il est peu probable que tous les propriétaires de terminaux concernés disposent des compétences nécessaires pour les nettoyer. Dès lors, disposer de ressources dans un centre de réponse coordonnée pourrait aider les utilisateurs. Et notamment leur fournir les outils de remédiation nécessaires.

Mais les utilisateurs ne sont pas forcément à blâmer : certains systèmes encore affectés peuvent être des systèmes embarqués. Là plus encore qu’ailleurs, une approche coordonnée impliquant tous les acteurs concernés est essentielle.

Se préparer pour l’avenir

L’incident Conficker donne ainsi des leçons sur la manière de gérer des incidents de sécurité en général. Mais celles-ci sont critiques pour la préparation de la réaction à incidents dans le monde des objets connectés.

De nombreux appareils relevant de l’Internet des objets fonctionneront en continu, et avec une durée de vie bien plus longue qu’un poste de travail : y trouver des logiciels malveillants vieux de sept ou huit ans n’aura rien de surprenant.

Et là, l’étude des chercheurs de l’université de Delft montre que le pays affichant le plus long effort de réponse coordonnée est également celui pour lequel le taux d’infection est aujourd’hui le plus bas. De quoi souligner l’importance d’une approche de long terme.

Les entreprises peuvent également adopter une approche de long terme et l’appliquer largement aux objets connectés, pour aider à assurer la sécurité de ces appareils et la confiance en eux.

Adapté de l’anglais.

Pour approfondir sur Gestion de la sécurité (SIEM, SOAR, SOC)

Close