Blockchain : un réel progrès pour la sécurité ?

1. Quelles applications de la blockchain pour la sécurité ?
2. Parity multi-sig-wallet : retour sur un bug à 30 M$
3. Quid de la sécurité des portefeuilles légers Bitcoin ?
4. De Coinhive aux programmes malveillants : analyse du « mining » indésirable

Exploit Corner

p. 04 Réalisation d’une preuve de concept pour la vulnérabilité CVE-2017-5123

Malware Corner

p. 12 Cadeaux de Noël aux reversers

Pentest Corner

p. 16 Utilisation de PowerSploit dans la vraie vie

Dossier

p. 24 Préambule
p. 25 Blockchain, nouveau paradigme de la sécurité ?
p. 34 Wallet Parity : exploitation d'une vulnérabilité à 30 millions de dollars
p. 42 Sécurité des portefeuilles légers Bitcoin
p. 46 Minage indésirable

Code

p. 58 Voyage en C++ie : les objets

Cryptographie

p. 66 Attaques par faute

Système

p. 66 MAC Adress Randomization : tour d'horizon

Réseau

p. 74 Analyse des configurations SSL/TLS de serveurs SMTP

Apocalypse et médiatisation en sécurité informatique

Tout d'abord, et pour reprendre les lignes du dernier édito, dans le cadre du retour aux sources de la ligne éditoriale de MISC, je vais focaliser les thématiques traitées dans les dossiers sur des aspects purement techniques. Bien entendu, certaines seront liées à de nouvelles tendances et comporteront parfois des approches générales du point de vue de la sécurité (conteneurs, blockchain). Tandis que d’autres seront déjà connues, mais avec une approche plus pointue dans les sujets traités (spoil : si tout se passe bien, le prochain dossier sera sur les attaques par canaux auxiliaires avec, au menu, de la crypto, mais aussi des attaques sur les caches – tiens donc !).

Nous sommes à peine quelques mois après l’annonce de Meltdown et Spectre en ce début d’année 2018, et l’on peut déjà rajouter un nouvel épisode à la série des apocalypses en sécurité informatique. XKCD [0] nous a d’ailleurs fait le plaisir de fuiter sa liste des futures CVE qui nous attendent cette année. Pour rappel, la fin du monde, en sécurité, c’est quand il y a eu tellement de progrès technique que nous ne sommes plus capables de corriger une faille sans avoir à changer une partie du système. Notez bien toute l’ironie du propos. Mais il ne faut pas tomber ici dans un relativisme qui mettrait sur un même pied d’égalité Meltdown/Spectre avec les failles qui ont connu un tant soit peu de médiatisation depuis que l’on a mis du marketing dans la boucle du responsible-disclosure.

Entre Heartbleed, Shellshock, une vilaine sqli dans Drupal ou WordPress, des flots d’attaques sur des implémentations de TLS, du RCE dans flash, de l’escape de VM sous Xen, du RCE sur Android, MS17-010 ou encore un mot de passe vide pour devenir root sur OSX : il faut tout de même convenir qu’avec Meltdown/Spectre, on a affaire à des vulnérabilités qui risquent de vivre un peu plus longtemps tant il va être compliqué, et c’est un euphémisme, de mettre à jour l’ensemble de ce qui est impacté (un peu près tout ce qui utilise un CPU : téléphones, routeurs, etc.). Cela va être d’autant plus compliqué du fait qu’il n’existe simplement pas de solution permettant de corriger entièrement le problème pour Spectre sur les systèmes existants, seulement quelques contre-mesures rendant plus difficile l’exploitation de la faille. La règle d’or qui consiste en l’application des mises à jour ne va pas tout résoudre, et nous ne sommes très certainement qu’au début d’une tendance qui va voir naître de plus en plus d’attaques visant le matériel, et donc une difficulté à trouver des remèdes logiciels efficaces. Mais qu’en est-il de l’impact réel de ces failles ? Car tout le monde n’est pas fournisseur de cloud (le prérequis pour exploiter la faille étant de pouvoir exécuter du code), et il est encore un peu tôt pour estimer les dégâts causés par ces vulnérabilités. La surmédiatisation des failles de sécurité entraînant la nécessaire expression des experts, Spectre et Meltdown ont connu un bel épisode les plaçant certainement devant l’invasion de sauterelles dans les évènements apocalyptiques. « Le Mensonge et la Crédulité s'accouplent et engendrent l'Opinion », écrivait Paul Valéry. Pour ceux qui cherchent une réflexion de qualité avec des explications accessibles sur Meltdown/Spectre, je vous conseille chaudement la lecture du billet Colin Percival sur le sujet [1].

