[Newsletter HSC] N°135 - décembre 2015 - janvier 2016

Newsletter d'information de HSC newsletter at hsc-news.com
Mer 13 Jan 10:07:36 CET 2016


========================================================================
        HSC Newsletter  --  N°135 --  décembre 2015 & janvier 2016
========================================================================



       « Avec un mauvais vocabulaire, on ne peut pas développer une
         bonne pensée, on est perdu. Tout notre travail devrait être
	 la vérification de chaque mot. »


                                   [Milan Kundera, émission Apostrophes]


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

      1. Éditorial
      2. Le saviez-vous ? La question
      3. Nouvelle formation : "Préparation au CISA"
      4. Nouvelle formation : "Formation RPCA"
      5. HSC by Deloitte présent au FIC à Lille
      6. Compte-rendu de la conférence Hackito Ergo Sum
      7. Appel à communication de la conférence du Club 27001
      8. Appel à communication des GS-DAYS
      9. Appel à communication JSSI de l'OSSIR
     10. Offre d'emploi continuité d'activité
     11. Offres d'emploi HSC pour consultants en sécurité
     12. Agenda des interventions publiques
     13. Prochaines formations HSC
     14. Actualité des associations : Club 27001, OSSIR, Clusif et ISSA
     15. Le saviez-vous ? La réponse



--[ 1. Editorial - Christophe Renard ]-----------------------------------

     Il y a 15 ans l'été dernier, Joel Spolsky publiait une liste qui est 
 devenue une référence du métier de développeur "12 steps to better code" [1].
 Cette liste, pratique bien que simple, est devenue un standard grâce auquel la 
 maturité d'une équipe de développement peut être mesurée.

 Toutes les applications web sont aujourd'hui attaquées. Qu'elles le soient
 pour leur valeur intrinsèque, pour celle des données manipulées, pour s'en
 prendre aux usagers ou utiliser les ressources de son environnement de
 production, toutes les applications sont des cibles. Il n'est plus possible de
 se départir de la responsabilité de sécuriser une application "sans
 importance" et cette responsabilité ne peut plus reposer exclusivement sur les
 équipes de production et de sécurité.

 Malheureusement, l'habitude a été prise de jauger la sécurité des applications
 à leur exposition aux 10 failles les plus courantes recensées par l'OWASP[2].
 Se concentrer sur les vulnérabilités plutôt que les mesures de sécurité
 s'avère peu productif pour les développeurs : c'est parler des problèmes
 plutôt que des solutions. L'OWASP propose une réflexion en sens inverse avec
 ses "10 Proactive Controls"[3] qui donnent une véritable feuille de route de
 sécurisation du développement web.

 Nous vous proposons une liste en 10 points qui vise aux mêmes caractéristiques 
 de simplicité et de lisibilité que celle de Sposky. Notre liste ne prétend
 pas se poser en alternative aux excellents travaux de l'OWASP, mais en
 complément : un inventaire rapide couvrant l'essentiel.

 Si vous êtes développeur et lisez la Newsletter HSC, les chances sont bonnes
 que vous soyez déjà familier avec les entrées de cette liste. Si vous êtes
 commanditaire de développement, elle peut vous aider dans l'interrogation de
 vos fournisseurs, voir dans la formulation d'exigences de sécurité.

 Vous êtes donc invité à partager et utiliser le plus largement possible cette
 liste de mesures de sécurité à contrôler :

  1 - Utilisez-vous systématiquement des requêtes SQL préparées (connues aussi
      sous le nom de requêtes paramétrées) ?
  2 - Utilisez-vous la gestion de session d'un cadriciel[4]/bibliothèque
      fiable ?
  3 - Encodez-vous systématiquement les valeurs venant de l'extérieur
      (utilisateur, base de données...) avant de les envoyer vers l'affichage ?
  4 - Utilisez-vous SSL/TLS sur la totalité de votre site ?
  5 - Stockez-vous et vérifiez-vous les mots de passe utilisateurs uniquement
      en les dérivant avec sha256crypt, bcrypt, scrypt, pbkdf2(sha256) ou 
      argon2[5] ?
  6 - Évitez-vous systématiquement d'utiliser les entrées utilisateurs pour des
      appels systèmes ?
  7 - Stockez-vous les téléchargements utilisateurs vers l'application
      (uploads) dans un environnement restreint ?
  8 - Séparez-vous les paramètres secrets du code ?
  9 - Faites-vous un suivi de version de tout votre code ?
 10 - Gérez-vous vos dépendances et leur sécurité ?

 Ces 10 mesures de sécurité à contrôler sont détaillées en fin de la présente
 newsletter au paragraphe 15.

 Si vous mettez en oeuvre ces 10 pratiques, félicitations, vos applications sont
 probablement immunes aux attaques les plus courantes et vous devriez être
 capable de travailler sur la sécurité dans la durée[6][7][8][9][10]. 

 Sinon, vous avez maintenant une liste de bonnes résolutions pour attaquer la
 nouvelle année.

 Toute l'équipe HSC se joint à moi pour vous souhaiter une excellente année
 2016.


 [1] http://www.joelonsoftware.com/articles/fog0000000043.html
 [2] http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20French.pdf
 [3] https://www.owasp.org/index.php/OWASP_Proactive_Controls
 [4] "cadriciel" en français ou "framework" en anglais
 [5] Argon2 https://password-hashing.net/#argon2

 [6] https://www.cert.org/secure-coding/
 [7] https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards
 [8] https://security.berkeley.edu/content/application-software-security-guidelines
 [9] https://www.sans.org/top25-software-errors/
 [10] http://cwe.mitre.org/top25/mitigations.html#MitigationMatrix



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

     Voici ci-dessous le code source d'un système d'authentification qui
 comporte une vulnérabilité.  En tant qu'utilisateur de l'application au
 quotidien, vous possédez les identifiants valides "user:pass" vous octroyant
 un accès à l'application avec des droits restreints. Comment exploiter la
 vulnérabilité pour obtenir des droits administrateurs ?
  
 Ci-dessous, le formulaire d'authentification "login.html":
 ################################################################## 
 <form action="/cgi-bin/login.cgi" method="GET">
     <p>LOGIN
     <input name="login" /></p>
     <p>PASSWORD
     <input name="password" /></p>
     <input type=submit value="Send form" />
 </form>
 ##################################################################

 Ci-dessous, le script Perl "login.cgi" responsable du traitement de
 l'authentification :
 ##################################################################
 #!/usr/bin/perl -T
 
 use 5.20.2;
 use CGI;
 use Digest::MD5 qw(md5 md5_hex md5_base64);
 
 my $q = CGI->new();
 say $q->header(), $q->start_html();
 
 my $login = $q->param("login");
 
 if (($login eq "admin") || ($login eq "user")){
     my %hash = ("login" => $login,
                 "password" => $q->param("password"));
 
     my $auth = checkCreds(%hash);
 
     if ($auth eq 1){
         if ($login eq "admin"){
             # From here, gives administrative rights to the client and proceed.
             # SUCCESS !!!
             say "<h1>LOGGED AS ADMIN</h1>"; 
         }else{
             # From here, gives only common rights to the client and proceed.
             # FAILED !!!
             say "<h1>LOGGED AS USER</h1>"; 
         }
     }else{
         say "<h1>LOGIN FAILED</h1>";
     }
 }else{
     say "<h1>LOGIN FAILED</h1>";
 }
 
 say $q->end_html();
 
 sub checkCreds{
     my (%hash) = @_;
     my $login = $hash{login};
     my $encrpass = md5_hex($hash{password});
 
     if (($login eq "admin") && ($encrpass eq "2e1f7eaf9b0ccb279cb10e1958d8db59")){
         return 1;
     }elsif (($login eq "user") && ($encrpass eq "1a1dc91c907325c69271ddf0c944bc72")){
         return 1;
     }else{
         return 0;
     }
 }
 ################################################################
 
   Réponse au paragraphe 16.



