Symposium sur la sécurité des technologies de l'information et des communications

.

Le tatouage (ou watermarking), de par ses principes, peut jouer un rôle complémentaire en matière de sécurité (intégrité, authenticité …) et de gestion de l’information médicale. Au cours de cet exposé, nous reviendrons sur quelques exemples où le tatouage est proposé comme outil de protection ou pour faciliter le partage et l’accès aux données d’imagerie médicale. Nous discuterons également des risques d’interférences liées à la présence de la marque avec l’interprétation de telles images. En effet, si l’exploitation de cette technologie est freinée du fait de la nécessité de préserver la qualité diagnostique des images, des solutions ont néanmoins été proposées (tatouage par régions d’intérêt et tatouage réversible ou sans pertes). Nous présenterons quelques un de ces schémas de marquage.

Cet article présente deux projets de recherche et développement de l’agence NC3A de l’OTAN dans le domaine de la cyber-défense, CIAP (Consolidated Information Assurance Picture) et DRA (Dynamic Risk Assessment). La cyber-défense est aujourd’hui principalement basée sur les outils suivants : systèmes de détection d’intrusion (IDS), scanners de vulnérabilités, antivirus ainsi que systèmes de gestion et corrélation d’événements sécurité (SIEM). Lorsqu’il s’agit de superviser un système informatique à grande échelle réparti sur plusieurs sites, il devient vite très difficile de corréler et analyser toutes les sources d’information disponibles en temps réel afin de détecter les anomalies et les incidents suffisamment vite pour réagir efficacement. Cette complexité est due à la quantité d’information générée, au manque d’interopérabilité entre les outils ainsi qu’à leurs lacunes en matière de visualisation.

Le projet CIAP vise à pallier ce manque en étudiant comment toute l’information nécessaire à la cyber-défense peut être consolidée dans un système complet, reposant sur un modèle de donnée commun s’appuyant sur des standards et sur un système de stockage distribué. CIAP fournit également diverses visualisations complémentaires de toutes les données collectées, notamment des vues d’ensemble de la topologie réseau et des vues géographiques.

Un autre problème majeur en cyber-défense est que la tâche de comprendre l’impact réel d’une vulnérabilité ou d’une alerte IDS est généralement dévolue à un analyste humain, qui doit lui- même faire le lien entre toutes les informations techniques et sa connaissance de tous les services ou processus qui dépendent des machines concernées. Le projet DRA est une étude complémentaire de CIAP qui vise à fournir une analyse de risque en temps réel, afin de déterminer automatiquement l’impact réel dû à la situation sécurité globale du système et du réseau. Pour cela une nouvelle méthodologie innovante a été développée en combinant un générateur automatique d’arbres d’attaque (attack trees/graphs) et un moteur d’analyse de risque « traditionnel » similaire à EBIOS.

L'établissement de tunnels (HTTP, HTTPs ou apparentés) avec un serveur distant maîtrisé pour y faire passer des flux illégitimes est un des moyens les plus efficaces et les plus utilisés pour contourner la politique de sécurité d'un réseau. Les produits de sécurité actuels (pare-feux, serveurs mandataires, IDS…) sont généralement incapables de détecter ce genre de contournements. Une des solutions proposées dans la littérature consiste à utiliser des outils de classification statistiques pour identifier le protocole encapsulé dans un flux. Nous présentons ces techniques dans cet article et nous évaluons leur faisabilité à travers une preuve de concept. En particulier, un outil original permettant la détection des tunnels illégitimes à partir de quelques paramètres extraits des flux interceptés est décrit. Les résultats de manipulations expérimentales sur des bases de données réelles, présentés à la fin de cet article, montrent la viabilité des techniques utilisées. Un tel outil pourrait être mis en œuvre pour pallier les lacunes des IDPS et serveurs mandataires existants.

Les botnets sont sans conteste la forme la plus développée aujourd'hui de délinquance organisée sur Internet. Leur usage permet toutes les formes d'action malhonnêtes: spam, phishing, collecte de données personnelles, hébergements furtifs, diffusion de logiciels malveillants, attaques en déni de service, etc.

Ils sont maintenant proposés à la location pour quelques jours ou juste quelques heures et sont au coeur de l'offre commerciale criminelle sur les réseaux.