Émilien Gaspar / gapz / eg@miscmag.com

[0] https://m.xkcd.com/1957/

[1] http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html

Forensic Corner

p. 06  Archéologie numérique

Exploit Corner

p. 14  Fini le bac à sable. Avec le CVE-2017-3272, devenez un grand !

Pentest  Corner

p. 18  Pentest dans les réseaux CAN : des standards à la pratique

Dossier

p. 28  Préambule
p. 29  Vérifier un code PIN
p. 36  Des attaques en boîte grise pour casser des implémentations cryptographiques en boîte blanche
p. 45  Meltdown et attaques sur KASLR : les attaques par canal auxiliaire passent à la vitesse supérieure
p. 52  Attaques par canaux auxiliaires sur AES – Partie 1

Système  

p. 58  SMTP : la « killer app » de DNSSEC

Réseau

p. 64  Compromission de claviers sans fil 2.4Ghz
p. 74  Evolution des architectures de sécurité réseau en entreprise – Partie 1

Application 

p. 66  Conpot : l'art de faire mûrir ses pommes en simulant un système de contrôle industriel (ICS)

Vous croyez qu'une bande d'énarques a un beau jour d'été inventé un algo meilleur que celui de Gale Shapley ? [1][2] 

Août 2017, petite discussion fictive entre deux conseillers dans les couloirs de l’administration centrale du Ministère de l’Enseignement supérieur, de la Recherche et de l’Innovation.

• On a communiqué largement durant tout l’été sur les ratés d’Admission Post Bac, les bacheliers sans affectation et le tirage au sort dans les filières en tension. Il nous faut une nouvelle application, la ministre s’est engagée à ce qu’il n’y ait plus ce type de problèmes l’année prochaine.
  
  
• Mais vous avez prévu d’ouvrir plus de places dans l’enseignement supérieur ? Parce qu’avec 800.000 candidats pour 650.000 places, vous ne pourrez pas faire des miracles…
  
  
• Ni le ministère ni les universités n’ont de marges de manœuvre budgétaires, nous restons à moyens constants.
  
  
• Alors vous pensez introduire des mécanismes de sélection pour l’entrée à l’université ?
  
  
• L’opinion publique n’est pas prête pour ça. Pas plus que d’accepter de continuer les tirages au sort...
  
  
• C’est la quadrature du cercle, cette question. Vous avez réussi l’année dernière à faire porter la responsabilité sur le logiciel et, même si l’opinion publique ous a plutôt bien suivi, vous ne pourrez pas rejouer la même partition une fois de plus. D’autant que plusieurs voix divergentes se sont fait entendre telles que celle de la Cour des comptes et jusque dans votre majorité [3]. 
  
  
• Avec Admission Post Bac, la totalité des vœux était centralisée et un algorithme tournait pour proposer une affectation au maximum de candidats [4]. Comme il y avait moins de places que de candidats, que personne n’a voulu assumer d’introduire une sélection, on a tiré au hasard les étudiants qui pourraient aller en STAPS et en psycho. Avec le nouveau dispositif, nous allons remettre l’humain au cœur en nous appuyant sur les établissements. Les candidats saisiront leurs vœux comme avant, puis on enverra le tout aux établissements qui se débrouilleront avec.
  
  
• Donc l’idée est de remplacer un processus automatisé par une gestion manuelle de 850.000 bacheliers. Mais étudier autant de dossiers va prendre un temps fou aux établissements !
  
  
• En fait, c’est un peu plus que ça, car, contrairement à Admission Post Bac, il n’y aura plus de hiérarchisation des vœux. Les établissements recevront tous les dossiers sans savoir si c’est le premier choix du candidat ou le dernier. Avec 7 vœux en moyenne l’année dernière, cela fera environ 5.000.000 de dossiers à étudier. À vrai dire, on anticipe que les établissements râlent un peu et que certains s’opposent à réaliser le classement. Si c’est le cas, on pourra toujours leur mettre sur le dos la responsabilité des dysfonctionnements.

