L’attaque du rootkit lnk –plus médiatisé pour les subtiles innovations qu’il contient plutôt que par sa dangerosité réelle- provoque bien des réactions, certaines attendues, d’autres pour le moins surprenantes. A commencer par celle du principal intéressé, Siemens, éditeur du logiciel de supervision de processus industriel qui conseille, nous apprend un papier de Bob McMillan de Network World, « de ne surtout pas changer les mots de passe de WinCC »… cela pourrait avoir des conséquences sur le pilotage des processus. Qu’un changement de crédence puisse modifier le comportement d’une boucle PID ou un enchaînement logique d’une chaîne de « process control », voilà qui laisse songeur quant aux méthodes SDL mises en œuvre et à l’interdépendance des parties de programmes logiquement indépendantes. Sur le site d’information en langue Française, pas la moindre alerte de sécurité. Sur cette même page d’accueil, le flash d’une icône animée clame « Cliquez ici, nous vous rappelons ! ». L’on clique donc, ce qui provoque, de la part des principaux navigateurs, l’alerte suivante :
Le certificat de sécurité du site a expiré !
Vous avez tenté d’accéder à webbies.siemens.fr, mais le serveur a présenté un certificat arrivé à expiration. Aucune information ne permet de déterminer si le certificat a été compromis depuis son expiration. Cela signifie que Chrome ne peut pas garantir avec certitude que vous communiquez avec webbies.siemens.fr et non avec un pirate informatique. Ne poursuivez pas. Par le plus grand des hasards, le certificat en question est d’origine Verisign, expiré depuis le 11 juillet dernier.
Oserions-nous suggérer à l’équipe de développement de Siemens de demander quelques conseils aux auteurs du « rootkit .lnk » sur l’art et la manière de bien employer les certificats ? Ou plus simplement d’éviter de coller un proto https sur de simples pages d’informations produits… la paranoïa peut rapidement tourner au ridicule.
Si le fait de modifier un mot de passe sur un système supportant WinCC peut potentiellement provoquer des catastrophes, l’on peut imaginer que les modifications de clefs de registre suggérées par Microsoft appartiennent également à la catégorie des actes Ganz Verboten par Siemens. Il faut dire qu’en désactivant toutes les icônes de raccourcis, l’usage d’un Windows conventionnel commence à devenir un peu laborieux. Mais Microsoft persiste et signe. Pour éviter aux glorieux professionnels de l’intégrée-dérivée et du capteur-actuateur d’utiliser l’explosif Regedit, l’éditeur consacre toute une page « Fix It » de la « K-Base » qui automatise l’activation ou l’élimination de la mesure de contournement.
On est moins radical, au Cert Lexsi. D’autant plus, explique Sylvain Sarmejeanne, que l’immolation par Regedit des fonctions WebDAV ne bloque en rien la propagation du rootkit par le biais de clefs USB baladeuses. La solution, explique-t-il, c’est AppLocker, l’une des nouveautés de Windows 7 et 2008 R2. Article fort intéressant traitant donc du blocage des DLL à l’aide des outils intégrés au système. Las, prévient l’auteur, la solution n’est pas absolument parfaite puisque, comme nous le signalions hier, l’invocation d’une DLL peut parfois échapper aux principaux contrôles de filtrage et de localisation effectués par le noyau. S’ajoute également un autre obstacle à l’utilisation d’AppLocker : le monde du contrôle de processus industriel a horreur des nouveautés, considérées par défaut –et non sans une certaine sagesse- comme de véritables nids à bugs inconnus. Là où l’automate programmable et le robot pneumatique règnent en maîtres, c’est surtout du XP SP3 et, parfois, quelques traces de Vista que l’on rencontre. Adieu AppLocker, bonjour les SRP (restrictions logicielles liées à une politique de sécurité), ainsi que le prêche Didier Stevens. Reste que les « policies » restrictives ne sont pas non plus d’une absolue fiabilité, et des mesures de contournement sont toujours possibles.
C’est l’Avert qui boucle ce rapide tour d’horizon du « virus .lnk », avec une FAQ très simple autour de ce rootkit : quelles sont ses méthodes d’exploitation, l’exploit nécessite-t-il un code pour fonctionner, quelles sont les conditions à réunir pour que le risque puisse se présenter.. etc. Un papier utile qui rappelle que, si seuls les industriels utilisant WinCC sont directement visés, toute machine Windows est susceptible d’être frappée par cette infection. Et surtout, insistent les ingénieurs de McAfee, « l’exploit .lnk » a de très fortes chances de faire des émules et d’être employé par d’autres auteurs de malwares moins élitistes et plus entreprenants.