
Du mercredi 1er au vendredi 3 Juin 2016 s’est
tenu le Symposium sur la Sécurité des Technologies de l’Information et de la
Communication (SSTIC), qui a rassemblé plus de 450 participants pour sa 14e
édition.
Trois jours de conférences techniques se sont enchaînés, alternés d’un cocktail et du traditionnel
« Social Event » en centre-ville de Rennes. Pas moins de 35
conférences ont été présentées par 59 orateurs, et 35 rumps (présentations très
courtes de 3 minutes maximum) ont permis de détendre l’atmosphère jeudi
après-midi. Le programme complet est disponible sur le site du SSTIC https://www.sstic.org/2016/programme/.
Voici le compte-rendu de la première journée.
Voici le compte-rendu de la première journée.
Conférence d’ouverture
La conférence d’ouverture a été présentée par Brad Spengler, auteur du projet
grsecurity. Pour rappel, grsecurity est un projet de durcissement du noyau
Linux visant à améliorer sa sécurité et à le protéger d’un large éventail
d’attaques. Brad a commencé par détailler les nombreuses améliorations qui ont
récemment été apportées à grsecurity (support ARM, protection contre des exploits récents, blocage des
périphériques USB qui n’étaient pas branchés au boot – désactivable à la
demande), y compris dans PaX, le patch en charge de la gestion de la mémoire
(le but étant d’empêcher les corruptions de mémoire, qui peuvent conduire à de
l’exécution de code).
Ensuite, l’auteur a donné son point de vue sur l’écosystème
de la sécurité de l’information dans son état actuel : les acteurs de la
sécurité manquent de recul et de regard critique, et succombent parfois au
sensationnalisme (ce qui n’est pas sans rappeler le kickstarter proposant un
routeur Tor pour protéger ses communications qui avait rencontré un vif
succès avant que plusieurs
failles de sécurité ne soient révélées). Il y a selon lui trop de
conférences, décevantes au niveau de la qualité des articles et des
présentations, qui ne sont par ailleurs pas forcément le meilleur moyen
d’effectuer des transferts de connaissance. Il y a également trop « d’experts »
qui se plaignent de l’état de la sécurité sans rien créer ou publier.
"Security will never be achieved through bug reduction" #SSTIC— newsoft (@newsoft) 1 juin 2016
Enfin, d’après Brad : “il y a de plus en plus de bugs,
mais la sécurité s’améliore”. Les attaques à l’état de l’art deviennent plus
difficiles à réaliser, tandis que beaucoup de menaces plus
« anciennes » continuent de peser sur les utilisateurs, comme les
macros Office.
La conclusion de cette conférence d’ouverture, qui
fait écho à la conférence de clôture est la suivante : « Security will never be achieved through bug
reduction ». La sécurité doit être prise en compte dès la phase de
conception, au lieu de consister à réparer les différentes failles au fur et à
mesure de leur découverte.
La journée s’est poursuivie avec plusieurs
conférences :
Démarche d'analyse collaborative de codes malveillants
A. Chevalier, S. Le Berre, et T. Pourcelot (ANSSI /
SOGETI) ont présenté un outil d’analyse collaborative de logiciels malveillants
nommé Polichombr, publié sur le Github de l’ANSSI.
Dans leurs travaux d’analyse et de rétro-ingénierie des logiciels malveillants,
les auteurs ont été confrontés à la difficulté de traiter un grand volume de
code de manière collaborative et ont décidé de créer Polichombr pour les
assister. Cet outil permet notamment :
- Une centralisation des informations et du stockage des fichiers ;
- L’automatisation de tâches d’analyse (calcul des empreintes, découvertes des zones intéressantes dans le binaire…) ;
- La classification automatique des logiciels malveillants à l’aide de l’algorithme maison « MACHOC », qui utilise des patterns dans le « graphe de flot de contrôle » (Control Flow Graph en anglais) invariants lors d’une recompilation ;
- La synchronisation avec IDA pour récupérer le travail d’autres analystes (plugin Skelenox) ;
- L’export de règles de détection Snort et d’IOC (Indicators of Compromission) OpenIOC.
Gunpack
Julien Lenoir (Airbus) a présenté un outil développé
en interne permettant de développer facilement des scripts d’unpacking en
Python, pour des binaires Windows 32 bits. Les techniques de
« packing » consistent à compresser, voire chiffrer tout ou une
partie d’un binaire original. Dans le cas d’un logiciel malveillant, la charge
utile est donc dissimulée et peut échapper aux contrôles des antivirus.
Gunpack, qui s’est inspiré du moteur d’unpacking MutantX-S, effectue une
reconstitution dynamique du payload à l’exécution en instrumentant l’OS pour
suivre l’exécution du packer, et en tirer les informations utiles à l’écriture
d’un unpacker.
Cryptanalyse en boite noire de chiffrement propriétaire :
étude de cas
Pierre Capillon (ANSSI), a présenté de manière
didactique une analyse récemment effectuée sur un boîtier utilisant un
algorithme de cryptographie propriétaire. L’accès physique au boîtier étant
interdit, seules les attaques logiques ont pu être réalisées. Pendant 6
semaines, l’auteur a étudié les mises à jour du fimware disponibles
publiquement pour comprendre le format de fichier utilisé, l’architecture de la
puce, et a fini par trouver des vulnérabilités dans le firmware. De nombreuses
techniques d’analyse, fructueuses ou non, ont été présentées, parmi lesquelles
le calcul d’entropie du fichier à l’aide de binwalk (permet de savoir s’il
s’agit d’un payload chiffré notamment), l’observation des modifications au
niveau binaire entre des versions différentes du firmware, le fingerprinting de données binaires
(formats de fichiers connus par exemple) et de structures habituelles de code…
On retiendra notamment la capacité de l’auteur à identifier l’empreinte SHA256
de la chaîne vide dans un blob binaire, ou l’utilisation par le constructeur de
l’algorithme ROT13 pour obfusquer des en-têtes ASCII. En conclusion, l’auteur
souligne que la cryptographie propriétaire peut s’attaquer beaucoup plus
facilement qu’on ne le croit.
Eurisko : développement d’une carte électronique sécurisée
7 agents de l’ANSSI sont ensuite venus présenter le
projet Eurisko, prototype d’une carte électronique mettant en œuvre une chaîne
de démarrage sécurisé intégrant un mécanisme d’authentification pré-boot.
Eurisko a des objectifs fonctionnels et de sécurité et embarque notamment deux
interfaces Gigabit ethernet sur une carte de 7x7cm à faible dissipation
thermique (pas de ventilation), sur une base Linux grsecurity et une
« base de code maîtrisée ». La chaîne de démarrage ne repose pas sur
la sécurité de la BootROM (interne au System
on Chip – abrégé SoC – puce centrale d’un circuit imprimé) mais sur un
composant sécurisé dédié, certifié EAL 5+, contenant une mémoire flash protégée
en confidentialité et en intégrité, ainsi que de sa propre source d’entropie et
de fonctions d’accélération cryptographie matérielles. Notamment, l’intégrité
et la sécurité des communications au sein même du circuit imprimé (notamment
avec le SoC) sont vérifiées, pour qu’enfin le système d’exploitation soit
déchiffré et exécuté depuis une carte microSD. La partie logicielle a également
été durcie en respectant la norme C99, en interdisant l’allocation dynamique
(prévention de la corruption de mémoire) et en gardant le code linéaire et
synchrone (prévention des race conditions).
Évolution et dé-évolution des systèmes multimédia embarqués
F. Pollet (Thales) et N. Massaviol (Toucan System) ont
présenté une étude anonymisée de la sécurité des systèmes embarqués dans les
véhicules, basée sur leurs expériences avec des grands constructeurs français.
Ils ont notamment pu constater les différences d’architecture des systèmes
multimédias. Les résultats sont sans appel : backdoors présentes dans
certains composants (souvent à l’insu du constructeur) livrés par des
prestataires, interfaces de développement non désactivées, ou mires de login
facilement accessible, les points d’entrée sont nombreux et relativement
facilement accessibles. Il leur a ainsi été possible de récupérer le contenu du
fichier /etc/passwd (ou /etc/shadow) pour « rooter » le véhicule, ou
d’exploiter l’absence de signature des mises à jour pour flasher un firmware
arbitraire. Les systèmes d’exploitation utilisés dans les exemples étudiés étaient
soit Android 2.2 ou 4.0 – pour lesquels plusieurs vulnérabilités sont connues –
soit Linux, utilisant parfois un compte root sans mot de passe.
L’exploitation de ces vulnérabilités permet le détournement
des fonctionnalités légitimes (diffuser du son à fort volume ou désagréable
pour déstabiliser le conducteur), l’accès à internet, et potentiellement le
contrôle des composants connectés au bus CAN. Enfin, les évolutions à venir
dans le domaine de l’automobile comme le contrôle à distance pour le
covoiturage (ouverture par smartphone), le platooning
(véhicules qui se suivent de manière automatique pour former des convois) ou
l’apparition de véhicules complètement autonomes, vont présenter des risques
encore plus importants et nécessitent une maîtrise des risques bien plus
rigoureuse de la part des constructeurs.
USB Toolkit : USBIQUITOUS
Benoît Camredon (Airbus Group) a présenté une série
d’outils open-source d’analyse USB, permettant d’interagir avec les composants
connectés ou directement avec l’hôte. Parmi les nombreuses possibilités
offertes, nous pouvons noter la présence d’un proxy USB intégrant un dissecteur
de paquets, d’un « pare-feu USB » en mesure de bloquer les clés USB, d’un
keylogger, d’un fuzzer, mais aussi d’un scanner permettant de connaître les
drivers USB disponibles sur l’hôte. Un mode « keyboard » permet aussi
de réaliser des attaques similaires au Rubber Ducky en émulant un
clavier, et un mode « replay » permet de rejouer des trames USB,
qu’il s’agisse d’un lance-missile USB ou d’une impression vers une imprimante.
Confusion de type en C++
Florian Saudel, d’AMOSSYS, a expliqué la problématique
des confusions de type en C++, où des hypothèses non vérifiées sur le type des
objets passés à une fonction permettent d’exécuter du code arbitraire. Ces
attaques reposent sur une mauvaise utilisation du polymorphisme et la présence
de « bad cast ».
Composants logiciels vérifiés en F* : Poly1305
Jean-Karim Zinzindohoué (INRIA, équipe Prosecco) a
présenté un langage de programmation fonctionnelle moderne dédié à la
vérification formelle : F*, ainsi que son utilisation dans l’implémentation
d’une primitive de code d’authentification de messages (Message Authentication
Codes, mieux connus sous l’abréviation MAC) : Poly1305. Pour rappel, la
vérification formelle permet d’assurer par des preuves mathématiques certaines
propriétés d’un programme, comme le fait qu’il ne peut pas crasher, ou la
confidentialité des données. Ces travaux font notamment suite à la publication
d’une implémentation formellement vérifiée de TLS : miTLS, également développée
par l’équipe Prosecco de l’INRIA.
My friends
botnet: How to use your friends to perform Cyber Int?
Amaury Leroy (CERT Airbus Group) a présenté son projet
de crawler dont le but est de récupérer des données diverses dans le cadre
d’une veille : détection de mots-clés ou de changements significatifs dans
l’infrastructure réseau (Whois, SSL, DNS par exemple). Le passage à l’échelle sur les solutions cloud
classiques comme Amazon EC2 est problématique car effectuer des millions de
requêtes DNS ou de recherches Google par jour provoque un blocage rapide du
crawler. L’auteur a donc réalisé un botnet en utilisant des Raspberry Pi et en
les déployant chez des amis pour récupérer les informations nécessaires. Sa
solution utilise notamment du SSH avec port
knocking, le framework Rebus pour la communication, et Selenium / PhantomJS
pour le scrapping d’informations.
Broken Synapse
Ivan Kwiatkowski a présenté une attaque contre le jeu
de stratégie Broken Synapse, lui permettant de lever le brouillard de guerre et
de gagner un avantage significatif dans ses parties en ligne. Il a pour cela
d’abord intercepté les données HTTP échangées avec le serveur, sans réussir à
interpréter les données retournées par le serveur. Il a ensuite choisi de
reverser le code du jeu pour désactiver le brouillard de guerre quel que soit
le mode de jeu, ce qui peut permettre à un attaquant de gagner facilement des
parties et de monter au classement sur Steam de manière déloyale.
Un FizzBuzz pour le cyber
Éric Jaeger et Olivier Levillain ont présenté un
questionnaire élaboré pour la sélection des candidats à la formation
« Experts en SSI » du centre de formation de l’ANSSI, autour de la
question : « comment évaluer efficacement un candidat lors d’un
entretien ? ». FizzBuzz est un jeu (il faut compter jusqu’à 100 et
dire « Fizz » pour les multiples de 3, « Buzz » pour les
multiples de 5, et « FizzBuzz » pour les multiples de 3 et de 5) qui
est également utilisé comme exercice lors du recrutement de développeurs, de
manière apparemment efficace. Plusieurs autres exemples de tests en apparence
simple mais révélateurs d’un état d’esprit ont été présentés.
La journée s’est terminée par un cocktail et a permis
aux participants de se rencontrer et de discuter des sujets de la journée (et
de la crue de la Seine).
Aucun commentaire:
Enregistrer un commentaire