Pour revenir à des questions de sécurité des systèmes d’information et d’analyse de risques, je n’envie pas les nuits à venir des RSSI et responsables de l’application ParcourSup ces prochaines semaines. Nous ne vivons pas tous les jours le crash test d’une application concernant une population de 800.000 utilisateurs sous l’attention de tous les médias en direct. Préparez votre popcorn le 22 mai prochain !

Cedric Foll / cedric@miscmag.com / @follc

[1] https://twitter.com/Ipochocho/status/983827378572054528

[2] Conférence inaugurale de Claire Mathieu au Collège de France expliquant l'algorithme Gale et Shappley et son application sur Admission Post Bac (à partir de la 54ème minute) : http://www.college-de-france.fr/site/claire-mathieu/inaugural-lecture-2017-11-16-18h00.htm

[3] Cours des comptes : « ces défauts ne sont pas techniques, mais relèvent de dispositions juridiques et de décisions politiques » ; Cédric Villani : « ce qui a « buggé » dans APB, ce n’est pas le logiciel, mais bien l’État » http://mobile.lemonde.fr/idees/article/2017/12/06/cedric-villani-ce-qui-a-bugge-dans-apb-ce-n-est-pas-le-logiciel-mais-bien-l-etat_5225204_3232.html?xtref=https://fr.m.wikipedia.org/&xtmc=apb&xtcr=1

[4] http://mobile.lemonde.fr/campus/article/2017/12/05/parcoursup-qui-succede-a-apb-risque-de-creer-du-stress-continu-pour-les-candidats-et-leurs-familles_5224705_4401467.html

Authentification :

enfin la fin des mots de passe ?

• Tour d'horizon de l'authentification multi-facteurs
• Retour d'expérience en bug bounty sur des failles d'authentification
• Découvrez le nouveau protocole d'authentification du W3C : WebAuthn
• OpenID Connect : anatomie d'une usurpation d'identité

IoT Corner

p. 06  PiRanhaLysis : rendre l'analyse IoT facile et reproductible

Malware Corner

p. 12  Émulation du bootloader de NotPetya avec Miasm

Forensic Corner

p. 22  Votre SIEM à portée de main avec ElasticSearcb/ElastAlert

Dossier

p. 30  Préambule
p. 31  Tour d'horizon de l'authentification forte (MFA)
p. 39  Web authentification / Password reset : REX de Bug Bounty
p. 48  « WebAuthn » : enfin la fin des mots de passe ?
p. 56  OpenID Connect : présentation du protocole et étude de l'attaque Broken End-User Authentication

Code 

p. 67  Comprendre le fonctionnement des CORS

Cryptographie

p. 72  Attaques par canaux auxiliaires sur AES – Partie 2

Organisation & juridique

p. 78  La surface d'attaque : son utilité, ses limites, ses nouveaux défis

La sécurité est un succès (et un processus d’amélioration continu)

Pour rebondir sur la note d'optimisme de bon aloi de Pappy à propos des 15 ans du SSTIC [1], ne nous enfermons pas dans la posture du berger criant « au loup » en matière de sécurité des systèmes d’information, car globalement le niveau de protection des systèmes d’information n’a jamais été aussi élevé et il est en constante progression.

Au risque de passer pour un vieux con, quand je vois les jeunes s’écrier « la sécurité est un échec » parce que leur brosse à dents se connecte sur un serveur dont le certificat n’est pas certifié A+ chez SSL Lab, je mesure le chemin parcouru ces quinze dernières années. Vous n’imaginiez pas à quel point le niveau de sécurité aujourd’hui semblerait stratosphérique pour un informaticien du début des années 2000 faisant un saut de 15 ans dans le futur.

