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.
Merci infiniment… effectivement, 3Com a été racheté par HP en 2009, opération approuvée par la « Cob Américaine » et finalisée en 2010. On ne devrait jamais utiliser le pavé numérique pour dactylographier une date.
Le but de cet article est de rapporter l’avis d’Eric Romang, pas d’approuver ou d’infirmer son propos. Comme vous le faites remarquer (et comme nous avons insisté sur ce point), il s’agit là de « Vieux débat, vieilles craintes et problème sans solution réelle »
L’article de Romang a au moins un mérite, c’est celui de rappeler que, côté blackhat, il y a toujours eu des tentatives d’exploitation suivant la publication de certains CVE. Or, comme le « reverse par boule de cristal » n’existe pas, pas plus que la génération spontanée de malware, et que les informations de la base CVE sont plutôt maigres pour en extrapoler un code exploitable, c’est que ces informations techniques proviennent bien de quelque part. Et, en l’absence de publication via un canal genre « full disclo », il ne reste guère plus que le reverse systématique des fichiers émis par les spécialistes du « patch », qu’ils soient virtuels ou destinés à être intégrés dans un firmware. Ce n’est certes pas quelque chose de nouveau, mais ce n’est pas non plus quelque chose qui se clame haut et fort, car cela sous-entend indirectement une responsabilité des éditeurs d’outils de protection périphérique concernés. La prétention d’être des éditeurs capables de « mieux » protéger leurs clients se fait au détriment de tous ceux qui ne possèdent pas précisément ces équipements de protection périmétrique spécifiques, et qui attendent impuissant la rustine officielle.
Ce qui est « nouveau », c’est que l’auteur du blog explique que la fenêtre de vulnérabilité s’ouvre non plus en date de publication du correctif de l’éditeur « faillible », mais à celle de la diffusion de la toute première rustine sur le marché (fuites via le F.D. ou autre non comprises). Le reverse de patch a toujours existé… il ne visait jusqu’à présent que les retardataires au déploiement, donc une minorité. Romang explique que cet état de fait tend à ne plus être : le reverse de patch vise désormais tout le monde, excepté une minorité de « bien nantis ». Et ça, c’est pas franchement ancien comme éclairage.
Le fait de considérer un commerçant « clean » ou « pas clean » sous prétexte qu’il mise sa bonne fortune sur l’antériorité d’une information est un débat clausewitzien. La morale de la (cyber) guerre n’est pas la morale en temps de (cyber) paix, et la droiture d’un comportement n’est jamais que le reflet de l’opinion du vainqueur, qui, seul, a droit d’écrire l’histoire. En revanche, l’on est en droit de se demander si la responsabilité de ces équipementiers n’est pas engagée à partir du moment où leurs correctifs ne sont pas soumis à des systèmes de protection (chiffrement par exemple), absence de précaution (ou précautions insuffisantes) qui faciliterait la vie des auteurs d’exploits « noirs ».
En vous remerciant d’avoir soulevé ce point de discussion qui n’est certainement pas prêt d’être résolu de manière définitive.
Marc
cet article est étrange… 2005 Rachat de 3Com par HP ??? c’est 2010 !!! le Zéro days a toujours fait débat et ce n’est pas ce Mr qui apporte quelque chose de nouveau !!!! est il en fort partenariat avec l’un des concurrents de TippingPoint ? parce que dans ce cas, faut il mettre dans la case des éditeurs « pas clean » tous ceux qui travaillent en amont et qui proposent par exemple du patch virtuel ou autres solutions destiné a protéger un environnement avant même que celui ci soit exploitable ?