Spécial sécurité : Faux flag Firefox, fabuleux filoutages et filtrages fantaisistes

Sommaire
1 - Faux flag Firefox, fabuleux filoutages et filtrages fantaisistes
2 - Quand les virus se propagent par le métro
3 - L’Inde : vite, un noyau, dépêche !

1 - Faux flag Firefox, fabuleux filoutages et filtrages fantaisistes
Le blog F-Secure est tombé sur une nouvelle technique d’attaque d’un genre inattendu : la fausse page d’alerte Firefox. De l’onglet au contenu du message, en passant par l’apparence générale, tout laisse à penser que l’internaute visé a sous les yeux un message d’alerte généré localement par son propre navigateur alors qu’il s’agit en fait d’une véritable page HTML distante imitant le goût, l’odeur et la couleur de ladite page d’alerte. Ce n’est là techniquement qu’une attaque en « ingénierie sociale », mais qui se distingue par son originalité. Le seul indice pouvant éveiller les soupçons de l’éventuelle victime est cet inhabituel bouton « Download Updates » qui n’apparaît jamais dans les véritables pages de blocage intégrées au navigateur. Lequel bouton déclenche illico la réception d’un faux antivirus.

Si, d’un point de vue technique, les chasseurs de virus y verront peu de différence avec les attaques en « pseudo codec » si fréquentes depuis ces deux ou trois dernières années, les spécialistes sécurité remarqueront sans la moindre hésitation une adaptation du milieu du malware à une contre-attaque destinée à accroître la sécurité du poste de travail.

A ce petit jeu, on peut se demander si la partie n’est pas perdue d’avance pour le camp des « blancs ». Effectuons un petit voyage dans le temps. Plus précisément à l’époque où les navigateurs ne possédaient aucun mécanisme de sécurité. Les premières usurpations et tentatives d’injection par le port 80 ont eu pour première conséquence l’intégration de vpn/ssl dans les navigateurs. Puis les attaques iframe, les certificats « autosignés », ou plus récemment les vrais certificats Verisign ont fait du « petit cadenas » ou de la barre d’URL verte des signes extérieurs d’inutilité. Sont ensuite apparues les tentatives de déclenchement de saturation de buffer via la barre d’adresse, puis les attaques en injection, à leur tour corrigées illico avec de meilleurs contrôles des champs de saisie, les filtrages de chaînes, la suppression d’erreurs de conceptions diverses notamment en matière de lancement d’applets ou de code Java. Contre-mesures rapidement contournées par le recours à d’autres astuces telle que l’utilisation de caractères expédiés en hexa, l’exploitation de caractères d’échappement (quand donc est morte la possibilité de glisser un 0a0d ?) etc. Les outils de filtrage intégrés sont les derniers de cette génération d’add-in de riposte. Ils sont plus intelligents, certains d’entre eux reposant d’ailleurs sur un service permanent assuré par l’éditeur du navigateur même. Mais à peine ces détecteurs d’attaques en drive by download et ces avertisseurs de sites douteux font-ils leur apparition, qu’ils sont immédiatement victimes d’une sorte de « html spoofing » tel que celui relevé par l’équipe de F-Secure.

Entre les cadenas fermés qui ne prouvent plus rien, les certificats dont la provenance est douteuse, les barres d’adresses colorées que l’on peut truquer à façon, les pages d’avertissement qui servent à compromettre l’usager, quel niveau de confiance peut encore avoir le fameux « utilisateur final et finaud » envers son client d’affichage html ? Si cette course à la contre-contre-mesure se poursuit, combien d’indicateurs prétendument infalsifiables les éditeurs seront-ils capables de faire s’allumer en vain, rendant la lecture des signaux de sécurité totalement incompréhensible ? Car les navigateurs modernes ressemblent de plus en plus à ces autobus qui croisent entre Lahore et Bombay, surchargés de lumières et de guirlandes, mais dont l’emprunt se fait au péril du voyageur. La faute, bien sûr, n’en incombe pas aux éditeurs, qui tentent par tous les moyens de parer une attaque dès qu’elle est signalée. Encore moins des concepteurs, dont le rôle est avant tout de concevoir un programme aussi génial et séduisant possible pour que les usagers l’adoptent sans discussion. C’est d’ailleurs là que se situe le hiatus principal attaché à la notion de SDL. On ne peut associer à la fois la créativité d’un auteur de roman, de logiciel, de musique ou de toute autre discipline avec le rigorisme d’une méthode SDL en matière de programmation, école de romancier dans la veine « écrire comme … » ou filière de composition formatée pour fabriquer du « hit ». Si Internet avait été pensé, conçu, inventé pour être sûr et bien écrit, il se serait appelé X400. On ne peut non plus porter atteinte au « génie » des auteurs de malwares, d’une toute autre nature, certes, mais qui est bien réel.

