La Banque de France n’est pas un moulin… ou presque pas

Zero day : Et si TippingPoint aidait les blackhats ?

Oh, la perfide (et troublante) remarque rédigée sur le blog d’Eric Romang. L’auteur constate qu’il y aurait une étonnante relation entre la découverte de certaines failles exploitables par quelques chercheurs de TippingPoint et la naissance de quelques malwares. Le lien est d’autant plus facile à faire que chaque faille est revendiquée et immatriculée par l’index CVE tenu par le NIST.

Or, fait remarquer Romang, TippingPoint déclare officiellement « vendre de l’exploit » aux « organisations » (généralement gouvernementales). En outre, il faut garder en mémoire que l’entreprise est depuis le début des années 2000, un acteur connu du monde des IDS, avec une compétence telle que 3Com s’en est porté acquéreur… un 3Com qui, en 2005, a été absorbé par Hewlett Packard. En d’autres termes, une faille découverte par TippingPoint est très rapidement intégrée et « poussée » dans les bases de connaissance des IDS HP, très souvent avant même que l’éditeur concerné n’ait lui-même écrit les premières lignes de sa rustine logicielle. Et notre blogueur sécurité de préciser au passage, à propos de la faille CVE-2012-4969 (celle-là même qui est corrigée par la rustine « out of band » MS12-63) que celle-ci était connue du MSRC Microsoft depuis au moins un mois.

Ce qui fait se poser à l’auteur un certain nombre de questions : une fuite au sein du ZDI ? Une erreur de crédit en paternité de la part de Microsoft ? Un « reverse » des correctifs poussés sur le réseau de mise à jour des IDS Hewlett Packard ? Une fuite chez un  client ayant acheté cet exploit auprès du ZDI ?

A ceci, David Maynor rappelle qu’il avait, lors de la BlackHat 2007, publié un article intitulé  A simpler way of finding 0day . Papier qui explique combien il peut être simple de se lancer dans le « reverse engineering » des correctifs émis à destination des IPS/IDS et ainsi devenir le Number One des auteurs de Zero Day.

Vieux débat, vieilles craintes et problème sans solution réelle. Il y a toujours eu, depuis l’invention du gourdin et du casse-tête en silex, une course au savoir, une course à la contre-mesure. Course qui nous apprend que l’évolution des risques n’est pas une succession de menaces (il y a eu les virus boot, puis les virus furtifs, puis les botnets…) mais une accumulation de menaces (il y a les virus boot ET les virus furtifs ET les botnets…) qui étend progressivement le front défensif des systèmes d’information. C’est d’ailleurs la raison pour laquelle il est bon de rappeler que personne ne peut espérer se protéger en respectant de prétendus « basics » que l’on aurait oublié par hasard avec le temps. Les stratégies de défense des SI deviennent de plus en plus complexes, de plus en plus coûteuses… et surtout de plus en plus sujettes à des compromis.

Reverse des rustines virtuelles expédiées vers les outils de défense périmétrique ou fuite d’information, peu importe. L’affaire du CVE-2012-4969 et la remarque d’Eric Romang nous rappellent que la fenêtre de vulnérabilité s’ouvre dès qu’un chercheur découvre une faille et y associe un exploit (et non pas en date de l’alerte de l’éditeur), et ce, quelles que soient les mesures de conservation du secret qui protègent cette découverte. C’est là une donnée importante dans l’appréhension des analyses de risque et dans l’établissement de métriques sérieuses, et qui nécessite à la fois une véritable transparence et une grande rapidité des outils de traitement d’informations relatives aux menaces.

IE8 « non grata » dans le Cloud Google

Le 15 novembre prochain, Google n’assurera plus le support des applications « Google Apps » sur Internet Explorer 8, forçant quelques millions d’utilisateurs attachés à leur Windows XP à changer de navigateur… à tout hasard Chrome ?

Principale raison évoquée : l’adoption de HTML5. Ce qui laisserait sous-entendre que même I.E. 9 serait à terme en partie dépassé, et que la migration vers I.E.10 (pour les inconditionnels de Microsoft) constituerait la seule échappatoire possible. Reste que ces navigateurs de nouvelle génération ne sont guère compatibles avec les vieux, très vieux noyaux. Le Cloud, dont le principal argument reposait précisément sur cette non-obligation de participer l’escalade technologique du « endpoint de plus en plus sophistiqué », souffre en fin de compte des mêmes maux que les défunts « thin clients » trop peu évolutifs dont on devait renouveler le parc aussi souvent que de poste de travail « lourd ». Une illusion du Cloud s’évapore, celle des économies réalisées au niveau d’un terminal prétendument immuable et pérenne.

Après Chaouane et Chatoux, SHA3

Alors que bien des réseaux sociaux, entreprises et particuliers utilisent encore l’antique algorithme de hachage SHA1 (régime sans sel), réputé faillible, voici que le NIST se prépare à annoncer le vainqueur du concours SHA3. Le départ de la course est annoncé le 31 octobre 2008, après un appel d’offre relativement médiatisé dans les milieux spécialisés. Le starter retentit, les concurrents abordent la ligne droite et l’on entend rugir les ventilateurs de processeurs graphiques. Le 10 décembre ; ils ne sont plus que 51 candidats retenus. Puis c’est l’hécatombe.

Le 24 juillet 2009, 14 compétiteurs restent en lice, après un gymkhana mathématique aussi meurtrier que le virage de Mulsanne, dans lequel 37 algorithmes y perdront la vie. Le filtrage des premiers comités scientifiques aura été sans pitié. Mais la course continue, les finalistes s’épuisent, seuls les plus résistants aux attaques se disputent la corde. Le 9 décembre 2010, ils ne sont plus que cinq, BLAKE, Grøstl, JH, Keccak, et Skein, tous sur le point d’entamer le dernier tour qui doit durer plus de 3 ans.

