Antoine Cervoise

Fuzzing intelligent de XSS type 2 filtrés selon Darwin : KameleonFuzz

Fabien Duchène, Sanjay Rawat, Jean-Luc Richier, Roland Groz

Seul Fabien Duchène a présenté l’outil d’analyse de vulnérabilités d’applications Web de type XSS.

Il est composé de deux parties : l’inférence de modèle et la génération automatique d’entrées malveillantes (appelé « fuzzing évolutionniste »).

Conscient de la difficulté des outils disponibles sur le marché à détecter efficacement des vulnérabilités XSS de type 2 (persistant), les auteurs se sont appliqués à développer un outil plus performant. En effet, selon les auteurs, les meilleurs outils détectent 40% des XSS de type 2, la plupart des autres outils, 20% et un tiers n’en détecte aucune. L’outil analyse et détecte également les XSS de type 1 (réfléchi).

La première partie de l’outil apprend de manière automatique un modèle formel du système audité en produisant un automate à état fini étendu.  Ce modèle est appris par des envois successifs d’entrées (requêtes HTTP) et analyse des sorties correspondantes, repérées par d’inférence de teinte.

La deuxième partie de l’outil prend en entrée l’automate généré précédemment par la première partie de l’outil sur lequel les réflexions (retours) potentielles sont annotées. Les valeurs des paramètres fuzzés sont générées grâce à une grammaire d’attaques puis elles évoluent grâce à un algorithme génétique. De multiples traitements sont effectués sur ces entrées  pour leur donner des scores. Les entrées ayant les meilleurs scores seront recombinées par des opérations de mutation et de recombinaison par croisement respectant la grammaire d’attaques. Ce processus prend fin quand les conditions d’arrêt imposées par l’utilisateur sont atteintes (exemple : 4 XSS découverts).

L’outil a été testé sur cinq applications Web  et comparé à quatre scanners XSS du marché. Il se révèle plus performant dans la découverte de XSS que tous les autres outils testés.

Une fois la présentation terminée, l’orateur poursuit par une démonstration de son outil.

Finger printing de navigateurs

Alain Ribault, Erwan Abgrall, Mario Heiderich, Martin Monperrus, Sylvain Gombault, Yves Le Traon

Erwan Abgrall , doctorant à Telecom Bretagne, aborde le finger printing de navigateurs par l’approche des attaques XSS.

Ce finger printing du navigateur présente deux usages :

• Accès à des informations privées (identifier un utilisateur, collecter des informations sur ses paramètres de configuration…). Cette approche est déjà suivie par le programme Panopticlick de l’EFF, des études sont en cours à l’INRIA. De plus, compte tenu de la faible valeur accordée par les utilisateurs à leurs informations privées, cette piste a été volontairement mise de côté par Erwan Abgrall pour se concentrer uniquement sur la seconde ;
• Identification du navigateur afin de lancer des attaques ciblées. De fait, le lancement d’une attaque ciblée, par l’esquive des machines d’audit ou antivirales, permet de limiter les capacités de détection de la victime.

Quelques techniques spécifiques à certains navigateurs sont présentées, telles que la détection d’un plugin Fiddler installé dans Google Chrome (fréquemment utilisé par certains analystes pour visualiser la sortie du navigateur), les tests de user-agents en JavaScript ou la compilation conditionnelle sous Internet Explorer via des astuces bien connues des développeurs Web.

Cette revue des techniques utilisées permet de constater que les techniques académiques restent aujourd’hui en avance sur celles effectivement exploitées dans des exploit kits.

On entre dans le vif du sujet après une présentation de quelques techniques académiques.

L’approche retenue pour la méthode de finger printing présentée repose sur des vecteurs XSS dont l’exécution est conditionnée par la capacité du navigateur à comprendre une portion de HTML donnée. Elle présente l’avantage d’être aisément testable depuis un serveur et automatisable, tout en se basant sur des vecteurs XSS disponibles en grandes quantités.

L’exécution de ces vecteurs XSS dans divers contextes, influençant le comportement du navigateur, permet de construire une signature pour chaque navigateur.

L’identification des signatures par arbre de décision a rapidement été abandonnée au profit d’une mesure de distances de Hamming afin de rendre le framework plus résilient face aux mises à jour fréquentes des navigateurs.

Ce framework permet, dans certains cas, de disposer d’un niveau de détail de l’ordre de la sous-version.

Le code est disponible et hébergé sur GitHub.

Duqu contre Duqu

Aurélien Thierry

Aurélien Thierry effectue actuellement une thèse en sécurité informatique à l’INRIA (Institut National de Recherche en Informatique et en Automatique).

Duqu est un ver informatique découvert en 2011 par CrySyS Lab. Il est présumé lié à Stuxnet car il possède des fonctionnalités et du code partagés.

Il fonctionne de la manière suivante : un dropper (ici, un fichier Word) est téléchargé sur la machine cible (par mail le plus souvent), une fois celui-ci lancé il exploite une faille noyau en rapport avec les polices TrueType dans win32K.sys. Cela lui permet d’écrire des fichiers chiffrés sur le disque et d’installer un pilote. Seul le pilote est présent déchiffré sur le disque. Ce pilote vérifie quels modules sont exécutés et déchiffre les DLL correspondantes pour lancer les charges.

Aurélien Thierry développe un outil de détection de malwares, celui-ci serait-t-il capable de détecter la DLL principale de Duqu ou même de déjouer une attaque en temps réel ?

Pour cela, il faudrait surveiller les processus lancés et intercepter la DLL déchiffrée au moment de l’injection. Or il existe un programme qui réalise ce genre d’opérations et c’est précisément le pilote Duqu. L’idée lui est donc venue de réutiliser le pilote à des vues défensives.

Pour cela, il a utilisé IDA et son module de décompilation, effectué l’identification des constantes, des structures Windows et des structures propres au pilote (PEData). Il ne restait plus qu’à trouver les conventions d’appel manquantes et les diverses options de compilation. Une fois le code récupéré, le C++ et l’ASM sont à analyser.

Ce code lui a appris beaucoup d’informations intéressantes: ce pilote est de type réseau, il est lancé avant la HAL (couche d’abstraction matérielle), puis le pilote détecte si l’OS est en mode debug, et une fois actif, il met en place des fonctionnalités de type rootkit en injectant la DLL dans services.exe. Une notification est émise lorsqu’un module est chargé en mémoire.

C’est cette fonctionnalité de notification qui a été réutilisée. Ainsi, une notification sera émise dans le pilote défensif lorsque l’injection aura lieu dans services.exe par le pilote Duqu.

Une démonstration a été faite, les deux pilotes étaient présents sur la machine : le pilote défensif intervient avant le pilote Duqu pour détecter les notifications d’injection et ainsi empêcher l’attaque.

Le TEE, nouvelle ligne de défense dans les mobiles (conférence invitée)

Hervé Sibert

L’orateur est responsable sécurité produits chez ST-Ericsson.

Le Trusted Execution Environment est un environnement de sécurité qui commence à être déployé sur les smartphones, particulièrement sur les processeurs ARM.

Entre 1990 et 2007, les fonctions de sécurité étaient implémentées dans la couche software du téléphone. Depuis 2007, certaines fonctions sensibles font appel à une implémentation hardware de composantes de sécurité (« trusted root », générations de clés cryptographiques…).

Les OS mobiles étant de plus en plus ouverts (sic), les fonctionnalités sensibles sont déportées dans le TEE, bien que leur gestion demeure externe. Le TEE est donc le seul à avoir accès aux fonctionnalités de sécurité de la plateforme.

Le séquencement des fonctions sensibles reste en environnement d’exécution standard alors que les fonctions en elles-mêmes sont déportées vers le TEE.

Les fonctionnalités du TEE sont dédiées à la gestion des fonctions sensibles du code dont l’exécution dans l’OS standard exposerait le système à des attaques. Il gère aussi le contrôle de la sécurité du boot (stockage et canaux sécurisés).

