Spécial sécurité : politique et malware, mélange sulfureux

1 - Politique et malware, mélange sulfureux
2 - Hit-parades des bugs et bugs des hit-parades

1 - Politique et malware, mélange sulfureux
Est-ce le fruit de certaines affinités électives ou, au contraire, une « attirance des contraires » ? Toujours est-il que politique et malwares font, ces jours-ci, un mariage prometteur. A commencer par la prise de fonction du président des USA qui, sans grande surprise, sert de plateforme de lancement à W32/Waledac.gen.b (ou Waledec selon le détecteur utilisé). L’Avert signale la chose en précisant que le site web servant de vecteur d’infection est conçu de manière «  très professionnelle ». F-Secure, de son côté, offre trois captures d’écran, trois images qui résument l’attaque, du courriel d’incitation à la page html d’hébergement du malware, en passant par une série de ping qui met en évidence le rapide changement d’IP du Web « fast fluxé » pour les besoins de la cause. A noter que les noms de domaine servant cette infection sont tous enregistrés en Chine. Ca, c’était l’histoire des malwares qui profitent de la politique. Officiellement, l’investiture du nouveau président ne fait réellement trembler que les services de sécurité, qui partent à la chasse aux illuminés et autres activistes d’extrême-droite. Dans ce cas précis, les hommes de la sécurité redoutent un peu plus une balle perdue qu’une attaque virale ou qu’une opération de phishing.

Passons maintenant à la politique qui profite des malwares, avec ce papier de Dancho Danchev qui s’est penché sur une sorte de groupuscule d’« étudiants » sympathisants pro-israéliens qui recrutent des cyber-guerriers pour combattre les ordinateurs palestiniens à grands coups de dénis de service. En Israël comme en Chine ou en Russie, l’étudiant patriote incontrôlé est une valeur sûre et qui sait obéir au doigt et à l’œil. Si seulement tous les conflits pouvaient se résumer à quelques escarmouches de code… Quoiqu’il en soit, les patriotes israéliens susmentionnés sont peut-être vindicatifs, mais ils sont surtout prudents. Leurs hébergements changent de domaine avec une régularité métronomique, histoire de ne pas attirer trop rapidement une riposte des cyber-policiers locaux. Danchev rappelle que malwares, politique, guérilla et hacking en période de conflits armés ont toujours fait bon ménage : blitz russo-géorgien, cyber-guerriers chinois partant en guerre contre les infrastructures diplomatiques du monde occidental, manuels de combat numérique à l’usage des cyber-jihadistes… et ce ne sont là que quelques uns des plus récents évènements recensés. L’un des premiers « warwares » recensé est le fameux Jerusalem B, alias Vendredi 13, un antique virus à exploitation d’interruptions créé en 1987, et dont l’écriture a été revendiquée non-officiellement par l’OLP.

2 - Hit-parades des bugs et bugs des hit-parades
La liste des 25 « fautes » de programmation les plus souvent commises (voir article « happy new bug » du 14 janvier ), ne semble pas soulever un enthousiasme général. Quelques esprits critiques pensent que de telles listes ne servent à rien, et qu’elles pourraient même provoquer un effet contraire à ce qui est recherché. A lire donc deux interventions, l’une de Gary McGraw dans les colonnes d’InformIT, intitulée « 11 raisons expliquant pourquoi les listes ‘’top ten’’ ne fonctionnent pas », et l’autre publiée sur le blog de Matasano, titrant «  Pourquoi les spécialistes des tests de pénétration détestent les listes de vulnérabilités ». En résumé, nos deux experts pensent – ceci étant le reflet de leur expérience -, que polariser l’attention des usagers sur une « dizaine d’erreurs majeures à ne pas commettre ou à corriger » limite considérablement leur attention aux points mis à l’index. C’est, expliquent-ils, une sorte « d’effet Owasp », un effet pervers inattendu des campagnes de sensibilisation. D’ailleurs, pour 25 failles ou erreurs mises sous les feux de la rampe, l’on peut en trouver 25 autres tout aussi dangereuses et qui ne sont pas autant médiatisées… et il suffit d’une seule faille exploitable pour qu’un système soit compromis.

McGraw se demande également à qui s’adresse ce message. En priorité, semble-t-il, aux sociétés d’audit. Car, si la sensibilisation « marchait » auprès des développeurs, cela ferait belle lurette que l’on ne découvrirait plus de trous conduisant à des XSS, BoF et consorts. Les directions, quant à elles, n’ont cure de ce genre d’alertes… trop techniques, pas assez « gestion des risques », trop éloignées des considérations financières qui font équilibrer coûts des procédures de développement et pertes potentielles en cas d’exploitation. Et puis, continue McGraw, cette zoologie de la faille, cette taxonomie des dangers n’est que le prélude à une éventuelle campagne de nettoyage… il serait bien plus intelligent de sortir des codes propres, autrement dit de modifier les habitudes de programmation à la source plutôt que de tabler sur le succès d’opérations correctives a posteriori. D’ailleurs, cette liste des dangers est à peine apprise qu’elle est déjà dépassée. Les failles évoluent avec les technologies, et s’échiner à rechercher des catégories de failles plutôt que de se concentrer sur un cahier des charges de la sécurité est vain. D’ailleurs, pour chercher des failles, il y a des outils automatiques qui font ça très bien. Ce dernier avis est peut-être un peu spécieux. L’on peut d’ailleurs se référer aux démonstrations d’André Gironda sur le «  continuous prevention testing »

…