Imaginez qu’à cette époque pas si lointaine, toutes les applications clients serveurs développées en Delphi ou Access, les bouts de fichiers Excel, se retrouvaient du jour au lendemain propulsées sur le Web, écrites sur un coin de table par un collègue qui avait acheté « PHP pour les nuls » quelques jours plus tôt. Certaines tenaient sans se faire p0wner quelques semaines grâce à magic_quotes_gpc laissé activé par défaut… jusqu’à ce que quelqu’un se plaigne de la présence d'antislash sur les messages déposés dans le livre d’or.

Imaginez qu’il était possible de faire un TP sur les stack-overflows à des étudiants disposant de rudiments d’assembleurs. Pas besoin de se compliquer la vie avec l’adresse aléatoire de la stack, le bit NX ou les canaris. Un coup de gdb pour la stack, un shellcode trouvé sur le net et en trois heures tout le monde réussissait son remote exec.

Côté réseau, c’était encore l'opulence des adresses IPv4 et tout le monde se fichait des problèmes de vie privée. Il était possible dans beaucoup de structures d’être en adressage public complet afin de ne pas trop avoir à se compliquer la vie avec des vues DNS et du NAT. Les utilisateurs naviguaient l’esprit léger pendant leur pause méridienne sur les TGP (Thumbnail Gallery Post, un peu l’ancêtre de Pornhub) depuis leur IP fixe dont le reverse DNS contenait parfois, accolé au nom de domaine de l’entreprise, leur identifiant. La fonctionnalité « navigation privée » n’existait pas encore et dans l’imaginaire collectif, comme à Vegas, ce qui se passait sur Internet restait (et pour cause !) sur Internet.

Ajoutons à cela aucun chiffrement, des outils d'administration se basant uniquement sur l’adresse IP de l'administrateur (les fameux r* tellement plus pratiques que telnet, cet outil pour paranos de la sécurité)  et un réseau bien à plat avec tout le monde dans un gros LAN, serveurs compris. Rappelons-nous qu’en 2000, 802.1q c’était un peu comme Shortest Path Bridge aujourd’hui, tout le monde en avait entendu parler, mais seuls les plus barbus d’entre nous y avaient goûté. Et pour faire bonne figure quelques ACL stateless sur le routeur WAN pour éviter que le port 139 soit accessible sur Internet et que le patrimoine informationnel, les mp3 sur le PC du secrétariat, soit dispersé à tous les vents.

Pour compléter, côté système, nous étions en pleine mode des pizza box (serveurs 1U) rackés à la chaîne sur lesquels tournaient dans le DC moyen au moins un exemplaire de toutes les distributions Linux de l’époque (il fallait bien les comparer) avec un niveau de mise à jour très variable. La virtualisation n’existait pas, encore moins les conteneurs, et faute d’Ansible les mises à jour, quand il y en avait, se faisaient en Expect, merveilleuse extension du non moins magnifique langage TCL. Un dialecte propre à chaque équipe système s’était aussi constitué pour la gestion du versionning des fichiers de configuration tels que « .backup », « .sos », « .derniereversionquifonctionne », « .anesurtoutpaseffacer ».

Alors je veux bien entendre que l’on croise encore des horreurs et qu’il reste des anachronismes qui nous font bondir. Qu’en 2018 il est désespérant que des langages aussi complexes et dangereux que le C soient toujours autant utilisés sur des briques critiques. Côté réseau, qu’Ethernet, ce protocole bête à manger du foin, et sur lequel il faut empiler des briques à n’en plus finir pour combler les lacunes de sécurité (l’ « arp cache poisoning » putain !) soit toujours là et qu’aucun protocole ne semble pouvoir lui succéder à moyen terme. Ou encore que des décideurs soient prompts à déranger leurs équipes en plein week-end pour leur faire patcher immédiatement une vulnérabilité médiatisée sur WPA, mais ne voient aucun problème à se ruer sur le premier portail captif disponible dans les hôtels et aéroports de tous pays.

Alors globalement, dans notre mission qui est la réduction de risque au travers de mesures techniques, il n’y a pas de quoi rougir. Des SI se font toujours pirater, et ce sera certainement encore très longtemps le cas, mais imaginons un instant le carnage que serait le cyber espace avec les besoins de sécurité actuels (à peu près tout est informatisé) ainsi que le niveau des menaces si nous étions restés au niveau de sécurité des années 2000 ?

