Archives

Parus au J.O. du 28 juillet, le décret n° 2014-845 donne au patron de l’Anssi pouvoir de décision et d’exécution, sans nécessiter l’aval et la signature du Premier Ministre, dès lors que ces décisions entrent dans son domaine de compétence.

Cette mesure de simplification semble logique dès lors qu’il s’agit de statuer sur la certification d’un équipement ou l’attribution du statut de Passi. Elle devient considérablement plus délicate lorsque la décision portera sur des outils de sécurité « active » ou « offensive » pour lesquels la frontière avec des instruments d’espionnage électronique et informatique devient de plus en plus floue. Ce décret donne donc à l’Anssi une parcelle de pouvoir politique qu’elle possédait jusqu’à présent seulement de manière officieuse et non-organique.

Un juge de district US vient de rappeler à Microsoft son obligation de rapatrier sur le territoire Etats-Uniens les données que ses services Européens étaient susceptibles de stocker, nous apprend un article de nos confrères ZDNet .

Dans les faits, cela change peu de choses. Le juge en question souhaite ainsi systématiser ce qui, auparavant, était inféodé à une procédure liée à une enquête soit criminelle, soit s’inscrivant dans le cadre d’une enquête antiterroriste (Patriot Act).

Ce combat portant sur la souveraineté des données est à la fois politique, commercial et technique. Politique car le gouvernement Fédéral s’oppose à la vision du Parlement Européen. Commercial puisqu’aucun acteur du Cloud ne souhaite endosser la livrée de preneur d’otages en matière de stockage des données et de confidentialité de l’information. Technique enfin parce qu’il contraint les grandes entreprises et organisations européennes, faute d’acteur significatif dans la zone CE, à doubler leurs infrastructures cloud public par une architecture privée chargée de la préservation et du traitement des données sensibles.

L’accident est survenu, pense-t-on, dans la nuit du vendredi 25 au samedi 26 juillet : les usagers des services professionnels Office 365 de Microsoft n’ont plus pu expédier le moindre courrier électronique aux abonnés des services grand-public Wanadoo.fr et Orange.fr. Panne d’autant plus étrange que les administrés du réseau interne d’Orange (regroupés dans le domaine Orange.com) recevaient bel et bien leurs emails.
S’engage alors une série de tests et de coups de téléphone du genre « je t’envoie un email, je te passe un coup de fil pour savoir si tu l’as reçu ? » digne d’un sketch de Michèle Laroque. Par mesure de prudence, quelques abonnés d’Office 365 réexpédient leurs messages avec un service tiers (Gmail ou autre)… messages que reçoivent alors leurs correspondants. Lesquels correspondants répondent illico (et avec succès) en direction du service Microsoft. Midi n’a pas sonné, ce samedi-là, qu’il faut se rendre à l’évidence : un docte administrateur est parvenu à inventer l’équivalent routage de la diode à semi-conducteur. Les messages passent dans un sens mais pas dans l’autre.
Et les usagers de 365 d’inonder de SOS tout ce que leurs carnets d’adresses peuvent compter de noms de domaine différents, histoire d’en avoir le cœur net et pouvoir conclure à leur tour que seuls les serveurs de l’Opérateur Historique sont devenus soudainement sourds à leurs requêtes. Samedi soir, un diagnostic à chaud se dessine, le firewall fou a encore frappé.

Douches froides et lignes chaudes

Tablant sur la réputation de compétence et de sérieux quasi séculaire de leur hébergeur, quelques wanadiens et quelques orangiennes expédient alors à leurs services d’assistance client l’expression de leur désarroi le plus profond. « Que nenni » répondent alors les calorolinéains (ou thermogrammes, opérateurs desdites lignes chaudes). « Si votre correspondant ne peut vous expédier un i-maihle, c’est que leur logiciel est mal paramétré ou que leur serveur est brusquement devenu berseck. D’ailleurs, la preuve, je vais vous expédier un courriel, qui vous prouvera que vous n’êtes point sourd aux échange épistolaires et néanmoins numériques ».
Et tous les wanadiens, toutes les orangiennes ont pu lire la missive suivante :
> Bonjour,
> Ceci est un mail dédié à tester le bon fonctionnement de votre boîte mail. Si vous parvenez à lire ce mail correctement, cela signifie que votre boîte fonctionne normalement, et que vous pouvez recevoir des mails.
> Si vous avez encore des questions, n’hésitez pas à consulter la rubrique assistance ou à contacter votre service client.
> Merci de votre confiance,
> Votre service clients Orange

