SSTIC 2018

Nous sommes en 2018. Fuites de données, attaques massives, failles structurelles, le monde constate chaque jour un peu plus à quel point la sécurité est un échec.

Un petit village gaulois en quête d’attention résiste encore à l’évidence dans cet article consacré à la conférence SSTIC 2018 (ainsi que l’édito du magazine MISC qui s’en suit). Car en cette période de défiance envers les médias institutionnels et les preuves scientifiques, le public affectionne la pensée dissidente : elle a l’apparence de la sincérité.

Fin de l’histoire. Ou presque.

Je ne prends pas la plume pour lutter contre les #FakeNews. Je ne prends pas la plume car someone is wrong on the Internet. Je prends la plume pour me défendre contre les attaques ad hominem dont je suis la cible.

« Ceux qui soutiennent [que la sécurité est un échec] sont bien souvent des personnes qui n’ont jamais essayé de construire quoi que ce soit, de développer un produit. »

Faut-il avoir tué quelqu’un pour être contre la guerre ? Mme Michu n’est-elle pas légitime à se plaindre des lenteurs de son ordinateur et du vol de ses mots de passe, sous prétexte qu’elle n’a jamais appris la programmation ?

Faut-il établir une échelle de valeurs ? Un éditeur de produits de sécurité est-il plus légitime à s’exprimer sur la cyber qu’un reverse-engineer ?

Ces arguments spécieux ne méritent pas qu’on s’attache plus longtemps à leur réfutation. Mais j’irai plus loin en affirmant que le principal frein à l’amélioration du niveau de sécurité global est justement l’écosystème de la sécurité (consultants, éditeurs de produits, et les conférences qu’ils organisent).

« Qui vit de combattre un ennemi a tout intérêt de le laisser en vie. »

La sécurité est un milieu hermétique, impénétrable au commun des mortels, qui vit sur ses rites et ses codes – une conférence comme SSTIC en étant la caricature. Le reverse-engineering est la discipline reine, la sécurité JavaCard s’apparente à la fée Carabosse, tandis que le juridique et l’analyse de risque ont été exclus de la famille. Sans parler de la privacy ou des méthodes de développement sécurisé, dont personne ne se soucie dans le sérail.

Les combats qui mèneront à la nobilité ont été figés par nos aïeuls, et les experts en sécurité se doivent de consacrer leur énergie à des sujets futiles tels que la longueur des mots de passe ou la sécurité des clés USB (sujet récurrent du SSTIC s’il en est). Un travail bien dérisoire tandis que la première cause d’intrusion reste le phishing – sujet malheureusement beaucoup plus ardu et moins valorisant à traiter. Heureusement, des professionnels de l’informatique (mais pas de la sécurité) s’y attaquent via U2F et WebAuthn.

« Il n'est pas de problème qu'une absence de solution ne finisse par résoudre. »

Quant aux éditeurs de produits de sécurité, ils ne font qu’ajouter de la complexité à l’écheveau logiciel. L’essence de la sécurité c’est la simplification : moins de lignes de code, moins de dépendances tierce partie, moins d’interfaces, moins de mots de passe. Rien de pire que d’interpréter dans plusieurs logiciels différents un format de fichier ou une requête HTTP.

Il y aurait beaucoup à dire sur la valeur des conseils prodigués par les experts en sécurité – tels que d’utiliser plusieurs logiciels antivirus différents au sein d’un même réseau – mais on me souffle que ce sujet pourrait faire l’objet d’une conférence à SSTIC. C’est aussi là l’une des clés du problème : les experts en sécurité sont bien trop fiers pour admettre qu’ils ont tort (ou que le monde a changé). Ils sont incapables de tirer les leçons de leurs échecs, comme le suggère pourtant l’article susmentionné. Félicitation à Bill Burr pour avoir admis – à 73 ans – que la publication NIST 800-63 sur les mots de passe était une erreur.

Pour toutes ces raisons, je suis intimement persuadé que la sécurité est un échec. Et j’en ai eu la preuve récemment, car la sécurité n’est pas un échec partout. Il existe des villages – certes pas gaulois – dans lesquels tout logiciel non maitrisé est isolé. Où le problème de la sécurité Linux est traité de manière systématique par des équipes constituées – pas des loups solitaires plus connus pour leurs effusions sur Twitter que pour leur capacité à soumettre du code dans le noyau. Où des efforts considérables sont déployés dans les comités de standardisation pour résoudre de manière définitive le problème du XSS en transformant HTML en un langage fortement typé. Et devinez quoi : dans cette entreprise personne ne réclame le titre de RSSI.

