La Lettre du CERT-Solucom

n 3 - octobre 2014 La Lettre du CERT-Solucom Dossier : ios Forensics 101 et cas concret d utilisation Depuis plusieurs années, l usage des terminaux mobiles dans le cadre de l entreprise suscite un intérêt croissant. iphone et ipad, plus particulièrement, sont devenus les terminaux préférés des VIP et commerciaux : simples, beaux, «à la mode», ces terminaux n en sont pas moins un canal d accès aux données, souvent sensibles, du système d information d une entreprise. Avec des usages parfois éloignés des bonnes pratiques de sécurité, iphone et ipad deviennent la proie d attaquants, en particulier à des fins d espionnage : activation du microphone pour écoute ambiante, vol de photos (comme l a démontré l actualité récente), vol du calendrier, accès aux SMS/MMS échangés Face à cette tendance, les équipes d investigation sont de plus en plus confrontées à cette question : «mon téléphone est-il compromis?». Cet article a donc pour objectif de dresser un panorama des différents moyens d investigation à la disposition d un analyste, et ce depuis la phase de collecte des preuves, jusqu à la réalisation de l analyse technique en tant que telle. Introduction ios et sécurité Le développement rapide du marché des smartphones ces dernières années a profondément transformé la vie des utilisateurs, tant dans leur utilisation personnelle que professionnelle. Véritables ordinateurs de poche, ces appareils n en restent pas moins une cible pour des attaquants ou des utilisateurs mal intentionnés, d autant plus que l aspect sécurité est encore assez méconnu sur ces terminaux. L actualité de la sécurité ios a été mouvementée ces dernières semaines. Tout le monde a en tête le désormais célèbre «Goto fail; Goto fail;» qui offrait la possibilité d une attaque de type «Man in the Middle» [1]. De plus, diverses vulnérabilités (41 exactement) ont récemment été mises en évidence [2] et corrigées par Apple, ce qui aura valu deux mises à jour de son système ios en quelques semaines (7.0.6 et 7.1) [3]. Une étude récente de la société FireEye nous rappelle aussi que, même si un terminal ios n est pas jailbreaké, certaines applications en apparence totalement inoffensives sont tout de même en mesure de faire de la surveillance de fond [4]. A lire également P14 Dossier : Délégation Kerberos et transition de protocole P19 Retour sur l actualité

L objectif de cet article est de présenter une méthodologie de détection simple de la présence d un malware sur un terminal ios à l aide d outils open-source. Dans un premier temps, les différentes techniques d acquisition des données seront présentées puis, dans un second temps, les méthodes d analyse des données ainsi collectées seront détaillées. Mener une investigation sur un iphone, dans quel intérêt? De plus en plus d investigations numériques sont réalisées sur des iphones, en particulier afin d enquêter dans le cadre de : Une suspicion d un possible espionnage : dans certaines situations sensibles, la défaillance technique d un terminal peut représenter un signal faible d incident de sécurité. Par exemple, si l iphone d un membre du COMEX a un comportement étrange (perte de synchronisation à la messagerie, lenteurs excessives ) au moment même où par exemple un appel d offre important est à l étude, il se peut que l entreprise ait à faire face à un cas d espionnage. À noter que ce scénario tend à se généraliser étant donné que les cadres/vip, cibles privilégiées pour un attaquant, utilisent presque uniquement des terminaux ios (iphone/ipad). Une infection : un mobile peut se retrouver infecté par un programme malveillant qui va effectuer des actions non désirées par son propriétaire. Cela va provoquer par exemple l envoi de sms ou l émission d appels surtaxés à l insu de l utilisateur. Le site «viruslist.com» a conduit une étude particulièrement intéressante dans ce domaine pour l année 2013 [5]. Une perte de données : un utilisateur peut avoir malencontreusement supprimé un ou plusieurs fichiers sur son téléphone qu il souhaite récupérer. Dans le contexte de cet article, il sera admis comme hypothèse que toute donnée utilisateur nécessaire au bon fonctionnement de l investigation (code PIN, mot de passe, etc.) pourra être directement obtenue auprès de l utilisateur. Connaître l environnement Pour mener à bien une investigation, il est nécessaire de connaître l environnement dans lequel l investigateur travaille. En ce qui concerne Apple et ios, il est important de se familiariser avec les mécanismes de sécurité implémentés sur les terminaux ios. Apple propose un éventail de fonctionnalités pour garantir à ses utilisateurs un environnement sécurisé [6] : Sécurité des appareils : méthodes empêchant toute utilisation non autorisée de l appareil (verrouillage par mot de passe ou TouchID, MDM, restrictions d utilisation, etc.). Sécurité des données : protection des données grâce aux mécanismes de chiffrement de disque de Data Protection (chiffrement de certaines données grâce au mot de passe utilisateur). Sécurité des échanges : protocoles de chiffrement (SSL, TLS). Sécurité des applications : signature par Apple, Data Protection. Il existe cependant certaines failles qui permettent encore de contourner ces mécanismes de sécurité. Ainsi Jonathan ZDZIARSKI, expert en sécurité ios, nuance la sécurité du mécanisme de chiffrement des appareils ios [7]. D autres experts ou groupes de pirates [8] avancent également des techniques permettant le contournement de TouchID. La sécurité des applications est elle aussi remise en cause. Une équipe de recherche du Georgia Institute of Technology a en effet réussi à publier une application «Jekyll» en passant entre les mailles de l Apple Store. Cette application, bien que signée par Apple, avait la possibilité d exécuter des actions malveillantes (vol d informations, publication d informations contre le gré de l utilisateur, etc.) une fois installée [9]. Lors de la sortie de l iphone en 2008, ce dernier était très peu sécurisé [10]. Cependant, de nombreuses améliorations ont été apportées depuis et l iphone est l un des systèmes les plus sécurisés. La sécurité était même au cœur des annonces dans la keynote d Apple début juin. 1. Méthodologie d investigation sur iphone La méthodologie d investigation sur iphone est de manière générale assez similaire à une investigation classique, à savoir documenter chaque action et prendre garde à préserver l intégrité des preuves. Comme toute investigation, les actions réalisées peuvent entraîner l accès à des données à caractère personnel : les différentes contraintes légales et réglementaires doivent être respectées. Les deux principales actions qu un investigateur aura à effectuer sont l acquisition d une image et l analyse de celle-ci. Figure 1 : processus d acquisition et d analyse d une image 2. Acquisition L acquisition est l étape visant à acquérir une image de l appareil. En termes d investigation forensic, il existe deux types d acquisitions possibles : logique ou physique. Chaque acquisition présentant des avantages et inconvénients, il convient pour l investigateur de bien choisir au préalable la méthode qu il souhaite utiliser. La première partie est consacrée à l étude du jailbreak, mécanisme requis dans le cadre de certaines acquisitions mais pouvant présenter des risques de perte d intégrité des données sur le terminal à analyser. La seconde partie est centrée sur le principe d acquisition logique alors que la dernière partie décrit le processus d acquisition physique. 2.1. Jailbreak Le jailbreak est un prérequis de certains types d acquisition. L usage de cette technique peut poser d importants problèmes (en particulier de validité des preuves selon les juridictions cibles), car elle altère potentiellement l intégrité des fichiers présents sur le terminal mobile. 2 La Lettre CERT-Solucom N 3 octobre 2014