– Certes, cher et docte linéocalorifère, rétorquèrent quelques wanadiens possédant quelque vernis technique, mais votre domaine n’est pas un domaine Office 365 !
– Cela vous prouve que la faute est bien de leur côté…puisque ça tombe en marche chez nous »
Sic, fermez le ban.

Un week-end passe, arrive le lundi, et avec lui un certain regain d’activité du côté des messageries. Quelques milliers de lettres partent des serveurs Microsoftiens pour ne jamais arriver, et quelques centaines de retours préviennent les abonnés du service 365 que leurs écrits datés du samedi n’ont pu être délivrés malgré deux jours d’incessantes tentatives. Avertissement accompagné du message d’insultes suivant :

7/28/2014 9:48:44 AM – Remote Server at emea01-internal.map.protection.outlook.com (10.47.216.25) returned ‘550 4.4.7 QUEUE.Expired; message expired’
7/28/2014 9:44:45 AM – Remote Server at emea01-internal.map.protection.outlook.com (10.47.216.25) returned ‘450 4.7.0 Proxy session setup failed on Frontend with ‘451 4.4.0 Primary target IP address responded with: « 421 mwinf5c08 ME Trop de connexions, veuillez verifier votre configuration.

Peste ! En jargon Héssemtépéhien, c’est bien là la signature d’un refus signé par l’engeance de France Telecom. Quelques échantillons de ces courriers sont transmis aux services techniques dudit opérateur, lequel répond « C’est là chose fort normale, nous respectons les rfc, nous. Manifestement, vos Microsoftiens serveurs commettent une des deux erreurs suivantes : soit ils envoient un nombre de requête smtp trop élevé dans un laps de temps trop court, soit ils excèdent le nombre maximum de connexions simultanées, ce qui peut être interprété dans les deux cas comme une attaque en déni de service. Demandez à vos administrateurs de retourner à leurs chères études, qu’ils apprennent à configurer proprement leurs machines ». Chez Microsoft, on assure que l’on « travaille activement sur le sujet ».
Lundi passe. Mardi s’écoule. Mercredi s’achève. Les deux géants se renvoient la balle avec autant de hargne qu’un McEnroe opposé à Lendl durant une finale de Rolland Garos. Dans les forums d’utilisateurs, l’exaspération devient palpable. Avec la fin du mois, des factures doivent être transmises, des collaborateurs extérieurs sont injoignables, les e-commerçants (qui ne peuvent choisir le nom de domaine de leurs clients) sont dans l’incapacité d’expédier la plus petite confirmation de commande.

Ce n’est que dans le courant de la journée de jeudi, soit après 5 jours et demi de défaut de fonctionnement, que les services techniques de Wanadoo parviennent à rétablir la situation. L’origine la plus probable de la panne serait une règle de sécurité qui considèrerait comme fortement suspecte toute adresse IP présentant des requêtes émanant de plus de 30 noms de domaines différents. Ah, le bon temps où chaque machine était un host, chaque IP un serveur unique… mais ça, c’était avant, dans les années 80 environ. Depuis, Internet a un peu changé et personne n’a pris la précaution de prévenir la Rue Olivier de Serres. La mode de la collocation, de l’hébergement multiple, du Cloud… sans mentionner l’art de gérer plusieurs domaines et sous-domaines derrière un unique proxy, une caractéristique technique précisément « inventée » pour plaire aux opérateurs et prestataires de services.

Des lendemains qui déchantent

Cette mésaventure relativement bénigne soulève tout de même quelques questions.
– Pour quelle raison une règle de sécurité a-t-elle été modifiée probablement un vendredi soir, sans que n’aient été achevés les tests de non-régression habituels ? (rappelons qu’Orange commercialise les services Office365 dans le cadre de ses offres « pro », et ne pouvait oublier un tel détail)
– Comment peut-on expliquer qu’il ait fallu plus de 5 jours pour que le problème soit pris en considération par la direction technique de l’opérateur ?
– Est-il normal que la cellule technique d’un opérateur de services rejette « par défaut » la responsabilité d’un dysfonctionnement sur les épaules d’un autre opérateur, sans avoir préalablement analysé avec sérieux puis éliminé toutes les causes probables de la panne.

