Compte rendu de la conférence SSTIC 2014 (Seconde partie)

Date : 07 Juillet 2014

En juin, le Cert-IST a assisté à la conférence SSTIC-2014, qui s’est déroulée à Rennes.

Le mois dernier, nous avons publié la première partie de notre compte-rendu de cet événement. Nous publions maintenant la fin de ce compte-rendu, en poursuivant notre description des présentations qui s’y sont déroulées.

 

[Reverse] Bootkit revisited (par Sogeti)

Les versions x64 de Windows empêchent l’ajout de drivers non signés ce qui rend difficile les rootkits de niveau kernel sur Windows x64. Pour contourner cette protection, depuis 2010, certains malwares (par exemple la famille TDL) utilisent la technique de Bootkit : le malware prend la main dès le boot (en infectant le MBR) puis surveille la phase de boot Windows. Lorsque Windows démarre, le malware insère alors un rootkit dans la liste des drivers natifs de l’OS (sans vérification de signature). Ce mécanisme utilisait jusqu’à présent la surveillance des accès disques pour repérer l’évolution du boot et le lancement de Windows. L’orateur propose une nouvelle méthode, qui ne dépend plus d’un pattern disque : il surveille les changements de l’état du processeur (passage en mode réel, puis en mode protégé et enfin en mode « long ») pour détecter l’évolution du boot et le lancement de Windows.

 

[Cloud] Tests d’intégrité d’hyperviseurs de machines virtuelles à distance et assisté par le matériel (par le CNRS/LAAS Toulouse)

La présentation s’intéresse à la sécurité des environnements virtualisés, et en particulier ceux utilisés dans les offres Cloud. L’orateur propose d’ajouter sur les serveurs, une carte PCI qui a pour rôle de surveiller la mémoire centrale du serveur (via des accès DMA) afin de détecter les tentatives de corruption de l’hyperviseur. Pour ce faire, la solution localise et surveille dans la RAM les tables EPT.

Cette présentation reprend donc les principes de la carte PCI IronHide (présentée à SSTIC 2012 – voir notre compte-rendu), et l’applique à la protection des environnements virtualisés. Il est intéressant de constater que ce sujet qui semblait encore très académique il y a 2 ans, semble désormais répondre à des préoccupations très actuelles. Il faut dire qu’avec les révélations Snowden, il parait nécessaire de renforcer le niveau de défense : adopter une protection hardware (avec une carte qui supervise l’intégrité du système) semble donc adapté à cette nouvelle demande.

 

[Intro] La sécurité des systèmes mainframes (par Volvo IT)

Il s’agit d’une présentation générale sur les systèmes Z/OS d’IBM et sur les mécanismes de sécurité disponibles dans ces environnements. La présentation est destinée plutôt aux personnes qui ne connaissent pas cet environnement. La lecture de l’article qui accompagne la présentation est alors recommandée !

 

[Network] Reconnaissance réseau à grande échelle : port scan is not dead (par QuarksLab)

Il s’agit d’une présentation similaire à celle faite par le même intervenant à l’INSA de Toulouse en janvier 2014 (cf. notre compte-rendu). Cette fois la présentation rentre plus dans le détail de l’architecture de l’outil (un scheduler distribue les tâches à des agents) et ses composants python (« libleeloo » pour distribuer les adresses IP et « Nodescan » pour scanner une cible).

 

[Intro] Cryptocoding (par Jean-Philippe Aumasson)

Le présentateur est un expert en cryptographie. Il explique que le développement de code cryptographique est vraiment complexe parce qu’il demande des compétences multiples : en développement,en  sécurité et en cryptographie. Il participe au projet cryptocoding.net qui tente d’établir les bonnes pratiques à suivre dans ce domaine. L’orateur revient aussi sur Heartbleed et OpenSSL : il montre la complexité d’OpenSSL (qui supporte trop de suites cryptographique et trop d’OS) et la difficulté à lire son code (ce qui le rend difficilement auditable).Il passe en revue les alternatives (dont NSS de Mozilla, GnuTLS ou LibreSSL) sans trouver de solution satisfaisante.

 

[SmartCard] Buy it, use it, break it ... fix it : Caml Crush, un proxy PKCS#11 filtrant (par l’ANSSI)

PKCS#11 est une API qui définit les échanges avec des équipements cryptographiques tels que les HSM (Hardware Security Module) et les cartes à puce cryptographiques. Il y a peu d’outils publics pour PKCS#11. En 2011, Graham Steel avait présenté à SSTIC l’outil Tookan pour détecter les anomalies des équipements implémentant PKCS#11 (cf. notre compte-rendu). Cette année l’ANSSI présente un outil (développé en CAML) qui bloque les tentatives d’attaques (par exemple l’attaque par confusion « Wrap/Decypt »). Il s’agit d’un proxy PKCS#11 qui voit passer toutes les requêtes PKCS#11 et les analyse avant de les transmettre à l’équipement PKCS#11.

 

[Intro] Martine monte un CERT (Airbus)

