mars 24th, 2011

Passé un léger temps de réflexion, les experts sécurité qui réfléchissent avant d’écrire émettent enfin leurs avis. Cédric Blancher ouvre le bal, en déclarant un « Kerckhoffs #FAIL ? ». Et d’expliquer en termes simples (ou presque) comment fonctionne un token RSA et comment le secret entourant l’intégration de ce mécanisme de sécurité ne devrait pas être un secret susceptible d’amoindrir la fiabilité du système s’il venait à être éventé. Les amateurs de littérature sur le chiffrement peuvent consulter une version Française du principe ici discuté sur le site de Fabien Petitcolas, Kerckhoffs Fail également pour Jeff Jarmoc Dell Security, ex-SecureWorks, ex-Luhrq. Là également, une approche méthodique. Kerckhoffs Fail encore, avec un véritable cours dispensé par l’un des plus prestigieux professeurs en la matière, Steve Bellovin. Article assez didactique pour que même un journaliste ait l’impression de comprendre de quoi il ressort. Plus de passion et de rancœur pour Steve Gibson, qui critique également ce mauvais usage du secret autour de l’implémentation du mécanisme. Un Gibson qui, au passage, écorne lui aussi la culture du secret médiatique et de la langue de bois cultivée par Art Coviello. « It would have been difficult for any bureaucrat to be less clear about what they know ». Propos nettement plus tranchés que ceux de Jeff Jarmoc « Due to RSA’s public nondisclosure of specific details regarding the nature of the compromise, the impact of this breach on their customers remains largely unknown ». Mais dans les deux cas, l’assourdissant silence de RSA est condamné. Bellovin se montre encore plus retors. Une faille d’intégration ? Allons donc… je suis persuadé qu’une entreprise aussi sérieuse que RSA a su éviter des écueils aussi évidents pour de vrais professionnels tels qu’eux, dit-il en substance. En revanche, le « back office » de RSA s’est montré faillible. C’est dans la gestion des comptes clients, des clefs, des renouvellements d’abonnement qu’il y a eu fuite, et c’est là qu’il risque d’y avoir un simple vol direct de clefs ou l’injection de fausses données. La crypto peut très bien être solide, mais qu’en est-il du logiciel qui l’administre ?

Le S.F. Examiner rapporte qu’une nouvelle technique d’escroquerie à la carte de crédit semble se répandre sur la Côte Ouest ; le hack des distributeurs à la colle. Le principe de fonctionnement est simple : les escrocs repèrent un DAB équipé à la fois d’un clavier de commande et d’un écran tactile. Ils bloquent ensuite, avec quelques gouttes de colle cyanoacrylate les touches « entrée » « annuler » « interrompre l’opération » de l’appareil. Après avoir introduit leur carte de crédit dans l’appareil puis, conformément aux instructions, entré le code PIN d’identification de compte, les victimes sont alors incapables de poursuivre leur opération de retrait, ni même de récupérer leur carte. Le temps qu’elles pénètrent dans la banque pour effectuer une réclamation et obtenir la restitution de leur carte, les voleurs ont achevé l’opération à l’aide de l’écran tactile, retiré l’argent et pris la fuite. La situation de stress dans laquelle se trouve le possesseur de carte au moment où l’appareil refuse de répondre est telle qu’il ne pense pas à utiliser l’interface digitale. C’est là une attaque relevant plus de l’ingénierie sociale que du hack technique. Bien entendu, si cette technique était utilisée en France, les services de communication des principales banques ne manqueraient pas d’en informer le public comme elles en ont l’habitude …

Une vulnérabilité du moteur Webkit,également utilisé par RIM, exposerait les utilisateurs de Blackberry à des risques d’attaques distantes. La faille, explique le bulletin d’alerte, possède un indice CVSS de 6.8 (catégorie critique) et a fait l’objet d’une preuve d’exploitation à l’occasion de la dernière CanSecWest, lors du concours P0wn20wn. La seule mesure de mitigation consiste, pour l’instant, à désactiver Javascript sur tous les terminaux, en attendant qu’une rustine soit « poussée » par l’éditeur. Le bulletin d’alerte intègre une série d’URL pointant sur des pages explicatives traitant de la désactivation de ladite fonction javascript selon les différents modèles commercialisés (Torch, Style, Bold, Curve et Perl). Une autre possibilité évoquée consiste à désactiver purement et simplement le navigateur via l’administration BES… mesure efficace mais quelque peu expéditive.