D’une manière plus générale, cette mésaventure montre à quel point les usagers des services Cloud sont vulnérables et à la merci des opérateurs de service… et de leurs sautes d’humeur. Si les politiques de « Best Effort » tant chantées sur les brochures commerciales, sont à l’image de cette expérience, les DSI qui ont cloudifié leurs ERP et autres outils de production et de gestion ne doivent plus se demander ce qu’il faudrait faire « si » leur opérateur venait à défaillir, mais de prévoir « quand » ledit opérateur déclarera forfait.

Autre conséquence de cette massification des services, ce « bug de messagerie » nous prouve à quel point les clients d’un service professionnel sont vulnérables par la seule défaillance d’un service totalement étranger à leur organisation ou à celle de leur sous-traitant. C’était certes déjà le cas auparavant, mais désormais, lorsqu’un accident survient, il prend rapidement des proportions dantesques. Un avion qui s’écrase fait plus de victimes qu’un accident de la route, un service Cloud qui déraille impacte plus d’entreprises qu’un défaut de configuration de serveur mail lié à une seule société. Cette amplification du phénomène ne semble pas encore comprise, ou prise en compte, par les grands opérateurs de service.
Se pose enfin la question de la responsabilité financière d’un tel défaut et des recours possibles lorsque la défaillance entraîne une perte d’argent. Dans un tel cas, ils sont inexistants, puisqu’aucun contrat ne lie Orange aux clients Microsoft. Passé le périmètre d’un opérateur de Cloud, tout peut arriver, rien n’est garanti. La sécurité d’une telle configuration ne peut être auditée, il est impensable d’espérer ainsi bâtir un plan de continuité de service.
Car l’accroissement du risque, ou plus exactement de l’accroissement des conséquences d’un accident d’origine extérieure réduit à un périmètre quasi autistique le champ d’action « fiable » d’une architecture du S.I. . Pourtant, le passage au Cloud était censé démultiplier (à moindre coût) l’efficacité et les capacités de communication et d’échanges des systèmes d’information.

De façon plus générale, cette panne Wanadoo est génétiquement liée à l’idée même de sécurité dans le Cloud. Plus un service a du succès, plus il provoque de tentations auprès des gardiens de Bot et autres grands diffuseurs de bootkits. Lesquels ont de plus en plus souvent recours à des mécanismes dynamiques de recherche de C&C (centres de contrôle).Lesquels C&C se cachent souvent derrière des centaines de noms de domaines générés également de manière dynamique. Face à un tel comportement, il est logique qu’un opérateur cherche à réduire sa surface de vulnérabilité et filtrer tout ce qui ressemble à un Bot ou à un prélude d’attaque en déni de service. C’est un combat sans fin, avec, parfois, des dommages collatéraux.

Les entreprises font face aujourd’hui à de nouveaux modes de consommation de l’informatique où les API jouent un rôle essentiel pour développer de nouveaux services et faciliter les échanges avec les clients et les partenaires. Si cette nouvelle « économie de l’API » génère de formidables potentiels de croissance, elle pose également de nouvelles problématiques en matière de sécurité et de confidentialité des données échangées, auxquelles il faut apporter des réponses adaptées et efficaces. Êtes-vous certain de l’intégrité de vos API ? Les réseaux sociaux, les services Cloud ou encore les terminaux mobiles ont bouleversé les conditions d’accès aux données et aux services, en même temps qu’ils ont généré de nouvelles opportunités de croissance pour les entreprises. C’est dans ce contexte que les API web, véritables couches communes faisant l’interface entre différents systèmes, plateformes et appareils, se sont peu à peu imposées dans la sphère technologique. Et ce n’est qu’un début : selon le cabinet Gartner, les trois quarts des entreprises du Fortune 500 envisagent d’ouvrir une API au cours de l’année. Toutes ces API participent à enrichir les services fournis aux utilisateurs : transmettre des résultats d’examens médicaux en ligne, gérer ses comptes bancaires depuis son téléphone mobile, consulter un historique de commandes sur sa tablette… Mais aussi séduisants et pratiques que soient ces services, ils n’en soulèvent pas moins des questions critiques quant à la sécurité des données qui transitent via ces API. Les entreprises l’ont bien compris et la sécurisation de leurs API est au coeur de leurs préoccupations. Non toutefois sans un certain nombre d’idées reçues qui en empêchent la pleine efficacité…