Quelle est la différence avec bon nombre de présentations SSTIC ? Ce sont des équipes, pas des héros. Ce qui permet aux projets de survivre au remplacement de tous les membres de l'équipe, tandis que la majorité des outils présentés à SSTIC entrent en déshérence le jour de leur publication. Le mythe du héros solitaire (si bien représenté par le hacker en hoodie, et perpétué par le challenge SSTIC) nous cause beaucoup de tort aujourd’hui.

Une autre différence ? Ce sont des ingénieurs en génie logiciel, pas des stars aux compétences limitées. Et ils ne se définissent pas comme travaillant dans le security circus ...

Alors, qu’est-ce qui a changé entre SSTIC 2003 et 2018 ? Beaucoup de choses, à commencer par un renouvellement complet des générations. Selon un sondage à main levée, il m’a semblé que plus de 90% de l’audience venait à SSTIC pour la première fois. Et aucun des jeunes avec qui j’ai eu le privilège de partager un instant social n’a jamais entendu parler de Frédéric Raynal, Cédric Blancher, ou même Hervé Schauer.

Les vieilles légendes ont vécu. Il faut l’admettre, ou se condamner à souffrir en s'appropriant la gloire de ce qui a été.

« Puisque ces mystères nous dépassent, feignons d'en être l'organisateur. »

Ma contribution au mois de la cybersécurité

Dans le cadre du mois de la sécurité, l'ANSSI met en avant son MOOC : la SecNumAcadémie. Il m'a semblé opportun de vous résumer les 2h48 que j'ai passées sur le premier module afin de vous épargner cette peine.

Dans l'ensemble la réalisation technique est correcte, quoi qu'un peu répétitive après presque 3 heures. Quelques animations, et une sensation de progression (plutôt qu'une répétition de la même image d'accueil) auraient été les bienvenues.

Toutefois je n'ai pas pu m'empêcher de prendre la plume face à la tare rédhibitoire qui afflige ce MOOC : il ne se destine absolument pas au grand public ; il est un pur instrument de politique interne à l'administration.

En effet, comment croire que je puisse recommander à mes proches un outil qui attaque bille en tête par le RGS, pour prendre ensuite soin d'énumérer exhaustivement tous les organes administratifs touchant de près ou de loin à la "cyberdéfense" en France (comme le CALID ou la DGSSI, totalement inconnus du grand public) ? Où sont les conseils pratiques qui vont parler à l'internaute moyen ?

L'autre point qui m'a choqué est le biais éminemment politique des messages prodigués. Certes la sécurité informatique n'est pas une science, mais dans le cas d'espèce, l'idéologie occulte parfois des réalités quantifiables. Par exemple, que penser de l'assertion ci-dessous ?

"De nombreux états souhaitent contrôler les frontières du numérique pour des raisons de souveraineté nationale". Au lieu d'une référence à "Shaping the Internet in China", il aurait peut-être fallu mentionner que la France est pionnière en la matière … bien avant les délires "souverains" de ces dernières années.

Le Cloud

Si j'ai bien compris le message de ce MOOC, l'administration ne croit plus à l'émergence d'un Cloud "souverain" et s'attache donc à dire pis que pendre de toute forme d'externalisation. Espérons qu'ils aient raison, sinon le rétropédalage sera compliqué …

"Les sites hébergés en France sont plus dignes de confiance car de nombreuses lois vous garantissent la protection de vos données" : que voilà une formulation vague et ambiguë ! Aucune loi n'empêche le piratage de vos données chez un prestataire … qu'il soit en France ou ailleurs. Ah, et le domaine "secnumacademie.gouv.fr" résout en "178.32.43.203" chez moi, qui est une adresse située chez OVH … en Belgique.
	Idem pour cette autre formule : "un service gratuit ne vous apporte aucune garantie de service". Les clients (commerciaux) du Cloud 2E2 ont appris à leurs dépens que payer ne vous apporte guère plus de garanties … Faut-il que j'arrête d'utiliser mon adresse email chez LaPoste.net car elle est gratuite ?
Une dernière à propos du Cloud et puis j'arrête. Sachez simplement que même si vous n'utilisez pas le "Cloud", vos données peuvent être perdues ou divulguées … Je serais curieux d'avoir des statistiques à ce sujet, mais je peux vous assurer qu'on perdait déjà des données bien avant l'invention du Cloud.

Précisons au passage que la page de login du site "secnumacademie.gouv.fr" utilise Google Recaptcha. Mais je suppose que "le Web" n'est pas "le Cloud".