La fonctionnalité principale du TEE correspond à l’isolation du code et des données, la protection des clés sur lesquelles reposent les fonctions de sécurité et l’isolation entre les différentes applications du TEE.

L’initiative Global Platform est à l’origine d’un ensemble de spécifications d’interfaces standards afin d’encourager le développement logiciel en TEE et simplifier la migration.

Le TEE est supporté depuis ARM76 et permet de disposer de deux processeurs virtuels sur un même cœur (un état normal et un mode sécurisé). Un bit NS permet d’identifier et propager la TrustZone vers la cible des accès afin de s’assurer qu’une donnée sécurisée ne soit accessible par un composant REE et inversement.

Un mode moniteur peut être invoqué via Secure Monitor Call afin d’héberger le code nécessaire à la transition d’un mode à l’autre, chaque mode disposant de ses propres instances MMU.

Le TEE nécessite une racine de confiance matérielle. Pour cela, un ROM boot est chargé de faire une initialisation de la plateforme en mode sécurisé en s’exécutant sur la « RAM-on-chip ».

Les méthodes de signature et l’implémentation des fonctionnalités de sécurité dans un environnement isolé et sécurisé sont des fonctionnalités disponibles sur la quasi-totalité des smartphones, mais restent assez peu déployées sur le marché.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/conf_invit1_j3_2013/.

La réponse aux incidents ou quelques recommandations pratiques pour les auteurs de malwares (conférence invitée)

Alexandre Dulaunoy

La dernière conférence du vendredi matin est réalisée par Alexandre Dulaunoy, chercheur sécurité au CIRCL (Computer Incident Response Center Luxembourg), le CERT National du Luxembourg. Sur 2012, ce CERT a traité plus de 10 000 événements de sécurité et réalisé plus de 400 investigations techniques.

La conférence s’articule autour des auteurs de malwares et des bonnes pratiques de développement qu’ils devraient adopter. En effet, comme le signale Alexandre, dans un CERT, on voit de tout : des malwares amusants, originaux ou parfois ennuyeux à analyser. À force, on les compare et l’envie vient d’effectuer des recommandations pour les auteurs de malwares.

Un logiciel malveillant reste un logiciel, il y a tout naturellement une tendance qui se dessine pour leurs auteurs : créer de nouvelles fonctionnalités.

La première préconisation est donc « Keep it Simple ! ». Comme dans tout, les premières réalisations ressemblent à du bricolage puis on avance, on épure afin de rendre l’outil plus propre. C’est aussi valable pour les produits de piratage, les skimmers en sont de parfaits exemples.

Pour commencer, Alexandre présente les différentes méthodes pour signer son code. Il existe plus de 600 autorités et plusieurs méthodes sont à la disposition des auteurs de malwares pour signer leur code :

• Voler la partie privée du certificat et émettre de faux certificats valables ;
• Acheter un certificat volé ;
• Faire une demande de signature.

Par ailleurs, le dernier cas est possible si la création de votre logiciel malveillant à des intérêts économiques ou politiques, ou encore si l’autorité ne fait pas de vérifications poussées.

Une autre option consiste à utiliser des failles dans des binaires déjà signés : une application signée charge un programme normal qui charge ensuite le malware. Il existe environ 900 DLL permettant cela sous Windows.

Plusieurs préconisations au niveau des usages du réseau par un malware :