--[ 3. Nouvelle formation : "Préparation au CISA" ]--------------------

     Nouvelle formation HSC : préparation au CISA. Cette formation sera
 dispensée 2 fois par an, environ 1 mois et demi avant l'examen.

 Le CISA (Certified Information Systems Auditor) est la certification
 internationale des auditeurs des systèmes d'information. Cette certification
 est régulièrement exigée auprès des auditeurs informatique et sécurité,
 notamment par les commissaires aux comptes, par le PCI-SSC [1] pour devenir
 QSA [2] ou par la WLA [3]. Elle est éditée par l'ISACA :
http://www.isaca.org/certification/cisa-certified-information-systems-auditor/pages/default.aspx

 L'examen est un QCM de 4 heures qui se déroule à dates fixes deux fois par
 an en juin et décembre. Il est en français et en anglais au choix du
 candidat. Il s'achète exclusivement auprès de son éditeur l'ISACA
 (http://www.isaca.org/).

 La formation HSC fournit les éléments d'audit et les techniques de base dans
 les domaines du CISA : la pratique de l'audit SI, la gouvernance des SI,
 l'acquisition et l'implantation des SI, l'exploitation et la gestion des SI,
 l'audit de l'informatique, des opérations, des infrastructures et des réseaux
 et la sécurité des actifs informationnels.
 La formation CISA d'HSC est une préparation à l'examen avec des questions à
 l'issue de chaque exposé et un examen blanc de 100 questions.

 Elle s'adresse aux consultants, auditeurs, informaticiens, responsables
 informatiques, chef de projets, etc.

 Première session à Paris du 4 au 8 avril prochain pour préparer l'examen
 du 16 juin. Seconde session du 10 au 14 octobre pour préparer l'examen
 de décembre.

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


 [1] PCI-SSC : Payment Card Industry Data Security Standard 
 [2] QSA : Qualified Security Assessor
 [3] WLA : World Lottery Association


--[ 4. Nouvelle formation : "Formation RPCA" ]---------------------------

     Nouvelle formation HSC : "Formation RPCA", dispensée 2 fois par an.

     Quel que soit son secteur d'activité, être capable d'assurer la
 continuité des activités est plus que jamais au coeur des préoccupations
 des entreprises. Et ne nous y trompons pas : si la dimension informatique
 est souvent primordiale en continuité d'activité, autant, elle n'est pas
 tout ! Si l'on souhaite que le Plan de Continuité d'Activités (PCA) soit
 efficace, alors la dimension métier doit en être le coeur.

 Historiquement, peu d'organisations s'intéressaient à la continuité
 d'activité. Aujourd'hui, la fonction de RPCA est une fonction stratégique.
 S'il doit toujours avoir la maîtrise métier et une bonne culture technique,
 le responsable de la continuité d'activité est maintenant avant tout un
 manager. Cette position de responsable implique une délégation minimale de
 responsabilité pour la définition, la mise en oeuvre et le contrôle des PCA.
 Il doit définir des politiques, s'intéresser aux différents référentiels de
 conformité, prendre les bonnes décisions en cas d'incident ou de sinistre,
 comprendre les problèmes techniques et prêcher la bonne parole auprès de la
 direction et du personnel.

 En somme, il doit faire le grand écart entre les orientations stratégiques
 et les décisions opérationnelles de tous les jours. Il doit comprendre et
 savoir parler à l'ensemble des acteurs de l'entreprise (management, experts
 techniques, métiers, utilisateurs, etc.) et pour se faire entendre, il doit
 communiquer sans relâche, au travers de tableaux de bord par exemple.

 La formation proposée par HSC a précisément été conçue dans le but d'apporter
 au RPCA tous les éléments dont il a besoin pour assurer ses fonctions.

 Elle s'adresse à toute personne amenée à exercer la fonction de Responsable
 du Plan de Continuité d'Activité.

 Première session à Paris du 21 au 25 mars 2016.

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



--[ 5. HSC by Deloitte exposant au FIC 2016 ]----------------------------

     Venez rencontrer HSC by Deloitte lors du FIC 2015 à Lille sur le stand
 Deloitte ! Pour les prestations, Adrien Pasquier mardi 25 et Jean-Jacques
 Cayet mercredi 26, et pour les formations Lynda Benchikh les deux jours,
 seront à votre disposition.

     Participation gratuite. Inscription en ligne obligatoire sur :
 https://www.forum-fic.com/site/FR/Visiter/Pre_enregistrement_gratuit,C58881,I58910.htm

    
      
--[ 6. Compte-rendu de la conférence Hackito Ergo Sum 2015 ]-------------
 Par Alexis d'Ussel et Jérôme Naucelle

 Keynote d'ouverture
 La conférence débute avec une Keynote animée par FX de Phénoelit et sa
 compagne qui traitent du bio-hacking. Ils commencent par rappeler les
 origines du "hacking", le fait que ce terme était utilisé avant l'arrivée
 d'Internet. FX compare les hackers aux sorciers médiévaux : si on
 compare avec la biologie, la saignée pratiquée à l'époque peut être rapprochée
 de nos antivirus et mises à jour actuels (parfois ça fonctionne alors on les
 applique). Ils enchaînent sur l'idée de construire une machine de Turing avec
 du matériel biologique. Ils détaillent l'existant et le compare à des notions
 informatiques : l'ADN serait une base de stockage de l'information. Une copie
 de l'ADN qui subirait des erreurs (comme une disquette) est une mutation.
 L'ARN de transfert remplit une fonction de traduction du message génétique
 (équivalent à ce que fait la libc, par exemple). Enfin, les ribosomes dont la
 fonction est de synthétiser des protéines à partir des informations reçues sont
 comparés à l'opération d'édition de liens lors de la création d'un exécutable.
 La plupart des pré-requis pour la construction d'une machine de Turing sont
 remplis (un médium en lecture/écriture, des états et des instructions) mais
 quelques difficultés subsistent comme la possibilité de faire des sauts en
 arrière lors d'une "exécution de code". Ils finissent sur une réflexion
 intéressante sur la responsabilité du monde des hackers sur la protection des
 connaissances qui émergent aujourd'hui avec ces recherches de bio-hacking. Le
 monde de l'électronique/informatique est maintenant plein de brevets détenus
 par de grandes sociétés, ce qui peut freiner les recherches à mener, il semble
 important que le monde du vivant ne suive pas ce modèle.


 Applying machine learning methods to network mapping hunting
 Camille Mougey et Xavier Martin ont présenté leurs travaux d'apprentissage 
 machine lié à la découverte réseau. Après avoir rappelé les bases de la 
 cartographie active et passive, les intervenants ont présenté les outils 
 disponibles pour le scan réseau de masse. scans.io, shodan et zoomeye sont 
 des exemples cités lors de cette intervention. Ils utilisent quant à eux IVRE 
 qui est open source et basé sur python et mongodb. Le parsing peut se faire 
 manuellement en invite de commande ou via une interface web. La problématique 
 devient alors de savoir comment grouper les machines et détecter des anomalies 
 automatiquement ?
 La complexité dans cet ouvrage est de transformer les scans nmap en matrices 
 pour alimenter les algorithmes déjà existants. En effet, les présentateurs n'ont pas 
 développé d'algorithme mais utilisé ceux qui existent déjà. Une démonstration 
 de l'interface web et des différents algorithmes a été proposée. Les 
 algorithmes abordés lors de la présentation sont les suivants: k-means,
 anomaly detection, dbscan, louvin.


 Cracking Sendmail crackaddr - Still a challenge for automated program analysis
 Bogdan Mihaila propose une présentation sur l'analyse statique de la
 vulnérabilité "Sendmail crackaddr" de 2003. Les outils d'analyse peuvent
 détecter si une version de Sendmail est vulnérable mais il est plus compliqué
 d'affirmer qu'une version donnée n'est plus vulnérable. Il présente dans un
 premier temps la base théorique de l'analyse de binaires et discute de la
 complexité des tests à mener pour couvrir l'étendue des chemins possibles. Les
 techniques d'extrapolation et de "narrowing" permettent de borner les tests.
 Une fois le cadre posé, Bogdan nous a présenté et comparé les résultats
 d'outils de découverte automatique de bogues disponibles sur le marché ainsi
 que les méthodes utilisées pour analyser: fuzzing, vérification de modèle,
 interprétation abstraite... Le critère d'efficacité des outils était
 principalement de voir s'ils arrivaient à détecter et affirmer que la
 vulnérabilité n'était plus présente sur une version corrigée.


 Complex malware & forensics investigation
 Paul Rascagnères & Sebastien Larinier sont venus présenter leur nouvel outil 
 "fastIR Collector" lors de la conférence. Les liens suivants sont alors rendus 
 actifs:
 http://www.sekoia.fr/blog/fastir-collector-on-advanced-threats/
 https://github.com/SekoiaLab/Fastir_Collector
 "fastIR" est la nouvelle version de l'outil déjà existant "fastresponder". 
 C'est un outil libre voué à pouvoir gérer toutes les versions de Windows
 dans le cadre d'investigations inforensique. Tous les artéfacts classiques
 de Windows sont gérés et survolés lors de la présentation.
 La 2ème partie montre comment ils s'en sont servi dans des conditions réelles, 
 le blog mentionné plus haut propose une description détaillée. Les cinq cas 
 suivants ont été présentés et sont à retrouver sur le blog:
   1)Uroburos/Turla/Snake
   2)comRAT
   3)Babar
   4)Casper
   5)HDroot


 Mind your languages!
 La présentation de l'ANSSI, animée par Olivier Levillain et Pierre Chifflier,
 venait d'un constat tiré d'une demande qui leur est régulièrement adressée :
 y a-t-il un langage plus adapté que les autres pour la sécurité ? Ils nous
 ont alors présenté avec beaucoup d'humour des exemples de comportements
 aberrants dans différents langages : javascript, PHP, Java mais également
 OCaml... Un tableau vide n'est pas égal à un tableau vide, des condensats de
 valeurs différentes qui semblent correctement comparés mais qui entrent tous
 en collision ou encore des entiers qui, au-delà d'une certaine valeur,
 deviennent différents. Les idées à en retenir : pour ceux qui créent des
 langages "assez de signes =. On a =, ==, ===, où s'arrêtera-t-on ?". Mais plus
 sérieusement, il n'y a pas un langage qui soit vraiment sans danger ou
 absurdité pour surprendre un programmeur. Il faut donc choisir le langage dans
 l'optique qu'il soit une aide selon le contexte.


 Malicious AVPs: Exploits to the LTE Core
 Laurent Ghigonis & Philippe Langlois sont venus présenter leurs avancements
 sur les attaques LTE. La présentation commence par un rappel des différents 
 éléments constituants d'un réseau LTE. On découvre rapidement qu'un attaquant 
 situé chez un opérateur tierce partie peut requêter le DRA, le HSS, le MME ou 
 encore le PCRF de l'opérateur cible via le réseau d'itinérance.
 L'attaquant peut exploiter les messages de signalisation sur le DRA (Diameter 
 Routing Agent). Après avoir rappelé le fonctionnement du protocole Diameter, 
 Laurent Ghigonis nous montre comment générer un crash et l'exploiter afin d'
 obtenir un remote shell over diameter. Selon eux tous les éditeurs sont 
 potentiellement vulnérables et beaucoup d'exploitations pourraient être
 protégées simplement en ajoutant des options de compilation lors de la
 création des binaires. Une exploitation réussie peut permettre à un attaquant
 de faire un DoS, des interceptions et redirections de toute la SIG diameter
 d'un opérateur !


 Android malware that won't make you fall asleep
 Une présentation faite par Lukasz Siewierski du CERT de Pologne dresse une
 sorte d'état des lieux des logiciels malfaisants sur Android. Il commence par
 faire quelques rappels sur Android, le fonctionnement du Manifeste et nous
 parle d'Android Malware Tracker qui est un outil de visualisation des liens
 entre logiciels malfaisants. Il nous présente ensuite quelques fonctions de
 logiciels malfaisants "originaux" qu'il a eu l'occasion d'étudier. L'un
 d'entre eux, une fois installé, expose une API en javascript. Il détecte si
 une application bancaire est en premier plan et y surimpose une fenêtre de
 demande d'identifiant. Ce logiciel malfaisant peut se connecter à un centre
 de commande pour récupérer les noms d'applications bancaires cibles ainsi que
 le descriptif de la fenêtre à afficher. Ces logiciels malfaisants peuvent
 également rendre muet le téléphone lors de la réception d'un SMS de la banque
 demandant confirmation d'un paiement. Il finit en parlant d'un logiciel
 malveillant développé par Hacking Team se faisant passer pour une application
 de nouvelles qui prend le contrôle total du téléphone et y installe un accès
 pour le contrôler à distance.


 Mechanical Locks Opening and Forensic Analysis
 Une présentation sur l'étude forensique des verrous physiques,
 animée par Alexandre Triffault d'Ouverture Fine. Après nous avoir présenté
 différents outils (bump key, micro-pique, pique manuel, clé "blanche"...) il
 propose à des volontaires de venir en tester quelques uns. Ce qui lui permet
 par la suite de montrer à l'aide d'un microscope les traces pour la plupart
 évidentes laissées sur les goupilles. Il nous rappelle que prêter sa clé
 revient à donner son mot de passe : il faudrait changer les serrures pour
 ne pas avoir de surprise. De la même manière, cacher ses clés, comme des mots
 de passe : on peut reproduire une clé par empreinte mais également depuis une
 image ou même de mémoire en découpant du simple plastique rigide. Il donne
 quelques contres-mesure et conclu en conseillant de faire effectuer une analyse
 forensic sur les serrures en cas de fuites d'informations avérées dans une
 entreprise, car tout ne passe pas forcément par les réseaux.


 Pentesting airports: field experiences
 Raoul Chiesa a proposé un retour d'expérience très animé sur la sécurité des 
 aéroports d'un point de vue réseau. Il constate que la sécurité n'est pas une 
 priorité dans ces environnements bien qu'ils soient en un sens fournisseurs
 de services comme certains opérateurs (utilisateurs, frontières, boutiques
 hors taxes, ...). En mode projet, il constate que le manque de budget se fait 
 sentir et que les périmètres d'action sont trop souvent mal définis, les choix 
 se portent souvent sur le moins cher au détriment de la sécurité. Raoul
 agrémente sa présentation de plusieurs exemples et anecdotes assez
 surprenantes comme le jour où il est tombé nez à nez avec une prise RJ45 aux
 toilettes dans un aéroport indien... Il prend enfin un exemple d'une
 prestation qu'il a réalisée en mettant en avant le nombre impressionnant de
 vulnérabilités critiques. La conclusion de cette intervention est qu'il ne
 devrait pas y avoir de limitation budgétaire lorsque la vie d'humains est
 mise en jeu.


 The hidden dangers inside the platform
 Les présentations sont clôturées par 2 ingénieurs d'Intel (Mickey Shkatov et
 Jesse Michael) qui nous parlent de risques inattendus, liés à notre matériel.
 Ils démontrent que le moindre matériel informatique vient avec un ou plusieurs
 processeur et zone mémoire. A partir de là, trouver une faille d'exécution dans
 ce matériel ouvre de nombreuses possibilités : discrétion, persistance,
 contournement des sécurités bas niveau, attaques par canaux cachés, élévation
 de privilèges, échappement de VM... ils finissent sur une démonstration
 impressionnante basée sur une faille qu'ils ont trouvée dans la puce 4G d'une
 tablette. Ils sont alors capables de maintenir une porte dérobée tout en faisant
 afficher à l'OS que les connexions réseau sont coupées. Ils nous montrent un
 redémarrage et une modification de paramètres du BIOS par leur contrôle à
 distance. La puissance de nos matériels augmente mais il semble que cela
 va de pair avec un accroissement de la surface et dangerosité des attaques
 possibles.