Tant que la notion de sécurité d’un logiciel ne relèvera pas d’une idée géniale qui remplacera le principe d’action-réaction (ou attaque puis défense a posteriori), il sera bien difficile de penser et d’agir autrement. La faute, s’il y en a une, serait du fait de deux professions qui n’existent pas, ou pas encore. Celle de « nettoyeur de code et de bonnes idées qui ont fait long feu », et celle de « temporisateur de contre-mesures géniales » chargé de l’élimination malthusienne des projets dont l’espérance d’efficacité ne dépasse pas 6 mois. Deux corps de métier qui devront tôt ou tard travailler avec d’une part les grand-maîtres du Software Lifecycle Development et autres approches de « safe coding », et d’autre part avec les ninjas du filtrage de niveau 7 qui semblent toujours connaître des déboires avec ce sacré port 80.

2 - Quand les virus se propagent par le métro
Nos confrères de Network World relatent un récent exercice de sécurité mis en œuvre par le DHS, dans le but d’& eacute;tudier la propagation des virus... et gaz contaminants dans le métro de Boston. Virus biologique bien sûr. Pour ce faire, l’équipe de scientifiques chargée de l’enquête a diffusé des gaz inoffensifs dans les couloirs du réseau de transport, et en a contrôlé la diffusion en fonction de l’heure, de la température, du mouvement des rames qui agissent tel des pistons pneumatiques et des configurations architecturales. Ceci dans le cadre de deux campagnes qui se sont déroulées en décembre de l’an passé et août de cette année, donc à des températures et taux hygrométriques différents. Deux paramètres importants lorsque l’on tente d’utiliser des vecteurs d’attaque bactériologiques.

Il semble que les résultats effectifs de cette étude soient tenus relativement secrets, puisque pas une ligne n’a été rédigée par nos confrères sur l’impact possible d’une telle attaque ou sur l’efficacité du procédé. Tout au plus les différentes titres abordant ce sujet se sont contentés faire un amalgame et de rappeler le hack de la carte d’accès à base de RFID (Myfare) qui défraya la chronique lors de la Defcon 16, plus en raison de la réaction brutale et irréfléchie du MBTA (métro de Boston) que de la difficulté technique de la faille de sécurité. L’on est très loin des considérations chimico-botuliennes de cet exercice du DHS… à moins que l’on puisse considérer l’art de sauter par-dessus un portillon ou resquiller le prix d’un ticket de métro comme les préliminaires d’une attaque terroriste.

Il reste cependant que cette simulation doit être classée dans la catégorie des attaques Scada, visant non pas à porter atteinte à l’intégrité du système de transport, mais utilisant le réseau de transport en question pour propager la menace. Les « bombes bactériologiques », aussi incontrôlables qu’un lâcher de virus informatiques, ont depuis toujours fasciné les armées du monde entier, qui ne cessent de tenter de les utiliser dans des milieux plus ou moins confinés afin d’en maîtriser la portée. On attribue la première guerre bactériologique aux Mongols qui, durant le siège de Caffa en Crimée, catapultèrent les cadavres de leurs soldats morts de la peste pour la propager à toute la population assiégée. Cette tentative fut, pense-t-on, à l’origine de la Grande Peste qui fit 20 millions de morts en Europe (tuant un habitant sur deux) entre 1348 et 1350. Plus près de nous, l’on peut se rappeler de l’attentat au gaz moutarde perpétré par la secte Aum dans le métro de Tokyo en 1995 avait fait 12 morts et 50 blessés graves, alors que l’attaque avait été circonscrite à une seule station et ne reposait pas sur l’utilisation de virus organiques.

3 - L’Inde : vite, un noyau, dépêche !
Selon l’Economic India Times, la Défense du pays devrait un jour disposer de son propre système d’exploitation. Un noyau conçu par des ingénieurs du pays, reposant sur une structure précise et maîtrisée « closed source » et, l’on imagine, dépourvu de tout soupçon de « backdoor », de « clef de séquestre étrangère » ou plus simplement de failles de sécurité connues par tout le monde. Pour l’heure, l’équipe de développement ne compterait qu’une cinquantaine d’ingénieurs.

Si le projet arrive à terme, il est très probable que ce pays, probablement l’un des plus productifs en termes de développements logiciels, sera capable de déployer son « OS national » aussi bien sur l’intégralité de ses réseaux d’administration, de défense et d’infrastructures sensibles Scada, mais également, sous forme de noyau embarqué, sur la plupart des équipements de commutation, sans oublier les passerelles de protection périmétrique.

En France, pays pionnier dans la création et enterrement de noyaux à des fins non-agricoles, l’on a vu ainsi passer des Pick, des Mos, des Prologues, des Mercures qui furent toujours plus grands morts que vivants.