1. L’opacité d’une API suffit à la protéger
La première erreur consiste à penser qu’une API est protégée de fait, seules les équipes impliquées
dans son développement en connaissant les rouages. Une approche assurément inefficace sur le
long terme, dans la mesure où si un produit ou un service est doté d’une API, celle-ci finira par susciter la curiosité de tiers qui ne manqueront pas de l’examiner. Et, pour peu qu’ils soient
malveillants, de s’en servir à mauvais escient. Le constructeur automobile Tesla a failli en faire
l’amère expérience : il avait choisi de ne pas documenter l’API de l’un de ses véhicules électriques
de luxe, ni d’y appliquer de règles d’authentification, estimant qu’elle ne présentait pas de risques
critiques en termes de sécurité. Jusqu’à ce qu’il découvre qu’elle permettait potentiellement à
n’importe qui de déclencher des actions à distance sur la voiture. En d’autres termes :
documentation et authentification doivent être les deux clés de voûte d’une API sécurisée.

2. Seul le contrôle des accès compte, les usages importent peu
Si des règles strictes d’authentification permettent de contrôler les accès à l’API, elles ne suffisent toutefois pas à en garantir pleinement l’intégrité. Il est également essentiel de contrôler, via un audit détaillé, la façon dont l’API est utilisée. D’abord pour disposer de données légalement exploitables en cas d’attaques malveillantes, ensuite pour garantir sa conformité avec les réglementations industrielles en vigueur. C’est particulièrement vrai pour les entreprises de secteurs sensibles, comme la santé ou l’énergie, où les contraintes réglementaires sont particulièrement fortes. Notons par ailleurs l’intérêt économique de connaître l’usage qui est fait d’une API au fil du temps …

3. Le protocole SSL a fait son temps
Les technologies évoluent et la tentation est grande de succomber à l’attrait de la nouveauté. Pour
ce qui est de la gestion des API, le protocole SSL a beau avoir de la bouteille, il n’en demeure pas
moins LA référence en matière de sécurisation des échanges. Ce n’est d’ailleurs pas un hasard si
une société comme Amazon, qui gère chaque mois des milliards d’interactions, n’autorise les accès à son API que via SSL. Et les nouveaux standards d’authentification, comme OAuth, doivent davantage être envisagés comme des compléments à SSL plutôt que comme des alternatives.

4. Rien ne vaut un système de sécurité maison
SSL, OAuth, OpenID, SAML, SW-Security et autre authentification HTTP : le nombre et la complexité des combinaisons et procédés possibles d’authentification poussent certains programmeurs à développer leurs propres systèmes de sécurité. Bien mal leur en prend, non seulement ils s’infligent une surcharge de travail, mais prennent aussi le risque de générer un système faillible. La moindre modification, aussi légère soit-elle, sur un standard existant, altère potentiellement l’efficacité – éprouvée – de celui-ci et expose l’API à des risques inconsidérés.

5. Sécurité et processus métiers ne doivent faire qu’un
Confondre logique métier et logique de sécurité n’est pas une aussi bonne idée qu’il y paraît. D’une
part parce que cela démultiplie les opérations de maintenance puisque tout changement dans les règles de sécurité a des répercussions sur les processus métier. D’autre part parce que cela peut impacter les performances de votre réseau tout entier. Avoir une plateforme séparée dédiée à la sécurité permet à l’inverse de préserver les performances de votre système tout en y ajoutant une couche de protection supplémentaire contre de potentielles attaques.

6. Une API n’est pas concernée par les menaces web traditionnelles
Il ne faut pas oublier qu’une API web est avant tout une application web et qu’à ce titre, elle est
exposée aux mêmes menaces que ses consoeurs : attaques en déni de service (DDoS), injections SQL, etc. Autrement dit, sécuriser une API implique de tenir compte non seulement des nouvelles menaces propres à l’API, mais aussi des attaques typiques et connues visant les applications web dans leur ensemble.

7. XML, JSON : on doit choisir le format de données le plus adapté
PC plutôt que Mac ? Chat plutôt que chien ? Bordeaux plutôt que Bourgogne ? XML plutôt que JSON ? En matière de formats de description de données, nos préférences personnelles ne doivent pas guider notre choix : il faut opter pour les deux ! Gérer à la fois du XML et du JSON permet de renforcer la sécurité d’une API en autorisant les interactions avec des API partenaires sans se soucier du protocole qu’elles utilisent.

