Une rapide histoire de l’informatique d’espionnage, couvrant de 1914 à 1972, rédigée par la NSA, est disponible sur le site Cryptome. A lire, ne serait-ce que pour l’ironie de certains noms de code …
Instructables publie un intéressant « pas à pas » sur la manière de spoofer le contenu d’une piste magnétique (de carte de crédit par exemple) à l’aide d’une bobine, d’une languette de métal et d’un Arduino
Dans un billet publié sur le blog sécurité de Google, l’équipe annonce que la politique de primes destinée à récompenser les chercheurs ayant trouvé des failles sur Chrome, sera étendue à Gmail, YouTube, Blogger et Orkut. Une recherche de failles qui se propage donc à toutes les applications « en ligne » en question. Les logiciels et noyaux locaux, tels que Android, Picassa, Google Desktop etc sont exclus de ce programme… du moins pour l’instant, précise l’auteur du billet. Un auteur qui rappelle les types d’attaques ou de vulnérabilités visés, et qui précise au passage que cet encouragement ne saurait justifier une attaque en déni de service ou toute autre tentative d’exploitation directe desdits services en ligne. En bref, ceci n’est pas une invitation à pirater YouTube ou autre en toute impunité. Sont naturellement exclus de ce programme les mineurs. Tout de même… si les marmots de Maternelle Supérieure passent leurs récrés à rédiger du bug-report, ça risque de tourner rapidement à la catastrophe et à la banqueroute. Le précédent Mozilla est là pour nous le rappeler. Sont également bannis les développeurs des pays considérés comme dangereux : Cuba, Corée du Nord, Iran, Soudan, Syrie… Et si l’auteur de Stuxnet était Nord-Coréen et avait utilisé un trou Gmail ? On ne sait si une telle réserve tient de la crainte d’avoir à recevoir une information sécurité d’un tel pays, s’il s’agit plus simplement de ne pas souhaiter envoyer les 3133,7$ au ressortissant d’un état-voyou. Ou bien encore, ce refus de voir ces pays « exporter » des failles que leurs chercheurs pourraient découvrir n’est peut-être là qu’une tentative détournée d’aide au développement interne, desdits pays souvent économiquement défavorisés. Une façon peut-être de favoriser la naissance d’une véritable industrie nationale de logiciels de pentesting ou d’inciter à l’ouverture d’écoles capables de sortir des CISSP par wagon …
La sécurité des appareils mobiles laisse souvent à désirer. Le dernier « buzz » sur le sujet concerne une série de contournements du code PIN de l’iPhone. Certaines de ces méthodes ne concernent que l’iPhone 4, d’autres également le 3 Gs et peut-être certaines éditions moins récentes, d’autres enfin sur les deux modèles mentionnés.
Toujours à propos d’iPhone, toujours à propos de sécurité mal digérée : depuis quelques jours, le lecteur audio-vidéo multiformat VLC est disponible sur Iphone via iTune. Mais voilà que Rémi Denis-Courmont, chef de projet de ce programme Open Source, envisage sérieusement de retirer son logiciel du catalogue en ligne, compte-tenu des libertés (ou plus exactement des limitations de liberté) que prend Apple en matière de droits d’utilisation dudit logiciel (et plus exactement en liant VLC à un mécanisme de DRM, contraire à l’esprit de la licence GNU). Rappelons que les DRM sont des mécanismes prétendument de « sécurité » qui ne participent en rien à la protection de l’appareil sur lequel ils sont installés. C’est une révélation Gizmodo et iLounge.
Encore à propos de l’iPhone et de sécurité ce très intéressant billet signé Jimmy Shah de l’Avert, qui fait référence à une communication de Collin Mulliner et Jean Pierre Seifert sur la faisabilité d’un botnet à base d’iPhones. La présentation des deux chercheurs explique dans les grandes lignes la supériorité d’une part, des injections de SMS « binaires » et non plus textuels (ce qui offre l’avantage de « compacter » les commandes) et d’autre part, des modes de fonctionnement reposant sur un protocole P2P pour qui une NAT (table de translation d’adresses IP) est totalement transparente. Car, que ce soit via son port WiFi, soit par le truchement de son accès au réseau GSM, un terminal mobile est pratiquement systématiquement masqué par une NAT, passerelle que n’apprécient pas les botnets traditionnels. Ce botnet de laboratoire, qui était présenté lors de la dernière manifestation Française Malware 2010, n’intégrait pas de mécanisme de réplication de la charge infectieuse… mais ce n’est là qu’un détail. Ces travaux ont prouvé qu’il était possible de faire converser une série de terminaux compromis avec leur C&C (centre de commande), et que pour ce genre d’attaque, l’iPhone avait toutes les capacités nécessaires au bon fonctionnement d’un tel réseau de malwares. L’iPhone et l’absence de filtrage et de mesures de protection contre les envois de binaires sur les réseaux d’opérateurs. Si l’on ne peut pas trop en vouloir à Apple à propos de l’inconsistance technique de ses appareils –trop « jeunes » techniquement pour prétendre à une certaine robustesse- ce n’est en revanche pas le cas des réseaux d’opérateurs qui, eux, existent depuis plus d’un siècle. Et sur lesquels la possibilité d’une série d’attaques binaires est connue depuis fort longtemps… au moins depuis les premiers tests de solidité des réseaux de messagerie X400. Une amnésie, disent certaines mauvaises langues, provoquée par une épidémie de « mise à la retraite anticipée » propre à quelques opérateurs historiques.
Exploit Adobe (Flash player, Reader et Acrobat) détecté « dans la nature ». Il tirerait parti de la faille CVE-2010-3654. Une mesure d’amoindrissement peut limiter les dégâts potentiels : info détaillée sur le blog Fortinet.