BYOD – The Privacy and Compliance Risks from Bringing Your Own Mobile Device to Work
Winn Schwartau
Winn Schwartau est un des plus grands experts en sécurité, vie privée, infowar, cyber-terrorisme et autre sujet liés.
[Depuis http://www.winnschwartau.com/assets/docs/WSchwartau%20Full%20Bio.pdf]
L’orateur introduit la conférence nous expliquant que BYOD voudrait en réalité dire Breach Your Own Data (trouer ses propres données), insistant sur le fait que le BYOD est un problème de gestion des risques, message qu’il répétera plusieurs fois au cours de la présentation.
Dans les années 90, tout le monde voulait avoir un PC dans son bureau. Tout comme la situation actuelle des smartphones et autre tablettes, les PCs étaient majoritairement des produits grands publics. Les PCs d’entreprises étaient ceux utilisés pour se connecter aux mainframes. A l’époque des analyses de risques ont été faites, et des risques pris.
Le problème aujourd’hui est que les entreprises ont très peu analysé les risques liés à l’introduction des appareils mobiles, d’autant plus ceux des employés. Elles ont entendu parler de ‘supposés’ produits de sécurité dont le but est de gérer ces appareils utilisés pour l’entreprise mais appartenant aux employés. Cependant, malgré la grande vague de popularité de ces produits depuis quelques années, nous observons aujourd’hui que la sécurité ne semble pas être leur objectif premier.
Les principaux OSs mobiles disponible sur le marché sont des OS à utilisateur unique, c’est pourquoi ils ne peuvent pas être administrés ou contrôlés. En effet, le MDM (Mobile Device Management) ne propose pas un contrôle complet de la configuration de l’OS, le Bluetooth par exemple, et utilise les applications natives. Dans le cas du sandboxing, les containers chiffrés utilisés ont été cassés, et voyant le nombre de vulnérabilités dans les navigateurs et les clients mail les plus populaires, comment pouvons-nous nous attendre à ce qu’un éditeur de ‘device management’ en soit exempt ?
Winn Schwartau pense que les organisations finiront par entrevoir les risques induits par la composante légale, comme c’est souvent le cas aux US (où le BYOD est devenu quasi obligatoire pour les grandes entreprises). En effet, malgré le fait que l’organisation ne possède pas l’appareil, elle a la possibilité de l’effacer à distance ou le réquisitionner en cas d’investigation policière par exemple.
En conclusion, il présent un graphique des différentes solutions et leurs risques associées. En le commentant il nous dit que nous aurions probablement dû nous en tenir à la situation dans laquelle nous étions, à savoir : votre appareil personnel et privé et celui de votre organisation, géré plus ou moins comme l’étaient les BlackBerry.
Remoting Android applications for fun and profit
Damien Cauquil, Pierre Jaury
Différentes méthodes existent aujourd’hui pour permettre le débuggage d’une application Android, parmis lesquelles DDMS + JDWP(Dalvik Debugging Monitor Server + Java Debug Wire Protocol) et le logcat Android.
Cependant, ces méthodes requièrent l’utilisation d’ADB, et donnent un accès au bytecode de l’application. Bien que cela permette une modification des variables ou du bytecode, Ces méthodes sont trop limitées pour proposer un reverse engineering efficace.
Le remoting est justement utilisé pour palier à ces manques en fournissant une abstraction du bytecode Dalvik. Ceci permet une meilleure analyse du fonctionnement global de l’application tout en permettant d’outre-passer les restrictions imposées par les développeurs au moment du développement.
Le remoting permet, globalement, de fournir une vision plus haut niveau, plus globale, du fonctionnement de l’application que par le biais d’un debugging standard.
A cette fin, Damien et Pierre ont développé un moyen d’accéder par remoting à une application Android en injectant un service dans l’application. Pas besoins de droits root, ou de debugging USB, la solution peut être utilisée sur un téléphone standard.
Cette solution est constituée de trois composants :
- FINO : composant principal de la solution, injecté en tant que service dans l’application pour intéragir avec celle-ci ;
- GADGET : proxy client, tournant sur le téléphone, permettant d’assurer la redirection des appels réseau vers l’API de FINO ;
- GADGET-CLIENT.
Le composant gadget accédant à l’ensemble des connexions réseau, il peut être utilisé via WiFi, réseau téléphonique opérateur etc…
Les démonstrations commencent par l’ouverture, par le biais de FINO, d’un shell sur le téléphone, la récupération des applications dans lesquelles FINO a été injecté, la récupération de variables définies par les applications et la modification à la volée du titre de l’application.
Le point intéressant mis en avant par cette démonstration est la capacité de FINO d’invoquer des fonctions des applications dans lesquelles il a été injecté, permettant notament un appel à la fonction de déchiffrement de l’application, plutôt que le reverse-engineering de l’application .
L’injection de FINO dans l’application se fait, en théorie du moins, très simplement :
- désassembler l’application,
- désassembler FINO,
- regrouper les deux et ré-assembler le résultat.
Un Proof of Concept amusant est ensuite présenté afin de montrer les exploitations possibles d’une injection de FINO dans les classes de base du système Android, telles que la téléphonie (phone.dial).
Damien et Pierre sont capables d’exploiter cette classe “remoted” afin de fuzzer un IVR (serveur vocal interactif) en lui envoyant différentes séquences de fréquences DTM aléatoires.
Cette capacité ouvre la possibilité de réaliser des tests poussés sur les systèmes IVR sans l’investissement financier important requis actuellement.
Lors de la démonstration, par l’appel du service de messagerie d’une opérateur de téléphonie, l’application est effectivement à même d’envoyer des DTMF, interprétées par le serveur vocal comme des commandes, entrainant un comportement surprenant, bien qu’aucun bug n’ait été soulevé dans ce cas précis.
Le dernier cas présenté est celui de l’injection de FINO dans une application de jeu afin de démontrer sa capacité à parcourir les variables d’une application à la recherche d’une valeur ou d’un motif. Après fiabilisation des données identifiées, les valeurs ont pu être remplacées et le score dans le jeu “remoted” modifié par remplacement des valeurs de ces variables, comme à la grande époque des Action Replay.
Le code des différents composants de ce projet est disponible aux adresses suivantes
https://github.com/sysdream/fino
https://github.com/sysdream/gadget
https://github.com/sysdream/gadget-client
The control of technology by nation state : past present and future.
Eric Filiol
Éric Filiol est un expert français en sécurité informatique spécialisé dans la cryptologie symétrique et plus particulièrement la cryptanalyse, ainsi qu’en virologie informatique opérationnelle. Il est lieutenant-colonel de l’armée de Terre française et a servi comme cryptanalyste militaire au sein de la DGSE1, les services d’espionnage français.
Lors de cette présentation non technique il a essayé de montrer après le scandale PRSIM que l’écoute par les gouvernements n’était pas une chose nouvelle. En effet sans tomber dans la facilité des backdoors chinoises présentes dans les routeurs Huawei, il y a beaucoup d’affaires de backdoor américaine comme dans les routeurs Cisco ou encore dans le logiciel Skype.
Il a ensuite fait un bref retour chronologique sur ce genre d’affaire :
- 1945/1975 : L’ère de la guère froide :
À cette époque la diffusion des nouvelles technologies étaient très controlée, notamment le GPS ou les ordinateurs, ainsi en France on ne pouvait trouver de calculateur en provenance des Etats Unis à cette période. Les backdoors étaient alors hardcodées dans le matériel et nullement dissimulées. Le CoCom (Coordinating Committee for Multilateral Export Control) a été fondé sous l’influence des Etats Unis pour controller au maximum la diffusion des technologies.
- 1975/2001 : La montée du terrorisme :
Les backdoors tel qu’elles étaient utilisées ne sont plus possibles. Le projet Socrates (à l’origine du projet Echelon) est lancé sous l’impulsion de Ronald Reagan en 1982. La cryptologie moderne entre en jeu avec notamment la cryptologie asymétrique (Diffie Helman en 1977 et RSA 1978) même s’il est fort probable que l’état américain la connaissait depuis 40 ans déjà.
- 2001/2012 : La phase de mondialisation :
La technologie de l’information est répendue mondialement, les pays émergents en profitent eux aussi et sont donc considérés comme des terroristes économiques par les grandes puissances, les multinationales sont les nouvelles armes de guerres des états. C’est aussi la montée du phénomène des hackers avec l’ouverture des réseaux et de la cryptologie non militaire (AES256). Les états emploient donc des RedTeam et utilise des malwares étatiques (MagicLantern, LOPPSI….)
- 2012 …. : La phase légale :
C’est la phase de surveillance des masses, chaque citoyen est maintenant considéré comme un criminel. On utilise de nouveaux moyens pour canaliser ce mouvement (DRM, brevet logiciel, guerre des standards). La cryptologie est sous contrôle : d’ailleurs en France on ne peut utiliser un algorithme de chiffrement librement. PRISM !
Malgré un ton librement inspiré des théories du complot, il est intéressant de voir que les états ont depuis longtemps contrôlé la diffusion de l’information. Il est donc important de posséder un état fort informatiquement afin de savoir qui contrôle nos données.
Windows Phone 8 application security
Dmitriy Evdokimov & Andrey Chasovskikh
Les orateurs sont tout deux Russes, développeurs d’application et Windows Phone addicts, l’un deux est aussi le co-fondateur de la conférence DEFCON Russia.
Windows Phone 8 (WP8) est sorti le 29 Octobre 2012, et possède 3,2% du marché, l’OS mobile de Microsoft est toutefois en expansion et l’intérêt qu’il suscite dans le monde de la sécurité en nette augmentation, notamment car le Windows Phone Store contient dès à présent 145 000 applications. Le but de la présentation est de faire une rapide revue du système et de son modèle de sécurité.
La conférence a commencé par une présentation du modèle de sécurité de WP8 :
WP8 est basé sur Windows 8 adapté pour les processeurs ARM, il possède deux niveaux de sécurité pour l’exécution de code :
TCP (Trusted Computing Base) : Niveaux de privilège élevé réservé au code noyau et aux pilotes ;
LCP (Least Chamber Privilege) : Pour tout le reste du code, principalement les applications et services. Ceux-ci ne possède que les permissions qui ont été demandées et acceptées. L’ensemble des permissions d’une application peut évoluer dynamiquement.
Les permissions sont demandées aux seins d’un fichier (comparable à un AndroidManifest.xml) le WMAppManifest.xml. Les permissions qui peuvent être demandées par une application en LCP sont de 3 sortes :
- Developers (pour les applications classique), au nombre de 27, elles regroupent les permissions classiques de type accès réseau/accès SDCARD/ NFC ou Appareil Photo ;
- OEM Developers (pour les applications constructeurs), au nombre de 39, celles-ci ont accès à des privilèges particuliers comme par exemple l’AP de la couche GSM ;
- System (pour les applications System et services Microsoft), plus de 350 permissions différentes comme à l’API SIM et l’activation du mode Debug.
Concernant les applications elles-mêmes :
Comme sur tous les autres OS mobile, les applications sont sandboxées et le système de fichier leur est totalement caché. Il n’y a pas de communication inter-application sauf par échange d’URI, ces URI peuvent être de plusieurs types (http, tel, wallet, NFC, LDAP, rlogin, telnet…). Sur le téléphone, les fichiers « système » de l’application sont dans un dossier séparé des fichiers de base de données (comme sur un système Android par exemple).
Les applications sont des fichiers .XAP , à l’intérieur les fichiers ainsi que les binaires sont signés, il y a un checksum sur chaque fichier et les fichiers XAP contiennent une sorte de clé DRM, rendant ainsi impossible toute attaque de type Man In The Middle depuis un téléchargement de fichier sur le Store. Le format XAP était jusqu’en Aout 2012 un simple archive Zip (à l’instar d’une APK) mais depuis c’est un vrai format de fichier particulier, avec un véritable en-tête, le contenu étant de plus chiffré.
Concernant les vulnérabilités les plus courantes voici un rapide retour :
- SD-Card : Seuls les accès en lecture sont autorisés ;
- Secure Storage : Bitlocker est disponible sur la version entreprise ;
- Le cache du clavier est isolé par application évitant ainsi la fuite d’information ;
- XSS : IE10 est présent par défaut et Javascript est désactivé ;
Concernant les exploitations Kernel celles-ci sont possibles mais très difficiles comme sous tous Windows8.
Analysis of a Windows Kernel vulnerability: from espionage to criminal use
Julia Wolf
Cette présentation s’est intéressée à la vulnérabilité CVE 2011-3402 : Kernel TrueType Font Engine Vulnerability (MS11-097). C’est une vulnérabilité qui été exploitée notamment par le malware Duqu. Comme l’oratrice le fait remarquer en début de présentation, le talk contient 80% de hexdump ainsi un compte rendu est difficile. Le compte rendu s’intéressera donc principalement à la première partie de la présentation qui introduit l’historique de la vulnérabilité.
Cette vulnérabilité a été découverte en Mai 2011 par Kaspersky, l’on suppose qu’elle était exploitée depuis au moins 2010 peut être même depuis 2005. En Août 2011 CrySys découvre le malware Duqu exploitant cette vulnérabilité. Un patch est publié par Microsoft en Décembre 2011.
En octobre 2012 un exploit kit est publié par Blackhole, et depuis environ 6 exploits différents sont publics et les développeurs n’ont quasiment rien modifié (jusqu’aux blagues à l’intérieur du code), si ce n’est l’apparition d’un module 64Bits étant donné que la version présente dans Duqu ne fonctionnait pas sur les OS 64bits.
Nous ne saurions que trop recommander de regarder les slides de cette présentation pour une approche approfondie de la vulnérabilité.
The Security of MDM (Mobile Device Management) systems
Sebastien Andrivet
Sébastien Andrivet est un expert de la sécurité applicative et la forensics, se spécialisant plus récemment sur les plateformes mobile (celle d’Apple plus particulièrement).
[Depuis https://www.hackinparis.com/speaker-sebastien-andrivet]
Il existe une grande sélection de diffèrent OS mobiles, et afin de les gérer, le département IT d’une organisation aura besoin d’un solution comme du Mobile Application Management (MAM), Mobile Content Management (MCM) ou du Mobile Device Management (MDM). L’orateur se focalisera sur le dernier pour cette présentation.
Les solutions MDM sont utilisées pour plusieurs fonctions, comme : garder un inventaire des appareils, gérer les configurations des OSs, gérer les dépenses téléphoniques, suivre la géolocalisation des appareils, sauvegarde et restauration, effaçage et verrouillage à distance, ou déploiement d’applications.
La sécurité des solutions disponibles semble être un des arguments marketing majeur pour leurs éditeurs, et en effet, en cherchant sur Internet, il semble qu’il n’y ait que très peu de problèmes.
Le but de ses recherches était donc de voir s’il est possible ou non de voir et/ou voler les informations des utilisateurs par un administrateur des solutions. Ces tests seront ciblés sur l’installation/déploiement de la solution, l’enregistrement des appareils, l’interface d’administration, et ce avec GoodTechnologies et MobileIron.
En ce qui concerne la configuration du réseau de l’organisation, MobileIron requiert l’ouverture d’une dizaine de ports sur le firewall, tandis que Good Technologies n’en a besoin que de deux. Pour la configuration d’Exchange, MobileIron fait passer les utilisateurs par un proxy Exchange (Sentry), alors que Good Technologies a besoin d’avoir un accès quasi complet aux données Exchange, ce qui veut dire qu’un administrateur peut lire les e-mails des utilisateurs sans qu’ils soient prévenus, comme ils peuvent désactiver les alertes.
Enfin pour la partie administration, les deux solutions sont vulnérables au failles de types XSS et CSRF. Il est possible d’accéder aux mots de passe des utilisateurs, leurs mots de passe LDAP ainsi que d’effacer celui de verrouillage des appareils. Toujours sur MobileIron (l’orateur semble avoir focalisé ses cherches sur cet éditeur), les mots de passe des administrateurs (pas de LDAP pour eux) et des utilisateurs (même ceux de LDAP sont conservés pour une meilleure expérience utilisateur !!) sont mal sécurisés et peuvent être récupérés facilement. Le mécanisme de chiffrement n’est pas exactement le même, mais dans les deux cas il utilise des clés hardcodées et présentes dans toute les installations de la solution.
Malheureusement ce ne sont pas les seuls problèmes. Il cite également une faible détection du jailbreak, des fuites du keychain d’iOS avec MobileIron, etc.
Il conclut en insistant sur le fait que le choix d’une solution dépend du contexte de déploiement, que les configurations recommandées sont loin de mettre la sécurité en avant, et qu’il est donc très difficile de dire quelle solution est meilleure.
Il ajoute également qu’il regrette vraiment que les deux éditeurs, qu’il a contacté, n’aient pas été intéressées par ses résultats.
Burp pro : Real-life tips and tricks
Nicolas Grégoire
Nicolas Grégoire intervient lors de cette conférence pour présenter les capacités offertes par la suite Burp Pro pour automatiser, réduire ou améliorer le travail d’un pentester.
S’il annonce qu’il n’est aucunement lié à PortSwigger ltd., et en dépit de la confiance que je peux avoir en Nicolas Grégoire, ce talk commence à ressembler à de la publicité pour la solution plus qu’à une présentation.
La solution, supportant beaucoup de formats et réputée pour sa capacité à se voir adjoindre diverses extensions permet de modifier les requêtes à la volée sans avoir à se soucier de l’encodage des données et autres charsets etc… C’est bien beau, mais on le sait.
Cependant, au bout d’une quinzaine de minutes, il commence à aborder d’autres capacités de la solution. A partir de là, il me reste 25 minutes pour constater à quel point j’étais de mauvaise foi. La présentation enchaine les fonctionnalités avancées, les extensions, les mises en situation et les exemples, parmis lesquelles :
- présentation d’extensions pour désobfusquer du code javascript (http://code.google.com/p/burp-suite-beautifier-extension et https://github.com/Meatballs1/burp/jsbeautifier )
- génération d’une commande curl pour l’automatisation
- l’automatisation de prise en charge de tokens anti-CSRF
- présentation de diverses extensions (détection de reverse-proxy, prise de note etc… )
A la sortie de cette conférence, on sait que Burp est un excellent outil (et que je suis de mauvaise foi), mais ceux qui le savaient déjà ont maintenant une bonne quantité d’exemple pour en être persuadés.
Les slides de cette présentation sont disponibles ici : http://t.co/z2rj2enGPG
Pwning Google Chrome Extensions
Krzysztof Kotowicz
Les extensions sont à différencier des plugins (Java, Silverlight….), ce sont des programmes à part entière comme des programmes de Adblocking, ou de développement. Ces extensions ont beaucoup plus de privilèges qu’une simple page web, elles peuvent avoir accès aux cookies (en lecture/écriture), aux paramètres du proxy, bloquer des requêtes (http). De plus celles-ci ne sont pas sandboxées, c’est donc une cible potentielle d’attaques.
Typiquement les applications se présentent sous la forme d’un .CRX qui est un zip chiffré par le certificat du développeur à la manière d’un .APK pour Android. Elles s’installent via le Chrome Web Store. Elles sont composées d’un Manifest (demandant les permissions), d’un content_script, d’une view page (page affichée par l’extension elle-même) et parfois d’un binaire NPAPI.
Le content_script est développé en JavaScript et a accès au DOM de la page web visitée mais pas au JS. La ViewPage envoie des requêtes et reçoit les réponses du content_script et peut faire des evals. La ViewPage peut aussi accéder aux ChromeAPI ainsi qu’au binaire. Il y a donc une séparation des pouvoirs entre le content_script et la ViewPage.
Pour attaquer les extensions, la méthode la plus simple reste une DOMXSS dans la ViewPage. Si par exemple la viewpage fait une requête au content_script pour récupérer le title de la page. Ainsi il est possible de former une page web avec une balise <title>bad title ‘-alert(1)-’</title>. Celui-ci est attrapé par le content_script qui est récupéré par la ViewPage et ensuite une XSS est déclenchée.
Une autre attaque permet d’envoyer des informations directement au NPAPI. Ainsi il est possible de faire des exploitations de type BufferOverflow dans le binaire. Un exploit a été montré sur une extension permettant de faire du gpg directement dans Gmail, ainsi il était possible d’envoyer directement des commandes système depuis une page web vulnérable.
La présentation s’est achevée par la présentation d’une nouvelle version du manifest (V2) qui permettrait d’empêcher ce type d’attaque. Celui-ci sera effectif en Septembre 2013.
Compte-rendus par Geoffrey Bertoli, Brice Duprieu et Yannick Fournel.