En début de semaine, les utilisateurs de Webroot, aussi bien le grand public que les entreprises, ont eu la mauvaise surprise de constater que le produit de sécurité de bout-en-bout identifiait des fichiers Windows comme malveillants. L’information a rapidement circulé sur Twitter et s’est prolongée sur le forum de la communauté Webroot, où la discussion occupait pas moins de 14 pages. L'entreprise a proposé une solution manuelle pour résoudre le problème, mais de nombreux utilisateurs ont toujours des problèmes pour remettre en état leurs systèmes.

Dans l'industrie des antivirus, ce problème est connu sous le nom de « faux positif », une situation où un fichier non infecté est signalé comme malveillant et bloqué ou supprimé. L’impact de ces faux positifs est variable. Parfois ils perturbent le fonctionnement d’un programme, mais parfois ils peuvent carrément paralyser l’ordinateur, empêchant le système d'exploitation lui-même de démarrer.

Des listes blanches inadaptées 

L'incident Webroot se situe entre ces deux extrêmes : il a effectivement ciblé des fichiers légitimes de Windows, mais pour les mettre en quarantaine. Ce comportement est assez inhabituel, car généralement les vendeurs d’antivirus établissent des listes blanches des fichiers impliquées dans le fonctionnement du système d’exploitation pour éviter les faux positifs. « Un dossier connu pour être ciblé par les logiciels malveillants a été identifié par erreur comme dangereux, et Facebook a été classé comme site de phishing », a déclaré Webroot dans un communiqué envoyé par courrier électronique à nos confrères d’IGN. « Le problème de Facebook a été corrigé, et l'équipe Webroot met au point un correctif pour résoudre complètement le problème de ce faux positif ».

Cette détection incorrecte a duré deux heures, entre 13 h et 15 heures (Mountain Standard Time) aux États-Unis, pendant lesquels les fichiers légitimes ont été marqués W32.Trojan.Gen. Comme le suggère le nom, il s'agit d'une signature générique de détection destinée à supprimer des Chevaux de Troie. Pour l'instant, sur son forum communautaire, Webroot a fourni la solution suivante : l’utilisateur doit se connecter à la console en ligne Webroot et créer manuellement des règles de substitution pour tous les fichiers bloqués à tort. Il doit ensuite attendre soit que le client du nœud final interroge le serveur et rétablisse les fichiers selon les nouvelles règles, ce qui peut prendre jusqu'à 24 heures, soit forcer manuellement l’analyse pour chaque client à partir de la ligne de commande.

Les MSP particulièrement mécontents

Mais, si cette solution semble fonctionner pour les utilisateurs, aussi bien le grand public que les entreprises qui utilisent la solution pour surveiller un nombre relativement restreint d'ordinateurs, elle provoque des problèmes pour les gros environnements, en particulier pour les fournisseurs de services gérés (MSP). « Cette solution n’est pas adaptée aux MSP », a prévenu un utilisateur sur le forum. « Comment suis-je censé faire avec 3 déploiements Webroot Global Site Manager couvrant plus de 3 000 sites clients ? Ce n’est pas possible », a déclaré un autre utilisateur.

Un utilisateur a indiqué qu'il avait récupéré les fichiers concernés à l'aide de la fonction Shadow Copy de Windows. Un autre a déclaré que son entreprise MSP envisageait de porter plainte parce qu'elle devra peut-être dédommager ses propres clients pour ces interruptions. « Nous ne pouvons pas utiliser la solution de récupération, car la plupart des cœurs de serveurs de sauvegarde sont également affectés », a-t-il déclaré. « Certains serveurs ne sont pas encore repartis et ce problème nous décrédibilise auprès de nos clients ». Sur le forum de l'entreprise, les représentants de Webroot ont déclaré qu’ils cherchaient une solution universelle également adaptée aux MSP.