Les initiatives sont nombreuses qui proposent de partager des informations sur leur présence sur les réseaux, les serveurs de contrôle ou référencer leurs tentatives d'attaques.

Mais peut-on sérieusement et légalement exploiter ces sources d'information ? Comment envisager de nouveaux modes d'action ? Cette présentation propose un tour d'horizon des initiatives et ouvre le débat sur une possible stratégie.

L'observateur perturbe la mesure : cette règle s'applique aussi dans le monde de l'analyse dynamique de programmes, où le fait d'attacher un débogueur peut entraîner des effets de bords modifiant le comportement du système étudié. Ainsi, plusieurs codes malveillants tentent de détecter la présence d'un débogueur ou d'un environnement de virtualisation pour altérer leurs actions en conséquence.

Le projet virtdbg a objectif but de créer un débogueur fondé sur un hyperviseur minimaliste. Il est injecté directement dans la mémoire du système cible en utilisant un transfert DMA et offre un ensemble de primitives simples permettant de contrôler la cible (pose de points d'arrêt, lecture et écriture de la mémoire, gestion des exceptions, etc.) Ces primitives s'appuient sur les fonctions de virtualisation matérielle des processeurs Intel et AMD récents. Le système est très peu altéré et le contrôle est total.

Les communications entre l'hyperviseur et le débogueur reposent sur le protocole gdbserver, implémenté au-dessus d'un médium physique choisi pour minimiser l'impact sur le système à étudier (USB ou Ethernet). Ce protocole a par ailleurs comme avantage d'être compatible avec différents débogueurs comme gdb, IDA Pro, GenDbg, etc.

L'analyse de programme sans code source, regroupant la recherche de vulnérabilités et l'analyse de logiciels malveillants, relève actuellement plus de la programmation système que de l'algorithmique. Par conséquent, ces champs de recherche ne bénéficient pas des avancées en analyse de code et en optimisation.

Nous proposons un cadre formel basé sur l'analyse de traces permettant de raisonner sur les propriétés algorithmiques des programmes binaires. Nous avons appliqué ce cadre à l'analyse des programmes auto-modifiants comme par exemple les malwares compressés ou chiffrés, et nous avons validé son utilité par l'expérience en testant une implémentation sur environ 100.000 échantillons collectés sur des honeypots.

Les traces présentent un intérêt évident pour l'ingénierie inverse : faciles à collecter de manière générique avec différents outils (même statiques) et plus fiables que le désassemblage, elles permettent de raisonner avec exactitude sur les effets d'un programme sur le système, les flux de données ou encore les multiples chemins d'un exécutable. Elles sont donc une manière simple et élégante d'unifier les différentes branches de l'analyse de programme.

2010 s'annonce comme un millésime pour le droit de la SSI.

2004 avait déjà été une année exceptionnelle (LCEN, LCESCA, Informatique et libertés 2, Perben 2, expression syndicale par voie électronique) mais 2010 s'annonce comme une année record avec au programme :

- LOPSSI 2 (Usurpation d'identité, vidéo-protection, intelligence économique,...), - Informatique et libertés 3 (CIL obligatoire, renforcement du droit à l'oubli, IP identifiante et surtout modification des articles sur l'obligation de sécurité), - Hadopi 1 et 2 (mise en oeuvre dans les entreprises d'une "politique Hadopi"), - jeux en ligne, LCEN 2,... entre autres

et ce... sans compter la jurisprudence en pleine effervescence également, notamment dans le domaine de la cybersurveillance des collaborateurs dans l'entreprise mais aussi au sein des réseaux sociaux.

2010, Tous Avocats !

Le choix de Java est souvent guidé par la sécurité qu'il est censé apporter. La plate-forme d'exécution Java assure en effet des propriétés de sécurité permettant notamment de se prémunir contre l'exploitation de la mémoire. Toutefois, de nombreuses vulnérabilités publiques concernent Java, notamment sa bibliothèque standard. Quant est-il donc de l'apport de Java en termes de sécurité? Quelles sont ses faiblesses? Quelles améliorations sont envisageables? Cet article tente de répondre à ces questions. Il décrit tout d'abord les différents composants de la plate-forme d'exécution Java en détaillant les mécanismes de sécurité offerts et les propriétés garanties. Il analyse ensuite les différentes faiblesses de ces composants et propose enfin des pistes pour l'amélioration de la sécurité de la plate-forme.

Aujourd'hui, il est difficile d'assurer la protection d'un noyau de système d'exploitation. Les attaques visant à le corrompre peuvent provenir de sources diverses. La plupart utilisent le processeur comme vecteur d'accès à la mémoire du noyau. Cependant, depuis un certain nombre d'années, nous voyons apparaître des attaques impliquant des périphériques, en particulier depuis le bus FireWire. Pour se protéger de ces derniers, une IOMMU est nécéssaire. C'est un composant matériel permettant à un système d'exploitation de contrôler l'accès des périphériques à la mémoire principale. Cet article s'intéresse à la robustesse des services fournis par une IOMMU vis-à-vis des attaques DMA. Nous rappelons, pour commencer, l'intérêt d'embarquer une IOMMU dans les chipsets actuels pour protéger le noyau du système d'exploitation. Ensuite, nous concentrons notre attention sur la technologie Intel VT-d qui implémente une IOMMU. Nous analysons l'efficacité du service qu'elle fournit puis nous détaillons la mise en oeuvre qui en est faite sous Linux. Cela nous amène à identifier quelques faiblesses dans cette technologie. Nous détaillons une de ces faiblesses que nous illustrons par une preuve de concept. Enfin, nous formulons quelques recommandations permettant d'empêcher son exploitation.

Les cartes réseau des postes informatiques font partie des composants les plus exposés à la menace informatique. En effet, quel que soit le système d'exploitation employé, c'est au final la carte réseau qui sera en première ligne et qui verra passer l'ensemble du trafic adressé à la machine. Ainsi, si une carte réseau était piégée ou comportait une faille d'exploitation, un attaquant pourrait prendre le contrôle à distance de celle-ci, indépendamment des mécanismes de sécurité proposés par le système d'exploitation.

Dans cet article, nous étudions les principes d'architecture des cartes réseau modernes et nous présentons les risques associés à leur complexification. En particulier, nous prenons l'exemple d'une fonctionnalité d'administration de machines à distance gérée par la carte réseau et nous montrons qu'une faille d'implémentation sur certains modèles de cartes réseau permet à un attaquant d'en prendre le contrôle à distance. L'une des contributions majeures de cet article est de proposer une preuve de concept d'une telle prise de contrôle.

Le projet Honeynet existe depuis plus de 10 ans et a pour mission d'amméliorer la sécurité d'internet sans coût pécunier pour le public. Association à but non lucratif orientée sur la recherche uniquement, nous publions de nombreux travaux librement accessibles sur notre site web. Des challenges forensics aux papiers KYE (Know Your Enemy), KYT (Know Your Tools) en passant par différents outils développés.

Le but de la conférence sera de présenter l'esprit et les travaux du projet.

La sécurité des systèmes de vote consiste à garantir l'intégrité des suffrages, le secret du vote, ainsi que la disponibilité et l'auditabilité des instruments électoraux. Nous présentons d'abord la sécurité des systèmes traditionnels, en montrant que le secret est, dans les démocraties, un acquis récent dont le respect n'est pas imposé de façon stricte, tandis que l'intégrité, la disponibilité et l'auditabilité sont des impératifs anciens et majeurs que la loi et le juge de l'élection s'attachent à faire respecter. Nous abordons ensuite le délicat problème de l'automatisation des systèmes de vote, qui soulève de graves problèmes en termes de sécurité. Pour y remédier, des solutions à base de trace papier et d'émission d'un reçu ont été proposées, mais elles ne résolvent pas totalement les problèmes soulevés. Nous proposons un protocole de vote se voulant simple à comprendre et facile à mettre en oeuvre. Son principe consiste à donner aux électeurs un reçu associant une marque anonyme à leur vote, cette association étant reprise sur un site web. Ainsi, les électeurs peuvent vérifier que leur suffrage a bien été pris en compte et toute personne peut refaire le calcul des résultats à partir du site. Le secret est quant à lui assuré en plaçant sur le reçu non seulement l'appariement entre le choix de l'électeur et la marque attribuée, mais aussi tous les autres choix possibles, associés à des marques correspondant à des votes antérieurs pour ces autres choix.

Les utilisateurs ont une confiance exagérée envers les réseaux sociaux qui deviennent pourtant peu à peu une cible privilégiée des attaquants. La nature même des plate-formes sociales facilite la propagation de malwares, qui se complexifient de génération en génération. En permettant la création d'applications intégrées, les réseaux sociaux offrent aux développeurs et aux attaquants des facilités d'accès aux données des utilisateurs, et des moyens d'interaction avec leurs comptes. Nous étudierons plus particulièrement dans cet article le cas des applications Facebook, qui est l'une des plate-formes les plus populaires. Ces différents risques doivent être identifiés afin d'être évalués et de pouvoir mettre en place une véritable stratégie d'intégration maîtrisée de ces outils au sein des entreprises.

Le projet OpenBSC est destiné à implémenter une station de base et ainsi fournir une couverture GSM. À plusieurs occasions, les développeurs du projet ont ainsi fait tourner leur réseau cellulaire et transmis des appels gratuite grâce à l'utilisation de VoIP. OpenBTS est l'implémentation d'une pile GSM logicielle et peut également servir à réaliser des tests de sécurité sur les téléphones mobiles classiques.

L'informatique de confiance, notamment au travers de la puce TPM, est présente dans l'industrie depuis environ 7 ans. Pour autant, les concepts de sécurité associés — tels que le principe de chaine de confiance, l'attestation d'intégrité ou encore le chiffrement conditionnel —, majoritairement poussés par le Trusted Computing Group (TCG), sont aujourd'hui peu implémentés par les industriels. Le composant TPM et sa pile logicielle demeurent les seules réalisations largement déployées sur les parcs informatiques grands publics et professionnels. Mais très peu d'applications tirent réellement parti des services offerts par le TPM.

Une remise en cause est donc nécessaire et a justifié l'écriture de cet article à vocation prospective. Nous dressons tout d'abord un panorama des atouts et limites de l'informatique de confiance avec un focus sur la technologie TPM. L'étude met en évidence deux problèmes de positionnement majeurs : une adéquation imprécise vis-à-vis des besoins des différents marchés ainsi que le manque de clarté sur le positionnement du composant TPM relativement aux technologies concurrentes. L'article montre que la couverture de nouveaux besoins nécessiterait soit une adaptation du TPM (transformation vers un co-processeur cryptographique, voire un processeur sécurisé), soit l'utilisation de technologies complémentaires telles que la virtualisation.

Les tests d'intrusion réalisés ces dernières années par HSC qu'ils soient internes ou externes montrent que la technologie J2EE occupe une place de plus en plus importante au sein du domaine applicatif. Sa portabilité, sa sécurité et ses nombreuses API sont les éléments principaux à l'origine de son succès. Le « boom » du J2EE a particulièrement impacté le monde du web que ce soit pour les applications web elles-mêmes ou bien la mise en place d'infrastructures beaucoup plus complexes comme des plate-formes de web services. De nombreux sites gouvernementaux, banques et grands organismes utilisent notamment cette technologie et cela ne va pas en régressant.

Bien entendu, les infrastructures web ont dû s'adapter à cette nouvelle technologie et de nouveaux serveurs ont dû être mis en place. Cependant, les bannières que l'on peut rencontrer sur la toile et sur les réseaux internes des entreprises ne sont pas si diversifiées. Pour les conteneurs web, il s'agit principalement de serveurs Tomcat utilisés généralement pour l'hébergement des applications web (JSP et Servlets notamment). Par ailleurs, ces dernières années, avec l'apparition des architectures N-tiers, la logique métier des applications a été modularisée nécessitant l'apparition de nouveaux serveurs dits « d'application ». De la même manière, le marché est principalement dominé par une seule bannière: JBoss Application Server.

Ce succès au sein des entreprises peut être justifié premièrement par sa portabilité, tant qu'une machine virtuelle Java (JVM) est disponible, il n'y a aucun problème. Puis, deuxièmement, par sa grande modularité qui permet d'utiliser JBoss pour à peu près tout et n'importe quoi, du simple hébergement d'applications web basiques (JBoss embarque un serveur Tomcat) à la mise en place d'une véritable plate-forme de web services complète mettant à profit tous les avantages des architectures distribuées.

Cependant, malgré ce succès, les mécanismes de sécurisation des serveurs JBoss ne semblent pas encore correctement maîtrisés par les administrateurs. Le retour d'expérience HSC montrent notamment que de plus en plus d'intrusions internes ou externes débutent par la compromission d'un serveur JBoss.

Cette constatation s'appuie principalement sur le manque de protection mis en place, par défaut, sur les nombreuses interfaces d'administration de ces serveurs. Contrairement aux serveurs Tomcat où cette vulnérabilité est maintenant connue et reconnue pour le Tomcat Manager, pour les serveurs JBoss cela est loin d'être le cas d'où l'intérêt de plus en plus prononcé des pirates pour ces serveurs. Là où le problème des comptes par défaut a été corrigé pour Tomcat dans les versions récentes, pour JBoss les interfaces d'administration ne sont même pas protégées par défaut. Lorsqu'elles le sont, le compte trivial admin/admin est créé pour peu que les administrateurs n'aient pas pensé à le modifier.

L'impact serait minime si les possibilités offertes par ces interfaces étaient limitées mais malheureusement c'est généralement loin d'être le cas. Un attaquant ayant accès à l'une de ces interfaces peut récupérer de nombreuses informations concernant le serveur, modifier la configuration « à chaud » voir même déployer ses propres applications web sur le serveur (webshells) lui permettant d'asservir totalement le serveur (y compris le système d'exploitation) à ses besoins. Une fois cet objectif atteint, libre à l'attaquant de rebondir sur d'autres systèmes...

