#SSTIC 2014 - Deuxième jour, on continue
Cette deuxième journée au #SSTIC était un poil moins dense que la première si on compte le nombre de conférences, mais la journée s'est terminée par 27 rumps, ce qui, en soit, est déjà assez intense !
Escalade de privilège dans une carte à puce Java Card par Guillaume Bouffard & Jean-Louis Lanet
La première présentation concernait les Java Card et était donnée par des chercheurs de Limoges1.
À peu près toutes les cartes à puces qui sont en circulation sont des Java Card, ce qui représente plus de 12 milliards de périphériques. Une Java Card, c'est donc une carte à puce qui embarque une JVM Java allégée et qui peut donc exécuter des applications Java.
2 étapes de sécurité différentes sont implémentées dans le modèle de sécurité Java Card :
- Le PC qui compile vérifie que le bytecode Java qui sera exécuté est correct et il signe l'applet;
- et un mécanisme de vérification des signatures et de sandboxing, ainsi qu'un pare-feu entre les applications sont également présent sur la carte elle-même.
Et c'est à peu près tout ce qu'il y a. Comme la carte est très légère (processeur 8bits, 32ko de ROM, 32ko d'EEPROM et 2ko de RAM) on ne peut pas implémenter beaucoup plus de choses. Par exemple, aucune implémentation connue de la JVM ne vérifie et empêche les débordements de tampons.
Du coup, plusieurs attaques sont encore possibles :
- Exécution de code natif à des adresses arbitraires ;
- Écriture de code à un index arbitraire dans la ROM ;
- Exécution de code et accès à un compte root sur l'OS de la carte ;
- Lecture de la ROM de la carte ;
- Appel de code natif.
Par contre des cartes à puce, même de développement, ça coûte un peu cher...
La recherche en France: "on a un class break dans toutes les cartes en circulation, mais on a pas l'argent pour s'acheter 2 cartes" #sstic
— newsoft (@newsoft) 5 Juin 2014Recherche de vulnérabilités dans les piles USB : approches et outils par Fernand Lone Sang & Jordan Bouyat
Comme les cartes à puce, l'USB est ultra répandu. C'est donc intéressant de se pencher sur la sécurité de ces périphériques, surtout qu'y accéder est super rapide et peu coûteux.
Pour faire leurs tests, les deux ingénieurs de @Quarkslab ont développé un outil qui récupère les trames USB, extrait les octets à modifier puis les rejoue sur le périphérique. Une sorte de proxy USB.
En fuzzant un peu n'importe comment pour accéder aux couches hautes (les applications), le pilote USB de Windows (USBSTOR.sys) plante.
Au final, je n'ai pas vu de résultats très avancés, mais la démarche et l'outil développé sont prometteurs et vont sûrement conduire à des trucs assez sympa.
Bootkit revisited par Samuel Chevet
En gros (c'est pas trop ce que je préfère les bootkits) j'ai compris qu'en infectant la chaîne de boot de Windows, l'orateur arrive à bypasser le mécanisme d'authentification de Windows pour se logguer sur la machine avec un mot de passe faux.
Tests d’intégrité d’hyperviseurs de machines virtuelles à distance et assisté par le matériel par Benoît Morgan, Eric Alata & Vincent Nicomette
Pour lancer des machines virtuelles, on dispose d'un hyperviseur qui est installé directement sur l'hôte (en gros, c'est un OS) qui est chargé de créer et exécuter les machines virtuelles en allouant proprement les ressources.
Il est possible que l'hyperviseur soit compromis par le réseau, ou par un composant hardware, ce qui impliquerait que toutes les VM sont compromises.
Ce projet est en quelque sorte un nouvel hyperviseur, qui va faire tourner l'hyperviseur réel et donc va pouvoir lancer des checks pour vérifier l'intégrité de l'hyperviseur et détecter plus rapidement des compromissions.
C'est basé sur une carte FPGA sur un slot PCIe et ça peut lancer toute sorte de checks et remonter des alertes.
La sécurité des systèmes mainframes par Stéphane Diacquenod
On est tous habitués à avoir chacun un poste de travail et on oublie que dans certaines sociétés, il existe encore des systèmes mainframe, comme c'est le cas chez Volvo.
Ici, on est sur du matériel IBM et, franchement, la sécurité n'est pas au point. Les mots de passe sont composés d'au maximum 8 lettres majuscules et chiffres, l'administration se fait sur du telnet, dans la BDD le système stocke le login chiffré en DES avec le mot de passe pour vérifier l'authentification, cette base est accessible en lecture par tous les utilisateurs (qui pourront facilement casser les mots de passe avec John the Riper, etc.
Bref, c'est pas au top, et toute la sécu repose sur le boulot des sysadmins qui ont énormément de taf pour maintenir un truc un peu propre.
Présentation courte : Reconnaissance réseau à grande échelle : port scan is not dead par Adrien Guinet & Fred Raynal
Nouvelle présentation de Quarkslab, sur le scan réseau à grande échelle.
Les outils connus, comme nmap, Nikto, Blind Elephant et autres, sont utiles pour des petits réseaux, mais pas pour des /8, surtout qu'ici les infos recherchées sont en couche 7 (textes, images, certificats, clés, etc).
Ils ont donc développé un sorte de petit botnet qu'ils ont déployé sur les VM dans des « pays acceuillants (Estonie, Roumanie, ...) » et qu'ils pilotaient à distance. Un ordonnanceur distribuait quelques adresses IP aléatoires (scanner un range d'IP depuis le même host ça fait recevoir des mails depuis abuse@) à chaque agent qui scanne ensuite la cible avec nmap puis renvoie les infos au scheduler qui stocke tout ça dans une grosse base Mongo DB.
Et en plus, on peut mettre un peu d'intelligence dans le scan. Du genre « si le port tcp/80 est ouvert, teste le tcp/443 et récupère le certificat x509 ».
Après, ça devient tout simple de faire des recherches la dedans pour avoir des infos sur les machines françaises (encore faut-il savoir si on cherche les machines en .fr ou celles qui ont des IP françaises), ou faire des statistiques sur les logiciels utilisés dans certains pays.
Par exemple, en Espagne, un FAI met le nom de l'abonné dans la bannière du service FTP qui est en écoute sur l'Internet. Au final, scanner les 30 millions d'IP espagnole à demandé 25 heures de scan.
La bibliothèque développée est en ligne sur Github.
Cryptocoding par Jean-Philippe Aumasson
Dans cette période troublée par différents — gros — bugs crypto (Heartbleed, GNUTLS et « goto fail; »), Jean-Philippe Aumasson a été invité à faire une conférence sur le sujet.
Le monsieur est un peu calé sur le sujet puisqu'il fait parti du projet OpenCryptoAudit qui a pour but d'auditer le code de Truecrypt. Et il aime un peu les trolls puisqu'il ne s'est pas géné pour taper un peu sur tout le monde.
D'abord, sur OpenSSL et la « qualité » de son code. Un nommage non consistant, des bugs ou corner cases connus par les développeurs mais non fixés (présente de FIXME, QUICK AND DIRTY SOLUTION dans le code), des fonctions crypto qui ne suivent pas les RFC, des fonctions ou des API pas assez propres, etc.
Une autre raison aux bugs présents dans le code d'OpenSSL c'est la trop grande variété des protocoles et OS supportés.
Il a aussi parlé un peu de Tor et Cryptocat, renommés comme étant des références en matière de protection de la vie privée, mais qui pourtant ont contenu pendant longtemps des gros bugs dans l'implémentation de leur crypto.
Pour bien coder de la crypto, il est à l'origine d'un wiki qui donne une douzaine de bons conseils pour être résistant aux principales attaques (time attack, misuse attacks) et éviter que les compilateurs optimisent trop le code.
1 Compare secret strings in constant time
2 Avoid branchings controlled by secret data
3 Avoid table look-ups indexed by secret data
4 Avoid secret-dependent loop bounds
5 Prevent compiler interference with security-critical operations
6 Prevent confusion between secure and insecure APIs
7 Avoid mixing security and abstraction levels of cryptographic primitives in the same API layer
8 Use unsigned bytes to represent binary data
9 Use separate types for secret and non-secret information
10 Use separate types for different types of informationp
11 Clean memory of secret data
12 Use strong randomness
Coder de la bonne crypto ça demande d'être très bon en maths et crypto, et très bon en programmation. Réunir les deux qualités est compliqué, il faut donc que les deux parties travaillent ensemble pour éviter les gros bugs.
Buy it, use it, break it ... fix it : Caml Crush, un proxy PKCS#11 filtrant par Ryad Benadjila, Thomas Calderon & Marion Daubignard
PKCS#11 (ou Public Key Cryptography Standards, ou « Cryptoki » (Cryptographic Token Interface)) est un standard qui est destiné à éliminer les implémentation propriétaires en fournissant une API/driver pour dialoguer avec des HSM (composants sécurisés).
Notamment, les clés cryptographiques doivent généralement rester à l'intérieur des HSM (des tokens ou cartes à puce par exemple). PKCS#11 va donc permettre de réaliser des actions cryptographiques tout en gardant les secrets dans les composants crypto.
Ces HSM peuvent contenir plusieurs clés, ayant chacune des propriétés distinctes. Par exemple, on peut avoir une clé R avec l'attribut SENSITIVE (qui ne doit pas sortir de la carte) et une clé B avec WRAP (pour encapsuler une autre clé) et DECRYPT.
Et c'est là dessus qu'il existe des vulnérabilités, notamment puisque (en gros) DECRYPT = WRAP⁻¹. On peut donc « wraper » R avec B, puis déchiffrer le résultat avec B pour réobtenir R.
Caml Crush est donc un proxy PKCS#11 qui va intercepter toutes les requêtes et les modifier/supprimer pour empêcher des attaques exploitant ce type de vulnérabilités.
Martine monte un CERT par Nicolas Bareil
Nicolas Bareil, du CERT d'Airbus Group, a fini la journée (avant les rumps) par un retour d'expérience sur la création d'un CERT. Ce milieu semble assez fermé, c'est pourquoi il voulait partager son xp avec le SSTIC.
Finalement, un CERT, ça doit se concentrer uniquement sur les gros incidents, ça doit prendre du recul par rapport aux incidents, et surtout communiquer. Dans le CERT, avec les utilisateurs/admins, la hiérarchie, etc.
Niveau technique, les attaquants ne sont pas toujours très intelligents mais, dans le cas des APT, ils prennent leur temps pour garder une porte d'entrée saine au cas où. Il faut donc être capable d'analyser du réseau ou du système pour remonter les traces. Mais attention, des malettes de copie de disques sont inutiles, généralement il faut tout faire en live pour ne pas « géner » l'attaquant et ainsi prendre le temps de bien comprendre tout ce qu'il fait.
Il faut donc être capables de déployer rapidement des IDS pour observer le trafic, des agents sur les postes impactés pour suivre les actions lancées par l'attaquant, et pouvoir remonter jusqu'au « patient zéro » de l'attaque.
Enfin, de très bonnes capacités de communication sont essentielles. Une infrastructure dédiée et sécurisée pour les membres du CERT doit pouvoir être mise en place très vite (plusieurs serveurs, infra mails, Wiki, tickets, etc). Les noms des contacts IT et responsables de tous les pôles de l'entreprise, dans les filiales et chez les sous-traitants doivent également être connus, et ils doivent tous connaître le rôle du CERT et le leur dans la résolution de ces incidents.
Je trouve que l'article vaut vraiment le coup d'être lu, tout y est bien expliqué, et Nicolas était prêt à partager toutes les infos qu'ils avaient dans leur CERT à ceux qui voudraient se lancer !
Rumps
Enfin, un #SSTIC sans les rumps ne serait pas un SSTIC et, commme il y en avait 27, elles font l'objet d'un article à part.
La suite est ici.
-
Où j'avais d'ailleurs fait mon Master ↩