L’orateur présente un retour d’expérience sur les activités du CERT d’Airbus. Il s’intéresse plus particulièrement aux cas des attaques APT. Il montre que :

  • Les attaques ne sont pas forcement évoluées,
  • Elles sont souvent découvertes par des organismes externes à l’entreprise (signalées par un autre CERT),
  • Le forensic classique (copie intégrale de disque dur) devient vite impossible quand l’attaque touche un grand nombre de postes.

 

[Reverse] Élaboration d’une représentation intermédiaire pour l’exécution concolique et le marquage de données sous Windows (par DGSIC)

L’orateur présente comment il a procédé pour porter sur Windows l’outil de fuzzing Fuzzgrind (présenté en 2009 à SSTIC, cf. notre compte-rendu). La plupart des composants nécessaires existent sur Windows (solveur de contraintes Z3, PIN pour instrumenter le code). Il reste par contre à créer un langage intermédiaire pour permettre une exécution concolique (le mot « concolique » est la fusion des mots « concrete » et « symbolique » et désigne une exécution symbolique dynamique d’un code). La présentation se concentre sur cet aspect.

 

[Reverse] Obfuscation de code Python : amélioration des techniques existantes (par QuarksLab)

Une présentation très compliquée mais qui porte bien son nom : elle explique comment rendre illisible (« obfusquer ») le code python de façon à rendre difficile son reverse-engineering.

 

[Reverse] Désobfuscation de DRM par attaques auxiliaires (par QuarksLab)

Très compliqué encore, et qui tente de résoudre un problème inverse de celui abordé dans la présentation précédente : comment analyser un code fortement obfusqué. Plutôt que la méthode traditionnelle d’analyse (qui est de lancer IDA pour analyser le code statiquement), l’approche adoptée ici est de lancer le code et d’enregistrer (dans une immense base MongoDB) toutes les instructions exécutées. Ensuite, on cherche dans ces traces des patterns significatifs. En particulier on peut reconnaitre les algorithmes cryptographiques en cherchant certaines constantes (par exemple les constantes d’initialisation de SHA-1). Un outil, baptisé PTra (Python Trace Analyser), a été développé dans ce cadre.

 

[Intro] Exemple de renforcement de la sécurité d'un OIV (par EDF)

L’orateur présente l’organisation de la sécurité informatique au sein d’EDF pour les centrales nucléaires. Il montre par exemple les atouts liés à la culture « informatique industrielle critique » de cette structure, comme par exemple la culture du formalisme (rédaction et application de procédures) ou la culture du retour d’expérience (analyse des incidents et cycle d’amélioration).

 

[Cloud] Sécurité de la gestion dynamique des ressources dans le Cloud (par Orange)

Cette présentation s’intéresse à une attaque spécifique aux environnements Cloud : perturber le service en générant des migrations de VM. Si un attaquant dispose d’une VM sur le service Cloud, il peut en effet tenter de gêner ses colocataires en augmentant son activité. Au-delà d’un certain seuil, le système de supervision va en effet décider de migrer une des VM pour libérer de la ressource et cette opération impacte la performance des serveurs. L’oratrice présente les résultats obtenus avec l’environnement VMware :

  • le composant DRS (Distributed Resource Scheduler) de WMware qui gère l’allocation de ressource a un fonctionnement complexe qu’il est difficile de prédire sans expérimentation,
  • un outil pour détecter ce type d’attaque, baptisé AMAD (Abusive Migration Attack Detection), a été réalisé dans ce cadre.

 

[Reverse] RpcView : un outil d'exploration et de décompilation des MS RPC (par la DGA)

RpcView est un outil qui permet de visualiser l’ensemble des services RPC disponibles sur un poste Windows. Il se veut l’équivalent, pour les services RPC, de l’outil « ProcessExplorer » de SysInternals qui traite lui des processus. RpcView ne se base pas sur le « Endpoint-mapper » (composant Microsoft qui liste les services RPC officiellement disponibles) et liste donc aussi les services RPC « privés » utilisés par les programmes (qu’ils soient Microsoft ou autres : Symantec, Sophos, Citrix ….). Une fois un service RPC identifié, RpcView décompile le code du service (ou au moins le stub chargé de la sérialisation des données) afin de comprendre son interface RPC.

 

[Network] Haka : un langage orienté réseaux et sécurité (par Arkoon)

Haka est un moteur d’inspection de trafic réseaux capable de traiter un fichier « pcap » (analyse d’un trafic capturé) ou de s’insérer dans le firewall NetFilter de Linux. Haka est piloté par une politique de sécurité écrite dans le langage LUA (aussi utilisé par Whireshark et Suricata pour écrire des dissectors) qui décrit le trafic qui doit être détecté et les actions à entreprendre.

Dans le futur, Haka pourrait être intégré aux produits Arkoon.

 

Conclusion

La conférence SSTIC est probablement la meilleure conférence francophone pour les passionnés de sécurité informatique. Les sujets présentés sont souvent de haute qualité technique avec une forte volonté de partager le savoir présenté. Et certains articles publiés dans les actes de la conférence (par exemple ceux de l’ANSSI) sont d’une qualité remarquable et méritent vraiment d’être lus. Si certains des sujets présentés dans ce compte-rendu vous ont intéressés, nous vous recommandons donc vivement de visiter le site web du SSTIC pour les approfondir.

Précedent Précedent Suivant Suivant Imprimer Imprimer