Compte-rendu de la conférence SSTIC 2012 (Première partie)

Date : 06 Septembre 2012

La conférence SSTIC 2012 s'est tenue à Rennes du 6 au 8 juin. Il s'agit d'une conférence francophone de haut niveau qui rassemble des personnes passionnés de techniques et de sécurité informatique. Les présentations y sont souvent orientées sur des aspects offensifs en mettant en évidence les faiblesses ou les limites des technologies actuelles. Mais cette année la conférence était plus conventionnelle et plus attachée à expliquer l’évolution des technologies (avec par exemple des présentations très techniques sur SSL, RDP, Miasm, etc…) qu’à des démonstrations de vulnérabilités. Cette édition 2012 avait donc plutôt une couleur académique et recherche, mais toujours dans une ambiance très agréable.

On notera que le comité d’organisation fait des efforts importants pour encourager le partage de connaissances :

La grande majorité des présentations est accompagnée, en plus des supports de présentation, d’un article approfondi consultable sur le site web de la conférence.
Cette année, des présentations courtes (15 minutes) ont été introduites dans la conférence. Elles sont réservées aux étudiants et jeunes chercheurs pour présenter le résultat de leurs travaux.

Nous donnons ci-dessous un compte-rendu rapide d'une première partie des présentations. Les autres présentations feront l'objet d'un nouvel article le mois prochain.

20 years of PaX

Le créateur de PaX (et unique membre de la « PaX team ») a expliqué l’évolution de PaX depuis sa création en 2000. PaX est un package Linux très connu qui permet de renforcer la sécurité du noyau Linux en implémentant par exemple des protections contre les débordements mémoire, ou la randomisation de l’espace d’adressage. PaX a été un précurseur dans ce domaine puisque ce type de protection n’est apparu dans Windows qu’en 2004 avec le SP2 de Windows XP. PaX est un patch du noyau Linux. Il est disponible au sein du package « grsecurity » mais, à notre connaissance, n’est intégré en standard à aucune distribution Linux majeure. La présentation a passé en revue les fonctionnalités de PaX et les ajouts successifs au cours du temps de nouvelles protections. Globalement, on retiendra que le package est toujours vivant et continue d’évoluer.

SSL/TLS: état des lieux et recommandations (par l’ANSSI)

Cet exposé présente tout d’abord les différentes versions de SSL/TLS et leurs niveaux de sécurité. Elle analyse ensuite quelles sont les versions le plus souvent rencontrées sur Internet. Nous approfondissons ces 2 aspects ci-dessous. Mais avant cela, rappellons la différence entre SSL et TLS : SSL a été créé par Netscape, mais, en 2001, l’IETF a pris la responsabilité du protocole, et l’a rebaptisé TLS (TLS V1.0 est le successeur de SSL V3).

En termes de sécurité, TLS V1.1 est considéré comme la première version sûre (il existe des vulnérabilités dans les versions précédentes). La dernière version publiée est TLS 1.2. Dans la pratique, sur Internet la plus grande majorité des serveurs acceptent TLS V1.0 (qui contient plusieurs vulnérabilités). TLS V1.0 est aussi le protocole par défaut (i.e. dans la configuration par défaut) pour IE, Firefox et Opera. Chrome utilise pour sa part TLS V1.1 et Safari TLS V1.2. Globalement l’adoption des versions récentes de TLS est donc lente (les spécifications de TLS V1.2 datent de 2008).

L’orateur s’intéresse ensuite aux « Suites cryptograpiques » utilisées, c'est-à-dire aux algorithmes qui sont négociés entre le client et le serveur et qui serviront pendant les différentes phases TLS (authentification, échange de clés, chiffrement et signature), certaines étant plus robustes que d’autres. Le choix de ces suites pose certains problèmes : par exemple, certains serveurs (comme IIS) sont directifs et imposent des suites trop faibles. De même, sur Windows il n’est pas possible de définir le paramètrage des suites cryptographiques pour chaque application : un seul paramètrage peut être défini et il s’applique à toutes les applications de la plate-forme qui utilisent TLS. L’orateur signale enfin que 40% des certificats serveurs rencontrés sur Internet sont incorrectement construits.

En conclusion, le protocole TLS est sûr d’un point de vue théorique et peut être mis en œuvre correctement lorsque l’on maitrise le paramètrage du serveur et des clients. Dans une utilisation sur Internet, la situation est bien plus difficile : restreindre son serveur ou son client à des configurations sûres entraîne une perte de compatibilité et est donc difficilement applicable.