L une des principales restrictions de l iphone pour un investigateur est l incapacité d exploiter toutes les fonctionnalités que peut offrir le terminal mobile et de devoir se limiter, par exemple, à une interprétation non exhaustive du système de fichiers par ios. Pour exploiter ces fonctionnalités, il faudrait pouvoir se placer en parallèle d ios. Cependant, le démarrage de l iphone se fait par «bootstrapping», c est-à-dire le chargement successif de programmes de complexité croissante : boot ROM, low-level bootloader (LLB), iboot et enfin le kernel ios. Apple ajoute en surcouche une vérification du programme exécuté par le programme précédent empêchant alors de remplacer l un d eux. Le jailbreak passe par la compromission au moment de l exécution du kernel ios afin d exécuter du code arbitraire et permettre notamment aux utilisateurs d utiliser une version «libérée» d ios autorisant, entre autres : l installation d applications non signées Apple, l exécution d applications en utilisateur root, etc. Il est important de noter que le jailbreak d un iphone peut sérieusement compromettre l intégrité des données présentes sur le téléphone et rendre caduque toute preuve obtenue à la suite de cette étape. Pour un investigateur, il ne s agit donc pas d une technique d acquisition «standard» et elle ne doit pas être retenue dès lors que des preuves formelles sont requises. En revanche, s il s avère que le téléphone de l utilisateur est déjà jailbreaké avant l analyse, il est envisageable d avoir recours à cette méthode. D un point de vue utilisateur, le jailbreak se traduit en particulier par l apparition de l application Cydia, AppStore alternatif de l iphone. L étape suivante pour l investigateur est d installer l application OpenSSH. Une fois installée, il est possible d ouvrir une connexion SSH vers l iphone de la manière suivante, en utilisant le compte par défaut «root/alpine» : Si l iphone est connecté en Wi-Fi, la connexion se fait sur le port 22 et l IP du terminal mobile. Sinon, en utilisant le script Python tcprelay.py fourni par usbmuxd (choisir une version contenant le dossier python-client), un tunnel SSH est établi entre un port local et le port 22 de l iphone. limité, cet espace n est pas accessible par le biais d une acquisition logique. Il existe deux types d acquisition logique qui sont présentés dans les parties suivantes : par les sauvegardes itunes, par une extraction logique exhaustive. Figure 3 : visualisation de l espace résiduel 2.2.1. Acquisition d une sauvegarde itunes itunes est le logiciel permettant la synchronisation d un appareil ios avec un ordinateur. L utilisateur peut alors transférer du contenu depuis son ordinateur vers son appareil mobile. Mais l inverse est aussi possible, et c est cette fonctionnalité qui va nous intéresser lors d une investigation. En effet, Apple a créé une fonctionnalité permettant de restaurer facilement un iphone depuis une sauvegarde. En plus de pouvoir transférer tous types de fichiers sur son ordinateur personnel depuis son iphone, l utilisateur a aussi la possibilité de stocker des images logiques de son appareil à chaque connexion, pour avoir à sa disposition une sauvegarde de son système en cas de problème. Par défaut, l option «sauvegarder automatiquement» est activée sur itunes, ce qui autorise la création automatique d une sauvegarde lors de la synchronisation de l iphone à l ordinateur. De plus il est intéressant de noter que l option «chiffrer la sauvegarde de l iphone» est désactivée par défaut. Cela permet de récupérer facilement les sauvegardes pour un attaquant qui aurait compromis l ordinateur d une victime. Figure 2 : connexion à l iphone Utiliser un jailbreak non persistant pour iphone serait moins intrusif et permettrait d arriver aux mêmes fins. Cependant cette méthode n est pas fournie par les outils à la disposition d un investigateur hormis via certaines suites logicielles payantes ou la méthode de Jonathan ZDZIARSKI [11] réservée aux forces de l ordre. 2.2. Acquisition logique L acquisition logique permet à l investigateur de récupérer une copie du système de fichiers actifs de l appareil. Contrairement à une acquisition physique, seule la compréhension de l unité de stockage par le système d exploitation est accessible. Par exemple, lors de la création d un fichier, si la taille de ce fichier n est pas un multiple de l unité minimale d allocation («cluster»), alors l espace restant non utilisé est susceptible de contenir un extrait d un fichier plus gros qui aurait occupé ces blocs auparavant. Comme l accès physique au disque est Figure 4 : sauvegarde de l iphone via itunes Sur Windows7 (itunes 11.1), les sauvegardes sont stockées dans le dossier : «C:\Utilisateurs\<utilisateur>\AppData\Roaming\AppleComputer\ MobileSync\Backup». Elles se présentent sous la forme d un dossier dont le nom est le numéro d identifiant unique de l iphone correspondant (UDID). Figure 5 : visualisation d une sauvegarde générée par itunes sur Windows La Lettre CERT-Solucom N 3 octobre 2014 3

Lorsque l appareil physique n est pas disponible, il est possible d utiliser la dernière sauvegarde du smartphone stockée sur ordinateur pour l analyser. La sauvegarde fournit des informations sur un smartphone qui ne sont pas à jour (seules les données disponibles à la date de la sauvegarde sont accessibles) et potentiellement compromises, mais permet d obtenir déjà beaucoup d informations sur un utilisateur. Pour confirmer que l investigateur utilise une sauvegarde du bon iphone avant toute analyse, le fichier info.plist doit être analysé. Figure 6 : fichier info.plist (PList Editor) Si la sauvegarde est chiffrée, il est nécessaire de récupérer le mot de passe auprès de l utilisateur (ou de bruteforcer le mot de passe de la sauvegarde) et d utiliser des outils spécifiques tels que backup_tool. py fourni par iphone-dataprotection [12] permettant d obtenir une sauvegarde en clair. Figure 7 : résultat d une tentative de visualisation d une sauvegarde chiffrée L analyste peut également réaliser une nouvelle sauvegarde itunes s il est en possession du terminal. Le principe d acquisition est le même que précédemment décrit. L avantage de cette méthode est qu elle garantit d une part le caractère «à jour» des données obtenues, et d autre part certifie que la sauvegarde obtenue n a pas été compromise depuis son extraction. 2.2.2. Extraction logique exhaustive L acquisition logique via une sauvegarde itunes ne permet pas d obtenir l exhaustivité du système de fichiers, mais seulement un extrait sélectionné par l ios. De nombreuses applications peuvent présenter dans leur fichier de configuration (.plist) des chemins vers d autres fichiers (configuration plus précise, logs, etc.) qui ne feront pas partie de la sauvegarde. L accès complet au système de fichiers permet donc d obtenir plus d informations que l exploitation de la sauvegarde itunes. Les fichiers présents sur l iphone sont regroupés en deux partitions : /dev/disk0s1s1 montée en read-only sur / : c est la partition «System». /dev/disk0s1s2 montée en read-write sur /private/var : c est la partition «Media». À travers les sauvegardes itunes, l utilisateur accède à une partie des fichiers de la partition «Media», qui est en fait une sélection de sous-dossiers qu il est possible de retrouver sur le système de fichiers : /private/var/mobile/library : contient des données utilisateurs tel que l historique des appels, les sms, les contacts, etc. /private/var/mobile/documents : contient des documents utilisés par des applications qui ne sont pas interprétées en tant que préférences (logs par exemple). /private/var/mobile/media : contient les données media utilisateur (photos, vidéo, etc.). /private/var/db/lsd : contient les données relatives aux services. /private/var/mobiledevice/provisioningprofiles : contient les données relatives aux différents profils (configuration et provisionnement) stockés sur le smartphone. /private/var/managedpreferences/mobile : contient certains fichiers de paramètres. /private/var/preferences/systemconfiguration : contient des fichiers de paramètres du système. /private/var/keychains (pour les fichiers TrustStore.sqlite3 et ocspcache.sqlite3) : contient les données relatives aux certificats et aux mots de passe de l utilisateur. Une acquisition exhaustive se fait alors par le biais de la connexion SSH en copiant un à un les fichiers (SCP, sftp, etc.). Il faut cependant prendre garde : À la copie sur un système de fichiers type NTFS qui ne recopiera pas correctement les liens symboliques qui peuvent être présents. Il faut donc préférer un système de type UNIX. À la copie du dossier /dev qui contient les disques physiques sous les formats «block special» et «character special». Ce répertoire est donc à exclure de la copie. 2.3. Acquisition physique L acquisition physique permet à l utilisateur de récupérer une copie bit à bit du disque de l appareil. Cependant, contrairement à un ordinateur, il n est pas possible de retirer aisément le disque et d en faire une copie, ce qui complique la tâche pour les investigateurs. Malgré cela, l acquisition physique reste la méthode la plus complète puisqu elle donne accès à l ensemble du disque, et notamment aux données supprimées. 2.3.1. Utilisation de suites logicielles Certaines suites logicielles peuvent permettre l acquisition d une image bit à bit sans jailbreak. Elles procèdent en injectant un firmware alternatif en mémoire, de manière à conserver l intégrité de la partition média. Aujourd hui, les outils existants sont développés et réservés aux forces de l ordre. Cependant, certains éditeurs proposent des suites logicielles permettant d acquérir des images physiques d un iphone. Les plus reconnus en matière d investigation iphone incluent : ixam (environ $3000). 4 La Lettre CERT-Solucom N 3 octobre 2014

.XRY (nécessite un iphone jailbreaké). Elcomsoft (environ $1500) 2.3.2. Acquisition par l investigateur via dd dans le cas d une méthode par jailbreak Cette méthode d acquisition nécessite que l iphone soit jailbreaké pour établir une connexion SSH. Le but est de lancer la commande dd à distance et de récupérer les données sur un poste de travail. Lors de la copie de données bit à bit, il est possible de copier le Figure 8 : copie bit à bit du disque complet via USB disque complet (/dev/rdisk0), ou une partition précise (System sur / dev/rdisk0s1s1 ; Media sur /dev/rdisk0s1s2). Il est important de noter que la partition Media est chiffrée à l aide de la clé «EMF». Actuellement, il n existe pas d outils publics permettant de récupérer cette clef au-delà d ios 5. Par conséquent, pour les terminaux ios 6/7, les données récupérées sur la partition Media par le biais de cette méthode ne sont pas exploitables : seuls les noms de fichiers sont accessibles. Pour parcourir la partition, il est possible d utiliser The Sleuth Kit [13] ou hfsplus [14]. 2.4. Conclusion sur les méthodes d acquisition Le tableau suivant récapitule les avantages et inconvénients des différentes méthodes d acquisition possibles pour un investigateur. D un point de vue analyse forensics, il est donc recommandé d utiliser soit l analyse d une sauvegarde itunes à jour qui privilégie l intégrité des fichiers aux dépens de l exhaustivité de la recherche, soit l utilisation d une suite logicielle dédiée, qui se révèle être bien souvent assez onéreuse. Cependant, une acquisition logique complète voire physique peut être effectuée si le téléphone est déjà jailbreaké. Il faut bien sûr toujours considérer le cadre légal avant tout et prendre des dispositions si nécessaire (appel à un huissier, création de copies supplémentaires, etc.). La Lettre CERT-Solucom N 3 octobre 2014 5