Le 16 janvier 2011, les équipes achèvent les dernières opérations secrètes de « tuning » : plus qu’une année de consultation publique. On passe la chicane des tribunes, la ligne d’arrivée est peinte en rouge à la fin 2012. La foule des cryptoanalystes en délire hurle et encourage ses favoris. On a même vu Bruce Schneier brandir une pancarte clamant « Go, Skein, Go », et soutenir mordicus qu’il y aura un vainqueur… car le Nist peut très bien décider d’organiser une nouvelle course si le résultat ne lui convient pas. Ah, que la vie des spécialistes du chiffrement est palpitante et pleine d’imprévus.

Windows 8 : nouveau bios étendu, nouveau bootkit

Il n’est pas sorti de l’œuf que l’on prévoit déjà un moyen de l’assassiner avant même son démarrage. Il, c’est naturellement Windows 8, par le biais précisément de UEFI (Unified Extensible Firmware Interface) l’un de ses mécanismes d’extension Bios que l’on disait aussi sécurisé que les couloirs de Fort Knox. Il serait donc possible, expliquent les techniciens d’IT Sec, entreprise transalpine des environs de Pérouse, de concevoir un malware s’exécutant durant le boot, capable de désactiver au passage les mécanismes de vérification de signature des pilotes ainsi que la fameuse « kernel patch protection » dont la création avait fait hurler d’indignation bon nombre d’éditeurs de logiciels antivirus. L’esprit de Rakshasa n’est pas mort. 

« Tel: » est pris qui croyait prendre

Certains hacks sont parfois simples comme un coup de fil. Ainsi nous le prouve la vidéo de la présentation tenue par Ravi Borgaonkar à l’occasion de la dernière conférence Ekoparty. Le principe de l’attaque est simple et repose sur l’utilisation du protocole USSD (Unstructured Supplementary Service Data). Un protocole destiné aux échanges client-serveur entre un terminal GSM et un service d’opérateur par exemple.

Ainsi, le lien 06 exécute la commande tel : * # 06 # qui affiche le numéro IMEI de l’appareil sans que l’abonné n’ait à taper quoi que ce soit : le démon est dans l’URL. Certains téléphones sous Android acceptent ce genre d’ordre sans demander leur reste, d’autres (les appareils sous IOS notamment) réclament une confirmation… de façon assez hermétique pour qu’un usager peu méfiant accepte sans trop se poser de question. Une majorité de ces ordres sont silencieux, généralement employés par les opérateurs pour activer ou invalider un service ou une fonction auprès des abonnés

Mais parfois, certains codes USSD vont un peu plus loin, explique le chercheur Indien. Notamment chez Samsung, qui a enrichi le vocabulaire interne de son S3 avec une commande d’initialisation des paramètres. Il n’y a que l’espace d’une macro entre un terminal opérationnel et un téléphone amnésique.

Les quelques médias Français qui relatent l’évènement parlent de « faille ». Certains même qualifient ce léger problème d’interprétation des normes comme « terrifiant » et stigmatisent les productions Samsung. Or, l’éclairage donné à ce genre de bug d’intégration touche la totalité des téléphones mobiles, intelligents ou non d’ailleurs. Il y a de fortes chances que dans les jours qui suivent, l’exposé de Ravi Borgaonkar incite pas mal de hacker à  fuzzer et  bruteforcer leurs propres téléphones à tire-larigot,  for fun and profit, cela va sans dire. Les habitués du monde de la sécurité ironisent : «  it’s not a bug, it’s a feature ». Une  feature qui permet d’envisager quelques amusantes opérations qui rappellent le temps pas si éloigné des fichiers « .com » qui n’étaient pas des URL ou des injections javascript dans les adresses Web.

IEEE : Aille, tri poli pour être honnête !

On ne sait s’il faut hurler de rire ou se lamenter devant tant d’inconséquence, lorsque l’on se plonge dans la lecture du papier de Radu Dragusin, expert sécurité travaillant pour le compte du Danois FindZebra : près de 100 000 login et mots de passe de membres de l’IEEE* étaient stockés en clair sur une ressource ftp, parmi un amoncellement de données diverses : statistiques de serveur Web, historique des requêtes http etc. Dragusin, dans sa grande sagesse, ne publie aucun passage, même savoureux, des données exposées. Rappelons toutefois que l’IEEE donne souvent des avis sur l’usage des protocoles sécurisés, légifère sur ceux que l’on doit adopter, et émet régulièrement des conseils de bonne pratique avec un ton qui fleure plus l’oukase technique que l’amicale suggestion.

Notons toutefois que notre spécialiste Danois s’est livré à un petit jeu statistique sur la distribution et la solidité des mots de passe utilisés par les membres du réseau de l’IEEE. On y trouve en première place l’inévitable 1234, le nécessaire 123456, ainsi que le plus évolué 12345678 ou l’extraordinairement complexe 1234567890, sans oublier les habituels Password et Admin. On ne peut exiger de l’IEEE une politique de sécurité plus élaborée que celle de la Banque de France, tout de même.

*ndlc Note de la Correctrice : IEEE, docte organisme de normalisation d’Outre Atlantique signifiant « Institute of Electrical and Electronics Engineers ». Leur IETF à eux, en quelques sortes. Les gens branchés prononcent ce sigle à l’américaine, en prononçant « Aille tripeul-hi », ce qui n’a bien entendu strictement aucun rapport avec la capitale de la Libye. Mais ça fait très bien dans une conversation.