Netzob : un outil pour la rétro-conception de protocoles de communication (par AMOSSYS et Supelec)

Ce projet aborde un sujet de recherche très sérieux : construire un outil qui sache faire la rétro-conception d’un protocole de communication en observant des échantillons d’échanges entre 2 machines.

D’après les orateurs, il s’agit d’un sujet très actif dans la communauté de la recherche mais pour lequel jusqu’à présent presqu’aucun outil n’a été publié sur Internet. Un outil comme Netzob peut être utilisé par exemple pour découvrir automatiquement le protocole de communication qu’un botnet utilise.

De façon très schématique Netzob fonctionne de la façon suivante :

Il analyse tout d’abord les messages échangés et, en se basant sur les similarités trouvées, il identifie les champs et le vocabulaire utilisé.
Il construit ensuite un graphe décrivant le comportement du protocole puis valide ce graphe en « fuzzant » le protocole dans un environnement contrôlé (envoi de stimuli et observation des réponses obtenues).

La théorie sous-jacente est visiblement ardue, mais la video de démonstration montre que Netzob obtient dans ce domaine des résultats a priori prometteurs.

Sécurité de RDP (par l’ANSSI)

Cette présentation analyse la sécurité du protocole RDP (Remote Desktop Protocol) de Microsoft. Elle montre tout d’abord qu’en termes de fonctionnalités et d’architecture, RDP est extrêmement complexe (2000 pages de documents de référence) du fait de l’ajout de fonctionnalités successives (à un protocole qui à la base permet le déport d’écran) et de l’empilement des couches protocolaires (TPKT, X224, etc...). Elle présente ensuite les aspects sécurité du protocole et explique qu’il existe deux variantes :

Standard RDP security : c’est le modèle utilisé par défaut et son niveau de sécurité est insuffisant. Le traffic réseau est ici protégé par une clé RSA de 512 bits (2048 sous Windows 2008) ce qui est insuffisant (car cassable).
Enhanced RDP security : pour ce modèle deux sous-variantes sont disponibles : TLS et NLA/credSSP. Le niveau de sécurité est ici meilleur. Un des problèmes identifiés cependant est que, lorsqu’une anomalie est identifiée par RDP à propos de l’identité du serveur, si la configuration n’est pas la plus stricte possible, l’utilisateur est averti mais a la possibilité d’accepter quand même la connexion. Cela rend possible les attaques MITM (Man In The Middle).

Les recommandations données en conclusion de la présentation sont :

d’utiliser NLA/credSSP pour les machines connectées sur le domaine,
d’utiliser à défaut TLS pour les machines hors domaines,
de protéger les flux RDP en les faisant circuler sur des réseaux isolés.

WinRT (par QuarksLab)

Cette présentation analyse la sécurité du composant WinRT (Windows RunTime) de Windows 8. WinRT est la couche logicielle sur laquelle s’appuie « Metro », la nouvelle interface graphique de Windows 8. Sous Windows 8, il y aura en effet deux types d’interface :

Le « bureau » classique permettant de lancer les applications classiques.
L’interface « Metro » qui présente les « Metro apps » sous formes de tuiles (comme sur Windows Phone). Les « Metro apps » seront téléchargeables sur le WindowsStore (équivalent Microsoft à l’AppStore Apple ou à l’Android Market).

D’un point de vue sécurité, WinRT implémente un mécanisme de bac à sable qui permet d’isoler les « Metro apps ». Les orateurs indiquent que le niveau de sécurité de ce bac à sable leur parait satisfaisant.

L'information, capital immatériel de l'entreprise (par une avocate)

Cette présentation juridique s’intéresse à la façon dont la notion d’information est vue (et est protégée) par la loi. Comme il n’existe pas de définition juridique du terme « information », la tâche n’est pas facile et il faut rechercher dans les textes législatifs les aspects qui paraissent pertinents. Par exemple, la loi parle de recel d’information, ou de diffusion de fausses informations. Elle parle parfois aussi de données ou de certains supports contenant l’information (par exemple les bases de données).

Audit des permissions en environnement Active Directory (par l’ANSSI)