Les erreurs

On peut comprendre que la position de l'ANSSI se doive d'être cohérente avec celle de l'ENISA … d'ailleurs le MOOC va jusqu'à reprendre certaines illustrations publiées par l'ENISA. Mais du consensus naquit la vulnérabilité …

Le choix d'un mot de passe : un grand classique. Outre le fait que cette recommandation ne pourra pas s'appliquer à tous les sites (voir @pwtoostrong et @badpasswordrule à ce sujet), elle est malheureusement l'opinion d'un seul homme … qui regrette désormais d'avoir donné ce mauvais conseil. Votre seul espoir : des mots de passe aléatoires, un password manager, et de l'authentification à deux facteurs partout où c'est possible.

Les trolls

Pour conclure, quelques captures d'écran "amusantes" dans le contexte.

	Pas sûr qu'il soit opportun d'utiliser la carte de NorseCorp pour illustrer les attaques sur Internet, alors que cette société est en pleine tourmente …
Apparemment on manque d'équipements "souverains", puisque le même téléphone est réutilisé 6 fois en illustration …
	Cette image pourrait laisser penser qu'il y a plus de femmes et de professionnels dans la ROC que dans la RCC … En pratique c'est pourtant l'inverse : la réserve opérationnelle comprend essentiellement des étudiants, tandis que la réserve citoyenne est un think tank.
Mais pourquoi avoir choisi tv.freebox.fr comme exemple de site rendu indisponible, alors qu'il est fermé par son propriétaire depuis 2011 ? S'agit-il simplement d'un clipart récupéré dans cet article ? J'espère que Clubic a donné son accord.
	Je me demande bien quelle est cette entreprise dans laquelle on doit payer ses croissants ?
Ah, le bon vieux coup du cadenas vert. Il faut pourtant que je vous dise qu'il n'existe pas sur mobiles, et qu'il va bientôt disparaître sur PC …
	Oh, la publicité déguisée pour GMail ;)
Internet Explorer en prend pour son grade … J'espère que le logo a été utilisé avec permission !

Conclusion

Pour ceux qui ont fait défiler cet article jusqu'à la fin sans le lire, il me semble opportun de réitérer ma conclusion : cette formation extrêmement longue (compter 3 à 4 heures pour aller au bout du premier module si vous n'êtes pas de la profession) sert essentiellement de publicité à ses auteurs.

Elle sera probablement imposée aux agents de l'administration ayant à traiter des problèmes de sécurité informatique (bon courage à eux !), mais en aucun cas elle ne "s’adapte aux besoins de différents publics, non experts, en proposant des contenus pédagogiques". Etudiants, particuliers et patrons de PME risquent forts d'être découragés par la surreprésentation des considérations administratives et réglementaires dans ce MOOC !

Un compte rendu alternatif du SSTIC 2017

Le SSTIC 2017 vient de se terminer. Comme chaque année depuis 15 ans, cet événement confirme sa place centrale dans l’écosystème de la cybersécurité française – aussi bien par la qualité des échanges entre les participants que par la fluidité d’une organisation bien rôdée.

Vous trouverez le compte-rendu technique des différentes présentations chez n0secure [J1][J2][J3] ou Xavier Mertens [J1][J2][J3]. En ce qui me concerne, j’ai souhaité vous faire partager un point de vue avec un peu plus de recul sur cet événement.

L’ANSSTIC

Dès la première matinée, on comprend que le SSTIC est devenu un événement politique interne de l’ANSSI (et dans une moindre mesure de la DGA-MI) – avec 4 présentations qui s’enchaînent.

On m’objectera que les agents de l’ANSSI sont les seuls à soumettre des papiers, ce qui explique leur surreprésentation. De mémoire cette année il y a eu ~35 soumissions pour ~25 créneaux de présentation, ce qui ne permet effectivement pas au processus de sélection de jouer à plein.

J’ai bien une explication à ce faible nombre de soumissions tierces. En 2003 le SSTIC était une conférence technique d’excellence, unique dans le paysage français et rare dans le paysage international. En 2017, le monde a changé ; force est de constater que soumettre à SSTIC ne présente plus aucun intérêt pour le commun des mortels.