Peut-il exister pire que la location de temps de cerveau chère à Patrick Le Lay ? Oui, l’intoxication des contenus « interactifs » offerts par le protocole HbbTV, affirment Yossef Oren et Angelos Keromytis de l’Université de Columbia.

Une fois de plus, il s’agit d’une menace visant le monde merveilleux de l’Internet des Objets, conduite une fois encore en mode « man in the middle », et visant un protocole très largement utilisé par, TF1, France 2, France 3, France 4, France 5, M6, ARTE, France ô, NRJ 12, ou i>Télé. Le succès de ce système est tout aussi important Outre Rhin, et le procédé tend à être adopté un peu de partout dans le monde.

De manière très sommaire, HbbTV est une fonction réservée aux téléviseurs de nouvelle génération, connectés, et permettant d’offrir au spectateur des informations complémentaires issues d’Internet durant le déroulement d’une émission, essentiellement des compléments Web utilisant des standards connus (XHTML, CSS, JavaScript). Las, le retour d’information (encapsulé dans un flux assuré par l’opérateur de broadcast ou celui se faisant passer comme tel), n’est plus corrélé avec le moindre contexte Internet… ce qui pose quelques difficultés pour authentifier le contenu de la réponse.

Techniquement parlant, expliquent les chercheurs, l’attaquant expédie sa requête via son propre émetteur DVB-T, autrement dit par la voie des ondes. Plus de détails techniques au fil de la communication universitaire d’Oren et Keromytis. Jusqu’à présent, les attaques visant les téléviseurs connectés utilisaient le chemin inverse, à savoir la connexion internet elle-même.

Comme il n’existe strictement aucun mécanisme de question-réponse entre l’émetteur TV et le récepteur, l’attaquant est quasiment certain de toucher ses cibles, et d’ainsi pouvoir injecter n’importe quel contenu à destination des téléspectateurs. Pour autant que les téléspectateurs utilisent réellement un tuner TNT, car l’attaque elle-même devient un peu plus compliquée à réaliser si la télévision utilise les services vidéo d’une « box » d’opérateur ou une liaison descendante de satellite.

Dénis de service, spam, manipulation d’opinion, injection de troyens d’exploration du réseau local de chaque spectateur… le champ d’exploitation de ce genre de hack est quasi illimité. Les parades possibles, en revanche, se limitent à une surveillance stricte des volumes des requêtes « montantes », afin de deviner une activité anormale. Ceci fait, une fois détectés les destinataires (et néanmoins victimes) de ces flux piratés, il devient facile d’établir une cartographie de l’ensemble des foyers touchés, et ainsi établir le barycentre sur lequel doit logiquement se situer l’émetteur TV utilisé pour l’attaque. Reste, font remarquer les deux chercheurs, que les capacités techniques nécessaires à cette recherche peuvent être également considérées comme une forme de flicage des contenus demandés par les spectateurs, donc à une atteinte à leur vie privée… rien n’est simple dès lors que l’on touche aux grands médias audiovisuels

Ajoutons (et l’étude Oren – Keromytis n’en fait pas mention ) que la majorité des récepteurs fonctionnant encore en réception hertzienne utilisent des antennes yagi, relativement directives, et bien entendu pointées en direction de l’émetteur local. Ce qui implique que l’émetteur pirate doit non seulement être situé peu ou prou dans la proximité dudit émetteur officiel (l’atténuation d’une yagi « hors lobe » dépasse rapidement les 10 dB), et est nécessairement capable de développer une puissance apparente rayonnée très supérieure à celle de l’émetteur officiel pour éviter tout risque d’hétérodynage. A moins que les pirates acceptent de restreindre leur attaque à l’échelle d’un quartier et, à l’aide d’un émetteur moins puissant, ne visent qu’un secteur de la zone couverte par la station officielle.

Tout ça ressemble donc fortement à une très belle analyse de risque « en chambre », pas franchement impossible à réaliser, mais hautement improbable compte tenu du rapport gain/infrastructure technique à déployer. La menace est en revanche tout à fait sérieuse dans le cadre d’une opération d’intoxication ciblée (genre spear phishing audiovisuel ne visant qu’un immeuble ou une personne), mais n’a, dans ce contexte, aucun caractère novateur. Le coup du « faux émetteur » est vieux comme le monde de la radiotransmission, et ce genre d’attaque par intoxication a même fait l’objet de plusieurs productions Hollywoodiennes, notamment l’Arnaque, avec Robert Redford et Paul Newman. Un peu de technologie « hype » ne change rien au principe d’insécurité qui caractérise tout système de diffusion « one to many » dépourvu d’un véritable protocole d’authentification en temps réel.