Cédric Foll

[1] https://www.linkedin.com/pulse/diff-u-sstic2003-sstic2018-pourquoi-les-vieux-sont-encore-raynal/

Environnements d'exécution sécurisés : de SGX à TrustZone

1. – « Trusted Execution Environment » sur Android
2. – Attaques contre la technologie TrustZone
3. – Créer son enclave d'exécution sécurisée à base de FPGA
4. – A la découverte du développement d'une application sécurisée avec Intel SGX

Malware Corner

p. 06  Analyse de JRAT

Pentest Corner

p. 14  Techniques de communications furtives avec Empire Ou comment exfiltrer des données sans être détecté

Forensic Corner

p. 24  Désanonymisation du jeu de données MAWI

Dossier

p. 30  Préambule
p. 31  Android & TEE
p. 40  Attaques sur la technologie TrustZone d’ARM
p. 50  Fabriquer sa propre enclave à base de FPGA
p. 56  Développer une application sécurisée avec Intel SGX

Cryptographie

p. 66  Attaques par canaux auxiliaires : évaluations de sécurité à court et long terme

Système

p. 72  EDR : Endpoint Detection & Response

Code 

p. 78  Cross Origin Resource Sharing : défauts de configurations, vulnérabilités et exploitations

C’est la rentrée, le travail reprend avec force et vigueur !

Dans mon dernier édito [1] relativement optimiste quant à l’amélioration de la sécurité, j’abordais en creux certains domaines pour lesquels il demeurait une marge importante de progression. L’un d’eux me tient particulièrement à cœur, œuvrant dans la sphère de l’éducation nationale depuis une bonne quinzaine d’années, c’est celui de l’enseignement et la formation à la sécurité des systèmes d’information.