• Le (long) processus de soumission et d’édition des actes n’est pas compatible avec le rythme médiatique ; seuls de travaux de recherche très amont (comprendre : très théoriques) peuvent s’accommoder d’un tel cycle. D’où le décalage notable entre les présentations retenues et les attentes des participants. Franchement, à quoi peut bien servir un parser de fichiers PDF écrit en OCaml dans le travail quotidien d’un industriel ? (Réponse).
• La couverture médiatique nationale est nulle (à l’exception de cet article dans Ouest France). Je ne parle même pas de la couverture internationale puisque SSTIC doit être l’un des derniers événements majeurs à se tenir dans la langue vernaculaire de ses hôtes.

Le SSTIC permettait auparavant à de jeunes consultants isolés en SSII de mettre en avant leurs découvertes et de rencontrer leurs pairs. Intervenir à SSTIC leur permettait de se faire connaître, voire d’être recruté dans des institutions où ils pourraient épanouir leurs talents. Cette mission n’est plus ; aujourd’hui le SSTIC sert essentiellement de piédestal aux différents bureaux de l’ANSSI afin qu’ils puissent se comparer entre eux (et je ne parle pas seulement de Rust vs. OCaml).

Le point d’orgue de cette compétition stérile fût probablement la conférence de clôture à propos de la compromission de TV5 Monde. Louons l’effort de mise en scène qui nous donnait l’impression d’être dans un film d’espionnage (« merci de ne pas divulguer l’identité des intervenants, nos agents risquent leur vie »). Mais au final, cette présentation ne fût que le rappel de quelques conseils de base sur les mots de passe par défaut, les dangers d’un réseau « à plat », etc.

Aucune mention des techniques d’attribution utilisées pour incriminer les Russes, l’utilisation d’outils de forensics et de reconstruction Active Directory qui ne seront probablement jamais publiés ; bref, rien d’actionable pour les participants.

Par ailleurs les quelques CERTs privés avec lesquels j’ai eu l’occasion de discuter attendent toujours de disposer des IOCs liés à cette attaque – qui n’ont apparemment été distribués … qu’aux journalistes ! Quand on compare aux rapports étrangers publiés après la compromission de Diginotar ou plus récemment RUAG, on mesure le chemin qui reste à parcourir avant de disposer de véritables retours d’expérience en France …

Il va être difficile pour le secteur privé de monter en puissance tant qu’il reste infantilisé par les autorités.

Le contenu

Le programme de l’événement peut lui aussi surprendre ; par exemple le fait de constater que plusieurs présentations de l’ANSSI étaient dédiées au parsing de fichiers PDF avec des outils et des langages différents …

Cet état de fait est symptomatique d’une tare plus générale : la recherche en sécurité – au moins en France – reste au point mort depuis des années. La cause en est que la sécurité ne se conçoit pas comme une science qui avance au rythme de l’innovation incrémentale, mais comme un one-man show. En clair, il est plus prestigieux de lancer « son » nouvel outil que d’améliorer à la marge l’existant.

Les exemples sont légions ; je pense par exemple à la présentation sur la détection de PDFs malveillants par « machine learning ». Sauf erreur de ma part, l’outil publié extrait un vecteur de caractéristiques (ex. présence du mot-clé « OpenAction ») qui est ensuite passé à un outil de classification. Comme je l’ai mentionné en séance, j’ai du mal à voir la différence avec le module PDF de « l’antivirus français » (Armadito) – ou le module pdfcop de l’outil Origami PDF publié à … SSTIC 2009 ! Le plus grave dans l’affaire étant que les intervenants semblaient sincèrement surpris par ma question, et n’avaient pas connaissance de tous ces travaux antérieurs (leur papier ne contient que des références académiques de type IEEE ou ACM).

Le plus triste est probablement la liste des occasions manquées – c’est-à-dire des présentations que personne n’a soumis. Rien sur l’Immutable Infrastructure (alors que Desired State Configuration pourrait trouver sa place dans la liste des outils de sécurité Windows), rien sur le Cloud, aucune conférence sérieuse sur le Machine Learning appliqué à la sécurité … bref, on tourne toujours sur les mêmes recettes.

A contrario, le nombre de présentations sur le Reverse Engineering semble disproportionné dans un monde où même Microsoft embrasse l’Open Source avec vigueur.

Le désespoir

Enfin, le point qui me choque le plus est probablement le désespoir – ou le cynisme – qui frappe la profession. Payé pour donner son avis à longueur de temps sur des projets en perdition, ou rafistoler des infrastructures entièrement compromises, le consultant en sécurité vieillit mal.