L'objectif de cet article sera donc de montrer d'une part les possibilités offertes à un attaquant face à un serveur JBoss mal protégé puis d'autres part les dispositifs de sécurisation existants afin de se protéger de ce type d'attaques qui peuvent se révéler désastreuses pour une entreprise (vol de données clients, compromission d'une multitude d'équipements via le JBoss, rebond sur un système étranger mettant en cause la responsabilité de l'entreprise...).

Cependant, avant toute chose, il est important de bien comprendre l'architecture interne des serveurs JBoss et plus particulièrement ce que l'on appelle le Java Management Extensions (JMX) qui correspond à la partie la plus intéressante pour un attaquant puisqu'il permet la gestion de l'ensemble des ressources (services, applications...) du serveur. Ainsi, la maîtrise de cet élément permet la maîtrise totale du serveur.

L'article décrira donc l'architecture de cet élément critique au sein d'un serveur JBoss et notamment sa structure en couche:

• Les Mbeans (instrumentation level) qui sont des objets représentant les ressources à proprement dites. Chaque Mbean propose, comme tout objet Java qui se respecte, des méthodes permettant de contrôler la ressource associée.

• Le Mbean Server (agent level) qui fournit aux interfaces d'administration les méthodes des différents Mbeans disponibles. Toute interaction avec un MBean passe par le MBean Server.

Les Mbeans à privilégier lors d'une attaque dépendent des motivations de l'attaquant. Les possibilités sont multiples et l'article final décrira plus précisément les MBeans les plus intéressants du point de vue d'un attaquant. Il existe notamment des MBeans permettant de gérer les mécanismes d'authentification des applications hébergées. Il est donc assez facile d'imaginer, qu'une fois l'accès à ces MBeans possible, le contournement des mécanismes d'authentification devient facile. D'autres permettent le déploiement d'application au format .war, .jar ou .sar par exemple, offrant la possibilité d'insérer des portes dérobées au sein du serveur. Puis finalement, certains permettent l'exécution de scripts BSH (BeanShell), c'est-à-dire du java à la volée, et autant dire que la seule limite sera l'imagination de l'attaquant dans ce cas.

La cible privilégiée des attaquants reste bien sûr le MBean Server qui permet de gérer toutes les ressources (MBeans) disponibles. Une fois la communication avec le MBean Server établie, un attaquant peut mener à bien la compromission du serveur.

Pour communiquer avec le MBean Server, JBoss propose plusieurs interfaces d'administration, ces fameuses interfaces encore trop peu souvent protégées. Ici, l'article fera un inventaire des différentes interfaces d'administration proposées par JBoss. JBoss en dénombre 4 et sont autant de points d'entrée pour un attaquant:

• La JMX console, la plus connue et la cible privilégiée des pirates puisqu'elle permet d'interagir graphiquement avec le Mbean Server et donc l'ensemble des MBeans.

• La web console qui permet, théoriquement, de n'obtenir que des informations concernant la configuration du serveur.

• L'admin console, disponible depuis JBoss 5, qui réunit les fonctionnalités principales de la JMX console et la web console. Elle est très utile notamment pour le déploiement d'applications à distance sur le serveur.

• Le port 4444 qui permet d'interagir par RMI avec le MBean Server.

L'article rentrera ensuite dans le vif du sujet en décrivant, par un exemple simple, comment un attaquant pourra profiter de ces interfaces pour compromettre le serveur. L'article prendra notamment l'exemple du déploiement d'une application à distance sur le serveur JBoss et décrira précisément chacune des nombreuses techniques d'attaque permettant d'atteindre notre but, dont voici un aperçu.

Dans un premier temps, la solution la plus simple sera abordée c'est-à-dire celle de la JMX console. Si l'attaquant a accès à cette interface, le déploiement d'une application ne peut pas être plus simple. La simple utilisation du MBean offrant ce service via l'interface web de la JMX console permet de réaliser l'opération voulue. Il est à noter que le serveur JBoss doit être autorisé à établir une connexion vers l'hôte hébergeant l'application à déployer.

Lorsque cela n'est pas possible, JBoss propose l'exécution de Java à la volée (scripts BSH) via un MBean particulier. Cette technique peu connue par les administrateurs permet facilement de déployer à distance une nouvelle application sans avoir à initier une connexion vers un hôte distant. Cette technique sera décrite précisement par l'article final.

Lorsque la JMX console n'est pas disponible à cause d'un filtrage ou tout simplement lorsque les mécanismes d'authentification ont été mis en place et que le compte par défaut a été supprimé, que pouvons nous faire? Pas de panique, l'ensemble des MBeans peuvent être manipulés via RMI, à condition que le serveur JBoss est activé les composants RMI (activés par défaut à l'installation). Le port par défaut en écoute est le port 4444. Pour communiquer avec ce port la suite JBoss propose un outil appelé Twiddle réalisant les appels RMI pour nous. Il ne nous reste plus qu'à savoir utiliser l'outil pour appeler les méthodes des MBeans cibles. Cependant, l'outil Twiddle étant incomplet, un outil a été développé en interne par HSC, que décrira l'article final, comblant certaines lacunes.

Il arrive également régulièrement que le port 4444 soit filtré par un pare-feu intermédiaire, notamment lors d'une intrusion externe mais tout n'est pas perdu pour autant. Il existe également d'autres méthodes beaucoup moins officielles permettant d'atteindre notre objectif que décrira plus en détail l'article final.

Dans un premier temps, l'attaquant peut utiliser l'interface web console. Cette interface prévue à l'origine pour réaliser de la simple consultation d'information peut en réalité être mise à profit par un attaquant lorsqu'il y a accès. Pour fournir les informations disponibles sur son interface, la web console utilise une servlet particulière. Elle permet d'invoquer des MBeans et cela ne se limite pas aux seuls MBeans que la web console a besoin. Un attaquant ayant accès à cette interface peut communiquer avec cette servlet pour invoquer n'importe quel MBean. Pour cela, il est nécessaire de générer des requêtes HTTP particulières. Un outil a été développé en interne par HSC pour réaliser cette opération est sera décrit ici.

Finalement, si la web console a été sécurisée par un mot de passe par exemple, il reste une ultime solution qui vise à utiliser une servlet installée par défaut sur les serveurs JBoss: JMXInvokerServlet. De la même manière, l'invocation de cette servlet permet d'interagir avec les MBeans à travers le protocole HTTP. Cette dernière méthode est particulièrement utile lors des intrusions externes où seul l'accès HTTP est généralement autorisé. HSC a également développé un outil en interne qui sera décrit ici.

L'article fera un détour sur les serveurs d'application JBoss 5 et 6 qui corrige un certain nombre de vulnérabilités en améliorant sa configuration par défaut rendant certaines attaques difficiles à mettre en oeuvre. Nous nous intéresserons plus particulièrement à l'interface admin console, la nouvelle interface d'administration, et aux techniques permettant de contourner l'authentification de cette interface (mise en place par défaut).

Après avoir décrit les différents angles d'attaque sur un serveur JBoss, l'article décrira les différents moyens de sécurisation qui peuvent être mis en place pour parer ces attaques et plus particulièrement concernant la configuration du serveur JBoss. Les vulnérabilités présentes au sein d'un serveur JBoss sont souvent le résultat d'une configuration trop laxiste et qui est malheureusement celle par défaut.

Un grand nombre de présentations SSTIC sont dédiées chaque année à l'analyse de code assembleur (x86, ARM, MIPS ou autre).

Ces présentations sont très orientées en direction de la lutte contre le code malveillant ou de la protection logicielle. Mais un sujet rarement abordé est celui de l'audit d'applications commerciales tout à fait "classiques".

Le principal défi lors de l'analyse d'une application commerciale est la complexité. Les développeurs écrivent du code de très haut niveau - dont la traduction en assembleur fait intervenir un nombre considérable de couches intermédiaires.

Comme dit le proverbe, "celui qui a débogué un script Ruby avec GDB est un génie, celui qui l'a fait deux fois est un fou".

C'est pourquoi cette présentation s'attachera à présenter les techniques d'analyse haut niveau applicables à l'environnement .NET. L'exemple de l'audit sécurité du produit Microsoft OCS 2007 sera notre fil rouge.

.

Les terminaux mobiles sont omniprésents dans notre monde actuel sous diverses formes : GPS, téléphones portables, PDAs, etc. Le smartphone est le résultat de la convergence de toutes ces plateformes. Il existe de nombreux systèmes d'exploitation embarqués sur le marché mobile. Windows Mobile, développé par Microsoft, est assez répandu. Par conséquent, il parait essentiel d'analyser le fonctionnement du système d'exploitation mobile de Microsoft, de comprendre les risques et menaces, et d'anticiper les méthodes qui pourraient être utilisées dans le but d'attaquer le terminal et de laisser une porte d'entrée pour un attaquant sans que l'utilisateur légitime du smartphone ne s'en rende compte.

Les mécanismes permettant de compromettre un système et d'y installer des portes dérobées (backdoors) utilisés sur les versions Windows des PC sont disponibles publiquement et sont connus depuis de nombreuses années. La version embarquée du système de Microsoft semble très similaire en surface puisque de nombreuses APIs qui existent dans les version PC de Windows sont également présentes dans Windows Mobile, pour les systèmes embarqués. Cela permet aux développeurs de porter facilement une application de Windows vers Windows Mobile. Cependant, les couches sous-jacentes sont très différentes. Cela explique probablement pourquoi les attaquants n'ont pas encore évolué vers le monde des systèmes embarqués. L'architecture matérielle sous-jacente ARM de type RISC (Reduced Instruction Set Computer) se différentie de l'architecture x86 utilisée sur les PC. Les contraintes du monde de l'embarqué font que la gestion en interne de la mémoire n'est pas du tout semblable à celle des PC. La gestion des appels systèmes a également été implémentée différemment.

Afin de comprendre les risques, plusieurs points devront être analysés. Les différents services offerts par un smartphone devront être compris (téléphone, SMS, GPS, SD-card, etc.). L'environnement réseau devra être considéré étroitement afin d'énumérer tous les vecteurs d'attaque possibles (téléphone, Bluetooth, WLAN, ActiveSync, etc.). Les mécanismes internes du système seront expliqués. Cela permettra de comprendre comment le système peut être compromis (keylogger, interception de SMS, rootkits, ransomwares, etc.). Les mécanismes de sécurité implémentés par Microsoft seront analysés et comparés aux risques. Enfin, de plus en plus d'entreprises antivirus proposent des solutions pour protéger les terminaux mobiles. Il est donc légitime d'essayer de comprendre la protection réelle que ces solutions apportent.

Nous détaillerons les façons d'injecter un rootkit, les mécanismes de furtivité, les possibilités de contrôle à distance, les façons de rendre le rootkit permanent, et les services qu'un attaquant pourrait utiliser sur des terminaux sous Windows Mobile. Ce document se focalisera sur les services qu'un attaquant peut potentiellement contrôler à distance et sur les différentes méthodes de rootkit qui peuvent être utilisées pour masquer ces actions à l'utilisateur légitime du smartphone.

Le projet OsmocomBB consiste à réécrire le microcode de l'interface analogique/numérique tournant sur les téléphones portables. Ce travail nécessite l'implémentation des couches 1 à 3, via la rétro-ingénierie des logiciels du marché. Le but du projet est pouvoir téléphoner en GSM en n'utilisant que des logiciels libres. Cette idée est néée à l'étude des systèmes existant n'implémentant peu ou pas de mécanismes de sécurité.

.