PACK Flipbook MISC & HS 2018


  • Flipbook (liseuse HTML5)


  • Flipbook (liseuse HTML5)


  • Flipbook (liseuse HTML5)


  • Flipbook (liseuse HTML5)


  • Flipbook (liseuse HTML5)


  • Flipbook (liseuse HTML5)


  • Flipbook (liseuse HTML5)


  • Flipbook (liseuse HTML5)

Docker : Quelle sécurité pour les conteneurs ?

  1. Tour d'horizon de la sécurité de Docker
  2. Initiez-vous aux fondamentaux des conteneurs Linux : namespaces/cgroups
  3. Bonnes pratiques dans le déploiement de Docker
  4. Sécurité et agilité grâce aux conteneurs

sommaire :

Exploit Corner

p. 04 Exploitation du CVE-2015-4843

Malware Corner

p. 10 C’est une bonne situation, ça, Scribbles ?

Forensic Corner

p. 14 Paniquez pas, on grep !

Dossier

p. 22 Préambule
p. 23 Aperçu de la sécurité de Docker
p. 31 Introduction aux containers Linux
p. 40 Docker : les bons réflexes à adopter
p. 48 Docker, DevOps & sécurité : enfin réconciliés !

Réseau

p. 54 Protection 802.1x et techniques de contournement
p. 62 Trouver efficacement les équipements réseau vulnérables à un PSIRT

Système

p. 70 FreeOTP : authentification VPN à 2 facteurs open source

Organisation & Juridique

p. 78 Les CERT, acteurs de la cybersécurité internationale

edito :

The user’s going to pick dancing pigs over security every time™

Lors d’une conférence il y a quelques semaines, j’évoquais avec une collègue la GPDR et la nécessité selon moi d’une intervention des États pour contraindre les sociétés à protéger les données personnelles des usagers de leurs services numériques. Pour balayer devant ma porte, les administrations font souvent elles aussi preuve d’une coupable négligence et la sécurité est trop souvent considérée par les maîtrises d’ouvrage comme une brique technique pouvant être ajoutée en toute fin de projet par les maîtrises d’œuvre quand tout le reste est terminé. L’expression des besoins se résumant alors très schématiquement à « le niveau de sécurité doit être maximum sans perturber les utilisateurs, retarder la mise en service ou dépenser un euro de plus. Bonne chance les gars, on compte sur vous ! »

Pour revenir aux différents exemples de sociétés ayant perdu dans la nature la totalité de leurs données utilisateurs, mon interlocuteur m’opposait que Yahoo! était déjà un cadavre à la renverse quand ses données s’étaient faites pirater, qu’Ashley Madison était un marché de niche dont l’impact des pertes de ses bases était difficile à évaluer. Enfin pour Equifax, les utilisateurs présents dans leurs bases n’ayant pas choisi d’y être, la perte de confiance dans la sécurité de leurs données n’aurait pas forcément une grande incidence sur le business.

Peut être suis-je pessimiste, mais pour reprendre un exemple récent, je ne pense pas que la fuite de données personnelles conduise beaucoup d’utilisateurs à renoncer à gagner quelques euros sur leur prochaine course de taxi. Et par conséquent, je doute de la capacité des entreprises à assurer sans y être contraintes la sécurisation des données de leurs utilisateurs, il en est évidemment de même pour les téléservices des administrations pour lesquels il est de plus en plus rare de se voir proposer une alternative.

Mais trêve de défaitisme, cet édito est également l’occasion de vous faire part de deux ajustements dans le magazine.

Le premier est qu’à partir de ce numéro, Émilien Gaspar, déjà contributeur régulier de MISC et rédacteur en chef de plusieurs hors-séries va prendre en charge les dossiers. Il commence dès le numéro de janvier avec un dossier sur la sécurité des conteneurs, technologie ô combien à la mode qui a déferlé dans nos data centers pour devenir en quelques années incontournable.

Le second est que nous allons recentrer le magazine sur les sujets techniques. Certains d’entre vous nous ont fait part de leur réserve quant à quelques dossiers ou articles s’écartant un peu de la ligne éditoriale historique de MISC pour s’aventurer sur des sujets plus organisationnels. Nous en prenons donc acte et nous engageons dans un retour aux sources dès ce numéro.