On me reprochera certainement de donner un avis un peu trop cru – que ce soit au micro ou dans mes billets. Mais j’ai le bon goût de le faire publiquement, ce qui permet aux personnes concernées de se défendre. J’avoue que le niveau de persiflage que j’ai pu entendre dans les couloirs du SSTIC me laisse pantois. Les hackers avaient l’image d’une communauté soudée qui tirent les nouveaux vers le haut et ne basent leurs jugements que sur des faits techniques. La communauté moderne de la cybersécurité n’ira nulle part si elle se construit sur la rancœur et le cynisme. Ce mal est probablement le fondement des tous les échecs en sécurité ; mes récentes expériences avec le monde des développeurs m’ont appris combien l’image des experts en sécurité avait été écornée par cette attitude nihiliste.

En ce qui me concerne, soyez rassuré : je n’ai jamais critiqué personne sans m’assurer que mes griefs circonstanciés lui soient transmis. J’espère que vous en ferez autant les uns envers les autres.

Le gâchis

Enfin ! Après 4 ans de travail et 5M€ de financement public, le projet d’antivirus « souverain » vient d’être publié sur GitHub.

Initialement connu sous le nom de DAVFI (Démonstrateurs d'AntiVirus Français et Internationaux), puis Uhuru Anti Malware (marque commerciale), le projet Open Source s’appelle désormais Armadito – est-ce un clin d’œil à la protection logicielle bien connue - mais désormais obsolète - « Armadillo » ?

Histoire

L’histoire de ce projet est controversée. Comme toute initiative dont la nationalité est la seule raison d’être, elle fut vertement critiquée à ses débuts. Et comme toutes les initiatives comparables, la malédiction n’a pas tardé à s’abattre : après avoir initié le développement du projet, puis transféré l’industrialisation (ainsi qu’un « personnel administratif senior » – en l’occurrence sa femme) au consortium porté par Nov’IT, M. Filiol a subitement fait volte-face et lâché ses chiens contre le projet Uhuru – allant même jusqu’à annoncer un « fork » Open Source sous le d’OpenDAVFI (dont on attend toujours la publication promise).

Ce drame franco-français n’est pas sans rappeler la mésaventure du « Cloud souverain », assez rapidement scindé en deux projets aussi infructueux l’un que l’autre. La dissension ne conduit généralement qu’au saupoudrage d’argent public.

Le divorce des « antivirus souverains » semble avoir été particulièrement douloureux, à en juger par les billets publiés sur le blog (payant) SecuriteOff : « Uhuru antimalware, a French deception » et « Les antivirus Uhuru, la grande mystification ». A contrario, le seul article positif – « Fin et bilan du projet DAVFI » - a disparu d’Internet (puisque le site n’autorise aucune indexation ni archivage de son contenu – à se demander qui sont ses lecteurs).

EDIT: l'article est toujours disponible à cette adresse. L'éditeur n'a pas jugé utile de rediriger les favoris antérieurs à la refonte du site (circa septembre 2015).

Technique

Il serait loisible mais peu charitable de se gausser des errements techniques du projet. Après tout nul n’est à l’abri d’une erreur d’implémentation.

Certes la librairie de « chiffrement » Perseus – censée protéger les SMS sur la version « Android » du projet – est régulièrement la risée des participants à la conférence SSTIC [2014][2015]. Le plus grave dans ces failles n’étant pas les détails d’implémentation, mais la méconnaissance répétée des mécanismes de génération d’aléa par son auteur ; pourtant l’un des fondamentaux de la cryptologie.

Certes la version « Android » du projet, publiée en 2014, a été immédiatement « cassée » de manière triviale : il était possible d’exécuter des commandes shell depuis la mire de démarrage du téléphone. Le plus grave a probablement été la réaction du projet, consistant à éditer agressivement la page Wikipedia dans une tentative désespérée de damage control.

Certes la version « Windows », récemment libérée sur GitHub, souffre de failles énormes – pour la plupart présentées lors BeeRump 2016 et dont j’espère la publication prochaine. Certains esprits taquins s’en sont même amusés publiquement. A cette liste s’ajoute la détection de codes malveillants dans les fichiers PDF par la recherche de motifs triviaux, ou l’incapacité totale à analyser des exécutables « .NET ».

L’essentiel des heuristiques « avancées » issues de la recherche en virologie consiste à comparer la liste des sections et des imports du fichier exécutable avec une base de référence, comprenant des fichiers « sains » et des fichiers « malveillants ». Il serait possible de se livrer à une analyse critique sur la méthode de calcul utilisée – et surtout l’importance de la base de référence – mais il s’agit d’un domaine technique ennuyeux pour le lectorat, qui est invité à chercher « import hash » dans son moteur favori (ou dépenser 35€ chez Springer).

Le véritable problème de cette heuristique, c’est qu’elle détecte plusieurs composants critiques du système Windows lui-même comme malveillants. Ce qui pose la question du contrôle qualité chez l’éditeur – le faux positif étant un événement essentiellement catastrophique.

Perspectives

Au-delà de l’idée assez classique des « import hash », le projet Armadito échoue à innover dans le domaine de la virologie opérationnelle.

Le principal reproche qu’on peut faire aux logiciels actuels est certainement l’accroissement de la surface d’attaque due aux nombreux parsers – qui ne sont malheureusement ni sandboxés, ni écrits en OCaml. Ce point est régulièrement mis en exergue par les travaux de Tavis Ormandy.

Un moteur d’analyse conçu pour résister à ses propres défauts – par exemple une sandbox pour ClamAV –  eut été un apport non négligeable à l’état de l’art, directement utilisable par la communauté. Au lieu de cela, les premiers tests de fuzzing semblent montrer une extrême fragilité du parser PDF – entièrement implémenté en C.

Parmi les autres idées dont on aurait pu se plaire à rêver, citons :

• La capacité à autoriser ou bloquer des processus selon des critères personnalisés, tels qu’une signature Authenticode (à la Bit9) ou une signature YARA - la fonctionnalité AppLocker offerte nativement par Windows étant bien trop limitée de ce point de vue.
• La capacité à journaliser et remonter en temps réel l’activité des processus sur une machine.
• Une API ouverte permettant d’interagir avec le moteur d’analyse, par exemple pour réaliser un hunt dans un parc étendu. L’intégration de cette API dans des outils standards tels que PowerShell serait un plus.
• Un kit de développement permettant l’extension du moteur avec des greffons – bien entendu sandboxés (à la Nessus, avec son langage NASL). Ceci permettrait également de créer une communauté autour du produit ; voire de pérenniser l’activité en commercialisant les greffons les plus complexes.
• Le support de vecteurs dangereux et peu analysés pour le moment, tels que les scripts PowerShell ou les macros Office.

Je n’aborde pas la question des signatures ; elle est à mon sens anecdotique. Les outils existants échouent systématiquement à détecter le dernier ransomware ou la dernière APT ; un modèle de sécurité basé sur des signatures (liste noire) est voué à l’échec face à des attaquants déterminés.

Conclusion

Confier le développement d’un logiciel – qui plus est de sécurité – à une armée mexicaine en partie composée de stagiaires et de thésards, n’ayant aucune expérience antérieure dans l’édition logicielle – ni la sécurité, ni aucune connaissance opérationnelle du monde de l’entreprise, sur la base de quelques travaux académiques à l’applicabilité douteuse : quelqu’un y croyait-il sérieusement ?

La seule explication rationnelle à l'existence de ce projet n'est probablement pas à chercher du côté de l'avancement de la science.

Etat de l’Art

Cette année encore, il m'a été donné d'assister à l'évènement professionnel majeur de la sécurité informatique française, à savoir les Assises de la Sécurité.

Je n'ai pas l'intention d'en produire un compte-rendu circonstancié ; d'autres s'en chargeront mieux que moi. J'ai plutôt l'intention de revenir sur un sentiment diffus parmi les barbus du domaine: plus les choses changent, plus elles restent les mêmes.

Retour sur une keynote

La seule conférence digne d'intérêt est la désormais traditionnelle keynote de l'ANSSI. Sans nier la qualité des autres "ateliers" – tantôt distrayant, tantôt édifiant – ils relèvent plus de l'anecdote quand il ne s'agit pas purement et simplement d'un vendor pitch. A contrario, l'ANSSI est probablement la seule institution qui dispose d'un plan. C'est la seule à pouvoir faire référence à ses interventions passées – réalisant un point d'étape sur différents sujets tels que la labellisation ou la législation. Tous les autres acteurs sont ballotés au gré des modes.

(Car la sécurité est une vraie victime de la mode. Cette année, exit le patch management ou l'APT. Cette année, c'est le (Cyber)SOC qui est fashionable)

Et il faut dire que l'ANSSI ne manque pas de sujets cette année: la règlementation, les coopérations avec l'Allemagne mais aussi avec les USA, le développement "en régions", la sensibilisation du grand public (jetez un œil à la Hack Academy, ça vaut son pesant de cacahuètes), le partage d'information avec les industriels, la labellisation des prestataires (PDIS, PRIS et Cloud entre autres) … impossible de tout commenter, mais les trois messages suivants me semblent intéressant.

1. L'ANSSI est réticente à partager des indicateurs de compromission (IOC) avec les industriels pour au moins deux raisons:

• d'abord les industriels disposent rarement de la maturité nécessaire pour pouvoir rechercher un IOC efficacement dans leur parc (ce qui n'est malheureusement pas faux) ;
• ensuite ils ne savent pas conserver ces IOC secrets. On peut débattre sur le fait qu'un IOC doive rester secret – puisqu'ils servent plus à comprendre le passé qu'à prédire l'avenir – mais il est certain que le recours massif à la sous-traitance dans les services informatiques est difficilement compatible avec la préservation d'un secret. Sans parler du cas où l'industriel est dans le conflit d'intérêt patent, étant à la fois fournisseur de services de détection d'intrusion et intrusé lui-même (ne rigolez pas, ça s'est vu).

2. La détection et la réponse aux incidents sont des domaines qui ne tolèrent pas l'amateurisme ; le recours à des prestataires aguerris est vivement recommandé. On ne peut que partager ce constat, néanmoins j'ai la vague impression que les prestataires actuels – qu'ils soient en cours de labellisation ou non – manquent singulièrement d'expérience dans le domaine et font une large part à l'improvisation la plus totale (voire à l'amateurisme).