La règle définissant les mois pairs comme mois « fastes » en matière de correctifs I.E. est en passe de devenir lettre morte. Juin en apporte la preuve, avec ce colmatage de tellement de failles affectant Internet Explorer qu’il faut au bas mot 9 « pages écran » pour couvrir tous les CVE concernés. Dire que le correctif MS14-035 est critique frise plus l’humour absurde que l’euphémisme.

Jugées critiques également, ces quelques possibles exploitations à distance dans Microsoft Graphic et de sa rustine MS14-036 qui élimine 2 CVE. Les autres alertes sont simplement qualifiées d’importantes, notamment un risque d’attaque distante via Word, une fuite d’information par le biais des services XML, un déni de service par le truchement d’un paquet TCP forgé et une falsification dans le cadre d’une session RDP.

Chez Adobe, on signale la résolution de 6 CVE touchant Flash Player.

Chez Mozilla, sont signalées 10 CVE ( 7 colmatages) dans Firefox 30, beaucoup plus dans la version 29. L’absence de date précise pour ce qui concerne le traitement de chaque CVE rend difficile toute chronologie des correctifs pour le mois en cours.

Un an jour pour jour après la publication des toutes premières fuites concernant Prism, le « contrat de confiance NSA » qui liait les principaux éditeurs US à l’agence de renseignement, Microsoft demande une réforme des pratiques de la No Such Agency et réclame que les éventuels mécanismes d’écoute et de déchiffrement s’arrêtent aux frontières des Etats-Unis, nous informent nos confrères de Network World. Cette trop grande surveillance pourrait avoir des conséquences néfastes sur le business et la confiance accordée aux produits commercialisés par l’éditeur.

Aux frontières des USA, entendons par là que Microsoft tolère les écoutes de la NSA au-delà desdites frontières, et ne formule sa prière que pour ce qui concerne le territoire fédéral. Le fait de barbouzer les clients « étrangers » que nous sommes ne semble pas particulièrement impacter la confiance desdits clients. Après tout, lorsque plus de 98 % des outils diffusés dans le monde sont sous le contrôle de AOL, Apple, Dropbox, Facebook, Google, LinkedIn, Microsoft, Twitter ou Yahoo, on craint nettement moins les risques de désaffection au profit d’un concurrent mort depuis longtemps.

Deux communiqués successifs préviennent d’un grave défaut l’un dans OpenSSL, l’autre dans la bibliothèque de fonction GnuTLS. La première, portant l’immatriculation CVE-2014-0224, ouvre la voie à une possible attaque « man in the middle ». Ce problème serait endémique et remonterait au moins aux éditions datant de 1998. Le second trou, concernant GnuTLS, est référencé CVE-2014-3466, et appartient à la famille des buffer overflow. Peut en découler une exécution de code arbitraire en mémoire ou un crash système. Les nouvelles versions 3.1.25, 3.2.15 et 3.3.4 corrigent cette erreur précise le bulletin d’alerte.

Lorsque l’équipe de développement de Truecrypt a annoncé l’arrêt brutal du développement de cet outil de chiffrement multiplateformes, les pires suppositions ont fusées, tant dans la presse que sur les blogs. Suppositions d’autant plus alarmistes que la première phrase, marquée au fer rouge en tête de page, ne laisse place à aucun doute « WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues ». De là à se demander, par simple réflexe post-snowdenien, si ces « security issues », et plus particulièrement d’éventuels erreurs d’implémentations plus ou moins volontaires, n’auraient pas été provoquées.

Pourtant, comme le fait remarquer Hervé Schauer, au fil de sa lettre d’information mensuelle, Truecrypt a été audité maintes et maintes fois : une initiative de l’Open Crypto Audit, deux audits CSPN en France comme le rappel un communiqué de l’Ansi. Lequel Ansi, au passage, recommande la migration vers d’autres solutions de chiffrement, toutes « closed sources » et commerciales.

