Spécial sécurité : le phishing via de véritables sites bancaires

Sommaire

- 1 - Le phishing via de véritables sites bancaires

- 2 - Downadup, un peu d’open source, deux doigts d’intox

- 3 - Happy new bug et appels de marchés d’Etat

1 - Le phishing via de véritables sites bancaires

Torturée, la dernière trouvaille d’Amit Klein, CTO de Trusteer ? Probablement. Mais indéniablement efficace. Imaginons un internaute en train de consulter l’état de son compte en banque en ligne, nous raconte Klein. Il s’authentifie normalement, après avoir vérifié la solidité de sa session SSL, la date fraîcheur et la qualité du certificat SHA1 échangé… et muse, parallèlement, sur d’autres sites Web. Soudain, un « popup » aux armes de sa banque s’affiche. Soit pour réclamer une nouvelle authentification après expiration d’une session trop longtemps inactive, soit pour inviter le client à remplir une enquête de satisfaction. Rien de très inquiétant au contraire, puisque l’usager sait pertinemment que ces messages ne peuvent provenir que de sa propre banque. Mais est-ce bien le cas ?

Pas forcément, nous explique le chercheur. Un défaut du moteur JavaScript commun à tous les navigateurs (Internet Explorer, Firefox, Safari, Chrome) permet à un site Web de vérifier si un utilisateur est, à un moment précis, logué sur un autre site Web. Le reste est simple à imaginer. Il suffit d’imaginer compromettre un site marchand ou d’information réputé et souvent consulté. Ledit site possède une liste précise d’organismes financiers-cibles et une panoplie de « popup » adaptés à chaque situation. Et ce n’est que lorsque se présentera un visiteur arborant précisément ce « drapeau » JavaScript très précis que l’attaque sera lancée.

La probabilité de tomber sur un internaute « multitâches » consultant très précisément le site d’information compromis est faible. Mais est-il aussi faible que le taux de réponse aux courriels d’incitation d’une attaque en phishing ? En outre, l’attaque n’est active –donc décelable- que dans cette configuration exceptionnelle. Le reste du temps, il ne se passe rien, si ce n’est un dialogue très anodin de vérification JavaScript. Enfin, ajoutant que la victime étant psychologiquement réconfortée par le bon déroulement de sa première session d’authentification, les chances de voir l’attaque psychologique couronnée de succès sont excessivement grandes… pour ne pas dire absolues.

2 - Downadup, un peu d’open source, deux doigts d’intox

Certaines semaines s’achèvent dans le calme et la béatitude. Certaines seulement. Conflicker/downadup, que l’on sait réellement empoisonnant, réserve encore quelques surprises. Désagréables bien entendu. F-Secure continue son analyse de la situation (http://www.f-secure.com/weblog/archives/00001580.html) et comptabilisait mercredi dernier 3,5 millions d’IP uniques infectées. 1 million de plus que la veille. La situation est grave mais pas désespérée.

Dans les labos de l’Avert, on dissèque du virus –toujours le même- pour s’apercevoir que ces tripes sont farcies de ruby. La charge utile servant à la propagation du ver repose en fait sur un code Metasploit très précis, ms08_067_netapi.rb. Le niveau de correctif et de service pack, la localisation du noyau, son numéro de version… en un mot comme en cent, les auteurs de malwares font plus que s’inspirer des développements de sécurité open source… ils les pillent littéralement, sans en changer une ligne.

Mais il y a plus retors. Lorsque Downadup frappe, il cherche à infecter toutes les ressources auxquelles il peut accéder. Les shares réseau, bien sûr, mais également les périphériques de stockage, dont les clefs USB. Une propagation qui s’accompagne de la création d’un module de lancement. C’est un vieux réflexe d’auteur de virus, qui remonte à l’aube des infections « boot sector ». Mais cette fois, le lanceur prend la forme d’un fichier Autorun, nous dit Bojan Zdrnja du Sans. Mais un autorun dont l’exécution s’affiche avec la formule « Ouvrir le dossier et afficher les fichiers » dans la section « installer ou exécuter un programme ». Une très légère inattention, et l’opérateur-victime, croyant déclencher un simple browse de répertoire, lance l’exécution du virus. C’est là une preuve éclatante que les auteurs de Downadup maîtrisent parfaitement les techniques de social engineering.

3 - Happy new bug et appels de marchés d’Etat

Les fonctionnaires de l’Etat de New York semblent avoir apprécié la lecture du dernier document du Sans. Au début de cette semaine, les labos de Raleigh avaient en effet publié les résultats d’une étude approfondie dressant une liste des « 25 erreurs de programmation à ne plus commettre à l’avenir ». Si ces erreurs sont parfaitement connues, elles devraient pouvoir être évitées, pensent lesdits fonctionnaires. Ils envisagent alors d’utiliser ce document comme référentiel, intégré dans tout nouveau contrat de développement ou de sous-traitance informatique passé avec l’Etat. C’était simple, il suffisait d’y penser, nous apprend Security News. En précisant par contrat qu’il ne doit plus y avoir de risque de cross site scripting ou de possibilités de buffer overflow, les logiciels seront bien plus sûrs, car « coded security in mind ».

On ne peut que s’incliner devant la toute puissance imaginative de l’Amérique. Car qui, avant eux, aurait eu l’idée d’écarter tout risque d’erreur de programmation en ajoutant un simple avenant dans les contrats de service? C’est en précisant les choses, en les formulant qu’on évite tout malentendu. D’ailleurs, ne demande-t-on pas aux voyageurs traversant l’Atlantique de signer, sur l’honneur, un formulaire les engageant à n’avoir jamais été membre du parti Communiste ou Nazi, ou de n’échafauder aucun plan machiavélique dans le but d’attenter au Président des Etats-Unis ? Ainsi, engagé moralement par sa propre signature, le touriste passant devant la Maison Blanche sortira plus volontiers son Nikon Coolpix que son canon portatif de 105 sans recul. Tout comme le programmeur, qui hésitera à outrepasser la vérification des champs de saisie ou à faire fi des mécanismes de protection mémoire tels que DEP et ASLR. On sous-estime souvent la puissance pacificatrice d’un bon contrat soutenu par une horde d’avocats prêts à en découdre. Le codex l’emporte sur le debugger et la méthode de développement structurée.

Ce genre de bonne résolution, toutefois, risque fort de ne pas dépasser les frontières de l’Etat de New York. Car, si d’autres Etats, si le Gouvernement Fédéral, pire encore, si toutes les Administrations du monde Occidental Civilisé venaient à avoir la même idée, l’industrie informatique de ce même monde civilisé pourrait bien en vaciller sur ses bases, pour enfin s’écrouler. Il faut savoir que la collégiale chargée d’établir ces règles du « secure coding » susmentionnées compte des gourous sécurité émargeant chez Microsoft, Oracle, Apple, Red Hat… Et qu’adviendra-t-il lorsque l’Etat de New York ou lorsque leurs émules invoqueront ces nouvelles règles lors du renouvellement des licences des systèmes d’exploitation, outils bureautiques ou SGBD ? Pour que le monde logiciel puisse survivre aux impacts dévastateurs de cette « bug free software assurance », il faudrait lui adjoindre un addendum exonérant de toute obligation les entreprises ayant participé à la rédaction de ces bonnes pratiques. Une sorte de témoignage de reconnaissance pour services rendus à la cause du développement.