3. Le Cloud élève le niveau de sécurité des petites entreprises dont le service informatique n'atteint pas la masse critique. Là encore, on ne peut que partager ce constat: vos emails sont bien souvent mieux protégés dans un service en ligne supportant l'authentification à 2 facteurs que sur un serveur de messagerie interne.

Au delà de la keynote de l'ANSSI, et avec mon regard désormais extérieur, j'ai été frappé par les trois plaies de la cybersécurité françaises tandis que je déambulais dans les travées du salon.

1. L'empilement des boites

C'est une tarte à la crème sur laquelle tout le monde s'accorde: la technique ne résout pas tout (pas de silver bullet), il ne faut pas négliger l'humain, etc.

Pourtant on ne croise au fil des allées que des vendeurs de boites.

Quiconque a déménagé sait que les boites s'empilent plus facilement quand elles sont du même gabarit. Et c'est bien le problème: chaque vendeur conçoit des produits parfaitement autistes, comptant sur les autres pour s'y intégrer. Chacun son format de log, chacun sa console d'administration, chacun son périmètre fonctionnel.

Le sens de l'histoire nous emmène pourtant vers les micro-services et les API. Pourquoi déployer un agent de forensics sur des machines déjà équipées d'un antivirus ? Ne serait-il pas plus efficace d'avoir un seul agent minimaliste, avec une API simple et documentée, permettant l'accès au système de fichiers ? L'avenir de la sécurité n'est-il pas dans la conception de briques de base Open Source ?