Cedric Foll / cedric@miscmag.com / @follc

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

sommaire :

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

edito :

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

Comment lire gratuitement ce numéro depuis votre PC, tablette ou smartphone ?

1) Créez un compte ou connectez-vous,

2) Ajoutez MISC 97 à votre panier, 

3) Confirmez votre commande, 

4) Rendez-vous sur votre compte de la boutique en ligne, rubrique « Mes publications numériques »

5) Cliquez sur l’icône de visualisation, vous pourrez ainsi profiter de votre magazine offert ! 

Toutes les revues proposées dans ce format, se feuillettent facilement, en ligne, depuis votre compte boutique. 
Véritable livre numérique, vous pourrez lire votre publication en tournant les pages de manière élégante, pour une lecture agréable.


SOMMAIRE :

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)

ÉDITO :

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é

sommaire

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

édito

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

Sommaire

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

édito

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

sommaire

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 ?

édito

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/

Recherche de vulnérabilités

Découvrez de nouveaux outils pour auditer vos applications


sommaire

Analyse statique & dynamique

p.10 Analyse concolique de binaires avec angr
p.22 Introduction au développement de plugins pour Radare2
p.44 Usages avancés d’AFL

Cryptographie

p. 66 Testons votre crypto !
p. 76 Algorithmes et implémentations cryptographiques vulnérables : détection avec grap

IoT

p. 92 Toolkit 4.0 : revue des outils pour l’exploitation pour l’IoT

Web

p. 110 Recherche passive de vulnérabilités web avec Snuffleupagus
p. 116 Wapiti : chasser les vulnérabilités web

Préface

« Aucune règle n’existe, les exemples ne viennent qu’au secours des règles en peine d’exister. »
André Breton

La recherche de vulnérabilités est un domaine vaste, tout comme les outils dont dispose le chercheur en sécurité. Les colonnes de MISC ont ainsi déjà vu bon nombre de ces programmes, incontournables pour certains, mais l’évolution du domaine nous apporte chaque jour son lot de scripts, bouts de code, plugins, preuves de concept et frameworks en tout genre. Est en cause notamment la grande diversité des cibles et des méthodes. D’une part, que l’on s’attaque à du web, de la cryptographie ou à tout ce que l’on peut trouver dans l’Internet des objets, force est de constater qu’il va être nécessaire, pour chaque cas, d’avoir un outillage spécifique pour peu que celui-ci existe et qu’il ne faille pas en développer un. De la même manière, les techniques utilisées sont extrêmement variées : reverse, fuzzing, analyse statique automatisée, exécution symbolique ou simple lecture de code, pour ne prendre que quelques exemples.

Dans cette étendue de possibilités, l’approche du présent hors-série va être de s’intéresser aux outils récents et qui présentent un intérêt dans un domaine particulier de la recherche de vulnérabilités. Les pages qui vont suivre vont se concentrer essentiellement à décrire les principes sur lesquels reposent les différents programmes sélectionnés dans ce hors-série ainsi que leurs usages via des exemples pratiques. Les limites vont être que l’on ne parlera pas d’exploitation et que les connaissances théoriques nécessaires à l’approche de certains domaines seront abordés partiellement et nécessiteront d’autres lectures pour ceux qui seraient plus intéressés. Il est d’ailleurs important de noter que, quel que soit l’outil, quelle que soit la technique, les connaissances élémentaires restent l’arme la plus forte. À quoi bon trouver des dizaines de crashs en utilisant du fuzzing si l’on n’est pas capable d’interpréter minimalement les résultats ?

Le numéro va s’articuler autour de quatre thématiques. Il va s’agir dans un premier temps de découvrir ou d’approfondir des outils permettant de faire de la rétro-ingénierie (radare2), du fuzzing (afl) et de l’exécution concolique (angr). S’ensuivra une partie passionnante et accessible sur la cryptographie : initiation à CDF (crypto differential fuzzing) et Wycheproof pour tester la qualité de votre code cryptographique, et découverte de grap, un outil aux nombreuses possibilités et dont on verra une application pour détecter des algorithmes cryptographiques obsolètes dans des binaires. Une troisième partie sera consacrée à la prise en main des outils nécessaires à l’analyse des objets connectés. Enfin, dans la dernière partie sera traité le domaine du web avec la découverte de Wapiti et Snuffleupagus, un scanneur de vulnérabilités et un module de sécurité pour php7.