Pour ne pas jeter le bébé avec l’eau du bain, quelques initiatives particulièrement louables ont été mises en places telles que le B2I [2] (Brevet Informatique et Internet). Ce dispositif, malheureusement peu connu du grand public vise à fournir un bagage informatique de base à tous les élèves. Il intègre notamment un volet sécurité des systèmes d’information et protection de la vie privée. Un dispositif d’évaluation en ligne remplaçant les actuelles applications localement utilisées dans les collèges et lycées est d’ailleurs accessible en bêta (https://pix.beta.gouv.fr/). Sachant que la validation de ces compétences est obligatoire pour tous les lycéens, parcourir les questionnaires relatifs à la sécurité rend plutôt optimiste quant aux compétences minimales dont devraient disposer nos concitoyens d’ici quelques années. Le niveau de compétence attendu pour tous les élèves de collège et lycée en matière de sécurité et de protection de la vie privée est plutôt ambitieux. Avec un peu d’optimisme, nous pouvons espérer que dans quelques dizaines d’années le phishing ne sera plus qu’un mauvais souvenir !

A contrario, intervenant depuis une bonne dizaine d’années en écoles d’ingénieurs et universités pour des cours de sécurité, je suis régulièrement surpris par l’absence totale de prise en compte des problématiques de SSI dans les cursus informatiques. Ainsi, certains étudiants ont suivi des dizaines d’heures de C et C++ sans savoir entendu parler de buffer-overflow, imaginant qu’au pire, si leurs tableaux sont gérés à la hussarde, leur programme plantera. C’est certes fâcheux, mais un bon watchdog suffira à relancer le programme si un utilisateur malgache essaie de saisir son nom de famille dans un formulaire d’inscription. Très récemment, j’ai fait découvrir les injections SQL à des étudiants quelques mois avant la fin de leur master alors qu’ils avaient transpiré sur Java et PHP des semestres et que la promo allait faire à 80 % du développement web. Si j’ai la faiblesse de croire que certains de mes anciens étudiants se poseront quelques questions lorsqu’ils devront écrire un code manipulant des données saisies par un utilisateur, je crains que de nombreux étudiants diplômés ces dernières années n’aient entendu parler d’aucune des vulnérabilités du top 10 de l’OWASP. La solution la plus pragmatique (ou réaliste si l’on est mauvaise langue) a été de protéger le développeur contre lui-même à renfort de langages évitant au programmeur de faire n’importe quoi avec la mémoire ou de frameworks destinés à l’empêcher d’interagir directement avec les bases de données. Si je ne récuse évidemment pas la pertinence de concevoir des outils évitant un trop grand nombre de failles, la réduction des risques ne peut pas uniquement reposer sur des briques techniques en partant du postulat que les développeurs feront toujours n’importe quoi en matière de sécurité.

On pourra m’objecter que les formations dans lesquelles j’ai pu intervenir ne sont pas représentatives, mais pour avoir participé à beaucoup de recrutements d’informaticiens, le niveau moyen en sécurité d’un jeune diplômé en informatique est généralement très bas. La sécurité est en effet intégrée dans beaucoup de cursus sous forme de modules totalement séparés du reste de la formation. C’est un domaine malheureusement considéré comme relativement secondaire pour un développeur et relevant de spécialistes dont c’est le métier. La complexification des systèmes d’information a induit dès la formation initiale une grande spécialisation et la fin des informaticiens généralistes passant de la configuration d’un routeur au développement d’une application. Il est néanmoins regrettable que beaucoup de filières ne se contentent, en matière de sécurité, que d’une très fine couche de vernis plutôt que de la considérer comme une compétence transverse à tous les métiers de l’informatique.

Quelques relecteurs attentifs m’ont d’ailleurs soufflé qu’une initiative de l’ANSSI engagée en 2013, CyberEdu [3], vise à introduire les notions de cybersécurité dans l’ensemble des formations en informatique et labelliser les cursus s’engageant dans cette démarche. La liste particulièrement réduite des formations actuellement labellisées [4] donne une idée de l'ampleur du travail restant à accomplir.

Cédric FOLL

[1] https://www.miscmag.com/ledito-de-misc-n98/

[2] http://www.education.gouv.fr/cid2553/le-brevet-informatique-et-internet-b2i.html

[3] https://www.ssi.gouv.fr/administration/formations/cyberedu/

[4] http://www.cyberedu.fr/pages/formations-labellisees/

SUPERVISION :

Retours d'expériences autour des SIEM

1. Déploiement d’un SIEM : enjeux et retour d’expérience
2. Développement d’un SIEM open source avec ELK
3. Collecte des logs de systèmes industriels isolés
4. Détection d’intrusion et supervision : s’interfacer avec Suricata

Tribune

p. 06  MISC 100, le changement c’est tout le temps

Malware Corner

p. 10  Analyse du malware bancaire GooTkit et de ses mécanismes de protection

Pentest Corner

p. 14  Quelques vulnérabilités du SDN

Forensic Corner

p. 24  10 ans de Suricata

Dossier

p. 38  Préambule
p. 39  Quelques enjeux pour votre SIEM
p. 46  Game of SOC : mise en place sans encombre d’une solution de SOC avec la stack Elastic
p. 57  Collecte de logs d’installations industrielles isolées
p. 64  Interfacer Suricata avec son écosystème de sécurité

Code

p. 72  Désérialisation Java : une brève introduction

Réseau

p. 78  Comment sécuriser la centralisation du calcul des routes d’un cœur de réseau ?

Et de 100 !

Lecteur de GNU/Linux Magazine depuis le 1er numéro, j’ai passé grâce à ce magazine des dizaines d’heures à expérimenter les merveilles parfois incongrues des langages Scheme, les perles de Mongueurs, le ray tracing avec POV, ou encore les bases de l’administration système. J’ai parfois été dérouté par l'enthousiasme du rédacteur en chef pour GNU Hurd comme j’avais pu l’être à la lecture des articles sur Amiga ou BeOS par la rédaction de Dream mais, sans flagornerie, une très grande partie des compétences informatiques dont je disposais à la sortie d’école d’ingénieur, je la devais à la lecture de la presse spécialisée.

Ainsi, après avoir pu faire mes armes sur les concepts techniques généraux que GNU/Linux Magazine a très largement concouru à me faire acquérir, j’ai découvert dans ses colonnes la série mythique « Éviter les failles de sécurité dès le développement d'une application » co-écrite par Pappy Raynal, Christophe Grenier et Christophe Blaess. Cette série décrivant par le détail les joies des « stack overflow », des « formats strings » ou encore des « race conditions » avec ce côté délicieusement ludique qui allait devenir la marque de fabrique de MISC.

En effet, la philosophie de ces articles n’était évidemment pas de lister par le détail toutes les fonctions dangereuses de C et de proposer une méthodologie d’analyse de conformité d’un code source sur étagère en décrivant les options de grep et les regexp les plus efficaces. Les articles exposaient avec pédagogie et détails le principe des vulnérabilités ainsi que la manière de les exploiter. Disposer d’une description détaillée des attaques pour pouvoir les reproduire, sur son propre système (ou à la rigueur sur un challenge de sécurité ;)), était vraiment inédit dans le paysage éditorial français.