Au lieu d'être l'esclave de ses produits, le RSSI deviendrait le maitre d'œuvre d'une intégration harmonieuse.

Et franchement, quand on regarde le périmètre couvert par certaines solutions du marché, on ne peut qu'être déçu. Comment justifier l'acquisition d'une solution complète (et fermée) pour un service aussi basique que le chiffrement de fichiers par exemple, qui est nativement disponible dans tous les systèmes d'exploitation du marché ?

Autant il me semblerait intéressant d'unifier la gestion des secrets cryptographiques à l'échelle de tous les systèmes d'entreprise (protection des fichiers, protection des emails, certificats, etc.), autant le chiffrement de fichiers en lui-même ne me semble être qu'un sous-ensemble trivial du problème – et ne justifie clairement pas l'absorption d'une quotité significative du budget sécurité.

2. Le franco-français

Les Assises de la Sécurité sont un évènement plus social que technique. "Le RSSI c'est celui qui mange seul à la cantine" ; pour une fois il peut échanger avec des milliers de personnes qui partagent le même buffet.

Malheureusement la rencontre est biaisée. Le milieu de la sécurité informatique français est si restreint qu'il frise déjà la consanguinité, mais ici tous les autres invités sont aussi des consommateurs de produits de sécurité. Quant aux intervenants, il n'y en a pour ainsi dire aucun qui ne soit pas exposant, à l'exception de quelques keynotes … très "high level". Ici, les organisateurs ne rémunèrent pas les intervenants pour assurer un contenu de qualité, mais monnaient au contraire le droit de s'exprimer.

Les échanges se limitent alors à un retour d'expérience sur tel produit ou tel prestataire, mais "on invente pas l'électricité en perfectionnant la bougie": les chances de repartir avec des idées disruptives ou de bousculer un visionnaire lors du cocktail sont assez minces. Surtout que l'appétence au changement n'est ni répandue, ni valorisée dans une profession de RSSI de plus en plus normée et standardisée.