--[ 7. Appel à communication de la conférence du Club 27001 ]------------

     Le Club 27001 (http://www.club-27001.fr/), association à but non
 lucratif, organise à Paris le jeudi 7 avril 2016 sa neuvième conférence
 annuelle autour des usages des normes ISO 2700X. Cette conférence se
 déroulera à Paris  à l'espace Saint-Martin dans le cadre des
 GS-DAYS (http://www.gsdays.fr).

 La conférence annuelle du Club 27001 privilégie les retours d'expérience
 dans l'utilisation des normes de la série ISO 27000, qu'il s'agisse de la
 mise en oeuvre d'une des normes, leur usage y compris sans certification,
 les difficultés rencontrées et les intérêts perçus.

     Voici les thèmes sur lesquels nous attendons des propositions, sans
 que ceux-ci soient exhaustifs :

  - Mise en oeuvre d'un SMSI
     . Retour d'expérience
     . Migration des versions 2005 vers les versions 2013 des normes ISO27001
       et ISO27002
     . Reprise de l'existant
     . Comment engager sa direction générale
     . Comment surmonter la peur du SMSI
  - Gestion des risques liés à la sécurité de l'information
     . Retour d'expérience de mise en oeuvre de l'ISO 27005
     . Technique d'entretien et d'implication des métiers
     . Échelles et calcul du risque
     . Interactions avec les autres gestions des risques : opérationnels,
       industriels, CHSCT, financiers, etc.
     . Intérêts de l'ISO 27005 dans les projets, les systèmes embarqués, etc.
     . Usage d'ISO27005 vs usage d'EBIOS, de Mehari ou de RiskIT
  - Audits internes
     . Mise en place d'audits internes pour le SMSI
     . Mutualisation des audits internes ISO 27001 (avec ISO 9001, etc)
     . Utilisation de l'ISO 19011 et ISO 27006
  - Gestion des incidents liés à la sécurité
     . Retours d'expérience
     . Usage de l'ISO 27035
     . Liens avec d'autres référentiels (NIST SP800-61rev1, etc)
  - Indicateurs, métriques et tableaux de bord
     . Retours d'expérience
     . Usage de l'ISO 27004
     . Liens avec d'autres référentiels (TBSSI de l'ANSSI, NIST SP800-50, etc)
  - Liens entre ISO 27001 et d'autres normes, référentiels ou règlements :
     . Utilisations d'ISO 27001 dans le cadre ou concomitamment à d'autres
       référentiels de sécurité : OIV et arrêtés sectoriels, RGS, PCI-DSS,
       ISAE3402, Bâle II/Solvency II, HDS (Hébergeur de données de santé),
       ARJEL, WLA, etc.
     . Coordination entre la SSI (ISO 27001) et la continuité d'activité
       ISO 22301 (SMCA)
     . Systèmes de Management Intégrés (ISO 9001, 14001, 20000-1, etc) avec
       ISO 27001
     . Cohabitation ISO27001 et ISO 20000-1 / ITIL (services informatiques),
       ISO 27013
     . Mutualisation, opposition, complémentarité, déclencheur, etc.
     . CobiT (audit informatique, contrôle interne)
     . Applications sectorielles de l'ISO 27001 : télécommunications,
       santé (27011, 27799, etc)

     Les propositions doivent faire part d'un retour d'expérience pratique,
 et ne doivent pas être la présentation d'une offre de service, d'un
 produit ou plus généralement d'une solution commerciale. Le comité de
 programme sera sensible à l'aspect pratique des propositions. Cependant, les
 propositions présentant une analyse ou un comparatif fondé sur des tests
 scientifiques pourraient être acceptées.

 Les présentations feront de 35 à 45 minutes et seront en français ou en
 anglais.

 Contenu des soumissions à envoyer à conference at club-27001.fr :
    - Nom de l'auteur, biographie et affiliation
    - Synopsis d'une page maximum de l'intervention avec un plan de celle-ci
    - Format libre

 Calendrier 
    - 17 janvier 2016 : date limite de réception des soumissions
    - 14 février 2016 : notification aux auteurs et
                        publication du pré-programme
    - 28 février 2016 : publication du programme définitif
    - 24 mars 2016 : réception des présentations
    - 7 avril 2016 : conférence


 Le comité de programme est composé des membres de l'association élus au
 conseil d'administration, soit :
     - Bertrand Augé, Kleverware
     - Thomas Bousson, On'X-Edelweb
     - Claire Cossard, CNAM-TS
     - Francis Delbos, ID Nouvelles
     - Eric Doyen, Humanis
     - Emmanuel Garnier, Systalians
     - Loïc Guézo, Trendmicro
     - Thomas Lebouc, Ipanema
     - Florence Le Goff, Solucom
     - Carl Roller, Akamai
     - Hervé Schauer, HSC



--[ 8. Appel à communication des GS-DAYS 2016 ]--------------------------
      
     HSC sera présent comme chaque année aux GS-DAYS 2016 le 7 avril 2016,
 et Hervé Schauer est membre du comité de programme de la conférence.
 Nous vous invitons à consulter l'appel à communication sur :
https://www.globalsecuritymag.fr/GS-DAYS-Appel-a-communication-de,20150914,55600.html



--[ 9. Appel à communication de la JSSI de l'OSSIR 2016 ]------------------
      
     La Journée Sécurité des Systèmes d'Information 2016 de l'OSSIR se déroulera
 le mardi 8 mars 2016 au MAS à Paris sur le thème : "Retour vers le futur :
 bienvenue en 1984 ?"
 Les sujets suivants pourront entre autres être abordés :
  - Big brother : surveillance en bande organisée (entreprise, organisme, état)
  - Comment protéger ses traces dans le monde numérique ?
  - Comment garder son anonymat sur Internet ?
  - Comment garder le contrôle des objets communicants (montres, voitures,
    domotique, etc.) ?
  - Quelle confiance dans la sécurité des produits en 2016 ? Sécurité par
    l'obsolescence, sécurité par la transparence, sécurité par l'obscurité...
  - Quelle maîtrise pour les nouvelles architectures des SI : fin de
    l'intranet, le tout virtualisation, poste de travail léger.
  - Comment échanger des données de façon sûre entre 2 entités qui n'ont pas
    les mêmes moyens ? Quelle interopérabilité ?
  - Réponse à incident : intervention et post-intervention, quelle gestion
    des IOC ?
  - Logiciel malfaisant "Big Brother" : ciblage et espionnage persistant

 Si un sujet pertinent n'est pas présent dans cette liste, n'hésitez pas à
 soumettre votre proposition.
 Des propositions d'intervention portant sur ces différents aspects de la
 sécurité sont sollicitées pour la JSSI 2016. Les interventions pourront
 inclure la présentation d'une démarche, d'une technique ou d'une solution
 de sécurité répondant à une problématique d'entreprise ou d'organisme public
 et être illustrées d'une expérience pratique de mise en oeuvre. Toute
 présentation strictement commerciale sera refusée.

 La durée des interventions sera de 45 minutes (questions incluses). La
 journée de la sécurité des systèmes d'information s'articulera autour de
 conférences et de retours d'expériences dans le domaine de la sécurité des
 systèmes et des réseaux.
 Seront privilégiées les propositions techniques et juridiques, issues d'une
 expérience concrète et/ou provenant de technologies nouvelles ou innovantes.

 Les propositions de contribution sont attendues au plus tard pour le
 18 décembre 2015.

 Les propositions d'intervention, en français ou en anglais, précisant le
 sujet et le plan sur une page, doivent être accompagnées de quelques
 transparents et d'une brève biographie de l'auteur. Envoyez vos propositions
 dans l'un des formats : texte simple, PDF ou HTML, par e-mail à l'adresse :
 jssi16 at ossir.org



--[ 10. Offre d'emploi consultant en continuité d'activité ]-------------

     HSC by Deloitte recherche un consultant en continuité d'activité afin
 de développer l'offre et répondre aux demandes croissantes des clients
 sur l'ISO 22301.
 Les notions d'indépendance et de travail en équipe sont fondamentales chez
 HSC by Deloitte. Le candidat doit être passionné, aimer partager son
 expérience et être capable de faire progresser ses collègues sur son sujet
 de prédilection. Le consultant sélectionné pourra bénéficier de l'expérience
 d'HSC by Deloitte, considéré comme leader d'opinion sur l'ISO 27001 et la
 gestion des risques en sécurité.

 Avec le développement de l'offre « Continuité d'activité », le consultant
 participera à l'animation des formations RPCA, ISO 22301 Lead Implementer,
 ISO 22301 Lead Auditor, et gestion de crise IT/SSI.

 Dans le cadre de sa prise de fonction, il suivra les formations ci-dessus et
 d'autres comme ISO 27005 Risk manager et/ou des formations ISO27001.

     Le candidat devra justifier d'entre minimum 3 ans et maximum 6 ans
 d'expérience sur le sujet : BIA, stratégies de continuité, DRP, gestion
 de crise, plan de repli utilisateurs (PRU), exercices-tests, etc.
 Des connaissance en sécurité des systèmes d'informations et/ou sur les
 systèmes de management constituent un avantage, mais ne sont pas
 indispensables.

 Le poste est basé à Neuilly-sur-Seine (Paris), au pied du métro Pont de
 Neuilly (ligne n° 1). Si vous souhaitez proposer votre candidature, nous
 vous remercions d'envoyer votre CV en texte ASCII (pas de .doc ni .docx) par
 courrier électronique à cv at hsc.fr.



--[ 11. Offres d'emploi HSC pour consultants en sécurité ]--------------

     HSC by Deloitte recherche des consultants brillants, débutants ou
 expérimentés, avides de partager et de s'épanouir dans une équipe
 indépendante, pluridisciplinaire, qui couvre tous les aspects liés à la
 sécurité et la continuité, des tests d'intrusion à l'expertise judiciaire, de
 la rétro-ingénierie à la gouvernance, des systèmes industriels et embarqués
 à la gestion des risques, des technologies sans-fil à la résilience, de
 l'inforensique à l'ingénierie sociale, etc., pour des missions d'expertise
 variées et haut de gamme.

     Les ingénieurs sélectionnés pourront être formés à la sécurité par HSC
 (intrusion, inforensique, Windows, SCADA, ISO27001, ISO22301, ISO27005,
 EBIOS, etc.), soit 2 à 6 semaines de formations suivies dans le cadre de
 la prise de fonction.

     HSC by Deloitte recherche également des stagiaires pour des stages de
 pré-embauche.

     Tous les postes sont basés à Neuilly-sur-Seine (Paris), au pied du métro
 Pont de Neuilly (ligne n° 1). Si vous souhaitez proposer votre candidature,
 nous vous remercions d'envoyer votre CV en texte ASCII (pas de .doc ni .docx)
 par courrier électronique à cv at hsc.fr.



--[ 12. Agenda des interventions publiques ]--------------------------------

 - 12 janvier - OSSIR - Paris
   "Sécurité SCADA et OIV" par Christophe Renard
   http://www.ossir.org/

 - 14 janvier - Panorama du Clusif - Paris
   Interventions d'Amélie Paget et d'Hervé Schauer
   http://www.clusif.fr/


 Retrouvez l'agenda de nos interventions publiques sur
 http://www.hsc.fr/conferences/agenda.html.fr



--[ 13. Prochaines formations HSC ]----------------------------------------

     Nos prochaines formations sont les suivantes :

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

 (*) : 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
        ISO 27005 Risk Manager    ..............    : 1 au 3 juin 2016 (#)
        Formation CISSP    .....................    : 27 juin au 1er juillet (#)
        ISO 27001 Lead Implementer    ..........    : 17 au 21 octobre (#)
        ISO 22301 Lead Implementer    ..........    : nous consulter (#)

 - Bordeaux
        Correspondant Informatique et Libertés .    : 9 au 11 mars (@)

 - Nice
        Correspondant Informatique et Libertés .    : 23 au 25 mars (@)

 - Toulouse
        ISO 27005 Risk Manager    ..............    : 18 au 20 mai (#)
        ISO 27001 Lead Auditor    ..............    : 9 au 13 mai (#)
        Correspondant Informatique et Libertés .    : nous consulter

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

 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/



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

  o Club 27001 (http://www.club-27001.fr/)
     . Prochaine réunion à Paris jeudi 21 janvier à 14h00 chez Beijaflore
         - "Logiciel MP-DSI & RSSI" par José Belda (MAAT-PILOT)
         - Seconde présentation en cours de confirmation
     . Reprise des réunions à Lyon !!
       Réunion à Lyon lundi 16 novembre à 9h00 au CIRIL
         - "Groupe Lyonnais du Club 27001" par les animateurs Didier Savalle
	    (Fidens) et Rémi Grivel (CIRIL)
         - "Points faibles constatés lors des audits ISO 27001" par
	    Ali Dincmen (Bureau Veritas)
     . Prochaine réunion à Toulouse vendredi 12 février à 13h45 au CNES
         - "Présentation des normes" par Claire Albouy-Cossard (CNAM-TS)
         - "Comment aborder un audit ?" par Pierre Darphin (Cegedim Activ)
         - "Présentation de la norme IEC-62443 (ISA 99)" par Jean-François
	   Baillette (G.Echo)
     . 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.
     . Conférence annuelle le 7 avril 2016, réservez votre date !

 o OSSIR (http://www.ossir.org/)
     . Prochaine réunion à Paris le mardi 8 décembre à l'ENSAM
         - "FIDO et MuTrust, PKI ouvertes qui réconcilient cloud sécurisé
	   et carte à puce" par Frédéric Martin (Neowave)
         - "Pentest de Mainframe" par Ayoub Elaasal (Solucom)
         - Revue de vulnérabilités
     . Réunion suivante à Paris le mardi 12 janvier à l'ENSAM
       avec Assemblée Générale Annuelle le matin !
         - "Sécurité SCADA et OIV" par Christophe Renard (HSC by Deloitte)
	 - "Cybersécurité" par Daniel Ventre (CNRS)
         - Revue de vulnérabilités
     . Réunion suivante à Paris le mardi 9 février chez HSC by Deloitte
     . Prochaine réunion à Toulouse mardi 15 décembre à l'Université
         - "Revelium : analyse comportementale d'APT" par (Itrust)
         - Seconde présentation en cours de confirmation
     . Réunion suivante à Toulouse mardi 16 février
     . Prochaine réunion à Rennes le mercredi 10 décembre
         - "Le routage, talon d'Achille des réseaux" par Pascal Nourry (Orange)
         - "Windows 10 : nouveautés et implémentations d'un AD avec HyperV"
	   par Guillaume C. (Amossys)
     . Conférence annuelle JSSI le 8 mars 2016 au MAS

 o Clusif (http://www.clusif.fr/)
     . Prochaine conférence mardi 15 décembre à 16h00 à la CCI place de la
       Bourse : "Sécurité de l'Information et Sécurité Physique"
       https://www.clusif.asso.fr/fr/infos/event/
     . Panorama annuel 2015 de la cybercriminalité le 14 janvier à 15h00
       Réservez votre date !
       http://www.clusif.fr/

 o ISSA France
     . Diner annuel mardi 15 décembre
       http://securitytuesday.com/



--[ 15. Les 10 points de contrôle du développement web, le détail ]-------

     Vous trouverez ci-dessous le détail explicatif des 10 mesures de
 sécurité à contrôler de l'éditorial.

  1 - Utilisez-vous systématiquement des requêtes SQL préparées (connues aussi
  sous le nom de requêtes paramétrées) ?  

  Si vous ne le faites pas, vos applications sont probablement vulnérables à des
  injections SQL. L'injection SQL est, de façon consistante, la principale plaie
  affectant les applications web, et elle peut être quasi-éradiquée par un
  emploi systématique des requêtes préparées. Qui plus est, l'usage de ces
  dernières permet, en général, d'augmenter la lisibilité et les performances du
  code.


  2 - Utilisez-vous la gestion de session d'un cadriciel/bibliothèque fiable ?

  La gestion de session est une discipline délicate : d'apparence simple elle
  est la clé dans le contrôle d'accès. Une implémentation peu rodée est
  généralement vulnérable.


  3 - Encodez-vous systématiquement les valeurs venant de l'extérieur
  (utilisateur, base de données...) avant de les envoyer vers l'affichage ?  

  Si vous affichez sans échappement des valeurs contrôlées par l'utilisateur 
  votre application est probablement vulnérable à du "cross-site-scripting". Ces
  injections dans la page web, quoiqu'apparemment anodines sont la porte pour
  des attaques sérieuses: CSRF, manipulation de l'interface utilisateur,
  utilisation du navigateur comme plateforme de reconnaissance[11].


  4 - Utilisez-vous SSL/TLS sur la totalité de votre site ?

  L'utilisation de HTTPS assure non seulement la confidentialité des données en
  transit, mais aussi l'identité du serveur et l'intégrité des données
  transportées. En l'absence de ces contrôles, vos usagers sont vulnérables à
  des injections de code hostile, des modifications de contenu à la volée, et
  l'usurpation d'identité de votre application ... Ces attaques nécessitent
  généralement que l'attaquant se positionne entre l'utilisateur et le serveur
  web. Mais cette situation est commune, en particulier dans les environnements
  sans fils publics: cybercafés, hôtels, aéroports, gares ...


  5 - Stockez-vous et vérifiez-vous les mots de passe utilisateurs uniquement
  en les dérivant avec sha256crypt, bcrypt, scrypt, pbkdf2(sha256) ou argon2 ?

  Si vous stockez vos mots de passe en clair ou utilisez une autre fonction de
  dérivation de mot de passe vous faites l'hypothèse que jamais le contenu de
  votre base d'utilisateurs ne fuira. L'expérience en test d'intrusion d'HSC,
  comme les collections d'informations fuitant sur pastebin.com, montrent la
  faiblesse de ce postulat. Utilisez une de ces fonctions, et stockez un
  triplet: type de dérivation, sel unique par mot de passe, valeur dérivée.
  Mieux ne stockez pas de mots de passe : appuyez vous sur une authentification
  extérieure. 


  6 - Évitez-vous systématiquement d'utiliser les entrées utilisateurs pour des
  appels systèmes ?  

  Si vous utilisez des entrées utilisateurs: champs de formulaire ou informations
  du navigateur, pour un appel système, nommage de fichier ou de répertoire ou un
  appel de commande, votre application est probablement vulnérable à des
  injections de commandes. La solution la plus simple quand ce type de fonction
  est requis est de nommer les ressources à partir d'une valeur dérivée
  (condensat du nom de fichier, compteur), stocker la valeur utilisateur dans
  une base de données et ne restituer l'association des deux qu'à l'affichage.


  7 - Stockez-vous les téléchargements utilisateurs vers l'application
  (uploads) dans un environnement restreint ?

  Un attaquant utilisera les fonctions de téléchargement vers vos serveurs pour
  déposer des contenus offensifs. Il est souvent possible par ces fonctions
  d'écraser des fichiers côté serveur (directement ou indirectement), de faire
  du contrôle à distance (webshell), ou préparer des attaques vers les usagers.
  Stocker les contenus dans un environnement "neutralisé"[12], avec des noms
  contrôlés par l'application, hors de l'arborescence web, rend de telles
  attaques quasi-impossibles au prix de peu d'efforts.


  8 - Séparez-vous les paramètres secrets du code ?  

  Le code source d'une application n'est que très rarement un secret fort. Il
  circule entre les environnements de développement, de test, de production et
  on le trouve souvent dans des archives de sauvegardes. Si votre code contient
  des secrets (mots de passe, clés cryptographiques), ceux-ci ont de fortes
  chances d'être exposés. La gestion des identifiants devrait être laissée aux
  équipes assurant l'administration et ceux-ci stockés hors de gestion de
  source.


  9 - Faite-vous un suivi de version de tout votre code ?  

  Que ce soit dans la gestion des vulnérabilités ou des corrections
  fonctionnelles, connaitre et garantir les versions dans les différents
  environnements est vital. Ne pas le faire expose aux régressions de sécurité,
  aux pertes de corrections, et rend impossible un développement structuré sans
  lequel la sécurité ne sait être garantie dans la durée.


  10 - Gérez-vous vos dépendances et leur sécurité ?  
   
  Les failles ne sont pas exclusives de votre code, celui des tiers en est une
  source pernicieuse. Si les dépendances de votre application ne sont pas
  connues, ne font pas l'objet d'une veille de sécurité, le code le plus
  sécurisé reposera sur un socle de sable.

 --

 [11] voir "The Browser Exploitation Framework" - BEEF <http://beefproject.com/> 
      pour un bon exemple de ce qu'il est possible de faire depuis une injection 
      de javascript.
 [12] un environnement neutralisé devra assurer que les fichiers soient: non 
      exécutables, servis par le serveur web avec des types MIME non exécutables 
      (du type: text/plain ou image/XXX), cloisonnés dans une sous arborescence
      spécifique.


--[ 16. Le saviez-vous ? La réponse ]-------------------------------------
 
      SOLUTION: 
  Il est possible pour un utilisateur disposant de droits restreints de
 s'authentifier en tant qu'administrateur en accédant au script
 d'authentification avec la requête :
     login.cgi?login=admin&password=pass&password=login&password=user
 
      EXPLICATION :
 L'exploitation de cette vulnérabilité repose sur l'abus de trois comportements
 de Perl peu connus et déroutants :
 
   1. Lorsque plusieurs arguments identiques sont récupérés par la fonction
 param() de CGI, un tableau de valeurs est retourné.
 
 Par exemple, le code suivant :
     my $q = CGI->new(); say for
     $q->param("password");
 
 utilisé avec l'URL
 "param.cgi?param.cgi?password=pass&password=other_param&password=other_param2",
 affiche :
     pass other_param other_param2
 
 Toutes les valeurs des paramètres "password" ont été récupérées par la
 fonction param() et ont été insérées dans un tableau. C'est, à ce jour, le
 comportement par défaut de Perl si une valeur unique n'est pas demandée
 explicitement.
 
   2. Les valeurs retournées par les subroutines en Perl sont toujours des
 listes et sont traitées dans le contexte d'une liste si aucun autre contexte
 n'est spécifié. Ainsi, l'instruction "$q->param("password");" retourne donc une
 liste de valeurs dans le contexte d'une liste.
 
   3. Perl considère une liste dans un hash comme étant une extension de ce
 hash ; les valeurs de la liste sont ajoutées aux combinaisons clé-valeur du hash
 dans laquelle elle est insérée.
 
 Ainsi, le code suivant :
     my @array = ("pass", "added_key", "added_value");
     my %hash = (login    => "user",
                 password => @array);
     print "$_ $hash{$_}\n" for keys %hash;
 
 Affiche :
     added_key added_value password pass login user
 
 Nous pouvons remarquer que la combinaison clé:valeur "added_key:added_value" a
 bien été insérée dans le hash. Ce comportement spécifique de Perl s'explique
 par 2 raisons :
 
 Premièrement, nous sommes ici dans le contexte d'une liste, type qui ne peut
 être multidimensionnel. C'est pourquoi la liste
 ("login" => "user", "password" => ("pass", "added_key", "added_value"))
 est pour Perl équivalente à
 ("login" => "user", "password" => "pass", "added_key", "added_value").
 
 Deuxièmement, l'opérateur "=>" n'est rien d'autre, en Perl, qu'une "virgule"
 (il est d'ailleurs vulgairement nommé "grosse virgule"). C'est la raison pour
 laquelle la liste
 ("login" => "user", "password" => "pass", "added_key", "added_value")
 sera traitée comme
 ("login", "user", "password", "pass", "added_key", "added_value").
 
 Il est à noter que si la combinaison clé-valeur insérée avait été
 "login:other_login", alors la valeur associée à la clé "login" aurait été
 écrasée par la nouvelle valeur. Ce comportement nous permet donc, en
 définitive, d'altérer un hash.
 
   En combinant les 3 comportements de Perl, nous avons donc à notre disposition
 la possibilité d'altérer un hash au travers de CGI. Grâce à la vulnérabilité
 my %hash=("login"=>$login,"password"=>$q->param("password")); (ligne 12)
 exploitée avec la requête
 login.cgi?login=admin&password=pass&password=login&password=user
 nous pouvons ainsi nous authentifier sous le login "admin" alors que les
 identifiants de l'utilisateur restreint "user:pass" sont utilisés lors de la
 vérification.
  
      CONCLUSION :
 Cette vulnérabilité est critique car le code responsable est ordinaire pour un
 développeur non sensibilisé, et son exploitation est triviale. Elle existe par
 ailleurs depuis plus de 15 ans, mais n'a été démontrée qu'en 2014. Il est à
 noter que cette vulnérabilité était présente dans de nombreux logiciels
 populaires, dont Bugzilla, comme en atteste la CVE-2014-1572.
 
 Afin de s'en prémunir, il est important de garder en tête que la méthode
 param() retourne par défaut une liste, qui sera traitée comme telle en
 l'absence d'un contexte explicite. D'un point de vue général, il faut toujours
 impérativement préciser le contexte désiré pour les éléments retournés par une
 fonction, soit en passant par une variable temporaire
 ex: "$parameter = $query->param("parameter");"
 soit en réalisant un transtypage
 ex: my %hash = ("login" => $login, "password"  => scalar $q->param("password"));




Plus d'informations sur la liste de diffusion newsletter