Ma passion pour les attaques informatiques ne faiblissant pas, c’est pendant mon stage ingénieur comme apprenti pentester que je suis tombé sur le hors-série « sécurité informatique » de GNU/Linux Magazine aka MISC 0 aka le numéro à la tête de mort vert fluo. Le niveau de technicité des articles pourrait faire sourire les lecteurs les plus hardcores de MISC aujourd’hui, mais au début des années 2000, les techniques présentées étaient peu documentées, jalousement gardées secrètes. Un nmap suivi d’un Nessus étaient facturés au prix fort par les cabinets de conseil qui se multipliaient sentant l’effet d'aubaine. Découvrir dans ce numéro ce qui constituait l’expertise technique jalousement gardée par la société avait de quoi faire souffler un petit vent de panique parmi les collègues.

MISC a été rapidement rejoint par une multitude de magazines plus ou moins sérieux. Je vous invite d’ailleurs à vous replonger dans toutes ces parutions plus ou moins éphémères sur le génial site « Magazine Abandonware » [1] pour quelques minutes de nostalgie. Si certains d’entre eux proposaient un contenu rédactionnel de qualité et des articles rédigés par des spécialistes du domaine, d’autres étaient rédigés dans une syntaxe qu’un professeur des écoles pourrait qualifier « d’en cours d’acquisition » et promettaient de devenir un h4ck3r sans rien comprendre des architectures systèmes et des protocoles réseaux.

À la différence de ces magazines qui ne sont restés en kiosque que de quelques mois à quelques années, MISC a été pensé autour de valeurs que nous nous efforçons de continuer à faire vivre 17 ans plus tard :

• être un magazine de référence francophone pour la sécurité des systèmes d’informations traités sous un angle technique ;
• couvrir autant des mécanismes de défense que d’informatique offensive ;
• élargir parfois le champ d’études sur des domaines organisationnels ou juridiques sans que cela n’empiète sur le cœur de la ligne éditoriale ;
• maintenir une qualité éditoriale et rédactionnelle propre à intéresser les spécialistes de la sécurité des SI tout en gardant des articles suffisamment didactiques et accessibles pour ne pas être totalement hermétique pour un lectorat débutant dans le domaine de la sécurité.

Pour finir cet édito, je souhaiterais remercier toutes les personnes sans qui MISC ne serait pas ce qu’il est aujourd’hui :

• Frédéric Raynal sans qui ce magazine n’aurait jamais vu le jour.
• Les Éditions Diamond pour avoir fait vivre ce magazine depuis 17 ans et tout particulièrement à Véro puis Aline qui assurent le secrétariat de rédaction. Merci à elles d’avoir géré l’incapacité à peu près générale des auteurs de MISC à utiliser correctement des feuilles de style sous LibreOffice. Incompétence d’ailleurs très largement partagée par les (co-)rédacteurs en chef qui se sont succédé.
• Tous les auteurs de MISC qui font la richesse éditoriale de ce magazine et la diversité des articles. Les anciens auteurs assurant également, avec la rédaction, la relecture de tous les articles avant publication.
• Un immense merci enfin à tous nos lecteurs sans qui nous ne serions plus là aujourd’hui !

Cedric Foll / cedric@miscmag.com / @follc

[1] http://www.abandonware-magazines.org/