3. Analyse Une fois l image acquise, il est possible de procéder à l analyse. Cette seconde partie de l article sera centrée sur l analyse d une sauvegarde acquise via itunes grâce à l utilisation de logiciels gratuits ou opensource. Ces logiciels permettent de visualiser le contenu des fichiers stockés dans une sauvegarde itunes et offrent à un investigateur une bonne vision logique de la partie «media» stockée sur l iphone. Cette section a pour but de présenter les différents fichiers «clés» à analyser pour détecter la possible présence d un malware sur l iphone. 3.1. Système Certains fichiers de configuration du système peuvent fournir des informations à l investigateur sur la présence d éléments suspects. Les trois premiers fichiers importants à vérifier lors de l analyse d une sauvegarde de l iphone sont les fichiers manifest.plist, info.plist et status.plist : Manifest.plist : ce fichier fournit des informations sur les applications et sur la sauvegarde (activation du chiffrement, présence d un mot de passe, etc.). 3.1.1. Bases de données La plupart des fichiers présents sur le terminal mobile peuvent être répartis en deux catégories : Les fichiers de configuration, dont l extension est.plist. Les fichiers de stockage de données, dont les extensions sont.db,.sqlite,.dbsqlite,.sqlite3, etc. Ces bases de données sont au format SQLite3, format où la suppression de données dans une table n entraîne pas immédiatement l effacement de ces données dans le fichier de base données. Il est donc possible de retrouver d anciens enregistrements en observant les chaînes de caractères présentes dans le fichier. 3.1.2. Journaux d exécution système Les journaux d exécution système de l iphone correspondent aux journaux Syslog des systèmes Unix, référençant alors les événements systèmes qui se sont déroulés sur le terminal mobile (applications lancées et arrêtées de manière brutale, connexions aux bornes Wi-Fi, etc.), auxquels sont rajoutés des événements générés par les applications tels que les URLs visitées et cookies associés, mais également les messages renvoyés par un appel à console.debug. Les événements retracés dans ce journal peuvent donc permettre de suivre le déroulement d une application malveillante. Figure 9 : contenu du fichier Manifest.plist L acquisition de ces journaux requiert l utilisation du logiciel Apple Configuration Utility, disponible au téléchargement gratuitement sur le site d Apple. Info.plist : ce fichier fournit les informations sur le smartphone (nom, IMEI, applications installées, etc.). 3.1.3. Profils Un profil de configuration est un fichier XML qui permet de définir des informations de configuration. Il est particulièrement utilisé par les MDM pour configurer un large nombre de terminaux ou pour définir des réglages personnalisés en termes d email, de réseau ou de chiffrement par exemple. Figure 10 : contenu du fichier Info.plist Status.plist : ce fichier fournit des informations sur la sauvegarde (version, date, etc.). Figure 11 : contenu du fichier Status.plist Les profils de configuration sont très importants à vérifier et à valider. En effet ils représentent un vecteur d attaque particulièrement attractif pour un attaquant [15]. Par exemple, un attaquant pourrait forger un profil malicieux lui permettant de déchiffrer les flux HTTPS émanant d un iphone en : Installant un profil malveillant contenant un certificat généré au préalable. Détournant le trafic réseau vers son serveur malveillant. Présentant son propre certificat à l iphone lors de l initialisation d une communication chiffrée. Ces profils sont situés dans le dossier «HomeDomain\Library\ ConfigurationProfiles». Identifier des profils qui ne devraient pas être installés sur un mobile permet d abonder dans le sens d une compromission. Les champs «InstallDate» et «InstallOptions» peuvent aider l investigateur à déterminer le rôle du profil. Ces différents fichiers permettent de valider l état du téléphone au moment de la réalisation de la sauvegarde. 6 La Lettre CERT-Solucom N 3 octobre 2014

Sur l iphone : dans le dossier /root/library/lockdown/pair_ records. L accès à ce dossier peut nécessiter un jailbreak. Sur l ordinateur cible : dans le dossier %APPDATA%/Apple Computer/Lockdown. Les conventions de nommage de ces fichiers sont telles qu un identifiant unique pour chaque terminal est utilisé comme nom de fichier. Par exemple, l identification de l iphone sur l ordinateur se fait grâce à l UDID attribué à l iphone (qui peut être récupéré dans itunes). Par conséquent, si le périmètre de l analyse forensicsinclut un ordinateur suspect, la simple vérification du nom de fichier présent sur cet ordinateur peut prouver l existence d une connexion passée avec l iphone. Figure 12 : exemple de profil de configuration De même, les profils d approvisionnement se présentent sous la forme de fichiers de type PLIST. Ils permettent de faire le lien entre un certificat, un identifiant d application et des périphériques. Cela permet de sécuriser la diffusion d applications. Par défaut, il ne doit donc pas y en avoir sur le téléphone. La présence d un de ces profils serait donc fortement indicatrice de la présence d un malware (ou d une utilisation non standard du terminal). Dans le cadre d un système de Mobile Device Management, un profil de configuration peut cependant être déployé sur le smartphone sans pour autant apporter des suspicions sur la présence d un malware. Ces profils sont situés dans le dossier «MobileDeviceDomain/ ProvisioningProfiles». 3.1.5. Autres ressources D autres ressources permettent d évaluer le niveau de confiance qu il est possible d avoir dans le terminal : La base de données «itunesstored.sqlite.db» contenue dans le dossier «HomeDomain/Library/com.apple.itunesstored/» fournit des informations sur les applications ayant accès aux micro-paiements. La table ZMICROPAYMENTCLIENT recense les applications pouvant accéder à cette fonctionnalité. Le champ ZIDENTIFIER est à analyser. Figure 14 : applications ayant accès aux micro-paiments L application «candycrushsaga» est ainsi en mesure de réaliser des micro-paiements. Les données d utilisation relatives aux réseaux Wi-Fi et aux réseaux mobiles sont à analyser : Le fichier «com.apple.wifi.plist» situé dans «SystemPreferencesDomain» renseigne sur les réseaux connus par l appareil. Il est intéressant de les relever, notamment les réseaux publics, sur lesquels les vecteurs d attaque sont plus importants (Man in the Middle par exemple). Figure 13 : visualisation d une partie d un profil d approvisionnement 3.1.4. Certificats d appairage Lors de la première connexion entre un terminal mobile et un terminal de bureau, l utilisateur doit déverrouiller le terminal mobile afin d autoriser le transfert de données. Pour faciliter les futurs échanges, chaque terminal reçoit un certificat qui permet de connecter un iphone à son ordinateur sans devoir le déverrouiller. Au-delà de la simplification des acquisitions que requiert l analyse forensic, ces certificats sont également une preuve qu une connexion a un jour été établie entre les deux terminaux. Ces certificats sont présents : Figure 15 : visualisation du fichier «com.apple.wifi.plist» La Lettre CERT-Solucom N 3 octobre 2014 7

Les fichiers contenus dans le dossier «WirelessDomain» contiennent les informations liées à l utilisation des connexions réseaux Wi-Fi ou mobiles (GPRS, EDGE, UMTS, etc.). Ces fichiers permettent d identifier les applications ayant généré des flux réseaux. 3.2.1. Sandboxes Figure 16 : visualisation de la table ZPROCESS du fichier «DataUsage.sqlite» De manière générale, les fichiers de base de données peuvent fournir des informations qui ne sont pas triviales à première vue. En prenant l exemple des appels téléphoniques, il est possible de visualiser la base de données «call_history.db», qui se présente sous la forme suivante : Figure 18 : explication du mécanisme Sandbox [16] Les applications sont organisées sous forme de Sandboxes. L intérêt est de limiter l accès aux ressources pour ne pas être en mesure de modifier des réglages au niveau système. Il est alors possible de visualiser les différents fichiers associés à une application pour vérifier si certains paramètres peuvent être suspects ou non. Figure 17 : base de données «call_history.db» Figure 19 : visualisation des différentes Sandboxes des applications Par exemple, l application «RealFlashlight» ci-dessus utilise un document «com-facebook-sdk-appeventspersistedevents.json». Il peut être intéressant de comprendre pourquoi une application lampe torche aurait besoin d avoir accès au SDK de Facebook. Il est cependant compliqué d exploiter ce fichier, il nécessite de coupler les informations de la table «call» à celles des «triggers». Il est ainsi possible de déterminer précisément d où (pays/réseau) un appel téléphonique a pu être réalisé. Ces différentes bases de données listent les actions effectuées sur le téléphone. Leur analyse peut donc aider un investigateur à obtenir des pistes sur une action qui serait effectuée contre le gré d un utilisateur. Dans le cas où les appels seraient mis sur écoute par lancement automatique d une conference call dès réception d un appel, le fichier call_history.db montrerait que chaque appel entrant est suivi de près par un appel sortant et que les deux appels se déroulent au même moment. Cette méthode étant particulièrement peu discrète, la probabilité d usage par un attaquant est relativement faible. 3.2. Applications Une fois les fichiers systèmes analysés, l étape suivante est l analyse des fichiers relatifs aux applications. La plupart des malwares sous ios prennent la forme d applications totalement légitimes en apparence. Dans ce cas il s avère que l application utilise simplement la fonctionnalité «App Events» [17] du SDK Facebook pour optimiser son système de publicité. 3.2.2. Préférences Chaque application utilise ses propres fichiers de préférences. Il est important de parcourir ces fichiers pour essayer d identifier les options activées pouvant indiquer la présence d un malware. Chaque application a recours à des fichiers de préférences différents, il faut donc prendre le temps de parcourir ceux-ci car ils seront toujours différents d une application à une autre. Figure 20 : fichier de préférences de l application RealFlashLight 8 La Lettre CERT-Solucom N 3 octobre 2014