Pour l’heure, donc, Truecrypt doit être considéré comme relativement fiable, et si l’on ne craint pas d’être la cible des attentions particulières de la NSA, et il est urgent de ne pas paniquer. Particulièrement pour ce qui concerne les personnes exploitant différentes versions (Windows/Linux/OSX) du programme. Un fork Helvétique devrait permettre aux inconditionnels de ce programme open source de perdurer encore.

Il y a un peu plus de 4 ans, David et Robert Maynor s’offraient un émetteur-récepteur logiciel (SDR) et entamaient un long travail de fuzzing dans le domaine du sans-fil. Rien n’est gratuit. Car contrairement à une faille Heartbleed qui ne parvient à émouvoir qu’un tout petit cénacle de spécialistes du chiffrement, les hacks radio « parlent » aux oreilles de la presse, et touchent notamment la dernière marotte des politiques en mal de popularité : l’internet des objets. Et c’est donc sur le thèmes « objets interconnectés, avez-vous donc une RAM que je puisse exploiter » que Bob Graham s’interroge sur la divulgation (ou non) d’un exploit radio visant les stimulateurs cardiaques, alias pacemakers. Et de décrire par le menu ce drame cornélien du chercheur qui trouve, et dont la découverte (ou plus exactement la publication de sa découverte) pourrait avoir pour conséquence extrême la mort de porteurs de ce genre d’appareil.

Outre le fait que ce genre de travaux s’opère généralement « en chambre », avec des niveaux de puissance ridicules, des distances de liaison se comptant en décimètres, et une totale absence de tests « grandeur réelle » en milieu urbain perturbé et à grande puissance/distance, on peut se demander si ce genre d’introspection blogo-sécuritaire ne frise pas la provocation. Certes, le domaine médical, à l’instar du secteur de l’automatisme industriel, a vécu, des années durant, avec l’absolue certitude que les techniques touchant à la radioélectricité relevaient de la sorcellerie et de la haute technologie, « inaccessible au commun des mortels ». Une forme de sécurité par l’obscurantisme en quelques sortes. Mais pour ce qui concerne le choix éthique du chercheur (dois-je ou ne dois-je pas communiquer le résultat de mes recherches à l’occasion d’une conférence technique telle que la DefCon), la question peut-elle sérieusement se poser ? Pour quelle raison existerait-il deux poids, deux mesures, entre le monde logiciel et le monde médical ? Le « full disclosure » raisonné, avec communication préalable auprès des éditeurs, correction des bugs puis divulgation après un laps de temps nécessaire au déploiement de correctifs est devenu une quasi-norme de nos jours. Tout comme est devenue une quasi-habitude le fait de rémunérer correctement les chercheurs ayant fait l’effort de découvrir et d’analyser une faille de sécurité. Que la cible soit un instrument médical ne change rien à l’affaire. A moins… à moins que cette industrie n’ait pas coutume de raisonner en termes de « fenêtre de vulnérabilité », de « calendrier de correction », de « campagne de déploiement de correctifs »… ou de barème publié de « bug bounty ».

Et c’est peut-être là le principal iatus.

Lorsqu’en 2009 Alex Sotirov, Dino Dai Zovi et Charlie Miller ont, à l’occasion de CanSecWest, entamé leur campagne « no more free bugs », ils s’adressaient à une profession d’éditeurs directement impliquée dans le développement de logiciels et firmwares. Langage d’informaticiens pour des informaticiens. Aujourd’hui, ce discours peut-il être entendu par les industries de l’automatisme, du contrôle de processus, de l’équipement médical, des équipementiers de la grande distribution, des secteurs financiers, automobiles, aéronautiques ? … Bref, de tous ceux qui, sans appartenir au monde du développement logiciel, développent leurs propres programmes ? Et lesdits industriels seront-ils enclins à récompenser ces chercheurs en cas de découverte d’un bug majeur, sans considérer ladite recherche comme une tentative de racket ?

La véritable question que pose Robert Maynor va bien au-delà du simple problème du full disclosure or not full disclosure. Elle interroge l’ensemble des secteurs d’activités qui, par un biais ou par un autre, ont numérisé leurs outils et applications, et n’ont pas toujours pris en compte la dimension infosec. Ni budgétisé les coûts induits… remerciements aux chercheurs y compris. Un « à votre bon cœur » qui s’annonce avec un hack de pacemaker, voilà qui atteint des sommets lacaniens.