Bonne lecture,

Émilien Gaspar / gapz / eg@miscmag.com

Machine learning & sécurité


sommaire

Actus

p. 08  Revue de livres
p. 10  Entretien avec Julien Cornebise, expert en machine learning

Malware

p. 16  Aux voleurs

Dossier

p. 24  Introduction
p. 28  Machine Learning : un (rapide) tour d’horizon
p. 42  ML & sécurité : les opportunités
p. 51  Vers une détection d’intrusion dynamique et continue en utilisant les réseaux de neurones
p. 62  Machine Learning en Python : clusterisation à la rescousse des hunters (de malware)
p. 74  Automeans, ou comment éviter le « k par k » avec K-means
p. 84  Analyse des sentiments avec le Deep Learning
p. 97  YaDiff : de l’Intelligence Artificielle pour comparer les codes binaires

Code

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

Sciences

p. 114  Introduction à l’apprentissage par renforcement, sans code et presque sans maths
p. 122  Graphes géants creux : comment définir le centre du Web

édito

De l’hermétisme au marketing

Qu’il s’agisse de lessive lavant plus blanc que blanc ou d’une énième vulnérabilité cataclysmique, la résultante invariable du marketing est de produire, à un moment, du faux. Prenons le quotidien de quiconque ferait un minimum de veille du côté des vulnérabilités : dans les méthodes à l’ancienne, suivre les listes de diffusion comme full-disclosure, bugtraq ou oss-sec par exemple n’est pas chose aisée tant la pluie de CVE est quasi-permanente et l’information toujours partielle (même si quelques advisory et discussions de qualité sont là pour rattraper l’ensemble). Du côté de Twitter, si l’on arrive à mettre de côté les petites querelles du moment, on y trouve une quantité intéressante d’informations, bon nombre d’experts en sécurité francophones et anglophones l’utilisant au quotidien. Jusque-là, faire la part des choses, distinguer ce qui est pertinent ou non, se faisait dans un flux permanent avec ces hauts (POC sur full-disclosure) et ces bas (hoax). Puis est arrivé le marketing : nom, site, logo, script/outil, vidéos, raz de marée sur Twitter, papiers dans les journaux grand public, annonce d’une demi-fin du monde, et cela pour une vulnérabilité (dans certains cas même quasi inexploitable). Et voilà que l’on a basculé dans le rythme infernal de la course à la célébrité pour les vulnérabilités. Certes, pour l’initié (toi, lecteur de MISC), tout cela s’apparente essentiellement à une dégradation du rapport signal/bruit dans la veille quotidienne.

Mais où est le faux ? D’une part, il n’y a pas de corrélation directe entre l’impact de la faille et la célébrité qui lui a été associée. Il peut s’agir parfois d’un travail élégant ou étonnant, ou qui touche simplement un élément important. Il est très difficile de quantifier le nombre de vulnérabilités critiques qui sont passées sous silence, tout comme la course aux vues/retweets/etc. pousse à exagérer l’impact réel. D’autre part, quand l’information arrive dans un média grand public, qu’elle soit traitée correctement ou non, il est souvent fait complètement abstraction des enjeux réels de la sécurité, qui sont souvent bien loin des failles à la mode. Ce ne sont que des exemples très simples de ce que peut produire le marketing, on peut facilement imaginer la confusion supplémentaire que cela rajoute d’une manière générale. Comme le disait si bien Nietzsche : « le demi-savoir triomphe plus facilement que le savoir complet : il conçoit les choses plus simples qu’elles ne sont, et en forme par suite une idée plus saisissable et plus convaincante ».

Alors certes, il y a des failles qui ont connu un grand succès pour de bonnes raisons, mais est-ce bien raisonnable de se prendre au jeu de la communication ? Si le travail produit est intéressant, la qualité ne se suffit-elle pas à elle-même ?

Émilien Gaspar / gapz / eg@miscmag.com

Acheter ce pack


Référence : PF_MISC&HS_2018

63,66 €

68,85 €

Nouveaux produits