![[couverture de Linux Magazine 120]](http://www.ed-diamond.com/bigres/lmag120.jpg "Linux Magazine 120")
Article publié dans Linux Magazine 120, octobre 2009.
Copyright © 2009 - Laurent Gautrot
![[+ del.icio.us]](/images/add-to-delicious.gif)
![[+ Developers Zone]](/images/add-to-dzone.gif)
![[+ Bookmarks.fr]](/images/add-to-bookmarks-fr.png)
![[Digg this]](/images/add-to-digg.png)
![[+ My Yahoo!]](/images/add-to-myyahoo.gif)
Cette première journée a été l'occasion d'écouter des orateurs d'horizons très différents. Tout d'abord, avec la keynote d'ouverture, on a eu un sujet très intéressant, presque d'actualité avec une présentation de la sécurité chez un constructeur aéronautique. Puis il y a eu trois présentations très techniques sur l'exploitation de failles de sécurité dans les javacards et deux autres qui ont parlé de marquage de données et décompilation.
Pour l'après-midi, c'est plus dans un registre (hi hi) bas niveau avec des analyses sur les attaques matérielles à travers l'ACPI ou le bus PCI, mais aussi les attaques sur Internet et une discussion sur l'apport d'ISO 27001.
Le premier contact avec le symposium est une file d'attente spectaculaire pour le retrait des badges, du T-shirt du symposium et de la copie des actes. Ça se passe assez rapidement, et l'amphithéâtre est à portée après un passage au stand.
L'équipe d'organisation a prévu des prises de courant électrique à chaque rangée, très bien réparties et très appréciées.
Les conversations vont bon train dans tous les domaines, mais mon oreille indiscrète capte quelques sujets sur le réseau et des failles dans TCP. Cependant, j'avais entendu parler de problèmes de compromission à ce sujet, mais je pensais que c'était lié à des implantations spécifiques dans certains routeurs, suite à des optimisations un peu hâtives.
Dans un registre plus polémique, j'ai aussi entendu une remarque sur un prestataire qui a travaillé dans un service de la fonction publique, où il y avait évidemment des fonctionnaires qui ne bossaient pas et qu'il fallait pousser. À ce qu'il semblait, la personne qui narrait cette anecdote a sauvé le monde, ou juste un sous-ensemble de ce dernier, mais à peine.
Pascal ANDREI est directeur de la sûreté d'Airbus Europe. Il est en charge de sûreté (« security » en anglais) des avions. C'est à opposer à la sécurité (« safety » en anglais).
Le but de son service est de parvenir à concevoir un avion pour qu'il y ait le moins d'incidents possible. Cette keynote ne sera pas assortie d'une présentation à l'écran. Compte tenu de l'actualité, la direction du groupe ne souhaite pas que des propos soient sortis du contexte et exposés dans la presse ou ailleurs.
Pascal commence avec une anecdote sur sa prise de fonction. Il avait été embauché pour comprendre pourquoi la division satellite n'enregistrait pas de commandes. La société a embauché Frantic, un hacker notoirement connu, qui est parvenu à déterminer que des sites du groupe avaient été piratés et que la concurrence avait accès à des informations consolidées sur les appels d'offre quelques jours avant qu'ils ne soient envoyés.
Il y a néanmoins un lien avec la sécurité, avec la découverte progressive des nouvelles attaques, et le travail à accomplir pour garantir un fonctionnement sans faille.
Les situations à détecter et prévenir sont par exemple la présence d'une bombe à bord, un passager clandestin dans les trappes des trains d'atterrissage, etc.
Le rayonnement électromagnétique est également pris en compte pour limiter les anomalies qui pourraient être provoquées sur les instruments de bord. Désormais, il y a aussi la menace informatique. Il y a quelques années, il n'y avait que du code propriétaire, des liens propriétaires qui n'étaient utilisés que dans l'aéronautique, et indisponibles dans le commerce grand public. Maintenant, avec l'introduction d'API dans les avions, même s'il n'y a pas d'impact pour la sécurité (ces équipements ne concernent pas la conduite, et les communications sont dédiées sur des circuits à part).
Pour les attaques physiques, la prévention est plus délicate. Les bombes liquides sont difficiles à détecter. Dans certains pays instables, on observe des attaques avec des MANPADS - Man Portable Air Defense Systems, de petits bazookas qui deviennent plus intelligents), utilisés par des terroristes.
Les systèmes qui tournent sous Microsoft Windows dans les avions sont dédiés à des tâches bien précises à bord, comme la lecture de mails hors-ligne, et il n'y a pas de connexion directe à internet dans les avions.
La réglementation a considérablement changée suite aux évènements du 11 septembre 2001.
Parmi les obligations, il y a des tests de pénétration, assortis d'un rapport, mais il n'y a globalement pas d'impact sur la sécurité.
Après la conception de l'avion, les chaînes d'assemblage se trouvent à plusieurs endroits en Europe. Par exemple, pour l'A380, il est stocké 1 à 2 mois sur place pour l'assemblage, mais il sera exploité environ 30 ans. Les niveaux de sûreté sont définis pour que l'exploitant l'utilise en toute sécurité sur cette durée.
Il y a une PKI sur les A380. Tous les logiciels sont signés. Les informations (sur le vol, les passagers) elles-mêmes sont également signées. Les messages sont envoyés au sol à intervalle régulier avec la check-list.
Le constructeur donne un objectif de sécurité et c'est à l'exploitant de l'assurer. Ces objectifs concernent l'interopérabilité avec les équipes au sol, mais aussi les responsabilités (qui est en charge de quoi).
La réglementation, qui évolue, impose de séparer les domaines, et de réaliser des tests de pénétration (depuis le 380). Auparavant, il n'y avait que peu de choses à ce sujet.
Le niveau de sûreté est défini pour 30 ans, mais la réglementation impose désormais de publier un mini-CERT pour alerter sur les failles, et la publication de correctifs. En cas d'impact, il doit y avoir une correction immédiate, sinon elle sera planifiée pour la future livraison.
Il y a un besoin de convergence pour les certifications de sécurité IT.
La maintenance sur les appareils a lieu tous les 28 jours, ou plus tôt en cas de défaut observé.
L'orateur présente alors les 3 entités qui sont concernées directement ou indirectement par la sécurité :
son service corporate ;
le service de développement ;
le service qui gère la conformité avec les exigences de sûreté ;
Deux autres entités plus lointaines sont aussi concernée d'un peu plus loin par la sécurité : IT et sûreté des bâtiments.
Il y a trois grands pôles dans la division corporate :
anticipation : pour identifier sur les nouvelles menaces. Ce pôle est en charge de la R&D. Des réflexions sont en cours sur la biométrie, le RFID pour les life jacket (pour l'anecdote, les gilets sont comptés avant chaque vol, il en manque parfois, des voyageurs doivent les embarquer pour leur piscine, mais l'appareil ne peut pas décoller s'il manque des gilets), des prises Ethernet RJ45 sur les sièges passagers à sécuriser, le monitoring des passagers (sky marshall). Si aujourd'hui, les avions transportent au plus 525 à 550 passagers, les prévisions sont de 800 personnes pour le futur. Il est envisagé de suivre les passagers jusqu'au siège, pour faire face aux retards liés à l'absence des passagers qui n'ont pas entendu l'appel, ou pour vérifier qu'un passager est dans l'aéroport. Le marquage des billets est une piste ;
développement : production, assemblage. Aircraft Security Management System (ASMS), gestion de crise ;
avion en service : suivi des objectifs de sécurité. C'est parfois très facile dans certaines compagnies qui ont conscience des enjeux et qui ont déjà des outils et des méthodes pour les assurer. Parfois c'est plus difficile, et ce service apporte du soutien. C'est ce service qui assure l'analyse de tous les liens interdomaines. Par exemple, les écrans partagés entre plusieurs domaines doivent être analysés pour vérifier l'absence de risque.
L'aspect rétroactif est très difficile à gérer. C'est aussi un travail ingrat.
« Comment font les avions pour être en conformité avec les réglementations locales sur l'usage de la cryptographie ? »
Pour ne pas être en défaut par rapport aux réglementations nationales, il n'y a pas le droit de chiffrer en vol, mais le déchiffrement est autorisé. Dans le cas de la PKI, est elle juste utilisée pour vérifier que la signature est valide. En fait, il n'y a pas de code de chiffrement à bord, même s'il n'est pas utilisé, les constructeurs ne prennent pas le risque de transporter du code potentiellement hors-la-loi.
[1] MANPADS - http://en.wikipedia.org/wiki/MANPADS
Après la keynote, une plongée dans la technique aborde la question de l'exploitation de failles dans la conception de certaines javacards pour l'exécution de code destiné à extraire des informations, et éventuellement modifier des données.
Le principe de cet exploitation est la modification du bytecode, et l'empêchement de l'édition de lien avant l'exécution. Normalement, durant cette phase d'édition de lien, toutes les adresses sont recalculées pour pointer aux emplacements légitimes. Dans certains cas, il est possible d'extraire une adresse mémoire, et de l'utiliser pour réaliser un appel de routine à un endroit précis.
Une javacard utilise du code exécuté dans la carte elle-même, et dans certains cas, du code exécuté à l'extérieur de la carte. C'est sur cette portion de code que l'on peut influer pour introduire du bytecode trafiqué.
Certaines javacards ont des contre-mesures. Sur le lot des cartes utilisées durant l'analyse, une permet de récupérer l'intégralité des données de la carte, d'autres sont plus limitées. Dans quelques cas, lorsque la carte détecte une tentative de lecture ou d'écriture illégitime, la carte se "suicide".
« Comment se comportent les cartes quand il y a des accès indirects à la mémoire ? »
Pour les cartes 16 bits sans indirection, tout se passe très bien. Pour les cartes avec indirection, il est possible de lire, mais l'écriture entraîne destruction de la carte parce qu'on ne pointe pas à la bonne adresse. La lecture en revanche ne pose pas de problème.
« Avez-vous testé les dotnetcards ? »
Elles n'ont pas été testées, mais elles fonctionnent sur le même principe, donc elles devraient avoir les mêmes risques. Là encore, les cartes cartes modernes ont des contre-mesures.
Tiré du site du SSTIC : « La virtualisation fournit des possibilités prometteuses dans le cadre de l'analyse automatique de binaires. Parmi ces possibilités, nous nous proposons ici d'en étudier une en particulier, le data tainting, et d'en voir les différents aspects dans le cadre d'une mise en application concrète. Cette application aura pour but de capturer de manière générique les données déchiffrées des fichiers de configuration des malware. »
Tiré du site du SSTIC : « Dans la suite de notre présentation de l'an dernier, nous travaillons sur le contournement automatique de techniques de protections logicielles. Nous nous concentrons particulièrement sur la problématique de l'obscurcissement (obfuscation). Jusqu'à présent, il était nécessaire de rechercher à la main les schémas utilisés par la protection afin de les annuler. Notre approche actuelle cherche à rendre ce travail fastidieux automatique, par une analyse de la sémantique du code binaire permettant d'en extraire une représentation minimale, ce qui revient à supprimer la couche d'obfuscation. Nous montrerons les résultats obtenus sur quelques exemples, où nous verrons que les méthodes développées permettent parfois de contourner d'autres formes de protection comme les machines virtuelles logicielles. »
En introduction, Marc DACIER lance une annonce pour aller travailler pour Symantec à Sophia Antipolis.
Il présente WOMBAT, qui ne signifie pas Waste Of Money Brain and Time ;) mais Worldwide Observatory of Malicious Behaviours and Attack Threats.
Le fonctionnement de WOMBAT s'articule autour des points suivants :
Acquisition ;
Enrichissement ;
Analyse des menaces.
VirusTotal donne des informations sur la détection des malwares par une vingtaine d'antivirus.
Anubis est une base de connaissance qui permet d'obtenir des informations sur le comportement des malware.
La détection des malwares est variable dans le temps. Quand on observe un malware bien précis, il est possible qu'il soit détecté très rapidement puis qu'il soit ignoré avant d'être détecté à nouveau. Pratiquement tous les anti-malware sont concernés. En général parce que faux positifs par exemple, ou nommage de variantes .a .b .c)
SGNET permet de collecter des données depuis des honeypots.
Tous les malwares sont décrits dans une machine à états finis (FSM - Finite State Machine). Il y a aussi une machine à haute interaction. Les deux machines ont été analysées sur 200 jours.
Dans la FSM, quand un chemin est mort, (10 jours) il reste dans la machine. Il est réactivé si une nouvelle attaque survient. Mais la purge serait envisageable. Dans les faits, le nombre de chemins distincts n'impose pas une purge actuellement.
L'utilisation des blacklists n'est pas systématique.
Les bogons sont évités par les attaquants, et les clients qui disposent d'adresses qui suivent immédiatement les bogons sont généralement épargnés. C'est lié au fait que les robots qui tentent d'implanter des malwares utilisent des générateurs aléatoires. Pour illustrer ce propos, la distribution sur le réseau des attaques n'est pas répartie également partout. Un client avait des machines attaquées en permanence et voulait proposer de nouveaux services. Il disposait d'un autre réseau d'une autre classe d'adressage et cette classe était beaucoup moins attaquée.
Le but ultime de protection est l'exclusion du BIOS de la zone de confiance. Mais en raison des choix faits depuis de nombreuses années sur la gestion du matériel, il n'est pas possible d'extraire le BIOS.
Très rapidement, une démonstration d'exploitation des routines de
traitement de la SMI est proposée avec un débranchage/rebranchage du
câble d'alimentation d'un ordinateur. Le déclencheur dans ce cas est un
débranchage et rebranchage à quatre reprises. Après cette manipulation,
une reconnexion avec un compte normalement non privilégié amène
un compte de root. Cela ne devrait évidemment pas être possible, et
c'est grâce à une exploitation préalable d'une faille de sécurité
que l'appel système setuid() a été redéfini. Pour mémoire, la
démonstration tourne sur une Mandriva 2007.
Une contre-mesure possible réside dans l'utilisation de Getsec[SENTER] qui désactive tous les CPU sauf le premier, puis le démarrage de SINIT et l'exécution d'un moniteur de machine virtuelle, puis la réactivation des CPU, hors initialisation du BIOS.
Quelques acronymes sont lancés :
SMM : system management mode ;
SMI : system management interrupt, possibilité de déclencher une SMI en écrivant dans un registre du chipset ;
SMRAM : System Management RAM ;
La faille est complète on n'a pas un BIOS de confiance.
Un autre problème concerne l'exploitation du cache en cas de writeback, pour redéfinir la stratégie de cache pour la zone qui gère la SMI, déposer du code malicieux et l'exécuter. Toutefois, dans ce cas, l'exploitation est éphémère et non statisfaisante pour un attaquant.
Une autre approche consiste à relocaliser complètement la SMRAM. Cela nécessite de ré-écrire 15 octets dans la SMRAM, pour pointer sur une zone initialement hors de porté de la partie protégée.
La table d'évènements est normalisée, mais pas la routine associée à un évènement. Par conséquent, quand l'OS exécute une routine, il est incapable de vérifier que la routine n'est pas malicieuse. La routine est exécutée par un interpréteur AML (ACPI Module Language). La version source de ce module est en ASL (ACPI Source Language).
Pour la démonstration, la fonction cachée modifie l'appel système
setuid() sur 4 branchement en 10 secondes.
En pratique, c'est vraiment intéressant seulement pour les machines Intel TxT.
Pour les autres machines, il y a déjà possibilité d'exécuter des choses de ce genre d'autres manières.
Pour le moment, il n'est pas possible d'empêcher ce type d'attaque. Il faudra voir avec le transfer monitor.
Les contremesures sont par exemple :
l'analyse statique de la table ACPI, pour vérifier si une routine modifie l'état du noyau, ce qui est assez compliqué ;
le contrôle dynamique, avec gestion des évènements avec moins de privilèges ;
L'exploitation du cache est à son tour illustrée avec une démonstration.
« Concernant EFI, est-ce mieux que le BIOS ? »
A priori, ce n'est pas forcément mieux pour EFI, parce que l'on a des mécanismes similaires pour les évènements SMI.
L'évasion de la machine virtuelle dépend de l'implémentation du traitement des évènements, et de la couverture.
Pour ces preuves de concept la mémoire physique est utilisée parce que la gestion est très simple. C'est beaucoup plus compliqué avec la mémoire virtuelle, et il n'y a a pas de généricité pour les autres OS.
La faille exposée concerne PCI, PCI-express et cardbus (qui est très proche de PCI) ou PCMCIA. Les deux normes diffèrent, mais le principe rest e le même.
Le problème est que le PCI Express permet de faire du DMA, et qu'il peut ne pas y avoir de contrôle sur la mémoire physique, pas tant sur le bus lui-même.
La présentation aborde ISO 27000 et les différentes normes qui la composent. Un tableau assez complet reprend les différentes normes avec leur portée, et la date de publication. On voit d'ailleurs que certaines normes sont prévues pour 2009 ou les années à venir.
27000 (2009) : Vocabulaire ;
27001 (2005) : Système de Management de la Sécurité de l'Information ;
27002 (2005) : Mesures de sécurité ;
27003 (2009) : Implémentation ;
27004 (2008) : Mesures et métriques ;
27005 (2008) : Gestion de risque ;
27006 (2007) : Certification du Système de Management de la Sécurité de l'Information ;
27007 (2010) : Audit du Système de Management de la Sécurité de l'Information ;
Pour ISO-27003, les émanations nationales peuvent préexister et s'appeler EBIOS ou MEHARI.
Cette présentation aborde la question qui fâche en général à propos des certifications, à savoir l'utilité pour le certifié.
Suite à des observations chez différents certifiés en France (une vingtaine à cette date dont une bonne partie a été auditée par l'orateur), ce qui apparaît, c'est que la certification est utile sur le long terme.
La force de 27001 est l'amélioration continue.
Quelques points plus polémiques sont abordés pour comparer l'approche du travail de fond de certains certifiés qui n'ont pas attendus la norme pour se pencher sur le sujet comparée à celle plus opportuniste de certains certifiés qui attendent la dernière minute pour la mise en conformité.
La présentation d'Ari Takanen sur le Fuzzing ne concerne pas les outils ou l'exploitation de vulnérabilités.
En revanche, elle parle de la fenêtre de vulnérabilité, à savoir les problèmes restant après prise en compte par l'éditeur.
Le problème principal est le choix des métriques et du bon outil pour la bonne tâche.
On identifie trois types de tests : les tests fonctionnels, les tests de performance, et les tests de robustesse.
Le fuzzing est du robustness testing.
La définition de Wikipedia est intéressante :
« Fuzz testing or fuzzing is a software testing technique that provides invalid, unexpected, or random data to the inputs of a program. If the program fails (for example, by crashing or failing built-in code assertions), the defects can be noted. »
En fait, les données ne sont pas si aléatoires que ça.
L'idée est que si il y a un défaut dans le logiciel, si ce dernier est bombardé de données aléatoires, il finira par montrer ses défauts, et éventuellement ses failles de sécurité.
Initialement, la technique était limitée aux interfaces en ligne de commandes, mais c'est extensible à des protocoles, comme TFTP par exemple.
Les extensions envisagées du fuzzing sont :
génération automatique des tests ;
exécution automatisée des tests ;
analyse automatisée ;
Ceci permet d'accélérer la détection de problèmes. Globalement, le fonctionnement est le suivant :
exploitation d'un modèle : PCAP, template, spécifications ;
surveillance et instrumentation : détection de fuite de mémoire, détection de corruption de tas/pile, contrôle de logique métier ;
automatisation ;
La maturité des modèles de test a évolué. Initialement, les tests étaient exécutés manuellement, puis ils ont été enregistrés. Par la suite, ils ont été scriptés, ce qui permet d'ailleurs d'assurer la non-régression. La phase suivante concerne l'action-word testing pour tester les changements de comportement des protocoles. Enfin, l'automatisation est l'étape ultime.
La plupart des fuzzers n'ont plus de comportement aléatoire, mais ce n'est de toute façon pas vraiment indispensable dans les faits.
Parmi les techniques de fuzzing, on trouve la mutation. Il n'y a pas d'intelligence, les modifications sont semi-aléatoires. On trouve aussi la génération, qui est intelligente, et produit des tests qui se basent sur un modèle ciblé.
PROTOS est un fuzzer qui peut utilisé en interne pour une utilisation personnelle. Les cas de tests ont été libérés.
Quand on parle de fuzzing, on parle de framework, d'outils ainsi que de suite de tests.
Le block-based fuzzing est une sorte de fuzzing. On part d'un échantillon ou modèle, et les changements sont décrits dans un modèle. Le modèle spécifie entre autres ce que sont les chaînes de caractères ou les nombres.
Ari montre un exemple avec Sulley et des tests pour écrire des requêtes HTTP.
Pour les évolutions du fuzzing, on peut envisager :
la mutation et le rejeu avec une capture, et et des rejeux instrumentés parce que l'on connaît le protocole ;
l'exécution scriptée, qui permet d'utiliser plus de tests et de frameworks, en mettant l'accent sur le parallélisme ;
le fuzzing block-based qui permet de spécifier plus de datablocs et de construire des structures complexes ;
le fuzzing model-based pour automatiser des acquisitions de protocoles, avec des modèles plus élaborés pour mieux gérer les nouveaux protocoles et détecter plus facilement les anomalies ;
Pour l'analyse des résultats, on a besoin de métriques. Parfois, un fuzzer peut provoquer des plantages, mais souvent le plantage est garanti si on en combine plusieurs.
Ari expose des résultats sur différents OS et différents protocoles.
Si on observe deux plantages dans deux groupes de tests, il est fort possible qu'il s'agisse de deux bugs différents.
La moitié des utilisateurs de fuzzers travaillent dans l'assurance qualité ou dans le développement.
Dans le cas des fuzzers qui ne montrent pas les failles, cela dépend du paramétrage. En pratique, même avec une bonne couverture, il n'y a pas de garantie de trouver tous les bugs.
Le fuzzing des téléphones : ce n'est pas forcément facile d'intégrer des documents, videos, etc. Mais le fuzzing des téléphones est beaucoup simplifié avec les piles IP et les autres protocoles comme GSM et Bluetooth.
» Sulley - http://code.google.com/p/sulley/
La présentation commence avec un rappel sur le fuzzing. C'est une technique de recherche d'erreurs d'implémentation logicielle par injection de données.
Les méthodes de génération de tests sont réparties en deux familles : grammaire ou modèle.
Plusieurs outils sont présentés :
Autodafé utilise gdb et analyse les données qui passent par les fonctions ;
Flayer modifie les instructions conditionnelles pour faire passer les données par des chemins différents de ceux prévus initialement ;
Le principe du fuzzing est l'exécution symbolique d'un programme, avec un jeu de données en entrée. Le travail du fuzzer est de détecter le chemin d'exécution, puis de modifier à chaque branchement conditionnel une nouvelle donnée, puis d'exécuter successivement la suite avec les nouvelles valeurs.
Valgrind est un cadriciel (framework) d'instrumentation binaire dynamique. En général, l'exécution passe par une représentation intermédiaire, puis une conversion en code machine, et se termine par l'allocation des registres et l'exécution à proprement parler.
STP est un solveur de contraintes générées par des analyseurs statiques. Il est rapide. Il fonctionne par marquage des données, puis propagation des données, et quand il rencontre une instruction conditionnelle, il extrait la contrainte, l'optimise, l'inverse, vérifie la contrainte inversée, et au final évalue un score.
Une démonstration est proposée avec un crackme simple et d'autres programmes dont readelf.
STP a permis de trouver des vulnérabilités dans readelf,
swfextract et libtiff, ainsi que dans certains exécutables pour téléphones
portables.
Il est possible de trouver plusieurs chaînes de caractère de mot de passe pour le crackme, parce qu'il y a une évaluation du mot de passe.
DynamoRio est assez performant. Son utilisation en place Valgrind est envisagée.
La présentation se conclut sur un appel à contributions. Toute remarque est bienvenue.
« Dans l'exemple du crackme, plusieurs mots de passe sont possibles parce qu'il pas de vérification de la chaine de caractère complète. Ce n'est pas réaliste ! »
C'est un crackme !
« Quid de la couverture du Graphe de contrôle ? »
L'exécution a lieu dans un ordre différent de ce qui peut être attendu.
L'enjeu est le déploiement d'une architecture de la manière la plus sûre possible. Cela concerne le quadrule play à venir.
Certaines extensions de réseau sont possibles sans licence, avec du wifi ou bluetooth. On parle d'UMA (Unlicensed Mobile Access).
Comme il y a un point d'entrée unique dans le réseau, il est l'objet d'une grande attention et d'une surveillance accrue.
Dans UMA il y a une authentification avec l'UNC (UMA Network Controller) par certificat (optionnelle), mais à vérifier, puis une authentification utilisateur, et ensuite l'établissement d'un tunnel IPSec.
Ce qu'il faut faire, c'est :
prévoir ;
standardiser ;
travailler en ingénierie réseau ;
améliorer par le biais des audits ;
Quand les outils existants sont inutilisables, il faut se lancer dans le développement de nouveaux outils pour tester.
Il n'y a pas de faux positifs avec le fuzzing. Cette technique permet de trouver généralement les défauts simples, mais permet parfois de trouver aussi des problèmes plus compliqués. Néanmoins, il ne faut pas se méprendre : ce n'est pas une assurance qualité !
Dans le cas d'une boite noire, les seuls stimuli sont des stimuli réseau. Il y a un risque de faux négatif. Les mécanismes de chiffrement imposent de connaître le protocole pour envoyer les paquets chiffrés.
Sulley est un outil de fuzzing. Sulley permet de réaliser du fuzzing par heuristiques après définition du modèle.
Il y a une démonstration d'un déni de service sur Strongswan (dernière version) exploitable à distance avec Sulley.
Le problème majeur avec les boites noires, c'est que l'on peut constater un plantage, mais il n'est pas possible d'identifier un bug à proprement parler.
Du côté des difficultés, on voit qu'il est compliqué et lourd de développer les modèles, et ces derniers sont forcément limités.
Pour le cas de Strongswan, une faille a été trouvée. Elle était causée par un problème dans un paquet hors état.
« Les communications sur le sujet sont inexistantes parce que les opérateurs ne souhaitent pas communiquer »
Pas de réponse. Il faut aussi dire que ce n'était pas une question mais une remarque.
« Pour les failles plus complexes, comme celle qui permet de se connecter sous une identité avec une clef SSH valide, même si elle n'est pas légitime, les fuzzers sont-ils efficaces ? »
Effectivement, le fuzzing ne permet pas de trouver ce type de failles. La réponse est évasive, mais globalement, on comprend que c'est compliqué.
Cette présentation aborde des techniques pour exécuter du code malicieux sur Microsoft Windows Mobile de la manière la plus discrète possible, avec du vol d'information comme objectif.
Un smartphone est la combinaison d'un téléphone et d'un PDA. On observe une grosse croissance de ce domaine, ainsi que des autres protocoles de communication.
Certains risques ne sont pas liés à l'OS. Comme il s'agit d'équipement mobile, il y a des risques accrus de perte, vol, et géolocalisation (espionnage).
Pour Symbian, les programmes tiers sont des binaires signés. Une signature valide est une condition indispensable pour l'exécution depuis Symbian OS 9. Il est possible d'obtenir un certificat pour du développement local. Ce certificat est bloqué sur l'IMEI. En fonction du prix du certificat, les fonctionnalités et possibilités sont différentes. Il y a des logiciels malicieux dont certains ont été signés par Nokia, mais ils sont rapidement blacklistés. On trouve aussi des logiciels espions commerciaux.
Dans l'iPhone OS, il y a une séparation des droits et un système de signature. Apple se réserve le droit de refuser une signature ou de la révoquer à tout moment. On trouve aussi le logiciel espion commercial. On peut aussi installer des programmes tiers si l'on est capable de jailbreaker l'appareil. Certaines vulnérabilités existent sur l'appareil, cf. CVE de 2006.
Pour Blackberry, il y a plutôt des failles permettant de remonter au SI de l'entreprise.
Microsoft Windows Mobile est un Windows pour l'embarqué, qui dispose aussi d'un système de signature. Des failles ont été corrigées pour la synchronisation, mais il y existe des virus, chevaux de Troie, et même rootkit kernel. En réalité, il s'agit plutôt de POC. Là encore, on trouve le même logiciel espion, très riche en fonctionnalités mais difficulté à supprimer. La configuration est possible à distance par SMS.
Ce logiciel espion permet de voler des informations, il est multi-plateforme.
En revanche, il n'y a pas de chiffrement pour envoyer les données sur le site de l'éditeur.
Comme dans tout autre Windows, il y a un système d'exécution
automatique lors du branchement d'un support amovible. Pour
l'anecdote, l'auto-exécution a lieu à l'insertion et au retrait d'un
media amovible (autorun.exe).
L'attaque via la synchronisation est possible. C'est d'ailleurs un vecteur très pratique, parce que l'outil de synchronisation est toujours utilisé sur le poste client.
On peut aussi tromper la vigilance d'un utilisateur en exploitant une fonction non documentée pour reconfigurer les niveaux d'interactivité dans l'exécution d'un programme lors de la reconfiguration.
Romain présente un démonstration avec une vidéo qui illustre les différentes phases.
Il y a beaucoup de vecteurs d'échange, mais pas de séparation de privilèges, et le code est portable. C'est souvent vu comme un avantage, mais dans ce cas, ça peut être pénalisant. Beaucoup de code malveillant peut être porté très facilement. L'API est variée, mais les outils système pas très élaborés.
« Quelles version de Windows Mobile ont été utilisées pour les recherches ? »
Les versions 5 et 6 ont été utilisées pour les travaux de recherche. En pratique, assez peu de choses varient. La seule différenciation porte sur la compilation du binaire, mais l'API est identique pour la synchronisation et la configuration.
« Y a t'il des statistiques sur les failles ? »
Il y a peu de failles. L'une est très difficile à exploiter. Une autre est facile à exploiter mais a été corrigée depuis longtemps. Il n'y a pas de statistiques connues sur les corrections appliquées par les utilisateurs.
Dans le cadre de recherche de coupables lors de la diffusion non autorisée de matériel soumis à des clauses de propriété intellectuelle, le traçage de traitres permet de trouver la source de la fuite.
Il faut partir sur des contenus similaires mais avec des subtiles différences.
C'est classiquement le cas par exemple avec la technologie Blu-ray. Le même disque lu dans deux lecteurs Blu-ray différents produira deux contenus différents.
Un axe de recherche qui consomme beaucoup de ressources est la recherche de traitres dans le cas d'une collusion (quand il y a au moins deux traitres). Teddy laisse échapper que ça peut être une chimère.
Comme on envisage la possibilité de mélanger plusieurs copies pour produire un contenu « original » et unique, ou du moins difficile à identifier, il faut envisager les risques sous l'angle de la défense. On pourrait imaginer une victime de collusion désignée à partir d'un identifiant obtenu à partir d'un mélange de deux (ou plus) identifiants de pirates.
Les procédés d'échanges sont le tirage uniforme, le vote majoritaire ou tout à zéro.
Le code anticollusion permet de retrouver les codes originaux.
Pour un adversaire, le brouillage des pistes peut exploiter plusieurs techniques, comme la fusion des blocs, le calcul de moyennes (min, max, médian), le tiling (découpage en morceaux). Le but étant de ne pas retrouver de bit caché. Pour se prémunir de ce type d'attaque, la solution est le marquage numérique.
Cette technique doit pouvoir résister à des dégradations, des recompressions, des post-traitements. Un seul colluder peut le faire. Le danger dans cette technique réside dans une erreur de décodage ou un effacement. Dans ce cas, on ne serait pas capable de retrouver le bit caché. La défense est le tatouage numérique.
Dans l'approche anti-collusion, on trouve de la cryptographie et des statistiques. C'est un problème théorique complexe, et bon nombre de théoriciens s'y sont cassé les dents.
Gabor Tardos a trouvé une solution, avec une aisance déconcertante.
Pour expliquer le problème et envisager des solutions, Teddy se lance dans une explication illustrée avec le jeu de « qui est-ce ? » et le « cluedo ».
Le tatouage numérique consiste à inclure un message dans une vidéo, une image ou un fichier audio.
Ce message n'est pas perceptible (filigrane ou watermark). Il doit être robuste, et on doit pouvoir retrouver le tatouage malgré des dégradations. En cas de dégradation dégradation très importante, ce n'est pas grave si le marquage est altéré.
Il peut s'agir d'un masquage temporel ou fréquentiel (pour l'audio notamment).
Pour gagner en robustesse, on combine les tatouages spatial, temporel, fréquentiel. L'orateur mentionne la technique de l'étalement de spectre.
Quelques démonstrations sont proposées avec l'outil Fantomas développé par l'INRIA. L'outil illustre la robustesse même avec une forte compression sur la vidéo originale.
Il y a juste un plantage avec un message d'erreur à la sortie de l'outil. C'est l'effet démo.
« En cas d'amélioration des techniques de compression, y a t'il un risque de perte d'efficacité ? »
Pas forcément. Les marquages complémentaires n'interagissent pas trop.
Le marquage fonctionne avec un motif de bruit et une clef secrète connue.
Pour l'accusation, il faut s'assurer que la clef est bien associée au contenu. C'est plus facile si le code est long. C'est aussi plus facile de retrouver les colluders s'ils sont peu nombreux.
« Que faire face à un traitre parmi les traitres ? »
Pour la diffusion de VoD, le marquage est à faire à la source. Ça coute cher, mais cette opération doit être réalisée à la volée.
Pour le tatouage dans la transmission par satellite, ce n'est pas pour tout de suite. Le marquage nécessite beaucoup de temps de calcul.
Enfin, plus les colluders sont nombreux, plus les risques d'accuser un innocent à tort sont élevés.
En commençant avec l'exemple du partage d'identifiant et mot de passe, on s'expose à des accès à des données qui ne doivent normalement pas être vues. Quand on parle de vol d'information, on pense aussi à la diffusion à des tiers.
Le « vol » est la soustraction frauduleuse d'une chose d'autrui (ravir : support, et déplacement). Pour les choses assez immatérielles, on peut remonter en 1912 pour un exemple de vol d'énergie électrique.
Il y a une jurisprudence, la difficulté réside dans le passage de la soustraction matérielle à la soustraction juridique. Pour les objets physiques, l'appropriation s'accompagne d'une dépossession.
Dans des affaires de vol d'information, la reconnaissance est venue du contenu informationnel, comme dans un cas de vol de disquette ET d'informations stockées sur ces disquettes.
Il n'y a toujours pas de consécration du délit de « vol d'information ».
Il n'y a par conséquent pas de protection contre le vol mais plus sur la divulgation et le détournement.
La solution réside dans les protections sur le secret :
défense nationale ;
secret professionnel ;
secret de fabrication et espionnage industriel ;
La menace interne est prépondérante : 59% des employés américains dérobent des données en quittant leur ancien employeur (ou du moins reconnaissent le faire), 1 sur 4 a accès au réseau d'entreprise après le départ de ladite entreprise. Il y a une illustration amusante avec avec la poupée « Barbie Hacker ». Elle n'est pas crédible, en fait.
L'information est un bien économique, pas juridique.
Ce n'est pas un hasard s'il y a de nombreux brevet et des marques déposées.
L'information peut aussi prendre des formes différentes, avec des enjeux différents. Pour un investisseur, il s'agira de bases de données, pour un employeur, des logiciels, pour un auteur, des productions intellectuelles.
Il n'y a pas de statut unique pour l'information.
Dans un contrat de travail, il y a une obligation de loyauté, qui impose pour toute la durée du contrat, de ne pas nuire à la réputation et au bon fonctionnement. Il peut aussi y avoir un devoir de réserve.
La politique de classification et de gestion des documents est un moyen de définir les règles d'accès à l'information. Il y a plusieurs niveaux de communication.
Pour les utilisateurs, les chartes, les messages récurrents, et la formation sont incontournables. Il s'agit moins d'être axé sur les règles (listes d'interdits) que d'expliquer les conséquences.
Avec les tiers, la contractualisation est obligatoire.
Il y a eu des décisions divergentes sur le recel d'informations confidentielles. La première difficulté est la détection.
En conclusion, les mots-clefs sont responsabilitation, communication et contrôle.
« Et dans HADOPI ? »
La « loi HADOPI » n'aborde pas vraiment le recel parce qu'il n'est pas couvert dans le code au départ.
On ne parle pas de vol de programmes non plus, mais plutôt de contrefaçon.
La présentation débute avec des exemples sur les publications d'auteurs connus, sur des annonces de sécurité.
La sécurité par la technologie, le papier et l'éducation ne fonctionnent pas.
Une solution acceptable serait l'utilisation de PKI gérée en entreprise.
Il faut aussi envisager d'autres méthodes d'authentification que login/mot de passe.
Dans des réseaux Microsoft il existe aussi des options simples comme NTLM v2 et la signature des mots de passe SMB sur le réseau.
L'idée est d'utiliser la virtualisation pour limiter les actions malveillantes. Par exemple, cela permettrait :
d'empêcher un malware d'entrer dans le noyau ;
protéger le noyau s'il est compromis ;
Le noyau utilise la mémoire de deux manières :
structure du noyau (code) ;
état du noyau (data) ;
Suite à une perte d'intégrité du noyau, les conséquences possibles sont :
rien ;
crash ;
exécution de code malveillant ;
Pour le matériel, l'attention est portée sur le DMA, l'utilisation de l'I/O MMU, et le problème des pilotes malveillants (qui peuvent désactiver l'IOMMU).
La protection des KCO, est assurée par un niveau de privilège matériel supérieur à celui du noyau (sort de ring -1).
Le code sera a priori publié sous licence GNU GPL, mais à voir.
Il y a un système de vérification de l'hyperviseur lui-même, et la protection IOMMU entre autres est implémentée.
Le logiciel n'est pas encore prouvé, mais c'est envisageable, et il n'est pas très gros.
Il s'agit d'un concours de développement d'un OS sécurisé facile à utiliser. Dans l'énoncé, le système d'exploitation est imposé, il s'agit de Linux.
Trois projets sont exposés, qui utilisent tous les trois des approches ou des techniques différentes.
La première solution exposée utilise Linux et VServer. Elle permet d'assurer une étanchéité entre les différentes applications. Il n'y a pas de réelle démonstration, seulement une présentation. Le système implémente aussi GRSecurity.
La deuxième solution présentée est à base de Xen. Le Dom0 ne fait pas tourner de serveur X. C'est un DomU qui prend en charge cette fonctionnalité. La question des mises à jour n'est pas encore résolue.
La troisième solution est à base de SELinux + LXCE. Par rapport aux autres solutions présentées, la démonstration est live. Un visiteur demande à produire un script et l'exécuter, ce qui s'avère possible en spécifiant l'emplacement de l'interpréteur. Cette découverte fait beaucoup de bruit, mais dans la vraie vie, il ne sortirait pas grand chose d'une telle « faille ».
Parmi les nombreuses présentations, j'ai relevé les suivantes. Pour les autres, ce n'est pas pour des raisons qualitatives, c'est juste qu'il était tard, que le cocktail et le social event s'annonçaient. N'en prenez pas ombrage, messieurs les orateurs.
micro espions ;
projet IMA obtenir des infos sur la qualité des mots de passe Windows ;
objectifs dans la vie (objectif-tactique) ;
éthylomètre sur port USB, un pong en OpenGL pilotable par le capteur, un module PAM et hook de precommit pour Subversion ;
Les supports des rumps sont consultables sur le site des actes : http://actes.sstic.org/SSTIC09/Rump2009/
Cette présentation, richement illustrée, était un vrai régal.
Pour commencer, Pierre rappelle que les attaques CSS ont gravi les échelons dans les centres d'alerte pour atteindre en quelques années la première place.
En XSS (Cross-Site Scripting), les attaques peuvent être volatiles ou persistantes. Pour le second cas, le script est téléchargé depuis un autre site.
L'orateur rappelle le principe, et mentionne quelques exemples mettant en cause plusieurs sites largement utilisés.
Les attributs script: et data: sont passés en revue. Les exemples sont spectaculaires, surtout quand on envisage l'ampleur des attaques possibles.
Pour un site vulnérable, il y avait un avertissement comme « les
balises script ne sont pas autorisées ». Comme le souligne
Pierre : c'est la sécurité par « ne le faites pas ». ;)
Le danger dans ce type d'attaque, c'est la conjonction des sites vulnérables, plus l'utilisation de plus en plus massive des réseaux sociaux, et le nombreux croissant d'utilisateurs.
Cette présentation expose les failles de sécurité de deux visualiseurs de documents PDF disponibles sous Microsoft Windows.
Si beaucoup de choses sont scriptables en Javascript, dans Adobe Reader, par exemple, la machine Javascript ne fait que reprendre pratiquement tout ce qui est déjà faisable en PDF. Pourtant, le moteur Javascript est le seul désactivable.
La taille de l'application est aussi un signe du potentiel de vulnérabilité.
Parmi les révélations surprenantes :
La clef privée utilisée pour le chiffrement des documents est copiée dans le profil de chaque utilisateur lors de la première utilisation ;
Cette clef est cassable en force brute ;
Il est possible de fabriquer des faux-vrais documents signés de l'éditeur ;
Il est possible d'exécuter un programme externe arbitraire depuis un document PDF, de manière très simple ;
Bref, un document PDF n'est pas qu'un fichier inerte ou inoffensif.
Philippe PRADOS présente une backdoor qui est disponible sous la forme d'une archive jar intégrable dans une application J2EE. Le nom vient juste de la pâtisserie qu'il apprécie.
En plus de cette porte dérobée, la suite Macaron regroupe des outils complémentaires d'audit, de scellement et de définition de politique. La définition de politique est d'ailleurs à peu près la seule solution fiable de protection, en combinaison avec le scellement, mais c'est loin d'être trivial à mettre en ½uvre.
La démonstration d'intégration du jar, du déploiement et son exploitation est spectaculaire.
Parmi les fonctionnalités de la porte dérobée, on a l'exploration et la modification des ressources JMX, JDBC, JNDI, et un interpréteur de commandes. Ce dernier n'est pas très rapide, mais pleinement fonctionnel.
C'est typiquement le genre d'outils que l'on aimerait avoir sous la main quand on administre un serveur d'applications
La mystification de prise d'empreinte consiste à présenter à un adversaire l'apparence d'un autre système que celui ou ceux qui sont réellement en ½uvre. Plusieurs techniques sont possibles : du filtrage simple, de la modification de pile réseau et enfin de la substitution de pile réseau.
La dernière approche est celle qui est utilisée dans IpMorph. Cet outil se comporte comme un serveur mandataire mais au niveau liaison et réseau.
Après avoir réimplémenté en espace utilisateur une pile IP, cette pile a été enrichie et réutilisée pour permettre de singer le comportement de nombreux systèmes. Par exemple, pour un système Microsoft Windows XP, il est tout à fait possible pour une charge de trafic réel de berner un outil de prise d'empreinte en lui présentant ce qui ressemble à une signature d'OpenBSD 4.
La prise d'empreinte en mode actif (nmap, etc.) ou passif (Ettercap, p0f, etc.) est à chaque fois bernée par IpMorph, pour tous les outils essayés (nmap, SinFP, p0f, Xprobe2, Ring2, Ettercap).
La présentation à l'écran était aussi spectaculaire. À ce niveau de maîtrise du logiciel de présentation, on n'a plus rien à prouver. C'était ludique et didactique, tout en restant terriblement efficace.
Kolumbo permet de réaliser l'analyse dynamique d'un processus en espace noyau. L'objectif est la détection de malware. Un processus peut détecter assez facilement qu'il est « observé ».
ptrace est utilisé en espace utilisateur pour analyser des
processus. Un seul processus peut être attaché à un autre. La
détection est très simple ;
La détection de points d'arrêt. Sous Linux on utilise l'int3. Il
faut donc rechercher dans le code cette interruption. On peut
aussi calculer une somme de contrôle de la page pour vérifier si
elle a été modifiée ;
int3 correspond au signal SIGTRAP. On peut aussi détecter ce
signal et agir en fonction ;
Sans trop de difficultés, pour ces techniques, un processus peut savoir s'il est observé, et adapter son comportement.
Les fonctionnalités de Kolumbo :
Le mode trace fournit un équivalent à strace et permet
d'afficher des appels systèmes, les registres et la page des
tables et suivi des fils. Pour l'exécution d'un appel système,
il y a une interruption logicielle. Le numéro de l'appel est
dans eax, des paramètres sont passés, l'interruption 0x80 est
levée, et l'appel est traité. Toute l'astuce consiste à
interrompre l'int80 (idtr). Ce mode permet de suivre les
processus fils créés à l'aide de fork, vfork et clone. Au
démarrage, il suffit de charger le module, et de configurer
quelques entrées dans /proc/sys/debug. Les messages sont
affichés dans dmesg, sans que le processus ne détecte une trace.
En l'occurence, il n'y a pas d'appel à ptrace.
Le mode dump est utilisable pour un programme simple. Ce mode permet de récupérer tous les segments d'un processus. On peut alors produire un programme qui pourra même être exécuté normalement. Ceci est vrai mais sous quelques conditions. D'abord, le programme produit n'est pas un binaire ELF valide. Et pour un programme chiffré, l'exécution n'est pas possible en l'état. En fait, on obtient bien un exécutable dans ce cas, mais qui fait n'importe quoi.
Le mode anti-anti-trace est utilisé pour lutter contre les malwares qui détectent les systèmes de détection. Ce mode doit donc être invisible pour les programmes.
La démonstration sur les exemples utilisés en début de présentation montre que le code de retour de l'appel ptrace ne laisse pas entendre que le processus est tracé.
Cette présentation aborde l'utilisation des GPGPU pour calculer autre chose que du graphique, et notamment l'exploitation de cette ressource pour des calculs cryptographiques. Pour grossir le trait, on pourrait parler d'utilisation des cartes graphiques comme accélérateurs cryptographiques.
Les cartes spécialisées accélératrices de cryptographiques sont chères et compliquées à gérer, surtout pour les aspects d'évolutivité.
Les cartes graphiques évoluées quant à elles disposent de langages optimisés pour manipuler des objets graphiques, mais ne sont évidemment pas généralistes. Les premières implémentations d'AES par exemple étaient fonctionnelles mais pas très performantes.
En reprenant des statistiques de 2007, on observe un facteur 16 entre les performances de calcul sur un CPU et sur un GPU. Les transferts prennent beaucoup de temps.
C'est donc facile pour les calculs à clefs secrètes, mais il n'y a pas de parallélisme évident sur la cryptographie à clef publique. Au mieux, on peut obtenir des gains de 20 à 30% sur GPU pour RSA/DSA, ce qui est bien, mais pas très intéressant.
Pour la cryptanalyse, sur des problématiques de recherche exhaustive, avec une architecture massivement parallèle, ce n'est pas très intéressant, mais très efficace, aussi parce qu'il y a peu de transfert de données.
Il reste aussi le problème de la consommation électrique. Par exemple, pour celui qui voudrait remplir une salle avec des cartes graphiques.
Parenthèse hardcore mathematics : le cas des courbes elliptiques et la forme d'Edward s'appliquent très bien sur cette architecture (parallélisme de type SIMD) dans la méthode ECM. L'algèbre linéaire est intéressant aussi.
La démonstration qui suit part d'un produit de matrices. En première approche, on a une écriture grossière avec des calculs sur des entiers. Une première étape de réécriture en compactant les valeurs apporte une première optimisation, du moins dans l'écriture, mais pas de réelle amélioration des performances. Une seconde phase d'optimisation consiste à réécrire le produit en exploitant le parallélisme interne (32 opérations/mot). Enfin, avec une optimisation finale, la technique du repliement permet de réaliser 5 opérations par mot.
C'est l'occasion de voir en vrai un programme écrit en C remanié puis réécrit totalement pour utiliser CUDA. Cette bibliothèque permet très facilement de transformer un programme classique en programme exécutable sur un GPU. C'est évidemment intéressant quand on utilise un programme déjà parallélisé, mais aussi si on dispose de plusieurs cartes. Il n'y a pas de différence, si ce n'est de configuration, entre un programme qui s'exécute sur une carte ou sur 3. Ça rappelle les fermes de consoles PS3, robustes, qui ne craignent pas d'être empilées.
Petite parenthèse GNU : en comparant les performances de cette opération dans les différentes implémentations, l'orateur a réalisé qu'il y avait un saut de performances entre GCC 4.2 et 4.3.3. C'est juste que l'optimisation MMX a été prise en compte quelque part entre ces deux versions.
Pour l'utilisation des cartes graphiques dans le domaine de la sécurité, les applications les plus évidentes sont le cassage des mots de passe et la recherche virus. La recherche serait plus « fiable » et « discrète » parce que la recherche de signature serait cachée en n'utilisant pas la même zone de mémoire.
Pour le futur, on peut imaginer des cartes de plus en plus intelligentes. Jusqu'à présent, le CPU initie les transferts, mais il est possible d'avoir des zones de mémoire partagée. Les questions à se poser viennent des transferts initiés par le GPU.
Deux questions sont posées. Une première concerne le dimensionnement, une seconde concerne la synchronisation prévue dans le GPU, qui est désormais beaucoup plus facile. Il y a un appel système pour resynchroniser.
Cette présentation, qui aborde principalement le problème des émanations électromagnétiques des claviers PS2 ouvre des pistes de réflexions plus large sur les autres périphériques du même type.
Pour commencer, un historique mis en scène joliment dans une présentation très stylée rappelle les problèmes liés aux émanations sonores, visuelle, et aux vibrations.
1899 : avec les lignes téléphoniques non torsadées, les usagers constatent ce qu'on appelle le crosstallk, c'est à dire qu'on entend une conversation d'autres interlocuteurs ;
1924 : le phénomène de boucle d'induction dans les tranchées, un seul fil et une pique dans la terre pour la masse ;
1944 : sur une machine de chiffrement les émanations étaient perceptibles à plus de 25 mètres, et permettaient une récupération de plus de 75% du texte clair ;
L'orateur présente le mode opératoire, explique la capture d'un jeu de données à l'aide d'une antenne (chère), d'un oscillateur et pour la capture et l'interprétation, c'est un Mac qui a fait l'affaire.
Le point à retenir, en particulier sur les clavier PS2, qui utilisent une tension de 15V, c'est surtout qu'ils utilisent chacun une fréquence caractéristique, qui permet d'isoler et identifier un clavier d'un modèle et d'un constructeur spécifique même dans un environnement où plusieurs claviers sont utilisés simultanément. La difficulté reste toujours de trouver le moment où déclencher la capture.
Dans les exemples amusants, l'orateur explique qu'ils ont tenté des expérimentations de ce type dans la vraie vie, entre plusieurs étages du même bâtiment. Dans ce cas, les captures sont presque plus nettes qu'en chambre semi-anéchoïque grâce à toutes les canalisations, même du sous-sol au cinquième étage. En revanche, d'un bâtiment à un autre, le risque de se faire vider par la gardienne n'est pas nul.
Toute la difficulté dans la vraie vie est donc d'identifier le déclencheur. Pour la capture de l'émanation électromagnétique, la portée est de 20 mètres au mieux avec la matériel à la disposition de l'équipe.
La démonstration consiste en une vidéo, qui présente l'équipement de capture dans un bureau, puis une saisie en aveugle dans un autre bureau, et l'affichage de ce qui a été saisi en clair sur le moniteur du Mac dans le premier bureau.
Ce qui est annoncé ici pour des clavier filaires peut aussi être extrapolé aux claviers sans fil. Cependant, en raison d'un accord contracté avec la conférence Usenix, il n'y aura pas de révélation au SSTIC.
« Est-ce possible de détecter les micros espions ? »
C'est possible aussi. Il y a une anecdote avec les détections par injonction linéaire. C'est vraiment risqué, tous les opérateurs qui s'y sont frotté sont morts. De fortes puissances à fréquence de micro-ondes sont utilisées. En gros, l'espérance de vie est d'un an.
« Est-ce plus difficile de capter les émanations électro-magnétiques des ordinateurs portables ? »
En théorie, c'est plus difficile, parce que les claviers des ordinateurs portables sont supposés utiliser la norme USB, mais à y regarder de plus près, pour des raisons de cout, un grand nombre de constructeurs continuent de livrer des claviers PS2 dans les ordinateurs portables. La différence la plupart du temps, c'est la taille du câble.
« Pour les petits appareils, y a-t'il des résultats ? »
L'équipe a mené des essais sur les bancomats. Et il y a des résultats. Mais il n'y a pas le droit de les diffuser. De vagues essais ont été menés sur des vieux téléphones, mais aucune stratégie n'a été élaborée pour le moment.
Cette présentation insiste sur le maillon humain. Le sujet est traité très différemment de ce que l'on a pu entendre jusqu'à présent.
Son analyse sociétale, étayée par une impressionnante bibliographie, l'engage à soutenir et encourager la résistance humaine, sans trop charger la barque.
À ses yeux, l'information, la formation est une hérésie. Ce message va d'une certaine manière à l'encontre de ce qui a été affirmé pendant le reste de la conférence.
Et pour illustrer ce propos, il insiste sur la délégation de sécurité que nous accordons tous à titre personnel pour tous les équipements, qu'il s'agisse de téléphone, de connexion à un réseau public, etc. Ceci est vrai pour deux raisons au moins :
Nous n'avons à titre individuel pas de besoin particulier de sécurité sauf pour des usages particuliers ;
Nous avons globalement confiance dans l'opérateur, l'exploitant d'un service, et c'est justement sur la confiance que se basent la plupart des relations en société ;
Il faut être clair, l'orateur souhaite provoquer la réaction des auditeurs, à travers le contenu de sa présentation, mais aussi par la forme, en appelant un auditeur pour lui demander de lire la devise nationale écrite en arabe, tout en insistant pour l'égalité sur l'Homme.
Il y a eu plusieurs questions et commentaires, mais je ne reprends ici que l'un d'entre eux.
« Concernant l'intrusion dans la sphère privée, notamment avec les téléchargements de pair à pair, des solutions techniques existent pour cacher du trafic. »
Il est effectivement possible de chiffrer du trafic, et l'orateur soutient la technique de deep packet inspection qui est la seule à même d'aider des enquêteurs à identifier des crimes et délits.
Par ailleurs, en cas de crime ou délit avéré, le chiffrement pour empêcher l'accès à des informations sur la nature des infractions est une circonstance aggravante.
Le symposium est un endroit très intéressant pour apprendre plein de choses. Ce n'est pas l'endroit idéal pour faire des rencontres, même au milieu de 420 personnes motivées.
Si certains orateurs mettent l'accent sur la compétence à tout crin, en avançant la formation et la sensibilisation comme seule solution aux risques de sécurité, la réalité est évidemment bien plus complexe, et la clef réside dans l'humain et les liens sociaux.
» Les actes du symposium - http://actes.sstic.org/SSTIC09/
» Les rumps - http://actes.sstic.org/SSTIC09/Rump2009/
![[IE7, par Dean Edwards]](/images/ie7.gif)
![[Validation du HTML]](/images/xhtml.gif)
![[Validation du CSS]](/images/css.gif)
Copyright © Les Mongueurs de Perl, 2001-2011
pour le site.
Les auteurs conservent le copyright de leurs articles.