3.2.3. Droits d accès Le fichier «TCC.db» fournit des informations sur les applications qui ont recours à des services ne leur étant pas propres. Il est donc possible de repérer certaines applications qui auraient des droits d accès trop intrusifs dans le smartphone d un utilisateur. 3.3. Données d utilisation Les dernières données à utiliser sont les données d utilisation. La présence d un malware sur un smartphone a souvent pour but d accéder à des informations confidentielles stockées sur ce dernier. Les données privilégiées vont être les messages, les mails, le répertoire des contacts, les calendriers, les photos, etc. Figure 21 : liste des clients requêtant les services d accès Il faut donc dans un premier temps analyser les différents fichiers de configuration régissant les comportement des différentes applications pour voir s il est possible de repérer des réglages qui pourraient être suspects ou modifiés. Ici, on peut voir que l application «RealFlashlight» a requêté l utilisation du service «ktccservicemicrophone», mais le système ne l a pas autorisé. Cela signifie que l application a demandé de pouvoir acquérir les droits sur le microphone, mais que l utilisateur lui a refusé. Ces différents fichiers sont présents dans le dossier «HomeDomain/ Library» : L historique des recherches effectuées sur Safari ainsi que les pages 3.2.4. Caches Les caches des applications sont des éléments importants à analyser. Ils peuvent notamment contenir les requêtes HTTP initiées par l application (par défaut, la classe NSURLRequest met en cache chaque requête émise). Les caches sont stockés dans le dossier «RootDomain/Library/Caches». Figure 23 : extrait du dossier «HomeDomain/Library» 3.2.5. Certificats signataires d application Pour chaque application, un fichier embedded.mobileprovision situé dans le package IPA est présent et est en mesure de fournir des informations sur l application telles que l ID de l application, la date de création, mais également un certificat identifiant le développeur de l application. 3.2.6. Services Daemons Chaque application utilise des fichiers qui lui sont propres pour pouvoir fonctionner correctement. Un bundle va assurer la gestion du code et des ressources associées aux processus qui peuvent être démarrés pour une application. Le fichier «lsdidentifiers.plist» va lister ces informations. Un investigateur peut analyser les différents IDs des bundles et déterminer ceux qui peuvent être suspects (ID étrange, correspondance des applications, etc.). visitées peuvent fournir à l investigateur des informations sur des potentiels sites malveillants qu un utilisateur aurait pu visualiser. Ces fichiers se trouvent dans la SandBox «AppDomain-com.apple. mobilesafari» : History.plist et SuspendState.plist : historique des pages affichées par l utilisateur. RecentSearches.plist : historique des recherches effectuées par l utilisateur par le biais de la barre de recherche Safari. De plus, chaque application utilise un fichier «cookies.binarycookies» Figure 24 : affichage du fichier «RecentSearches. plist» qui stocke les cookies utilisés. Il est très intéressant de les visualiser, notamment ceux générés par le navigateur Safari, puisqu on peut obtenir des informations sur les sites potentiellement malveillants visités par l utilisateur. Figure 22 : visualisation d une partie du fichier «lsdidentifiers.plist» Figure 25 : extrait du fichier «cookies.binarycookies» La Lettre CERT-Solucom N 3 octobre 2014 9