Les Active Directory Microsoft sont de tailles de plus en plus grandes (certains AD contiennent des millions d’objets) et vérifier qu’il n’y a pas d’anomalie de sécurité au sein d’un AD (par exemple un compte ou des permissions ajoutées par un pirate) est une tâche difficile. Pour faciliter cette tâche d’audit, l’ANSSI a développé un outil (disponible ici) qui permet d’analyser les fichiers bruts contenant les données de l’AD (à la vue de la complexité de la structure interne de l’AD, cette phase est loin d’être triviale), puis de les explorer au moyen d’une interface graphique.

En termes de technique d’audit, les orateurs donnent ensuite toute une série de conseils :

Eliminer tout ce qui paraît normal pour faire apparaitre les cas qui posent question (réduction progressive du nombre d’enregistrements à analyser)
Trier les droits attribués de façon à faire ressortir les comptes qui ont un nombre anormalement élevé de droits.
Vérifier les droits attribués sur les boites-à-lettres Exchange pour vérifier qu’un utilisateur ne s’est pas attribué le droit de lire les boites-à-lettres d’autres utilisateurs.
Vérifier l’objet « adminSDholder », car cet objet définit des droits d’accès qui seront automatiquement re-attribués toutes les heures. Une modification de cet objet peut permettre d’implémenter un mécanisme très discret d’augmentation illégale de droits.

Windows 8 et la sécurité : un aperçu des nouvelles fonctionnalités (par Microsoft)

Cette présentation passe en revue certaines des améliorations de sécurité de Windows 8. Elle aborde en particulier :

Les protections de bas niveau : comme l’adoption de l’UEFI (Universal Extensible Firmware Interface) en remplacement du BIOS traditionnel, le TPM V2, ou la possibilité de déclencher un antivirus dans la chaine de boot (fonction ELAM – Early Launch Anti-Malware).
L’implémentation de la notion de carte à puce virtuelle grace au TPM : le fait de posséder l’ordinateur et de pouvoir fournir une information secrète (de type PIN) sera alors considéré comme une authentification à 2 facteurs.
Des améliorations de BitLocker pour faciliter le déploiement.
L’amélioration du modèle des ACL en y ajoutant la notion de « revendication » (« claims » en anglais) ; il sera alors possible d’exprimer une condition complexe comme : « ce répertoire est accessible si l’utilisateur est dans le réseau de l’entreprise ».

Compromission d'une application bancaire JavaCard par attaque logicielle (par SERMA Technologies)

L’orateur présente l’audit de sécurité qu’il a réalisé sur une carte à puce qui embarque une application bancaire sous forme d’applets Java. Comme il dispose pour cet audit des clés de chargement (ce dont ne dispose pas un attaquant ordinaire) il peut installer des applets offensifs sur la carte. Il montre qu’il parvient ainsi à mettre en défaut les mécanismes de sécurité de JavaCard puis à altérer l’application bancaire. Il réalise par exemple une attaque de type « Yes card » (la carte considère n’importe quel code PIN comme étant valide) ou même il extrait les clés cryptographiques stockées dans la carte (ce qui est le pire scénario d’attaque pour une carte bancaire).

IronHide : Plate-forme d'attaques par entrées-sorties (par le LAAS/CNRS)

Cette présentation est dans la continuation des présentations faites par le même orateur les années précédentes. Elle s’intéresse aux attaques matérielles sur les plates-formes PC via des équipements périphériques (cartes graphiques, controleurs d’entrées/sorties, etc…). Cette année l’orateur présente « IronHide », une carte PCI-Express conçue spécifiquement pour espionner le bus interne du PC. Elle permet par exemple de découvrir des messages non documentés échangés sur le bus interne, ou injecter sur ce bus des requêtes arbitraires. A titre d’exemple, l’orateur fait une démonstration d’un programme qui capture le mot de passe BIOS au moment où il est échangé entre le clavier et le BIOS, et qui rejoue ce mot de passe en faisant croire au BIOS que celui-ci a été tapé au clavier. En conclusion, l’orateur indique que ce type de carte pourrait être utilisé comme un IDS interne au PC : elle surveillerait le bus pour détecter si un composant interne a un comportement anormal (détection d’un composant piégé).

La suite (et fin) de ce compte-rendu sera publiée le mois prochain.

Pour plus d’informations :

Le site officiel de la conférence : https://www.sstic.org/2012/actes/
Quelques-uns des blogs qui parlent de la conférence 2012 :