Pourtant de nouvelles idées – comme la dépérimétrisation – existent … ailleurs.

3. L'incompréhension des enjeux

L'ultime frontière – qui catalyse toutes les peurs et tous les espoirs de la profession – se nomme Cloud. Le Cloud, c'est comme le sexe chez les ados: personne ne sait ce que c'est, mais tout le monde pense que les autres en font.

Pourtant derrière le Cloud, se dessine une réalité tangible: l'informatique devient trop compliquée – et les investissements trop couteux – pour les utilisateurs finaux.

C'est le sens de l'histoire. J'ai connu la télévision en noir et blanc (la redevance était moins chère que sur la couleur) avec le condensateur en façade permettant de syntoniser les chaines. La génération précédente construisait elle-même son téléviseur en suivant les schémas disponibles dans feu Radio Plans. Aujourd'hui il ne viendrait à l'idée de personne de concevoir sa propre carte mère allant du démodulateur DVB-T au décodage de flux H.264.

L'informatique suit le même chemin ; les leaders ont compris qu'on n'avancerait plus en essayant d'empiler des legos de forme et de couleur différente, mais en devenant maitre de son destin. Développeur est le métier le plus prisé de la Silicon Valley ; il n'y a plus de catalogues produits mais des briques de stockage, de traitement et de présentation qu'il faut assembler pour créer les services du futur. Docker everywhere.

S'il est un point sur lequel les vieux barbus se sont accordés pendant ces Assises de la Sécurité, c'est bien que les RSSI "d'infrastructure" sont dépassés. Ce qui viendra après reste à définir.

Sécurité et espionnage informatique

J’ai donc lu “Sécurité et espionnage informatique – connaissance de la menace APT”.

Je ne vais pas vous faire le profil de l’oeuvre. Si votre chef vous a demandé une synthèse des solutions miracles pour demain … débrouillez vous :)

Par contre je vais vous épargner la recopie manuelle des hashes donnés en exemple page 106 – ils ne contiennent rien d’intéressant.

$ john --show hash.txt
borislz:TOTO42:F67AC4C658E4EBA7AAD3B435B51404EE:F116850228DF3C891BB260730A65E78F
cpe:TOTOTOTO42:A466CD4F80A06085A973C7865148EF2E:837DB89C7B7C6444E1D189AFC266F1BE

Non, si vous avez vraiment du temps à perdre, il vaut mieux vous attaquer directement aux hashes donnés page 105: ils ont été “anonymisés” ; ils doivent donc être importants.

Voici ce que ça donne:

cpe:cpe-PC:3A6999A4D3EA7D4469...:35560bc48654e...

Nous disposons donc du hash LM partiel et du hash NTLM partiel pour le même mot de passe. C’est entièrement suffisant pour retrouver le mot de passe d’origine, sauf collision hautement improbable.

Tout expert sécurité sait que le hash LM se compose de deux demi-hashes totalement indépendants. Ici la première moitié du hash LM est donnée en totalité, l’inversion du demi-hash s’effectue donc instantanément avec John ou n’importe quelle Rainbow Table.

3A6999A4D3EA7D44 –> PCKRD42

Malheureusement le mot de passe est mis en majuscules avant le calcul du hash LM ; il n’est donc pas possible de connaitre la casse réelle à ce stade.

Prenant en compte ce fait, il est désormais possible de compléter le mot de passe jusqu’à tomber sur un hash NTLM commençant par 35560bc48654e (la probabilité d’une collision est pour ainsi dire nulle).

Un simple script Python suffit, car la réponse ne tarde pas à venir:

Pckrd42!:3A6999A4D3EA7D44695109AB020E401C:35560BC48654EF33BD7162C7721BDE8C:::

Ce mot de passe est très intéressant, car il vérifie tous les critères appliqués habituellement en entreprise (mais beaucoup plus rarement chez les particuliers):

• Longueur 8
• Présence de majuscules/minuscules/chiffres/caractères spéciaux
• Deux derniers chiffres ressemblant fortement à un incrément (il s’agit d’une construction universellement appliquée par les utilisateurs lorsqu’un changement régulier de mot de passe est imposé – 42 jours par défaut sous Windows).

S’agirait-il d’une capture d’écran réalisée sur le poste de travail de l’auteur ? Celui-ci ayant changé d’entreprise il y a quelques semaines ; on peut de toute façon espérer que son compte ait été verrouillé et ses accès révoqués :)