3.4. Cas d un terminal jailbreaké Lorsque le terminal mobile est déjà jailbreaké, une quantité plus importante d information est alors disponible. Cependant, ces informations ne sont pas facilement accessibles, et il peut alors être nécessaire de faire appel à un logiciel tiers. Parmi ces derniers, on recense : Class-dump-z, un outil d analyse des classes d un binaire Objective-C (langage de programmation utilisé pour développer des applications pour ios). Clutch, un utilitaire pour déchiffrer et/ou cracker des applications au format IPA. FileDP, un utilitaire qui permet de récupérer la classe de protection attribuée aux fichiers présents sur le terminal. Filemon, qui permet un monitoring en temps réel du système de fichiers. Keychain_dumper, un programme qui permet de récupérer les mots de passe stockés sur le terminal mobile en déchiffrant les keychains. Lsock, un outil de monitoring des sockets réseau. Lsof2, un outil de monitoring des descripteurs de fichier. 3.5. Tableau récapitulatif des méthodes d analyse Le tableau ci-dessous résume les fichiers/dossiers accessibles grâce aux différentes méthodes d acquisition. Il est important de garder en mémoire que dans une optique d analyse forensics, seules les analyses de sauvegarde itunes ou les acquisitions physiques n altérant pas l intégrité du mobile sont conseillées (contournement temporaire du mécanisme de chiffrement). L analyse d une sauvegarde itunes est limitée car beaucoup de fichiers intéressants (notamment logs), ne sont pas accessibles à l investigateur. Cependant, il est très simple d acquérir une telle sauvegarde et l analyse est elle aussi très aisée et rapide. L analyse d une image physique quant à elle donne accès à tous les éléments du smartphone, mais se révèle être bien plus compliquée sans l utilisation d une suite logicielle dédiée, à cause du mécanisme de chiffrement mis en place par Apple. 3.6. Cas concret : FlexiSpy L application des différents contrôles présentés précédemment permet d identifier rapidement des applications malveillantes qui seraient installées sur un terminal ios. Prenons un exemple sur un cas concret : l application FlexiSpy. FlexiSpy est une «application espion» qui offre de nombreuses fonctionnalités pour un individu malveillant : Interception de SMS/MMS. Localisation GPS. Récupération des photos, vidéos, historique de navigation. Etc. Cette application commerciale (environ $150) requiert le jailbreak du terminal. Sa simplicité d installation et d utilisation, ainsi que ses nombreuses fonctionnalités en font l une des applications commerciales d espionnage les plus répandues. De nombreux sites référencent FlexiSpy comme l une des meilleures applications de surveillance (http://www.chilireviews.com/) La simple analyse de la liste des icônes présentes sur le SpringBoard (à savoir, les icônes affichées sur les pages d accueil ios) nous permet Figure 26 : applications suspectes sur le SpringBoard 10 La Lettre CERT-Solucom N 3 octobre 2014

d identifier des applications suspectes : L application Cydia, bien connue par toute personne ayant déjà réalisé un jailbreak, est l application remplaçant l AppStore d Apple pour les terminaux jailbreakés. Une seconde application interpelle : «com.applle.systemcore». L œil aiguisé d un analyste verra de suite le «double L» à «applle» Il ne s agit pas d une erreur de frappe mais bien d une volonté des développeurs de FlexiSpy de «camoufler» cette application dans le système. L analyse des fichiers de configuration du SpringBoard révèle une autre technique de camouflage : l absence d affichage de l icône de l application sur le SpringBoard. Le fichier «/Library/SpringBoard/DesiredIconState.plist» localise l application dans le second écran de l iphone (seconde entrée Figure 29 : répartition des icônes des applications sur les pages du Springboard Le fichier «/Library/SpringBoard/IconState.plist» confirme cette disparition de l application «systemcore» de l écran d accueil. Par conséquent, «systemcore» est une application cherchant volontairement à être silencieuse et ne pas apparaître aux yeux de l utilisateur. Un contrôle rapide des applications téléchargées depuis l AppStore permet de renforcer les suspicions en «com.applle.systemcore». En effet, la clef «downloaded-apps» de la base de données SQLite «Library/com.apple.itunesstored/kvs.sqlitedb» contient l ensemble Figure 27 : répartition des icônes des applications sur les pages du Springboard «Array») : Or, cette application n apparait pas sur l écran : Figure 28 : capture du second écran de l iphone Figure 30 : liste des applications téléchargées depuis l App Store officiel des applications issues du Store officiel d Apple. L absence d entrée concernant «com.applle.systemcore» signifie que cette application n a pas été installée via l App Store, mais bien par un autre mécanisme (Cydia en l occurrence). Afin de lever les doutes sur cette application, vérifions si elle requiert des droits particuliers pour son fonctionnement. Comme vu précédemment, il s agit d analyser le fichier «TCC.db». La Lettre CERT-Solucom N 3 octobre 2014 11

Ainsi, dans la majorité des cas, même si l analyse d une sauvegarde itunes à jour est loin d être exhaustive, elle permet cependant de fournir des preuves suffisantes à un investigateur pour confirmer ou infirmer une compromission standard de l iphone. Figure 31 : privilèges demandés par application De nombreuses entrées correspondent à l application «systemcore» du bundle suspect «applle». En effet, cette application requiert plusieurs droits, et en particulier pour accéder : Au carnet d adresses. Aux profils installés. à la caméra. Au microphone. Au GPS. Au calendrier. En synthèse, la conjonction d un ensemble de suspicions à l encontre de l application «systemcore» permet de statuer sur son caractère malveillant : Nom suspect de l application. Application non installée depuis l AppStore. Droits importants exigés. Application cachée sur le SpringBoard. Dans une mission d investigation, il serait alors intéressant d étudier les fichiers de configuration propre à cette application afin de déterminer les données qui ont déjà pu être volées, la date d installation du logiciel espion, etc. 3. 8. Synthèse des contrôles à mener selon la typologie de menace Bien qu une analyse sur une acquisition logique complète ou une acquisition physique se révèlerait être plus intéressante, les prérequis de ces acquisitions bafouent bien souvent les principes forensics d intégrité des données. Il est aussi nécessaire de bien comprendre les méthodes utilisées par les suites logicielles pour les acquisitions. En effet, certaines vont passer par un jailbreak persistant, d autres par un jailbreak non persistant, voire par une analyse plus «détaillée» d un backup. L investigateur doit connaître parfaitement le mode de fonctionnement de l outil utilisé, notamment pour garantir le cadre légal de l investigation. Bien que peu exhaustive, l analyse d une sauvegarde itunes permet de révéler rapidement des comportements suspects de par l accès aux bases de données recensant les actions effectuées par le terminal mobile qui auraient pu être réalisées par l utilisateur (émission d un appel, envoi d un SMS, etc.). Ainsi, il est déjà possible de déceler la présence de malwares agissant à l insu de l utilisateur. Pour obtenir la liste des applications installées sur le terminal (qu elles soient cachées sur le springboard ou non), plusieurs solutions : Library/SpringBoard/DesiredIconState.plist. Library/Preferences/com.apple.springboard.plist. Library/BackBoard/applicationState.plist. Library/com.apple.itunesstored/kvs.sqlitedb (clef «downloaded-apps»). lsd/com.apple.lsdidentifiers.plist. Certaines suites logicielles permettent cependant d accéder au système de fichiers dans son ensemble, voire au disque physique, et permettraient donc une analyse encore plus poussée du comportement des programmes installés sur l iphone : récupération de fichiers effacés grâce à l espace résiduel, logs des services, accès au dmesg, etc. 12 La Lettre CERT-Solucom N 3 octobre 2014

Références [1] Pourquoi la faille «goto fail» des OS d Apple est très grave, http://www. journaldunet.com/solutions/dsi/faille-goto-fail-0214.shtml [2] ios 7.1 : Retour sur la sécurité, http://www.igen.fr/iphone/ios-71-retour-surla-securite-110479?utm_content=buffera53c5&utm_medium=social&utm_ source=twitter.com&utm_campaign=buffer [3] About the security content of ios 7.1, http://support.apple.com/kb/ HT6162 [4] ios7 : Even if you don t jailbreak your iphone, bugs still creep in, http:// www.theregister.co.uk/2014/02/25/ithings_snoopware_risk/ [5] Menaces mobiles en 2013, http://www.viruslist.com/fr/ analysis?pubid=200676348 [6] ios Security Frebruary 2014, http://images.apple.com/iphone/business/ docs/ios_security_feb14.pdf [7] Your ios device isn t as encrypted as you think, http://www.zdziarski.com/ blog/?p=2149 [8] Chaos Computer Club hackers trick Apple s TouchID security feature, http://arstechnica.com/apple/2013/09/chaos-computer-club-hackers-trickapples-touchid-security-feature/ [9] Jekyll on ios: When Benign Apps Become Evil, http://www.cc.gatech. edu/~klu38/publications/security13.pdf [10] 25 Years of Vulnerabilities : 1988 2012, https://community.qualys.fr/ servlet/jiveservlet/previewbody/1541-102-1-1535/sourcefire%2025%20 Years%20of%20Vulnerabilities%20Research%20Report-%20A4%20(1)%20 -%20copie.pdf [11] iphone Forensic Method FAQ, www.zdziarski.com/blog/?p=524 [12] iphone-dataprotection ios forensics tools, https://code.google.com/p/ iphone-dataprotection/ [13] The Sleuth Kit, https://github.com/sleuthkit/sleuthkit [14] XPwn!, https://github.com/planetbeing/xpwn [15] Les profils de configuration ios comme vecteur de malware, http://www. igen.fr/iphone/les-profils-de-configuration-ios-comme-vecteur-de-malwares- 105426 [16] Malicious Profils The Sleeping Giant of ios Security, http://www.skycure. com/blog/malicious-profiles-the-sleeping-giant-of-ios-security/ [17] App Events for ios, https://developers.facebook.com/docs/ios/appevents/ La Lettre CERT-Solucom N 3 octobre 2014 13

Dossier : Délégation Kerberos et transition de protocole : comment fournir un accès à la messagerie d entreprise depuis l extérieur sans utiliser le mot de passe ActiveDirectory? 1. Authentification depuis l extérieur du SI 1.1. Cas pratique avec mot de passe de domaine Afin d illustrer cet article, prenons le cas d un utilisateur se connectant à OWA en suivant les étapes ci-dessous : Le poste de travail de l utilisateur est connecté à internet. Il se connecte via son navigateur à un frontal (reverse-proxy) qui se situe dans une DMZ de l entreprise. Le frontal réalise une authentification forte et demande le mot de passe de domaine. Le frontal transmet la requête au serveur OWA et utilise le mot de passe de domaine pour authentifier l utilisateur sur OWA. La saisie du mot de passe de domaine est le moyen d authentification le plus répandu pour ouvrir une session sur son PC Windows d entreprise. Néanmoins, dans certains cas, l entreprise ne souhaite pas que l utilisateur saisisse son mot de passe de domaine et préfère utiliser une carte à puce, un token ou une authentification biométrique. Ce peut être un choix stratégique, par exemple pour l accès au SI depuis internet, ou un choix technologique. Une fois la session Windows ouverte, les applications peuvent utiliser l authentification intégrée Windows (IWA) pour éviter de redemander une authentification à l utilisateur. Ce mécanisme de Single-Sign-On (SSO) fonctionne seulement si le poste de travail peut communiquer avec le Domain Controller (DC). En cas d accès depuis l extérieur ou depuis un terminal (PC, Mac, tablette, etc.) hors du domaine, l utilisateur doit saisir à de multiples reprises son mot de passe de domaine, impactant considérablement l ergonomie. Ainsi la problématique étudiée dans le présent article concerne l accession à des applications utilisant l authentification Windows intégrée depuis un poste n ayant pas accès au domaine et sans utiliser de mot de passe. Une solution basée sur les mécanismes de délégation et de transition de protocole Kerberos sera présentée. Elle sera illustrée à travers le cas concret d une entreprise souhaitant mettre à disposition de ses utilisateurs un webmail Outlook Web Access (OWA) où l utilisateur possède un vecteur d authentification forte (carte à puce, token, biométrie et autres facteurs d authentification ) et n utilise pas le mot de passe de domaine. Figure 1 : scénario avec envoi du mot du mot de passe de domaine 1.2. Cas pratique sans le mot de passe de domaine Si on ne souhaite pas que l utilisateur saisisse son mot de passe de domaine, il est possible d utiliser Kerberos en suivant les étapes ci-dessous : Le poste de travail de l utilisateur est connecté à internet. Il se connecte via son navigateur à un frontal (reverse-proxy) qui se situe dans une DMZ de l entreprise. Le frontal réalise une authentification mais sans demander le mot de passe de domaine. Le frontal transmet la requête au serveur OWA, mais il ne peut pas authentifier l utilisateur sur OWA puisqu il n a pas son mot de passe. Le frontal demande un ticket Kerberos au DC pour le compte de l utilisateur, pour le service OWA. Figure 2 : scénario sans envoi du mot de passe de domaine 14 La Lettre CERT-Solucom N 3 octobre 2014

1.3. Fonctionnement de Kerberos Le protocole d authentification Kerberos v5 est définit par la RFC 4120 [1]. Microsoft a intégré le protocole dans son OS à partir de Windows 2000 [2]. Il fait intervenir 3 entités : Le client (poste de travail de l utilisateur). Le service, défini par un identifiant unique : son Service Principal Name (SPN) au format <service class>/<host>[:<port>] [/<service name>] [3]. Le Key Distribution Center (KDC). Tous les Domain Controller (DC) sont forcément des KDC [4] et ils jouent les rôles : - d Authentication Service (AS) qui authentifie le client et fournit un Ticket Granting Ticket (TGT) à celui-ci - de Ticket-Granting Service (TGS) qui identifie le client grâce au TGT et, en fonction des habilitations du client, génère les Service Tickets. 1.4.2. Constrained Delegation Afin de limiter le champ d action du compte de service, qui a la possibilité de se faire passer pour n importe qui, Microsoft a introduit la notion de constrained delegation [5]. Pour ce type de compte, Microsoft oblige à définir une liste précise de services sur lesquels le compte a le droit de passer pour qui il veut. Sans réduire le risque de compromission du compte de service, cette configuration en restreint l impact aux services pour lesquels il est habilité. 1.4.3. Spécification Service for User (S4U2self et S4U2proxy) Ces fonctionnalités sont définies par Microsoft dans une extension de Kerberos nommée Service for User [6] (S4U). Cette extension définit 2 protocoles : Service for User to Self (S4U2self), qui permet à un service d obtenir un ticket Kerberos pour lui-même au nom de l utilisateur. Service for User to Proxy (S4U2proxy) qui permet à un service d obtenir un ticket Kerberos pour un autre service au nom de l utilisateur. Figure 3 : fonctionnement de Kerberos 1.4. Protocol Transition et Constrained Delegation 1.4.1. Protocol Transition Dans notre exemple, le client n a pas la possibilité de s authentifier sur l AS pour récupérer un TGT car son poste de travail ne peut pas joindre de DC. Le frontal va donc utiliser la fonctionnalité de protocol transition. Lorsqu un utilisateur s authentifie avec un autre mécanisme d authentification que Kerberos sur un serveur, le protocol transition permet au serveur de demander des Service Tickets Kerberos au nom de l utilisateur et opère ainsi une transition de protocole d authentification. Pour cela, un compte de service est défini avec les droits nécessaires sur le domaine pour demander des Service Tickets au nom des utilisateurs. Le frontal s authentifie sur l AS avec ce compte de service et obtient un TGT, puis il présente ce TGT au TGS pour récupérer un Service Ticket au nom de l utilisateur. Autrement dit, la fonctionnalité de protocol transition permet donc d habiliter un compte de service donné à passer pour n importe quel utilisateur du domaine. Figure 4 : S4U2self et S4U2proxy [7] Dans notre cas pratique, le frontal est le service 1, et OWA le service 2. 2. Sécurité de la solution Cette solution permet d éviter les problématiques de gestion du mot de passe de domaine depuis l extérieur du réseau d entreprise. Elle améliore l ergonomie pour l utilisateur qui a ainsi un mot de passe de moins à saisir. Elle permet également d éviter l enregistrement du mot de passe de domaine utilisateur sur son poste de travail (ou son smartphone dans le cas d ActiveSync par exemple) diminuant le risque d usurpation d identité. En revanche, sa mise en place oblige à paramétrer un compte avec des pouvoirs d impersonnification très élevés, dans notre cas sur un frontal en DMZ. Ceci présente un risque particulièrement important si celui-ci est compromis suite à une attaque : l identité d un utilisateur ou d un administrateur de domaine pouvant être usurpée (attaque de type Pass-The-Ticket) [8]. La Lettre CERT-Solucom N 3 octobre 2014 15

Dans le cas de OWA, sans aller jusqu à prendre le contrôle du domaine (la capacité de rebond dépend de chaque configuration), l attaquant pourrait à minima consulter les boîtes mails de l ensemble des collaborateurs, ce qui présente un impact non négligeable. Ce risque peut être partiellement mitigé par la restriction des services accessibles et la restriction des flux entre le frontal et le reste du SI au strict nécessaire. Globalement l usage de délégation de contrainte Kerberos n est pas recommandé ; compte tenu des risques de rebonds importants induits sur le domaine, il est préférable d utiliser une authentification double (mot de passe AD et second facteur). Cependant, certains cas spécifiques (souvent liés à des raisons historiques propres à l entreprise) ne laissent que peu de marge de manœuvre et cette solution est parfois la seule pouvant être mise en place. Dans ce cas il convient de paramétrer du mieux possible le système, tel que présenté dans la partie suivante de l article. 3. Mise en œuvre 3.1. Mise en œuvre de la délégation La mise en œuvre nécessite que le domaine s exécute avec les fonctionnalités Windows Server 2003 au minimum. 3.1.1. Création du compte de service Il faut commencer par créer un compte de service dans AD (dans notre cas pratique, le compte dlgowa). Ce compte de service doit être dans le même domaine que le serveur hébergeant OWA, pour les versions de Windows antérieures à Windows 2012 [9]. En revanche, le compte de service n a pas besoin d être dans le même domaine que les utilisateurs, du moment qu une relation d approbation existe du domaine du compte de service vers le domaine des utilisateurs. Dans les spécifications de S4U, la délégation est donnée à un service (et non à un compte). Il faut donc associer un SPN au compte avec l outil setspn [10] : setspn -U -S HTTP/dlgowa <domain>\dlgowa. Après cela, l onglet «Delegation» apparait dans les propriétés du compte. Cet onglet permet de définir la liste des services autorisés pour la délégation. Dans notre cas, il s agit de [11] : HTTP/<FQDN du serveur OWA>. Figure 5 : liste des services autorisés dans l onglet delegation Dans le cas d un cluster de plusieurs serveurs OWA, c est le SPN correspondant au FQDN du cluster qui est utilisé. Il est alors nécessaire de créer un compte de service, de faire en sorte que les serveurs IIS du cluster exécutent OWA avec ce compte et enfin de créer le SPN HTTP/<FQDN du cluster> en l associant à ce compte [12]. Dans le cas d un frontal IIS ou TMG dans le domaine, il est possible de donner la délégation au compte machine plutôt que de créer un compte de service. Dans notre exemple, le frontal internet n est pas dans le domaine pour des raisons de sécurité. 3.1.2. Configuration de l authentification sur OWA Le serveur IIS hébergeant OWA doit être configuré pour autoriser l authentification Kerberos. Cela nécessite que le rôle «Windows Authentication» du service IIS soit installé [13] et que le site hébergeant OWA sur IIS utilise l authentification «Windows Authentication». Pour s assurer que OWA permet bien l authentification Kerberos et ne diminue pas systématiquement le niveau d authentification à NTLM, on peut vérifier les requêtes effectuées par le navigateur web : À la 1 ère requête, le serveur répond avec un code HTTP 401 et l en-tête HTTP «WWW-Authenticate: Negotiate». À la 2 ème requête, le client envoie l en-tête HTTP Authorization avec une valeur qui commence par Negotiate suivi d une chaîne en base 64 commençant par «Y» (il s agit du Initial Context Token dont le 1 er octet est 0x60 tel qu indiqué dans la RFC 2743 au chapitre 3.1). On peut également visualiser le Service Ticket grâce à la commande «klist tickets». 3.1.3. Configuration du frontal Pour configurer le frontal (reverse-proxy), il faudra a minima paramétrer : L adresse du serveur OWA. L adresse du serveur KDC (n importe quel DC du domaine du compte de service convient). Le compte de service en précisant, son login, son domaine (Realm) et soit son mot de passe, soit son fichier keytab [14] (selon l implémentation). Au niveau réseau, le frontal doit avoir accès au KDC sur le port 88 en UDP et TCP [15], et bien sûr à l application OWA. Lors de l authentification forte sur le frontal, ce dernier devra savoir déterminer le login de domaine de l utilisateur ainsi que son domaine (en particulier s il y a plusieurs domaines utilisateurs). 3.1.4. Exemples de frontaux implémentant les extensions S4U Voici quelques exemples de produits ayant une fonctionnalité reverseproxy et supportant l extension S4U. Juniper Secure Access [16], F5 BIG-IP Local Traffic Manager [17], Citrix Netscaler [18], Apache (patch non officiel pour mod_kerberos) [19]. L extension S4U est également implémentée nativement dans différents langages de programmation : Microsoft.NET 2.0 et supérieur [20], Java 8 [21]. Enfin, le MIT propose une version Open-Source du protocole Kerberos incluant S4U [22]. 16 La Lettre CERT-Solucom N 3 octobre 2014

3.1.5. Accès à des services sous-jacents Lorsque l application fait elle-même appel à d autres services en utilisant l authentification utilisateur (une base de données par exemple), ces services doivent être dans le même domaine que l application et déclarés dans la liste des services autorisés pour la délégation. Cette liste peut être complexe à déterminer. Si on souhaite aller plus loin et ouvrir un bureau Windows complet en Kerberos Constrained Delegation (via Citrix par exemple), il faudra : Ajouter dans la liste tous les services nécessaires au bon fonctionnement du bureau Windows (tous les DC du domaine, les serveurs de fichiers, etc.). Configurer les applications web en authentification Kerberos pour que l utilisateur y accède, ajouter les SPN correspondants à la liste, ainsi que les SPN des services sous-jacents (base de données, etc.). Dans ce cas, on comprend que la liste des services à autoriser pour la délégation est complexe à définir et fastidieuse à maintenir au fil des évolutions du SI. Cette solution peut être mise en œuvre de façon simple dans le cas d une application Web bien ciblée comme OWA, ActiveSync, ou SharePoint, mais elle est difficile à industrialiser dès qu il y a beaucoup de services sous-jacents à adresser. 4. Évolutions Afin de simplifier l implémentation de la solution Kerberos Constrained Delegation, Microsoft a intégré de nouvelles fonctionnalités dans Windows Server 2012 [23]. Ce nouveau mode de fonctionnement présente plusieurs avantages : Il n est plus nécessaire de disposer de droits administrateurs du domaine pour configurer la délégation. Il suffit d être administrateur du service ciblé (dans notre cas serveur ou compte qui exécute OWA). Il n est plus nécessaire de connaitre la liste des SPN, il suffit de connaître les comptes et/ou les serveurs qui exécutent les services ciblés. En particulier, il n y a plus besoin de préciser le protocole (service class). Il est possible de faire de la délégation sur des services de domaines différents ou de forêts différentes (avant Windows Server 2012, il fallait nécessairement que le compte de service ayant les droits de délégation soit dans le même domaine que les ressources accédées). Conclusion La Kerberos Constrained Delegation permet d apporter une réponse technique à certains cas d usage, en particulier lorsque l utilisateur n utilise pas son mot de passe de domaine et ne dispose que d une carte à puce ou d un token. Cette facilité d usage est cependant à mesurer en regard du risque de compromission du domaine induit par la prise de contrôle du frontal par un attaquant, mesure nécessitant une analyse de risque approfondie et au cas par cas. 4.1. Délégation basée sur la ressource Comme expliqué précédemment, avant Windows Server 2012, la liste des services autorisés pour la délégation est associée à un compte de service (dans notre cas pratique dlgowa) dont les identifiants sont ensuite paramétrés sur le frontal. Techniquement, il faut définir l attribut msds-allowedtodelegateto de ce compte avec la liste des SPN des services autorisés [24]. La configuration de cet attribut doit se faire par un administrateur du domaine et les services ciblés n ont aucun contrôle sur cette configuration. À partir de Windows Server 2012, il est possible de définir la délégation directement sur le service visé (dans notre exemple, OWA). Techniquement, sur le compte qui exécute OWA, il suffit de remplir l attribut msds-allowedtoactonbehalfofotheridentity [25] avec la liste des comptes (dans notre cas pratique dlgowa) ayant le droit de faire de la délégation sur ce service. Pour définir cet attribut, on peut utiliser la commande PowerShell Set-ADComputer [26] : Figure 6 : commande PowerShell Set-ADComputer La Lettre CERT-Solucom N 3 octobre 2014 17

Références : [1] The Kerberos Network Authentication Service (V5), http://www.ietf.org/ rfc/rfc4120.txt [2] Windows 2000 Kerberos Authentication, http://technet.microsoft.com/ en-us/library/bb742431.aspx [3] Name Formats for Unique SPNs, http://msdn.microsoft.com/en-us/library/ windows/desktop/ms677601(v=vs.85).aspx [4] Key Distribution Center, http://msdn.microsoft.com/en-us/library/windows/ desktop/aa378170(v=vs.85).aspx [5] Summary (Kerberos Protocol Transition and Constrained Delegation), http:// technet.microsoft.com/en-us/library/cc772683(v=ws.10).aspx [6] [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol, http://msdn.microsoft.com/en-us/library/cc246071. aspx [7] [MS-SFU] Open Specifications Documentation, Figure 2, http://msdn. microsoft.com/en-us/library/cc246071.aspx [8] http://www.ossir.org/jssi/jssi2014/jssi_2014 Solucom_WinSec_vf.pdf [9] Appendix A-<2> de [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol, http://msdn.microsoft.com/en-us/ library/cc246071.aspx [10] SetSpn http://technet.microsoft.com/en-us/library/cc731241.aspx [11] How to use SPNs when you configure Web applications that are hosted on Internet Information Services, http://support.microsoft.com/kb/929650/ en-us [12] Setting up Kerberos Authentication against the cluster name Service Principal Name, http://technet.microsoft.com/en-us/library/ cc736453(v=ws.10).aspx [13] IIS Windows Authentication, http://www.iis.net/configreference/system. webserver/security/authentication/windowsauthentication [14] MIT Kerberos Documentation (keytab), http://web.mit.edu/kerberos/krb5- current/doc/basic/keytab_def.html [15] Voir RFC 4120 chapitre 7.2. KDC Messaging: IP Transports [16] http://www.juniper.net/techpubs/software/ive/guides/howtos/ SSLConstrainedDelegation.pdf [17] http://www.f5.com/pdf/white-papers/kerberos-constrained-delegationpki-wp.pdf [18] http://support.citrix.com/servlet/kbservlet/download/35879-102- 706395/CTX139133_25th_September_2013.pdf [19] http://sourceforge.net/mailarchive/message php?msg_id=28531618 [20] http://msdn.microsoft.com/fr-fr/library/system.security.principal.windowsidentity.impersonate(v=vs.80).aspx [21] http://openjdk.java.net/jeps/113 [22] http://web.mit.edu/kerberos/ [23] What s New in Kerberos Authentication in Windows Server 2012 and Windows 8, http://technet.microsoft.com/en-us/library/hh831747. aspx#bkmk_cd [24] Attribute msds-allowedtodelegateto, http://msdn.microsoft.com/en-us/ library/cc220234.aspx [25] Attribute msds-allowedtoactonbehalfofotheridentity, http://msdn. microsoft.com/en-us/library/hh554126.aspx [26] Set-ADComputer, http://technet.microsoft.com/en-us/library/hh852268. aspx 18 La Lettre CERT-Solucom N 3 octobre 2014

Retour sur l actualité Retour sur l actualité Dragonfly : la libellule qui crachait du feu sur le secteur de l énergie Découverte et annoncée par les éditeurs Symantec et F-Secure, une nouvelle campagne de cyber-espionnage fait aujourd hui couler beaucoup d encre. Et pour cause (!), s étant déroulée entre février 2013 et mai 2014, elle touche principalement «les grands» du secteur de l énergie européen, notamment espagnols, français, italiens, allemands et turcs. Avec 24% des attaques identifiées, les États-Unis occupent la deuxième place du top10 des pays les plus touchés. Intitulée Dragonfly par Symantec ou encore Energetic Bear par d autres, cette campagne a pu aboutir grâce à plusieurs vecteurs d attaque, du plus commun (spamming, sites web piégés, etc.) au plus sophistiqué («à l image de Stuxnet» selon certains experts). L un des plus complexes et astucieux a notamment permis aux attaquants d installer un trojan, intitulé «Havex» (ou encore «Backdoor.Oldrea» ou «Energetic Bear RAT»), sur un grand nombre d équipements industriels ICS pour Industrial Control System. Outre un accès de contrôle distant aux ICS, ce trojan a permis la récolte de nombreuses informations précieuses liées aux systèmes : configurations, listes des programmes, listes des fichiers stockés, journaux d évènements, carnets d adresses Outlook, etc. Havex a pu être déployé de la sorte par le biais des paquets de mise à jour logicielle mis à disposition par trois fournisseurs d équipements ICS, directement sur leur site web (ndlr. initialement par souci de praticité). De ce fait, les attaquants ont réussi, grâce à plusieurs failles de sécurité web présentes, à remplacer ces paquets par des équivalents corrompus qui, une fois déployés par les équipes adéquates (patch management), permettaient l installation de Havex en toute transparence. Symantec estime que ces «paquets piégés» ont pu être disponibles en téléchargement libre pendant une période de 2 à 6 semaines. Des études approfondies ont permis d en savoir plus sur les méthodologies de ce trojan et de définir des premiers indicateurs de compromission. Les experts ont pu constater l intelligence du trojan mais surtout son développement très proche du contexte de ses victimes ; les moyens mis en œuvre semblent donc importants, laissant soupçonner une initiative étatique ou tout au moins de grande envergure. Pour le moment, les noms des victimes qu elles soient fournisseurs d équipements ICS ou acteurs du secteur énergétique ne sont pas connus du grand public. Il est en revanche fortement conseillé aux organisations concernées, de mettre les moyens nécessaires pour détecter et se protéger d une éventuelle compromission (notamment par le biais des signatures fournies par Symantec ou par la recherche d indicateurs de compromission). Sources : Figure : répartition géographique des victimes infectées http://www.symantec.com/connect/blogs/dragonfly-western-energycompanies-under-sabotage-threat [IOC] http://www.f-secure.com/weblog/archives/00002718.html h t t p : / / w w w. s y m a n t e c. c o m / c o n n e c t / b l o g s / dragonfly-western-energy-companies-under-sabotage-threat Source à ajouter : http://info.belden.com/a-cyber-security-dragonfly-bc-lp Addendum : lors de la rédaction de cet article, les analyses approfondies de Belden n avaient pas encore été publiées : il semblerait que le secteur réellement impacté par Dragonfly ait été l industrie pharmaceutique. Ainsi, le secteur énergétique ne serait qu une victime collatérale de l attaque. La Lettre CERT-Solucom N 3 octobre 2014 19

Retour sur l actualité GnuTLS/OpenSSL : double #Fail! Après les multiples déboires autour des implémentations SSL dont la faille «Heartbleed» pour OpenSSL, le «Goto: fail» d Apple pour ios, et également un «Goto: fail» de GnuTLS, voici une nouvelle faille impactant GnuTLS. Trouvée par Joonas Kuorilehto, qui n est autre que le chercheur ayant découvert Heartbleed, la CVE-2014-3466 fait état d une vulnérabilité de type «Buffer overflow» permettant l exécution d un code arbitraire sur les clients utilisant GnuTLS lors de l établissement d une connexion SSL avec un serveur. La vulnérabilité provient de l absence de vérification de la longueur d un identifiant de session SSL dans un message ServerHello lors du handshake SSL. Cet identifiant de session est retourné par le serveur suite à la connexion d un client SSL : il permet entre autre la reprise rapide d une session SSL. La faille trouvée dans le client GnuTLS est liée au fait que la valeur annonçant la longueur de cet identifiant de session n est pas vérifiée par rapport à la valeur maximale autorisée, soit 32 octets. La transmission d une longueur arbitraire N supérieure à 32 octets va par provoquer le crash du client, lorsque celui-ci va essayer de copier ces N octets dans un tableau fixe de 32 octets : Il est à noter qu un message de type ServerHello est échangé durant le handshake SSL, par conséquent avant l établissement même d une connexion chiffrée : le flux est ainsi échangé en clair et il est donc théoriquement possible d exploiter cette vulnérabilité au moyen d un Man-in-The-Middle. La bonne nouvelle est que GnuTLS étant nettement moins utilisé qu OpenSSL, cette faille devrait impacter moins de monde. Les principaux logiciels connus utilisant la bibliothèque GnuTLS étant les suivants : Filezilla Weechat Xen XBMC Qemu Chronium Lynx Aucune exploitation de ce bug par des tiers malveillants n a pu être mise en évidence jusqu ici. Des correctifs ont été produits par l équipe de développement GnuTLS et les packages associés sont disponibles pour les principaux systèmes. Sources : http://www.tripwire.com/state-of-security/top-security-stories/gnutlscrypto-library-vulnerability-cve-2014-3466/ http://radare.today/technical-analysis-of-the-gnutls-hellovulnerability/ http://www.gnutls.org/security.html http://www.cert.ssi.gouv.fr/site/certfr-2014-avi-248/certfr- 2014-AVI-248.html Figure 1 : extrait du code source vulnérable La correction ajoutée a consisté à ajouter la vérification suivante (avec TLS_MAX_SESSION_ID_SIZE = 32 octets) avant tout traitement d un message ServerHello reçu : Figure 2 : contrôle complémentaire sur la faille des sessions TLS 20 La Lettre CERT-Solucom N 3 octobre 2014

Retour sur l actualité Revue des backdoors ios : «It s not a bug, it s a feature!» Le 18 juillet dernier, lors d un talk à la Hackers On Planet Earth, Jonathan ZDZIARSKI a présenté plusieurs portes dérobées présentes dans le système ios d Apple. J. ZDZIARSKI est un expert en sécurité bien connu dans le monde du hacking Apple : il est notamment l auteur de nombreux articles sur le forensics ios et des outils d analyse associés. Petit rappel de l existant : Sur sollicitation, Apple peut fournir aux forces de l ordre de nombreuses données, même sur un terminal protégé par un passcode : SMS, photos, vidéos, contacts, enregistrements audio et historique des appels. Lorsqu un passcode est utilisé, un mécanisme de protection des fichiers est automatiquement activé et l accès à chaque fichier peut être protégé selon différents niveaux de protection : Niveau 0 : Sans protection, le fichier est chiffré à l aide des informations du terminal («NSProtectionNone»). Niveau 1 : Accès dès le premier déverrouillage d u t e r m i n a l j u s q u a u p r o c h a i n r e d é m a r r a g e («NSFileProtectionCompleteUntilFirstUserAuthentication»). Niveau 2 : Accès si le terminal est déverrouillé ou si le fichier était ouvert avant verrouillage du terminal («NSFileProtectionCompleteUnlessOpen»). Niveau 3 : Accès uniquement lorsque le terminal est déverrouillé («NSProtectionComplete»). Constats Solucom : Les niveaux de protection généralement constatés par Solucom lors de la réalisation d audits d applications ios sont 0 ou 1. La plupart des données stockées sur le terminal peuvent être récupérées à partir du moment où le terminal a été déverrouillé au moins une fois. Figure 1 : extrait de la présentation de J. ZDZIARSKI fonctionnalité de recopie des flux com.apple.mobile.file_relay : capture de nombreuses données issues d applications diverses et variées, tout en contournant le chiffrement du terminal. Présentation des «nouvelles» backdoors : Le magazine d investigation Allemand Der Spiegel avait mis en avant la capacité de la NSA à accéder à certaines données sensibles (SMS, données GPS, etc.) après l activation de près de 38 services ios non documentés (comprendre «cachés»). J. ZDZIARSKI présente ces services : com.apple.pcapd : capture/redirection du trafic réseau et des requêtes/réponses http de manière complètement transparente pour l utilisateur. com.apple.pcapd : capture/redirection du trafic réseau et des requêtes/réponses http de manière complètement transparente pour l utilisateur. Figure 2 : extrait de la présentation de J. ZDZIARSKI liste des applications dont les données sont collectées via le service file_relay Quelques détails sur ces applications : - Accounts : liste les différents comptes enregistrés sur le terminal (email, Twitter, icloud, Facebook, etc.). - Caches : tous les différents caches utilisés par le système (screenshots de mise en background des applications, images partagées, presse-papier, cache du clavier, etc.). - CoreLocation : les données GPS sur près de 2 mois... - HFSMeta : une copie des métadonnées du système de fichiers une mine d or pour les analystes forensics (timestamps de création de tous les fichiers, date de dernière activation/effacement du terminal, liste de toutes les applications installées, noms de fichiers des pièces-jointes d emails, nom d hôte des terminaux appairés, etc.). La Lettre CERT-Solucom N 3 octobre 2014 21

Retour sur l actualité - Keyboard : une copie du cache d auto-complétion/correction. - MobileCal/MobileNotes : copies complètes des calendriers et notes de l utilisateur (les données supprimées peuvent être récupérées ). Puis par la mise à jour de la knowledge base Apple : com.apple.mobile.house_arrest : accès aux répertoires Library, Caches, Cookies contenant des informations sensibles sur les comptes enregistrés (Facebook, Twitter, etc.), par exemple pour Twitter : une base de données de tous les messages privés (dont ceux supprimés), les tokens OAuth, etc. Pour accéder à ces services «backdoors», il suffit d accéder au service lockdownd (les informations d appairage suffisent à s authentifier auprès de ce service) et de lancer la commande «StartService» suivie du nom du service désiré. L appairage peut être interdit ou verrouillé mais cette interdiction peut être contournée et désactivée à distance par Apple. Figure 4 : knowledge base Apple après mise à jour Elle ne répond néanmoins pas aux questions soulevées par J. ZDZIARSKI : Figure 3 : extrait de la présentation de J. ZDZIARSKI contournement du mécanisme d appairage Figure 5 : extrait de la présentation de J. ZDZIARSKI problématiques soulevées par la présence des services découverts La réponse d Apple ne s est pas faite attendre : Tout d abord par le biais d un communiqué : «We have designed ios so that its diagnostic functions do not compromise user privacy and security, but still provides needed information to enterprise IT departments, developers and Apple for troubleshooting technical issues. A user must have unlocked their device and agreed to trust another computer before that computer is able to access this limited diagnostic data. The user must agree to share this information, and data is never transferred without their consent. As we have said before, Apple has never worked with any government agency from any country to create a backdoor in any of our products or services» En synthèse, des fonctionnalités «cachées» permettent d accéder à des services avancés sur les terminaux ios. Ces services offrent la possibilité d écouter toutes les communications réseaux et d accéder à de nombreuses données, qu elles soient protégées par passcode/chiffrement ou non. Le mécanisme d appairage des terminaux permet de se protéger mais ce mécanisme peut être contourné, notamment à distance. Sources : POC : https://www.youtube.com/watch?v=z5ymf0useuw http://www.zdziarski.com/blog/wp-content/uploads/2014/07/ios_ Backdoors_Attack_Points_Surveillance_Mechanisms.pdf http://www.zdziarski.com/blog/?p=3466 http://www.zdziarski.com/blog/?p=3447 https:// support. apple. com/ kb/ HT6331? viewlocale=en_ US&locale=en_US 22 La Lettre CERT-Solucom N 3 octobre 2014

Le CERT-Solucom : news Le CERT-Solucom accrédité par le TF-CSIRT Le CERT-Solucom a été accrédité par le TF-CSIRT, et accède au premier réseau européen des équipes de réponses à incidents. Cette nouvelle étape marque, une fois de plus, l importance que Solucom accorde à la manipulation des données sensibles de ses clients à travers des process et exigences approuvées par l organisme Trusted Introduicer. Solucom obtient la certification PASSI Cette certification «Prestataires d Audit de Sécurité des SI» (PASSI), délivrée par LSTI en utilisant le référentiel conçu par l ANSSI, garantit la qualité et la sécurité de la réalisation des missions d audits de sécurité. Solucom est l un des premiers cabinets porteurs de cette nouvelle certification. Evénements Prochains événements de l Observatoire de la Sécurité des Systèmes d Information et Réseaux : 14 octobre 2014 (dans les locaux de Solucom) 18 novembre et 9 décembre 2014 (dans les locaux de l INRIA) Pour plus d informations, consultez le site de l OSSIR (www.ossir.org) Conférence BlackHat Europe 2014 (14-17 octobre 2014): Arnaud Soullié, auditeur sénior chez Solucom, animera un workshop sur la sécurité des SI industriels et les tests d intrusion sur les automates industriels programmables (API). Les participants pourront tester sur des automates réels les méthodes et outils d attaques spécifiques aux SI industriels. Pour plus d informations, consultez le site de la BlackHat (www. blackhat.com) La Lettre CERT-Solucom N 3 octobre 2014 23

Le CERT-Solucom Le CERT-Solucom a pour objectif de répondre aux attentes de nos clients en matière de gestion des incidents et des crises sécurité. Evaluation des risques cybercriminalité et sensibilitation Veille menaces, évaluation d attractivité, cartographie des risques, veille innovations, lien avec la cyber-assurance... Audit & tests d intrusion Simulation d attaque cubercriminelle, social engineering, tests d intrusion physiques... Investigation numérique / Forensics Détection de comprimissions avérées ou suspectées, identification des données ciblées, des méthodes d attaque... Gestion de crise cybercriminalité Organisation de crise et tests préalables, pilotage de crises réelles, coordination d intervenants, reporting vers la Direction Générale... Accompagnement à la remédiation / continuité d activité Construction des plans d actions, correction de failles, sécurisation du SI, reconstruction ex nihilo de périmètres sécurisés... Le CERT-Solucom associe un ensemble d expertises techniques et métiers afin d apporter une réponse globale aux incidents de sécurité. Plus de 45 profils expérimentés sont mobilisables au sein du CERT-Solucom. Directeur de la publication : Pascal Imbert Responsable de la rédaction : Frédéric Goux Contributeurs : Gérôme Billois, Baptistin Buchet, Etienne Capgras, Simon Declerck, Florian Drouin, Matthieu Garin, Kevin Guérin, Ary Paul Kokos, Jean Marsault, Benjamin Massif, Vincent Nguyen, Philippe Planche, Arnaud Soullié. Photographies : Getty images Fotolia Graphiques : Solucom Conception graphique : les enfants gâtés Impression : Axiom Graphics ISSN 2270-8162 CERT-Solucom Responsable CERT : Matthieu Garin cert@solucom.fr Tour Franklin, 100-101 terrasse Boieldieu La Défense 8 92042 Paris - La Défense solucom@solucom.fr http://www.solucom.fr abonnement : cert@solucom.fr