• Évitez de mettre des mots de passe et des clés par défaut, cela compliquera la tâche des équipes de recherche ;
• Utilisez le port 53 (DNS) pour exfiltrer de l’information. C’est une bonne idée, cependant, si les paquets émis ne ressemblent pas à du DNS, ils sont visibles dans les logs (cas de sshd library rootkit) ;
• Si vous utilisez HTTP, évitez que ce soit le client qui envoie une page HTML au serveur (Fakem RAT) ;
• Ajoutez de la latence entre les requêtes afin que ce soit crédible ;
• Comme il a été signalé par Nicolas Brulez lors de son retour sur Red October, évitez de faire une faute de frappe lors de l’enregistrement du nom de domaine de votre botnet ;
• Lorsque vous enregistrez le domaine, préférez une adresse email anonyme plutôt que votre adresse personnelle ;
• Utilisez des user-agents crédibles ;
• N’utilisez pas l’adresse IP de votre connexion personnelle (cas d’URL utilisée pour exfiltrer de l’information : http://<IP>:1001/c.php?botnet=<victim_name>).

Au niveau de l’utilisation sur le système, il est judicieux de préférer un stockage en mémoire plutôt que sur le disque. L’utilisation de logins par défaut est bien évidemment à bannir.

Il peut aussi être intéressant de détecter si le malware se lance au sein d’une machine virtuelle, comme par exemple en regardant s’il y a des actions de la souris, du clavier, en tentant d’imprimer une page de test ou en analysant le nombre d’événements dans Word.

Le conférencier termine par un peu de publicité pour la conférence Hack.lu, vous trouverez plus d’informations sur cette conférence sur ce site : http://2013.hack.lu.

Présentation courtes

Détection comportementale de malwares P2P par analyse réseau

Xiao Han

Cette présentation de Xiao Han d’Orange Labs, traite de la détection comportementale des malwares peer-to-peer par analyse réseau.

Plusieurs malwares récents basent leurs communications sur des protocoles peer-to-peer. On notera entre autres ZeroAccess sur Kademlia ou Storm sur Overnet.

Ces communications sont difficiles à détecter puisqu’elles dépendent d’une architecture décentralisée (il est donc impossible de bloquer un nom de domaine de C&C). De plus, le trafic étant souvent chiffré, il est impossible d’établir des signatures de détection.

Ces constatations mènent à une approche comportementale de la détection.

Ainsi, une méthode automatisée est utilisée pour générer les footprints des communications sur un ensemble d’éléments caractérisant le trafic P2P (nombreux échecs de connexion vers des nœuds non connectés, absence de requête DNS avant l’établissement de la connexion…).

Cette méthode a permis, sur divers échantillons de malwares P2P, de les détecter avec un taux de faux positifs de 0.14%.

L’apprentissage automatique des profils à détecter est une implémentation du modèle Support Vector Machine qui a permis, via l’analyse de la périodicité des flux, du nombre de paquets envoyés et d’autres composantes, d’aboutir à un taux de détection de 97.2% sur les échantillons de malwares étudiés.

Le point de blocage majeur semble résider dans la capacité de séparer les flux P2P licites et illicites. Ceux-ci faisant partie des flux à risque devant être identifiés et monitorés en entreprise, la viabilité de l’approche ne semble pas remise en cause.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/2013_short_han/.

Attestation distante d’intégrité sous Android

Dimitri Kirchner

Pour cette deuxième présentation courte, Dimitri Kirchner aborde le sujet de l’informatique de confiance par l’attestation distante d’intégrité sous Android.

Après avoir laissé son ordinateur dans sa chambre d’hôtel lors d’un séjour et suite au passage d’une « Evil Maid », Dimitri d’interroge sur la possibilité d’utiliser son smartphone, toujours dans sa poche, comme racine de confiance lui permettant de savoir si des actions malveillantes ont été commises sur sa machine.

Le processus se déroule en trois étapes :

• L’utilisateur connecte son smartphone à l’ordinateur ;
• Le smartphone vérifie l’intégrité de l’ordinateur ;
• L’utilisateur décide de poursuivre ou pas, le démarrage de sa machine.

Cette vérification repose sur l’utilisation de la puce TPM de sa machine qui sert à certaines fonctions cryptographiques, au stockage sécurisé ainsi qu’à la vérification de la chaîne de démarrage de la machine.

L’analyse de conformité se déroule en deux phases :

• Phase amont, au déploiement, obtention de la signature de la chaine de démarrage considérée comme intègre et récupération de la clé publique de la puce TPM permettant de s’assurer que les données transmises ne soient pas forgées ;
• Phase de vérification, à l’utilisation, le téléphone demande à vérifier l’intégrité de l’ordinateur, l’ordinateur renvoie la valeur de sa chaîne PCR chiffrée vers le téléphone.

L’implémentation retenue se base sur OpenPTS, fondée sur un vérifieur en Java, aisément portable vers Android, et un transfert des données via SSH, utilisable via la connexion USB entre le téléphone et l’ordinateur.

Le code de ce PoC devrait être bientôt disponible sur GitHub.

Le rôle des hébergeurs dans la détection de sites web compromis

Davide Canali

Davide Canali d’Eurecom, conclut ce cycle de présentations courtes en étudiant le rôle des hébergeurs dans la détection de sites Web compromis.

Les hébergements mutualisés servent aujourd’hui majoritairement à des utilisateurs qui ne sont pas sensibilisés aux problématiques de sécurité (particuliers et petites entreprises) ou à des power-users n’ayant de toute façon ni contrôle, ni visibilité sur la configuration. En résulte une grande surface d’attaque potentielle, face à laquelle les hébergeurs devraient jouer un rôle plus important dans l’assistance à leurs clients en cas d’attaques.

Plusieurs abonnements à des fournisseurs d’hébergements mutualisés ont donc été souscrits afin d’étudier leur capacité à détecter et à répondre à une faille de sécurité.

Sur ces hébergements, ont été installées diverses applications volontairement vulnérables afin de réaliser différents scénarios d’intrusion.

La première phase a consisté à compromettre de manière répétée des applications Web hébergées et à attendre une réaction de la part des hébergeurs (soit durant 25 jours).

Une deuxième phase, de 5 jours cette fois-ci, a consisté à déposer des plaintes auprès du fournisseur de service (certaines plaintes valides, d’autres inventées).

Ces tests ont concerné un total de 22 hébergeurs, 12 de niveau mondial, 10 régionaux, répartis dans le monde entier.

Les résultats sont inquiétants puisque si les hébergeurs font leur possible pour dissuader les inscriptions frauduleuses, peu de mesures sont prises pour garantir la sécurité des services hébergés.

De fait, un seul hébergeur sur les 22 a détecté un cas de compromission, 17 jours après sa première occurrence et n’en a informé l’utilisateur que par le biais de son interface d’administration.

La moitié des hébergeurs n’a simplement pas répondu aux plaintes et ceux qui l’ont fait semblent, pour la majorité, l’avoir fait rapidement (en moins d’une journée).

Pire, certaines plaintes ont été traitées sans vérification puisque des plaintes fictives ont par la suite été reprochées au client du service.

Chez les hébergeurs testés dans cette étude, rien ne semble être fait pour détecter des signes évidents de compromission et les plaintes des utilisateurs (du service d’hébergement ou de l’application Web) sont traitées, au mieux, de façon expéditive et inadaptée.

Conférence de clôture : faire face aux cyber-menaces => détecter (les attaques) et former (des experts en SSI) – conférence invitée

Ludovic Mé

Ludovic Mé est enseignant-chercheur à Supélec, il a une expérience de plus de 20 ans de recherche dans le domaine de la sécurité informatique et plus particulièrement dans la détection d’intrusion.

Il se base sur le Livre blanc sur la défense et sécurité nationale 2013 pour introduire son propos.

Le constat est que les cyber-attaques constituent des menaces majeures à forte probabilité. Une fois ce constat posé, il devient évident qu’il faut faire quelque chose. En effet, toutes les organisations, gouvernementales comme privées, subissent des attaques informatiques sur une base quotidienne. Aujourd’hui, ces attaques semblent avoir comme objectif la prise d’empreintes et la récupération d’informations afin de les exploiter ultérieurement. Des attaques de grandes envergures se préparent donc.

Même s’il ne faut pas être alarmiste, il convient tout de même d’être capable de se protéger contre ces attaques, tout comme pour des attaques armées. Cette protection repose sur une forte capacité de détection des attaques et d’identification de leurs auteurs.

Le Livre blanc suggère donc la mise en place d’une « posture robuste et résiliente de détection », ce que l’orateur comprend comme une volonté d’être capable, au niveau national et/ou européen, de produire de manière autonome des dispositifs de détection. À sa connaissance, c’est la première fois que l’on met les systèmes de détection au même niveau que la cryptographie.

Il mentionne également d’autres points importants du Livre blanc tels que la capacité de réponse, la sensibilisation/formation, les moyens opérationnels (standards industriels, audit, réserve opérationnelle spécialisé, etc.), la riposte (point hautement sensible) et la capacité offensive.

Au vu de l’importance de tous ces items, Ludovic Mé souhaite s’attarder sur deux points qu’il connaît très bien : la détection et la formation.

La détection

Aujourd’hui, la détection est réalisée de manière ultra-classique : on capte, on analyse et on envoie des alertes.  Certains positionnent éventuellement des mécanismes de corrélations, et enfin essaient de réagir (patchs, corrections, etc.).

Les IDS (Intrusion Detection System) émettent des alertes évaluées suivant deux propriétés :

• Leur fiabilité : pas de faux négatifs ;
• Leur pertinence : pas de faux positifs.

Dans la réalité, l’idéal ne semble pas atteignable. Les faux négatifs et positifs sont incontournables, même dans le cas de systèmes comportementaux. Cependant, comment peut-on faire pour s’en rapprocher ?

L’administrateur de sécurité n’est pas vraiment intéressé par ces taux, ce qu’il veut savoir c’est la probabilité que l’alerte qu’il reçoit soit vraie. Pour ce faire, il faudrait améliorer les taux de faux positifs.

Or malgré les améliorations apportées aux outils de type pattern matching, Snort (http://www.snort.org) par exemple, ceux-ci ne suffisent pas. Ils vont dans le bon sens, mais il n’en reste pas moins que nous n’avons pas vu baisser le nombre de vulnérabilités et que le trafic va être de plus en plus chiffré.

L’orateur met en avant deux manières, non exclusives, d’envisager les choses :

- Soit on considère que l’on a fait ce que l’on pouvait. Ce n’est pas idéal et cela va requérir beaucoup de travail en aval, car malgré la mise en place de systèmes de corrélation :

• Il n’y a pas de base de scénarios commune,
• Il y a une masse énorme de données,
• Il y a peu d’administrateurs,
• Il y a un manque d’outils de visualisation.

Il précise qu’il faut faire de la corrélation mais que cela n’est pas suffisant.

- Soit on produit de meilleures alertes :

• Améliorer l’analyse par les NIDS,
• Développer une offre HIDS, OS et applicatif (il me semblait que certains outils existaient déjà…),
• Prendre en compte la politique de sécurité (HIDS et NIDS)*,
• Apporter des capacités de diagnostic aux IDS comportementaux,
• S’inspirer des techniques de la sûreté de fonctionnement*,
• Offrir un contrôle des taux de faux positifs et négatifs,
• Développer des environnements de tests d’IDS.

*Points les plus importants, selon lui.

Il faut donc qu’un HIDS soit paramétré suivant une politique de flux d’information.

Considérons une entité à surveiller, avec des entrées et des sorties. Il y a des entrées de certains types comme des sorties de certains types. On définit une politique qui établit quels sont les flux autorisés en entrée et en sortie et on surveille le composant en question afin de lever une alerte le cas échéant.

À Supélec, Ludovic Mé travaille autour de l’outil Blare (http://blare-ids.org). Son objectif est d’avoir un IDS au niveau OS qui ne soit pas de type pattern matching et qui connaisse la politique de sécurité (en l’occurrence la politique de flux).

Une autre idée serait d’avoir des logiciels auto-testables. C’est-à-dire qu’un logiciel devrait pouvoir à tout moment s’autotester afin de savoir s’il se comporte et/ou produit ce qu’on attend de lui.

Pour conclure sur les considérations en termes de détection, Ludovic Mé insiste sur le fait que les IDS ne sont pas forcement basés sur des signatures. Il y a une multitude d’autres mécanismes à tester et à explorer.

Enfin, il ajoute qu’il regrette grandement que la communauté sécurité, y compris celle du SSTIC, ne se focalise pas davantage sur la défense plutôt que sur les attaques.

La formation

Il en vient à la deuxième partie de son propos concernant la formation.

Il attire notre attention sur la différence de niveau des connaissances requises. Ainsi, il est nécessaire de sensibiliser le grand public, les professionnels et les ingénieurs de tout type (même les PME ou l’artisanat), alors qu’il s’agit de véritables formations pour les informaticiens et, bien sûr, pour les experts SSI (masters en doctorats). Ces sensibilisations/formations doivent prendre en compte la pluridisciplinarité de la sécurité : logique, physique et organisationnelle.

Il donne des exemples de nombreux pays dans le monde où des cours d’informatique sont donnés dès le plus jeune âge, ce qui est loin d’être le cas en France. Il note cependant que quelques progrès sont faits : une spécialité informatique a été inaugurée pour les terminales S en 2012 et le programme des classes préparatoires scientifiques inclut désormais l’apprentissage du langage Python, mais est-ce assez ?

Enfin, pour les experts, il préconise l’apprentissage d’une base très large et très solide sur l’ensemble des domaines de l’informatique pour la Licence, puis sur tous les aspects de la sécurité (de la cryptographie à la politique de sécurité, mais aussi les métiers) au niveau M1/2.

Il serait également nécessaire d’y inclure les méthodes offensives bien qu’il y ait une organisation à mettre en place à ce sujet (contrôle, audit, éthique, etc.) car ceci est illégal à l’heure actuelle.

Il conclut la partie formation en insistant sur le fait que former les experts SSI, c’est former les informaticiens de manière générale.

Enfin, il rappelle que si ces deux points sont extrêmement importants, il n’en faut pas moins traiter tout le reste.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/conf_cloture_2013/.

Propos recueillis par: Geoffrey Bertoli, Antoine Cervoise, Brice Duprieux, Yannick Fournel, Julien Vallet et relu par Isabelle Feetz.

Antoine Cervoise

DreamBoot et UEFI

S. Kaczmarek

S. Kaczmarek est employé chez QuarksLAB, il s‘est intéressé à l’UEFI (Unified Extensible Firmware Interface), un composant logiciel s’interposant entre le matériel et le système d’exploitation. Il a pour vocation de remplacer le BIOS.

Avant de se lancer dans sa présentation, l’orateur a laissé la parole, pour une courte présentation de l’UEFI, à Pierre Chifflier qui a mené parallèlement, et sans que S. Kaczmarek ne le sache, le même type de recherche.

Finalement, leurs deux présentations sont complètement différentes : l’un présentant un développement (bootkit) permettant d’obtenir les permissions SYSTEM sur un Windows 8 (x86 et x64) à partir d’une ISO bootable dont les travaux sont ici présentés, l’autre à partir d’un composant se logeant dans la carte graphique et permettant également d’obtenir les droits SYSTEM sur Windows 8.

L’UEFI est assez différent du BIOS vieillissant qu’il remplace. En effet, c’est quasiment un véritable système d’exploitation, doté de fonctionnalités telles qu’un Secure Boot, de la cryptographie, une gestion de disques durs supérieurs à 2,2To, un interpréteur Python, un serveur Web pour faire du diagnostic et bien d’autres fonctions encore…

Le bootkit présenté opère une succession d’étapes ayant pour but final d’obtenir les permissions de niveau SYSTEM.

Il s’accorche (hook) au chargeur de démarrage UEFI (bootmgfw.efi) dans le but de patcher le chargeur du noyau en mémoire (winload.efi) avant son exécution. Après plusieurs opérations, s’en suit une corruption du noyau ainsi que la désactivation de plusieurs protections, comme PatchGuard et le bit NX.

Le noyau ainsi modifié va alors patcher lsass.exe pour permettre l’authentification d’un utilisateur sans mot de passe sur Windows avec les mêmes droits que l’utilisateur courant préconfiguré sur le système. À ce stade Windows est lancé, la page de demande de mot de passe est affichée et l’utilisateur courant peut se loguer sans mot de passe.

Vient la phase où le bootkit va récupérer le token d’un processus ayant les permissions de niveau SYSTEM et attendre qu’un processus cmd.exe soit lancé pour placer ce token sur le processus. Il en résulte l’obtention de permissions de niveau SYSTEM par le processus dès qu’il est lancé par l’utilisateur. L’utilisateur est alors administrateur sur l’ordinateur depuis le shell cmd.exe.

Ce genre d’attaque existait déjà avant l’UEFI et Windows 8 mais l’implémentation est ici assez différente. Ceci est dû aux spécificités et nouveautés mises en place par ces systèmes. Si le développement n’a pas été aisé, l’utilisation de cet outil est très simple.

Par conséquent, il est recommandé de désactiver le démarrage sur média externe (clé USB, DVD…), de définir un mot de passe UEFI et de chiffrer son disque dur.

UEFI et bootkits PCI : le danger vient d’en bas

Pierre Chifflier

Pierre Chifflier travaille actuellement à l’ANSSI. En parallèle, il est « Core Developper » sur le projet Debian et participe au maintien de Grub2.

L’objectif de la conférence est d’expliquer les étapes de la création d’un bootkit sur une architecture avec un UEFI.

Pour commencer, Pierre explique les plus gros défauts des bootkits « classiques » : ils sont soit temporaires et ne permettent pas de garder une emprise durable sur une machine, soit permanents et impliquent de modifier le système de fichiers, ce qui les rend détectables.

Ensuite, il commence la présentation de ses choix techniques pour la réalisation de sa preuve de concept. Il a choisi de placer sa charge malveillante dans la ROM d’extension d’une carte graphique PCI qui, bien que supposée être en lecture seule, est accessible en écriture. Cette ROM peut être flashée sans avoir à manipuler l’électronique… sauf en cas d’erreur, la machine se mettra alors à biper et refusera de démarrer. Il faudra alors flasher la puce matériellement.

En effet, lors du chargement des drivers, l’UEFI charge cette ROM, mais pour des raisons de compatibilité entre les cartes graphiques et les BIOS, l’UEFI est capable de charger plusieurs drivers en parallèle. Ce mode de compatibilité permet donc de ne pas avoir à s’attaquer aux drivers, il suffit de placer un second driver à la suite.

Cependant, la puce ayant 64k de mémoire, dont 40k sont déjà utilisés par le vrai driver, la charge devra tenir dans 24k.

Les étapes suivantes sont une succession de phases qui font penser à la pose de breakpoints. Il faut d’abord patcher la fonction « ExitBootServices » appelée à la fin de l’exécution de Grub2, pour placer un breakpoint matériel au début de l’exécution du kernel.

Puis, arrivé à ce breakpoint, il faut placer le suivant après la décompression du kernel. Ce dernier breakpoint permet la mise en place de l’élévation de privilèges dans l’appel système fork. Cet appel système n’est en fait plus utilisé au profit de clone.

Une fois sur le système, il suffit de créer un petit programme en C qui utilise la méthode « syscall » pour faire appel à « fork ».

Pour pouvoir se protéger contre de telles attaques, les méthodes classiques, comme les antivirus et grsec, sont totalement inefficaces. Les méthodes plus avancées, comme l’utilisation de TPM, peuvent être contournées comme l’ont montré J. Butterworth, C. Kallenberg et X. Kovah à la NoSuchCon. Enfin, la Secure Boot pourrait supprimer le problème mais rendrait obsolète tous les anciens matériels.

Finalement, une des meilleures protections serait peut-être que les constructeurs produisent des ROM qui soient uniquement accessibles en lecture, conformément aux spécifications.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/uefi_et_bootkits_pci/.

Programmation d’un noyau sécurisé en Ada

Arnault Michelizza

Arnault Michelizza travaille à l’ANSSI. Il a développé par le passé un micronoyau, développé en C qu’il a appelé « Pépin ». Depuis qu’il est à l’ANSSI, il a été sensibilisé à la sécurité et s’est intéressé au développement d’un noyau sécurisé. C’est le résultat de ses recherches et du développement associé qu’il présente ici.

Lors de la conférence, l’orateur est revenu brièvement sur les différents mécanismes de protection existant sur les noyaux modernes : PAX, ASLR, Canaris, bits SMAP, bit SMEP… Il a également montré les différents types de vulnérabilités qui ont touché récemment les noyaux et en a conclu que 80% de ces vulnérabilités entrainaient des dépassements de tampon (buffer/integer overflow) ou des déréférencements de pointeurs.

Dans sa recherche pour trouver la meilleure manière de concevoir un noyau sécurisé, il a fait deux constats :

• Comme le nombre de bugs augmente proportionnellement au nombre de lignes de code, l’utilisation d’un micronoyau est préférable pour réduire la surface d’attaque. De plus, dans un micronoyau, les drivers ont leur propre espace d’adressage ce qui réduit l’impact de la découverte d’une vulnérabilité ;
• Un langage de programmation ne permettant pas de débordement de tampon ou d’utilisation de pointeur, celui-ci serait privilégié. L’Ada, bien qu’inconnu de l’orateur au moment du choix du langage, a été sélectionné car il répond à ces prérequis, il est encore maintenu et il permet de faire du code bas niveau. Ainsi, Arnault a notamment éliminé Java, C, OCaml entre autres, pour ne plus retenir qu’un langage : l’Ada.

L’Ada est peu utilisé, il a été développé par des militaires, il est souvent employé dans des domaines où la vie de l’être humain est en jeu. Arnault a mis 6 mois pour le maîtriser et assure que ces six mois d’investissement seront rapidement rentabilisés tant il est facile de debugger et de retrouver où se produisent les erreurs des programmes en Ada.

Actuellement, son noyau en Ada est plutôt au stade de preuve de concept. En effet, même s’il fonctionne parfaitement, son créateur n’y voit qu’un domaine d’application  très localisé (firmware, UEFI…) car quasiment aucun driver n’est développé pour, ce qui le rend inutilisable sur un poste de travail.

Comparé à un micronoyau développé en C, le sien a seulement 60% de cycle d’horloge supplémentaire.

Arnault n’a pas eu le temps de faire une démonstration de son noyau lors de la conférence mais il a profité des rumps sessions pour en faire une avec un driver (stack TCP/IP) qui affiche les paquets ICMP reçus et cela a fonctionné sans problème.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/programmation_d_un_noyau_securise_en_ada/.

La Couleur du Net (conférence invitée)

Laurent Chemla

Laurent Chemla est un des cofondateurs du célèbre registraire et hébergeur français, Gandi. Il est également l’auteur du livre Confessions d’un voleur : Internet, la liberté confisquée (Éditions Denoël, 2002) et connu pour ses prises de position et de parole en faveur de la neutralité d’Internet.

Il est invité par le SSTIC pour nous parler d’un sujet tout autre que la sécurité, mais un sujet qui lui tient aussi à cœur : Internet dans notre société.

Il commence la présentation en nous annonçant qu’il nous a menti.

Il le dit et le répète, haut et fort, à coup de photographies de de Gaulle (cf « Je vous ai compris »). En effet, pendant des années il s’est attelé à expliquer lors de conférences diverses et variées (par exemple, au Sénat) qu’Internet était un outil comme un autre ne nécessitant pas de régulation particulière. Il préconisait une régulation de l’usage plutôt que de l’outil, se servant de l’analogie autoroute/cambrioleur (On ne sanctionne pas une autoroute parce qu’elle est utilisé par un cambrioleur).

Poussant son raisonnement à l‘extrême, il nous annonce donc qu’Internet est bien la cause du terrorisme, de la grippe A, des photos de chatons, de la guerre, etc. . On s’en doutait…

Il prétend donc avoir menti car bien qu’un outil, en soi, ne doive pas être régulé, on ne peut considérer Internet uniquement du point de vue technique, son influence sociale importe également. Or il remarque que dans les débats ayant lieu depuis plusieurs années, les différents protagonistes ne veulent en réalité pas réguler la même chose, ce qui développe un sentiment de frustration de part et d’autre. Il y aurait donc la neutralité technique et la neutralité sociale d’Internet.

Par la suite, il donne l’exemple de Free qui est un assez bon acteur neutre techniquement alors que sur les aspects sociaux, ce n’est pas le cas (filtrage du port 25, filtrage de la pub, peering Google/YouTube). Cependant, chacune des atteintes à la neutralité dite sociale a eu un impact médiatique bien différent. Le filtrage du port 25 a eu très peu de répercussion alors que non seulement les médias mais aussi l’état se préoccupent du blocage de la publicité et du peering Google/YouTube.

En clair, il a été beaucoup question de vouloir protéger la neutralité dans ces débats alors qu’il s’agit, de la part des médias et de l’état, plutôt d’un acte protectionniste envers l’écosystème de la publicité ainsi que la société de manière générale.

Il nous dit donc que défendre la neutralité technique d’Internet ne serait pertinent qu’à la marge, l’objectif réel des partisans de cette neutralité n’étant pas tant la pérennité de l’outil Internet mais la garantie qu’il continue à changer  notre société dans le bon sens. En d’autres termes, il s’agirait d’une lutte entre les personnes déjà au pouvoir et le reste de la population qui n’a jamais eu les outils des puissants pour s’exprimer, ce qu’un Internet « neutre » leur permettrait.

Il pointe aussi le fait qu’Internet engendre la disparition d’un certain nombre d’éléments tels que :

• Les intermédiaires dans le commerce des biens matériels, dans l’industrie culturelle, dans le journalisme, dans l’économie et en politique ; cette « désintermédiarisation » menant soit à une totale décentralisation, soit à une hypercentralisation. Il cite notamment l’invention  du feu ou de l’imprimerie, ou plus récemment Bitcoin comme exemples d’inventions/révolutions qui dérangent le pouvoir en place (les états et la banque, plus particulièrement pour Bitcoin) ;
• Les frontières dans l’application des lois nationales, dans la fiscalité « numérique », dans la diffusion de l’industrie des loisirs et dans la diffusion de la culture en général, allant même jusqu’à nous dire que la mondialisation mène à une dictature libérale planétaire ou à l’utopie libertaire, en est pour exemple la réponse de Twitter face à  une plainte  de l’UEJF (Union des Étudiants Juifs de France) pour injures raciales et diffamation, rétorquant qu’en tant qu’entreprise américaine, il ne répond pas du droit français ;
• Les supports physiques et la numérisation permettent l’abondance pour le plus grand nombre ou l’accumulation des richesses pour quelques-uns. Il n’y a aujourd’hui quasiment plus de logiciels en boite, la musique et les films se consomment de plus en plus de manière numérique. Tout ceci résulte d’une évolution du support, les produits en eux-mêmes existent toujours. Le summum de la numérisation étant l’impression 3D qui pourrait nous permettre demain de tout numériser et d’imprimer à volonté.

Tous ces points mènent à une perte de valeur globale des biens qui laisse entrevoir deux futurs différents. Le premier dans lequel tout le monde devient très, très riche : il est possible d’imprimer, via des imprimantes 3D, sa propre nourriture, sa propre maison, etc… et le deuxième dans lequel une majeure partie de la population est pauvre tandis que quelques personnes s’enrichissent grâce aux DRM et aux copyrights.

Laurent Chemla trouve donc amusant que depuis des années, on entende les mêmes dires : Internet est une révolution qui ira dans le bon sens alors qu’en même temps on dit vouloir préserver une neutralité qui n’a jamais existé. Tous les soi-disant défenseurs ne veulent pas pérenniser Internet, mais veulent pérenniser les changements induits par la création et l’existence d’Internet.

Pour conclure, Laurent Chemla nous dit qu’à défaut de neutralité, Internet devrait être transparent à tous les niveaux (blog, Twitter, donnée publiques, etc.). Il est assez favorable à ce que l’on perde toute vie privée, que l’on perde certains éléments de la vie passée (comme les intermédiaires susmentionnés), mais qu’en échange nous bénéficions d’une distribution massive du pouvoir de se surveiller les uns les autres. La solution de 1984, de George Orwell (1949) serait donc dans The Shockwave Rider de John Brunner (1975).

Présentations courtes

Hack Android/Samsung, à l’attaque du noyau

Étienne Comet

Étienne Comet est consultant en sécurité informatique chez Lexfo.

Il existe beaucoup de moyens pour attaquer un smartphone Android à distance. Cependant, l’accès obtenu reste assez restreint. Pour aller plus loin, il est donc nécessaire d’élever ses privilèges. C’est pour cela que l’on s’intéresse à l’attaque du noyau.

Le noyau Android est basé sur un noyau Linux, avec de nombreux patchs supplémentaires. On retrouve donc toutes les failles du noyau Linux, mais la surface d’attaque est étendue : comme indiqué précédemment il y a beaucoup de patchs en plus. Ainsi, le noyau est compilé avec des options peu auditées, Android tourne sous ARM (failles potentielles spécifiques à ARM comme le CVE-2011-1759).

Si on se concentre ensuite sur un téléphone spécifique, le constructeur ajoute des périphériques, des applications, ce qui élargit d’autant plus les possibilités de compromissions. Le noyau est donc un vecteur d’attaques prometteur.

Ensuite, l’orateur revient sur les différentes techniques de debug, avec ou sans les droits « root », notamment via KGTP (Linux Kernel debugger and tracer, http://code.google.com/p/kgtp/), un projet naissant.

L’intervention se termine par la présentation de deux bugs exploitables : un 0day et un second qui a été corrigé depuis sa découverte.  L’exploitation des failles prend la forme d’une application Android, donc en Java. Pour exploiter du code natif, il est nécessaire d’utiliser JNI qui permet d’utiliser du code natif dans une classe Java.

Compromission d’un environnement VOIP Cisco

Deuxième présentation courte de la journée, réalisée par un autre chercheur de Lexfo.

La présentation tourne autour du retour d’un audit sur environnement VOIP Cisco. L’orateur revient sur le schéma d’architecture classique VOIP Cisco. De nombreuses conférences ont présenté des vulnérabilités au sein de VOIP Cisco mais aucune n’a ciblé le call manager.

L’orateur revient sur le détail d’un audit en trois grandes phases :

• Black box : récupérer les credentials administrateur ;
• White box : obtenir une exécution de code ;
• Audit du système : élever ses privilèges vers « root ».

Il détaille les six vulnérabilités (des 0 day non remontés à l’éditeur) permettant la compromission du call manager et effectue une démonstration. Il n’est pas prévu de remonter ces failles à l’éditeur, point qui a d’ailleurs fait débat auprès des participants du SSTIC.

Observatoire de la résilience de l’Internet français

Guillaume Valadon

La dernière présentation courte de la journée est effectuée par Guillaume Valadon (ANSSI).

Comme il existe des bonnes pratiques de développement, il existe également des bonnes pratiques au niveau du réseau. L’un des objectifs de l’Observatoire de la résilience de l’Internet français est de vérifier que les acteurs Internet respectent ces préconisations. L’application de ces préconisations permettra d’assurer la résilience de l’Internet français.

Il existe plusieurs définitions de la résilience, dans notre cas de figure,  on utilise celle issue du Livre blanc de la défense nationale de 2008 : « Capacité de fonctionner pendant un incident et de revenir à l’état nominal ».

Cependant, il n’est pas possible de tester si Internet est robuste car trop grand, trop gros et trop fragile. L’Observatoire, en plus d’émettre des préconisations, effectue une vaste opération de surveillance et d’analyse.

L’orateur revient rapidement sur quelques notions de BGP (Border Gateway Protocol) et présente les risques liés à de mauvaises utilisations du protocole. Cependant, il existe peu d’AS qui, s’ils tombaient, casseraient l’Internet français.

Ensuite, Guillaume nous présente le cas du DNS. Le constat effectué par l’Observatoire, est que, sur les zones gérées par l’AFNIC, quasiment tout le monde utilise plus d’un serveur DNS pour sa zone. Cependant, 80% des zones sont chez un unique AS. De plus, le DNS permet d’analyser le taux de pénétration d’IPV6 (soit environ 10%).

Pour conclure, l’orateur rappelle quelques bonnes pratiques : déployer IPV6, répartir les DNS faisant autorité au sein de différents opérateurs, etc. Pratiques que l’on retrouve dans l’état des lieux 2011 disponible sur le site de l’Observatoire (http://www.ssi.gouv.fr/observatoire/).

De plus, le rapport 2012 sera disponible d’ici la fin du mois et un guide des bonnes pratiques BGP sera disponible en septembre 2013.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/resilience_internet/.

Sécurité des applications Android constructeurs et réalisation de backdoors sans permission

André Moulu

André est actuellement en alternance chez QuarksLAB, il est spécialisé dans la recherche de vulnérabilités sur Android.

Il a choisi Android car c’est actuellement le système leader sur le marché. Sa sécurité est souvent mise en cause par des annonces sur des malwares. Il rappelle que ces malwares sont téléchargés par les utilisateurs sur des markets alternatifs et que le système Android est correctement sécurisé. Cependant, il nuance ses propos et montrera ultérieurement que les surcouches du constructeur dégradent également cette sécurité apparente.

Il a donc décidé de s’attaquer à ces surcouches. Il prend comme téléphone cible un Samsung Galaxy S3 (car il s’est vendu à 50 millions d’exemplaires pour le moment) mais ses recherches sont finalement communes pour tous les téléphones possédant une surcouche Samsung (S2/S4/Notes). Les vulnérabilités exposées permettent de plus de s’attaquer à un utilisateur au courant des problématiques de sécurité et vérifiant les permissions des applications qu’il installe.

Généralités sur Android

Le système Android est un système d’exploitation Mobile détenu par Google, développé en C et en Java. Il utilise sa propre machine virtuelle Java (Dalvik) qui est une machine à registre, contrairement à la JVM classique. Les applications installées sont des fichiers .apk, mais ceux-ci ne sont finalement que des fichiers .zip contenant les fichiers d’applications. Parmi les fichiers présents dans .apk on peut notamment citer :

• AndroidManifest.xml : c’est un fichier de configuration de l’application qui contient les demandes de permissions, les composants ainsi que le SDK cible ;
• Classes.dex : qui contient le code exécutable (bytecode) ;
• Les bibliothèques de fonctions natives en .so.

Description d’une application

Les applications sont composées de :

• Activity : c’est l’interface graphique, chaque Activity correspondant à un écran de l’application ;
• Broadcast Receiver : permet de récupérer les événements extérieurs, comme l’insertion d’une carte SD ou la perte de la connexion Internet ;
• Content Provider : permet à l’application de communiquer avec les bases de données ou la liste des contacts ;
• Services : qui permettent à l’application de rester en mémoire et, par exemple, de récupérer les mails en fond de tâches.

La dernière notion importante est l’Intent : c’est la source de communication sous Android, il peut être inter-composants ou inter-applications. Par exemple, c’est un l’Intent qui demande l’ouverture du navigateur lorsque l’on souhaite ouvrir une page Web. L’Intent communique avec des composants. Par défaut, ces composants ne sont pas accessibles depuis l’extérieur de l’application, sauf si ceux-ci sont déclarés explicitement comme exportables dans l’AndroidManifest.xml. Il est aussi possible d’exporter un composant tout en le protégeant par une permission.

Modèle de sécurité sur Android

Il existe 2 types de sécurité implémentés dans Android.

1)      Sécurité par cloisonnement

Le système attribut un UID à chaque application. Cela permet d’avoir les processus isolés en mémoire et les systèmes de fichiers des applications ne sont accessibles que par elles-mêmes.

Il y a un cas particulier : deux applications peuvent partager le même UID, pour cela il faut le déclarer dans l’AndroidManifest, il faut également que les applications soit signées avec le même certificat.

2)      Sécurité par moindres privilèges

Par défaut une application ne possède aucun privilège, le développeur doit demander explicitement toutes les permissions de l’application dans l’AndroidManifest. Les permissions sont affectées à chaque UID. Par conséquent, les permissions sont cumulées pour toutes les applications qui partagent le même UID.

Réalisation d’une backdoor

L’idée est de réaliser une exploitation de vulnérabilité sur les applications constructeur qu’un simple utilisateur ne peut pas désinstaller. L’exploitation de la vulnérabilité se fait donc en user land.

André Moulu a donc listé les applications constructeur présentes dans /system/app et /system/framework. 216 Fichiers .apk sont présents correspondant à 500Mo d’applications (contre 91 fichiers pour un téléphone Nexus « nu »), à cela il indique que certains opérateurs ajoutent une surcouche eux aussi, étendant d’autant plus la surface d’attaque.

Des contraintes entrent en jeu ; en effet, le nombre conséquent d’applications oblige l’automatisation de la recherche d’applications potentiellement vulnérables, puis la rétro-conception dans le but de trouver des permissions pouvant être détournées de leur usage premier.

Pour cela, il a développé plusieurs modules Androguard :

• ASA manifest : analyse le manifeste et indique les éléments accessibles ou non et sous quelles conditions ;
• ASA Database : analyse et enregistre les informations des applications dans une MongoDB ;
• ASA Diff : développement en cours.

Son objectif est maintenant clair : avoir un maximum de permissions depuis sa backdoor !

Accès à la carte SD

Historiquement, toutes les applications avaient accès en lecture et en écriture à la carte SD. Depuis, seul l’accès en lecture est toléré par le système, uniquement dans un souci de rétrocompatibilité. Si dans le manifeste le SDK cible est inférieur ou égal à 3, alors le système autorise les accès en écriture à la carte SD.

De nombreuses autres permissions ont été détournées, comme l’envoi de SMS, sans en faire la demande explicite, en exploitant des vulnérabilités dans ui.MMS.BGSender.apk. Il suffit de lui envoyer un Intent le forçant à envoyer un SMS.

Une élévation de privilèges est aussi possible en utilisant une vulnérabilité trouvée dans une application partageant son UID avec l’utilisateur « system », une fois ce niveau de privilèges atteint.

Forwading de SMS

L’application DSMLawmo.apk reçoit un Intent à l’arrivée d’un SMS, dans le cas où le SMS n’aurait pas déjà été reçu il n’y a pas longtemps (afin d’éviter le SPAM). Ensuite, l’application transfère le SMS au numéro présent dans la base de données. Ce numéro n’est pas renseigné par défaut. Simplement, après  avoir obtenu les droits système, il est possible de modifier cette base. Ainsi, on ajoute son numéro dans la base de données et il est possible de transférer les SMS de la victime de manière tout à fait transparente.

Pour cela, les antivirus sont inefficaces.

Conclusion

La surface d’attaque augmente avec chaque nouveau terminal. En effet, la surcouche constructeur est de plus en plus grande, mais les innovations qu’Android met en place, notamment SELinux, permettent petit à petit de résoudre ce problème. Il est aussi possible de se protéger en achetant des téléphones « nus », sans surcouche constructeur.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/securite_applications_android_constructeurs_et_realisation_de_backdoors_sans_permission/.

Limites des tables rainbow et comment les dépasser en utilisant des méthodes probabilistes optimisées

Cédric Tissieres, Philippe Oechslin, Pierre Lestringant

Concrétisation de la mission de stage de Pierre Lestringant au sein de Objectif Sécurité, société suisse, notamment éditrice d’Ophcrack, cette conférence débute par une rapide présentation du principe de fonctionnement des tables rainbow et de leurs applications.

L’objectif est donc d’effectuer la majorité, voire l’intégralité, des calculs en amont de la phase de cassage, tout en gardant un rapport performant entre la durée d’exécution et le taux de réussite.

Suite à la démocratisation des calculs sur GPU, l’intérêt des tables rainbow peut sembler plus limité dans un contexte où les délais d’accès au contenu des tables rainbow tend à représenter une plus grosse contrainte que l’exhaustivité d’une attaque par brute force.

Par conséquent, il devient nécessaire de procéder à des optimisations sur les tables rainbow par le biais de fonctions déterministes : la détection de patterns et les chaînes de Markov.

La détection de patterns consiste à identifier les comportements habituels des utilisateurs lors de la définition de leur mot de passe : alternance de casse, remplacement de caractères par des équivalents numériques, ajout de ponctuation…

Ainsi, avec l’application d’un algorithme de sac à dos (approche heuristique de l’algorithme glouton), il devient possible de trier par ordre de fréquence d’occurrence les différents patterns.

Une fois cette étude probabiliste réalisée, on connaît donc, pour chaque bloc, sa probabilité et l’impact qu’elle aura sur la taille des tables rainbow.

Suite à des tests effectués sur des bases de données « leakées » dernièrement, il a été constaté qu’une réduction de taille des tables rainbow par un facteur 10 000 (sur les mots de passe de 9 caractères) engendre une simple réduction de 4% de la probabilité de cassage de la chaîne (de ~99% à ~95%).

Les chaînes de Markov permettent de considérer qu’un utilisateur définit un mot de passe proche de sa langue maternelle. De fait, on peut raisonnablement considérer qu’un caractère sera influencé par les deux caractères le précédant (chaîne de Markov d’ordre 2).

La phase d’optimisation des recherches correspond à une implémentation de la méthode Alias. Elle permet d’assimiler la sélection des patterns au tirage d’un dé biaisé dont chaque face représente un pattern, pondéré par sa probabilité d’occurrence.

Cette méthode Alias permet d’optimiser le découpage des espaces de résultats et de limiter le nombre de cycles nécessaires à la recherche. Elle présente aussi l’avantage de ne pas pouvoir réduire les performances de la recherche, même en cas de sets inadaptés à cette méthode.

Ces optimisations permettent donc d’améliorer la viabilité des tables rainbow face à la parallélisation des calculs apportée par les GPU. De plus, de nombreuses fonctions de réduction des hash étant incluses dans les calculs des tables rainbow, la génération de celles-ci peut, à son tour, bénéficier des améliorations apportées par les capacités de calcul des GPU .

Rumps

1. Des Trucs en Stock Sur SSTIC – L’équipe du SSTIC

• Rapide rappel informatif sur le social event.
• Finance : tout va bien, les tarifs ont légèrement baissé cette année.
• Il est à noter que 75% du budget part dans l’alimentation (buffet tout au long des confs, social event, etc.) ;
• Soumissions : L’équipe invite tout le monde à soumettre des papiers pour l’année prochaine ;
• Inscriptions :
  • 1^ère vague : 150 places vendues en 4 minutes et 41 secondes,
  • 2^ème vague : 130 places vendues en 12 minutes,
  • 3/4/5^ème vagues : 96 places vendues en 50 minutes ;
  • Il y avait un système qui bannissait pendant 20 minutes les personnes rafraîchissant la page plus de 40 fois par seconde. Une personne a été bannie 1 seconde après l’ouverture… :s

2. MGCP, un protocole VOIP oublié –  Sn0rkY

MGCP est un protocole utilisé dans beaucoup d’infrastructures VOIP, mais très souvent oublié. Il utilise de l’UDP sans authentification, il est possible de modifier une connexion à la volée, de scanner toutes les grandes classes d’adresses. Interroger des « Endpoint » est également relativement aisé.

Sn0rkY a donc créé des scripts pour récupérer plus facilement des informations. Il peut également rediriger le flux pour un appel sortant et se positionner en écoute au milieu de flux (type Man in the Middle). Une attaque de ce type est faisable depuis Internet car beaucoup de gateways opérateurs sont ouvertes sur Internet. Le MGCP est donc à bannir.

3. Quel est l’OS de Kim Jong-un? – Pierre Capillon

Pierre Capillon est l’auteur de java-0day.com, une page qui donne le nombre de jours depuis le dernier 0day Java.

Il donne des statistiques des accès à sa page. Il y a beaucoup de hits provenant d’Oracle, mais également des IP d’APT1, de .gouv.fr, de Syrie, d’Iran, de Cuba, du Pentagone, de whitehouse.gov, etc.

Il a également eu un hit d’une IP nord-coréenne, et proclame : « L’IP de la Corée du Nord vous l’avez !! ». Kim Jung-un surferait donc avec un MAC pas du tout à jour. Il finit sa rump avec un silde spoil du dernier épisode de Game of Thrones, le 9 de la saison 3.

4. La sécurité est un ______ (complétez la phrase) – Nicolas Ruff

Il nous livre ses trouvailles lors d’un audit sur une appliance dont l’applicatif a été réalisé en PHP :

• Possibilité de contourner l’authentification dans l’URL (login=admin&password []=) ;
• SHA-1 en commentaire dans le code ;
• exec.php à la racine ;
• Clé privée disponible dans l’arborescence de l’application ;
• « La question n’est pas combien de secondes il faut pour passer « root », mais avec combien de méthodes différentes » ;
• Il y a un compte « root » disponible pour communiquer vers l’éditeur, une backdoor en somme ;
• Etc.

Et cela fait plusieurs années que le produit est certifié CSPN par l’ANSSI ! Toutes ces failles ont été remontées à l’éditeur.

5. Another perspective to IP-Darkspace Analysis – Alexandre Dulaunoy

C’est un sujet dont on parle depuis quelque temps. Il y a beaucoup de chercheurs, mais les résultats ne sont pas très intéressants. Quant à l’orateur, il a choisi de se focaliser sur les erreurs de frappes. Par exemple, 193.168.1.x au lieu de 192.168.1.X. Il a donc réussi à obtenir l’une de ces IP que l’on concocterait en faisant une erreur de frappe de ce genre et a pu récupérer plein d’informations provenant d’équipements différents (imprimantes, PC, serveurs, etc…) qui cherchaient à se connecter à une adresse légitime.

6. L’histoire d’un bug vieux de 20 ans – Florian Ledoux

Présentation de la détection et l’exploitation d’une faille vieille de 20 ans permettant une élévation de privilèges sur les plateformes Windows NT à Windows 8. Cette faille est publique et n’a toujours pas été patchée.

7. Cloud iso 14001 – Low-Power ARM-based grsec-enabled server – Arnaud Ebalard

L’orateur explique son cheminement, le choix matériel ainsi que la mise en place d’un mini serveur de stockage à la maison. Les informations détaillées sont disponibles ici : natisbad.org.

8. WTF avec Suricata – Éric Leblond

WTF : Word Terminator Flow

Création de règles Suricata/Netfilter pour éviter le transfert de fichiers Word :

• Possibilité de faire de la QoS avec TC ;
• Fonctionnalité d’anti-évasion avec stockage du fichier ;
• Version longue de la rump aux RMLL cet été et informations disponibles ici : https://home.regit.org/2012/10/defend-your-network-from-word/

9. Rump Pub!

• Botconf à Nantes, les 5 et 6 décembre 2013 ;
• GreHAck à Grenoble, le 15 novembre 2013 ;
• OWASP EU Tour 2013 à Sophia Antipolis, le 24 juin 2013.

10. Raspberry Spy – Antoine Cervoise (Devoteam)

Présentation d’une petite machine d’interception de paquets réseau basée sur le modèle du keylogger physique.

Objectif : coûter moins de 50$, donc basé sur un Raspberry Pi avec, notamment l’ajout d’un deuxième port Ethernet (via USB). Fonctionne très bien, relativement discret, il a été posé en environnement de bureau pendant 2 semaines sans être vu.

Limites : alimentation en USB (machine cible ou secteur), ne supporte pas la PoE, batterie possible mais 3 heures maximum, pour le moment.

Les slides sont disponibles sur le site perso d’Antoine : http://www.antoine-cervoise.fr/wp-content/uploads/2013/06/SSTIC-2013-Raspberry-Spy-Rump-A.-Cervoise.pdf.

11. me@your.home – how to succeed in your robbery 2.0 – Deux stagiaires de QuarksLab

Géolocalisation via Twitter et autres, pour savoir si vous êtes à distance de votre logement et donc si votre appartement ou maison est sans protection.

12. IOC – Ivan Fontarensky

Présentation d’un outil  de classification des attaques, comme celui utilisé par Mandiant.

13. Démo de la présentation du noyau Ada ayant eu lieu le matin même – Arnauld Michelizza

L’orateur montre un exemple de retour console lorsqu’il y a une erreur dans le code. Il corrige cette erreur sous nos yeux, il n’y a alors plus d’erreur lors de l’exécution. Il « ping » la machine pour prouver que ça fonctionne.

14. Stack overflow vs stack-based buffer overflow – Aurélien Francillon

L’orateur explique la différence entre les deux et donne un exemple en Ada.

15. Analyse d’AD – Philippe Biondi

L’orateur présente un outil qu’il a créé pour analyser des AD. Il scan l’AD, ou la forêt d’AD, enregistre les informations (fichier ntds.dit) dans une base de donnée (mongodb), puis utilise des « miners » pour analyser les informations récupérées.

Son outil offre la possibilité de faire des analyses différentielles entre deux versions d’un même AD (une propre et une autre contenant une backdoor, par exemple).

Les rapports peuvent être exportés en dump live, REST ou CSV (via zip).

16. PandaOCR – Romain Leonard (Devoteam)

Présentation d’un outil d’OCR en Python pour capter les PIN de sites bancaires, donc sur des images minimalistes. Il a ensuite agrémenté son outil pour les CAPTCHA utilisant des polices rares. Le projet est disponible sur github : https://github.com/Plopi42/PandaOCR.

17. Hack my CCTP – Anonyme (capuche, lunettes et hélium)

Présentation humoristique sur la rédaction de réponse à un appel d’offres, ou comment faire jouer les chiffres en sa faveur.

Vidéo disponible ici : http://www.dailymotion.com/video/x10opn8_hack-my-cctp_fun

18. RW2 – XXX

Le RW2 est le format RAW utilisé par les appareils Panasonic. Il permet de corriger plus facilement les images et donc d’obtenir de bons résultats sans investir dans un reflex. Il y a plein d’outils sur Windows et MAC pour traiter ce format, mais rien sur Linux et Panasonic ne fournit de documentation permettant de créer son propre outil. L’orateur a tenté de « reverser » les outils existant, mais cela s’avère extrêmement complexe.

Il n’a donc pas réussi à créer un outil de traitement de RW2 sous Linux et cherche d’ailleurs des personnes souhaitant participer à son projet.

19. PhotoRec – Récupération de données – Christophe Grenier

Présentation de PhotoRec, un outil sous licence GPL et multiplateforme, permettant la récupération après suppression de photos ou tout autre type de fichiers. La grande nouveauté étant un mode graphique venant d’être ajouté à l’outil qui jusque là n’était disponible qu’en CLI. Le site du projet : http://www.cgsecurity.org/wiki/PhotoRec.

20. Je choisis l’option offensive ou pourquoi il ne faut pas s’auto-intoxiquer –  Florent Chaveau

Rapide prise de parole par le FSSI du Ministère de la Défense : « Est-ce que vous préférez être surveillé par votre État démocratique ou par une multinationale américaine ? ». Il précise que l’État n’a pas l’intention d’acheter de 0day, mais qu’il recrute activement !

21. TNS Hijack – Un employé de chez Synacktiv

Présentation d’une attaque de type Man In The Middle sur un TNS Oracle. Par défaut, Oracle ne met pas de protection sur sa couche transport.

Objectif de l’attaque : SQLi arbitraire, sans perturber le client, sans crasher.

Difficultés : pas de documentation, pas d’outil, pas de structure claire de type TLV, etc.

Résultat : hijacking du flux TNS, injection à la volée de requêtes SQL arbitraires.

Évolutions : interception de commandes, récupération de mots de passe, code propre.

L’orateur nous fait une démonstration pour conclure.

Propos recueillis par: Geoffrey Bertoli, Antoine Cervoise, Brice Duprieux, Yannick Fournel, Romain Léonard, Julien Vallet et relu par Isabelle Feetz.