Analyse d’un malware iOS : Unflod.dylib

Suite à la parution de commentaires sur /r/jailbreak concernant un malware ciblant iOS, je me suis dis qu’une analyse serait intéressante vu que cette plateforme est encore peu ciblée par ce type de menaces du à son architecture.

La première étape fut de récupérer des informations sur le binaire, ie. Entitlements et signature du code. Le premier point n’apporte pas grand chose sur le binaire, à part qu’il peut être débuggé et accéder au Keychain.

checksignBien que n’ayant été trouvée que sur des terminaux jailbreakés, cette bibliothèque est signée avec le compte iPhone Developer de Wang Xin. Ce procédé est étrange vu que le jailbreak désactive la validation de code signé sur iOS.

L’EntryPoint de la bibliothèque est assez simple et ne réalise qu’une seule action: remplacer la fonction SSLWrite du système par une fonction implémentée dans la bibliothèque: replace_SSLWrite. Le hooking de la fonction est réalisée à l’aide de la fonction libsubstrate.dylib!MSHookFunction. La bibliothèque MobileSubstrate est utilisée par  beaucoup d’applications provenant d’AppStore tierce afin de réaliser du Swizzling/hooking, il n’est donc pas étonnant de la voir utilisée ici.

call_mshookfunction

La fonctionnalité de la fonction remplaçant SSLWrite est elle aussi très simple: détecter une tentative d’authentification sur les serveurs d’Apple et intercepter les authentifiants de l’utilisateur. Pour ce faire, la chaine /WebObjects/MZFinance.woa/wa/authenticate est recherchée dans les données envoyées via SSL. Cette chaine fait en général partie des URLs pointants sur *.itunes.apple.com.

searching_iTunes_login

Une fois identifiés, les authentifiants sont envoyés à un serveur en écoute sur le port 7878 soit à l’IP 23.88.10.4, soit à l’IP 23.228.204.55.sending_info

Pour le moment, aucune information n’est disponible quant-à la source de l’infection. Il est toutefois intéressant de voir que les terminaux iOS jailbreakés commencent à être la cible de malware grand-public.

Analyse et détection de cyber-attaques: Import-Module IncidentDetection

Introduction

Le 16 octobre dernier nous avons eu l’opportunité de présenter sur le sujet de la détection d’incidents lors de l’Application Security Forum d’Yverdon. Ce sujet, bien que relativement bien connu est encore trop peu utilisé en entreprise où l’on voit principalement le déploiement de défenses périmètriques, d’antivirus ou encore d’IDS.

Le résultat lié au déploiement de telles solutions dépend fortement du niveau de l’attaquant et peut très vite être réduit suite à une erreur de configuration. Un tel exemple pourrait être le non-filtrage des archives au format XYZ permettant à l’attaquant de mener une attaque à base de spear-phishing . Les solutions anti-virales sont quant-à elles très vite contournées…

D’un autre coté nous avons des politiques de logs qui sont inexistantes ou aucunement gérée, produisant des montagnes d’entrées qui ne sont pas revues.

Une solution

Une des solutions au problème peut se trouver dans la détection de l’intrusion dans le cas où la prévention a échouée. Nous avons détaillé dans notre présentation différents points pouvant indiquer un comportement suspect dans un environnement Microsoft.

Une grande partie des actions peut être détectée en activant les règles d’audit dans les GPOs, comme les évènements indiquant une authentification échouée par exemple.

Les phases liées à l’exécution de programmes ou l’exploitation de vulnérabilités nécessitent quant-à elles l’utilisation d’outils tierces. Dans ce cadre là, la technologie AppLocker de Microsoft peut être déployée de manière à non pas bloquer une exécution, mais dans son mode ‘Audit Only’. Concernant l’exploitation les évènements générés par EMET sont à surveiller.

Bien entendu, la simple génération d’évènements ne va pas indiquer qu’une attaque est en cour. Un outil remontant ces informations de manière centralisée est alors nécessaire. Dans le contexte de la conférence nous avons développé un module PowerShell permettant de trier les évènements et lever une alerte en cas de comportement suspicieux. Cet outil sera prochainement mis à disposition sur notre site web.

Implémentation

Conscients de cette problématique présente dans de nombreuses sociétés, SCRT propose du conseil pour la mise en place de mécanismes de détection d’incidents ainsi que de l’aide pour l’écriture de procédure de réponse à incidents.

Sécurité des terminaux Android

Introduction

Lors d’un précédent article nous nous intéressions à la sécurité des terminaux iOS, notamment face aux outils de jailbreak permettant de contourner le chiffrement de la NAND. Bien que le marché Suisse soit majoritairement tourné vers iOS pour le moment, la sécurité des terminaux Android n’est pas à négliger, d’autant plus que leur popularité est grandissante.

Contrairement au cas iOS, il est beaucoup plus difficile de généraliser sur la sécurité des terminaux Android du fait de la grande diversité de constructeurs sur le marché et des modifications ou spécificités que chacun d’eux peut introduire dans ses terminaux. De plus, contrairement à iOS dont les terminaux ont tendance à converger assez rapidement vers la dernière version disponible, un large éventail de versions Android peut être rencontré en parallèle, pour lesquelles les fonctionnalités qui nous intéressent peuvent ne pas être uniformes (un exemple de ceci est la disponibilité de la fonction de chiffrement). Ceci étant dit, nous détaillons dans cet article quelques cas que nous espérons suffisamment génériques pour être applicables à une majorité de terminaux.

Récupération des données

Dans le cas d’un terminal Android « lambda », un certain nombre de fonctionnalités ou de limitations peuvent avoir un impact direct sur la sécurité du terminal face à une tentative de récupération de données, par exemple en cas de perte ou de vol de l’appareil. Certaines des ces fonctionnalités sont liées à des aspects « hardware » et donc directement liées à des choix faits par le constructeur. Parmi celles-ci nous allons notamment considérer le verrouillage du bootloader (qui empêche le démarrage du terminal sur une image système modifiée) et la présence d’éventuelles interfaces de debug accessibles (JTAG, UART, …).

A l’inverse d’autres fonctionnalités sont directement proposées par le système d’exploitation (Android) et donc communes à tous les constructeurs, notamment ADB (Android Debug Bridge), le verrouillage du téléphone par un code ou un schéma ou encore le chiffrement des données (disponible depuis Android 3.0 pour les tablettes et depuis Android 4.0 pour les téléphones).

Cas #1 : out-of-the-box

Dans une grande majorité des cas, les terminaux Android sont vendus avec une configuration assez peu « intéressante » pour un attaquant, comprendre par là que la protection des données est assez bien garantie. En effet, le bootloader est généralement verrouillé par défaut et ADB n’est pas activé. Seul bémol (mais de taille) à cela, le chiffrement des données n’est pas activé par défaut sur les terminaux actuellement disponibles. Bien entendu, tout cela est inutile si l’utilisateur ne protège pas son terminal par un code d’accès (passcode). Toutefois ce cas étant trivial, nous n’allons pas le considérer et nous partons du principe que cette fonctionnalité est activée.

Un attaquant a alors trois options principales pour extraire des données d’un terminal:

  • « Deviner » le passcode (ou tenter une smudge attack s’il s’agit d’un schéma de verrouillage)
  • Extraire des données de la carte externe (micro-SD) si le terminal en dispose (ce qui n’est, par exemple, pas le cas des terminaux de type Nexus de Google). Les données contenues par la micro-SD peuvent toutefois ne pas être les plus intéressantes pour l’attaquant
  • Utiliser un équipement permettant l’extraction des données de la NAND, par exemple via l’interface JTAG

Cette dernière option est généralement toujours envisageable, mais elle demande du matériel spécifique ainsi que le démontage plus ou moins profond du téléphone, suivant les modèles. Si ces deux conditions sont remplies, il devient alors toutefois possible d’extraire l’intégralité des données en faisant un « dump » complet de la mémoire flash.

AND_PHOTO1

Lors des tests menés dans notre laboratoire sur des terminaux équipés d’une NAND de 4Go, il aura fallu environ 4h pour réaliser une copie bit-à-bit au travers de l’interface JTAG.

AND_PHOTO2

AND_PHOTO3

Toutefois, une fois cette copie effectuée il aura suffi de quelques secondes (à l’aide d’un petit script Python) pour localiser les « hash » du passcode, le « salt » correspondant ainsi que pour récupérer le code par brute-force (PIN de 4 chiffres). Cette récupération est par ailleurs déjà bien documentée sur Internet.

Une fois le passcode récupéré il suffit alors de remonter pour en prendre le contrôle total et obtenir l’accès à ses données. Si ceci s’avère impossible, il est évidemment également possible d’extraire les autres données intéressantes directement à partir du dump de la flash. Il faut toutefois, pour cela, s’affranchir du fait que le dump est très bas niveau et ne fournit pas directement un système de fichiers pouvant être monté. Néanmoins, comme pour le cas du passcode, en sachant ce que l’on recherche quelques expressions régulières peuvent faire des miracles.

Cas #2 : Android Debug Bridge

Cette fonctionnalité se découpe sous la forme d’un client installé avec le SDK et d’une partie serveur lancée sur le terminal Android. Très utilisé dans le cadre du développement d’applications, il offre des options intéressantes pour un attaquant, telles que l’installation et le lancement d’applications.

Dans le cas où cette fonctionnalité est activée sur un terminal, un attaquant peut aisément accéder aux données de l’utilisateur, installer des applications et les lancer et ce sans avoir besoin du passcode.

Il est donc très important, pour la sécurité d’un terminal Android, de s’assurer que ADB n’est pas activé par mégarde.

Cas #3 : bootloader déverrouillé

Le bootloader est responsable du démarrage de l’appareil et de l’amorce du système d’exploitation. C’est donc lui qui démarre Android et qui fournit également la possibilités de démarrer le terminal sur une image de « recovery » permettant ainsi, par exemple, de flasher un nouveau système. Dans son mode de fonctionnement par défaut (verrouillé), ce bootloader ne permet le démarrage d’une image système que si cette dernière est signée par le constructeur. Toutefois, la plupart des constructeurs permettent maintenant de déverrouiller le bootloader afin de démarrer (ou de flasher) une image système non-signée (par exemple un système Android « rooté »).

Ainsi, si le bootloader du terminal à attaquer n’est pas verrouillé il est possible de démarrer le terminal sur une image « recovery » modifiée, contenant – par exemple – des outils de forensique offensif dans le but d’extraire des informations. Le système de recovery ayant généralement un accès complet à la flash (des particularités peuvent exister pour certains constructeurs, notamment pour ce qui est des droits d’écriture) il est alors possible, depuis là, d’accéder à l’intégralité des données utilisateur.

Une contre-mesure à cela est fournie par le chiffrement des données, toutefois, il sera alors possible (si le terminal a été dérobé alors qu’il était démarré mais verrouillé) de tenter des attaques de type cold-boot visant à récupérer la clé de chiffrement.

A ce stade le lecteur est en droit de se demander pourquoi il ne suffit pas – alors – pour l’attaquant de déverrouiller le bootloader du terminal pour en extraire les données. La raison est simple : l’opération de déverrouillage du bootloader entraîne, chez tous les constructeurs qui le permettent, la remise à zéro du terminal et ainsi l’effacement des données. Il ne s’agit pas là d’une contrainte technique mais bel et bien d’une fonctionnalité de sécurité visant justement à empêcher la compromission des données.

Conclusion

Comme nous avons tenté de le présenter dans cet article, la combinaisons des différentes fonctionnalités de sécurité peut rendre plus ou moins complexe la récupération des données sur un terminal Android. Les configurations d’usine sont généralement prévues pour être sûres toutefois, la grande liberté laissée à l’utilisateur dans la modification de son terminal Android (par opposition aux terminaux iOS) permet également à ce dernier d’effectuer des modifications entraînant un risque pour la sécurité de ses données.

De plus, il est à relever que même dans le cas où le terminal dispose d’un bootloader verrouillé et que ADB n’est pas démarré, il reste possible pour un attaquant ayant quelques connaissances en électronique (et surtout l’équipement approprié), de procéder à une copie bit-à-bit de la NAND et ainsi accéder aux données stockées sur le terminal, pour autant qu’elles ne soient pas chiffrées.

Pour conclure nous relèverons donc que, bien que ceci ne soit – malheureusement – pas fait par défaut sur les terminaux Android, l’activation du chiffrement des données apparaît comme une composante de base indispensable à une bonne protection des données de l’utilisateur.

Julien Bachmann
Sergio Alves Domingues

Jailbreaks iOS et risques pour l’entreprise

Introduction

La sortie récente du jailbreak evasiOn pour iOS 6 et 6.1 et ce type d’outil en général inquiètent les entreprises ayant déployé des terminaux Apple. Nous allons donc ici, non pas faire une description technique d’evasiOn, mais expliquer les risques que cela implique en entreprise.

Post-evasiOn

Tout d’abord un topos de la situation avant lundi: via l’exploitation d’une vulnérabilité dans la bootrom des terminaux iOS (limera1n) il était possible de démarrer les iPhones 4 (et précédents) et iPad 1 sur une ROM non-signée. Du fait que ce composant est intégré au hardware, il est impossible à Apple de corriger la vulnérabilité sans produire de nouveaux modèles (ce qui a été le cas depuis l’iPhone 4S et iPad2).

Il est alors possible de démarrer les terminaux impactés avec une ROM contenant des outils spécialisés dans le but de brute-forcer le passcode défini par l’utilisateur. Sur un iPhone4, le temps moyen pour un passcode de 4 chiffres est de 10 minutes… A partir de ce moment, l’attaquant (ou l’analyste forensics) a accès à tous les secrets protégés à l’aide des fonctionnalités telles que le stockage dans le KeyChain ou le chiffrement à l’aide de la Data Protection API (ex: mot de passe du domaine utilisé pour la connexion à MS Exchange et certificats et clefs privées pour le VPN d’entreprise). La copie complète des informations stockées sur le terminal peut également être réalisée (environ 45min pour 16Go).

Un attaquant qui a physiquement accès à un terminal protégé par 4 chiffres pendant moins de 20 minutes peut donc réaliser des dégâts considérables en fonction des données stockées et ce sans laisser d’autres traces qu’un redémarrage dans les logs…

evasiOn

Les jours précédents la sortie de cet outil il a été possible de comprendre que le jailbreak nécessiterait de connecter le terminal via USB. On aurait donc pu penser, malgré une faible probabilité due aux revues effectuées par Apple, à une vulnérabilité pré-boot du même type que limera1n. Fort heureusement ce n’est pas le cas et le terminal doit être déverrouillé afin d’effectuer la manipulation. Du fait que la première phase d’evasiOn passe par la modification d’un backup, il est nécessaire que le terminal soit déverrouillé ou tout du moins déjà pairé avec le poste auquel il est connecté pour qu’il autorise le backup.

Dans le cas où un passcode a été défini, il n’est donc actuellement pas possible à un attaquant d’accéder au contenu d’un terminal iOS verrouillé. On pourrait néanmoins voir apparaitre des vers se propageant de postes Windows/OSX infectés aux terminaux iOS via l’injection de code exécutable dans iTunes.

A l’heure actuelle, les terminaux de versions supérieures ou égales à l’iPhone 4S et iPad 2 sont donc protégés contre une attaque liée à un accès physique (pour rappel, le système de fichiers d’iOS est chiffré avec une clef en partie stockées dans le matériel).

Conclusion

Du fait que la découverte d’une vulnérabilité pré-boot ne doit pas être exclue, il est recommandé de forcer l’utilisation de passcodes d’au moins 6 chiffres et si possible alpha-numériques. D’autre part, la démarche ne doit pas s’arrêter là et les procédures de changement de mot de passe en cas de perte ou de vol de terminaux doivent être revues, ainsi qu’expliquer les risques aux utilisateurs afin qu’ils préviennent au plus vite en cas de disparition de leur terminal.

Restent également les vulnérabilités dans les applications ayant une large surface d’attaque tels que MobileSafari. Ces dernières requièrent de mettre en place une politique de mise à jour des terminaux.

Comme l’a rappelé Vincenzo Iozzo, il ne faut pas oublier que les attaquants choisiront toujours le chemin avec le coût le plus faible vers leur cible. Ainsi, la sécurité des applications déployées sur les terminaux doit également être prise en compte. Le système de cloisonnement d’iOS n’empêchant pas l’accès aux données d’une application via l’exploitation d’une vulnérabilité dans cette dernière (ou les données auxquelles elles a accès, ex. carnet d’adresses).

Les oubliés des forensics: les Local Shared Objects

Dans le cas d’une analyse forensics, lors de la reconstruction des actions d’un utilisateur les cookies du navigateur sont l’un des premiers points à être analysé. Néanmoins, dans un navigateur ce dernier n’est pas le seul à laisser des traces: le lecteur Flash dispose également d’un système de cookies.

Le lecteur Flash utilise également des cookies afin de permettre aux sites de suivre les visiteurs lors de leurs passage. Par défaut, le stockage des cookies est activé ce qui en fait un atout lors de l’analyse d’un poste client. Flash intègre un mécanisme de sécurité basé sur le nom de domaine afin de restreindre l’accès aux LSO, mais ces fichiers sont indépendants du navigateur.

Les Local Shared Objects sont stockés dans le répertoire personnel de chaque utilisateur avec l’extension .sol. Un LSO contient les informations suivantes en plus des métadonnées:

  • le nom du site
  • le nom de l’objet représenté
  • le type des données stockées (nombre, booléen, chaine de caractères, date, …)
  • les données stockées

L’outil log2timeline peut être utilisé afin d’extraire des informations de fichiers LSO.

[sourcecode language=”bash”]

$ perl log2timeline -f sol -z Europe/Zurich "/Users/julien/Library/Preferences/Macromedia/Flash Player/#SharedObjects/36QMEH7N/www.hulu.com/BeaconService.sol"
Starting to parse file using format: [sol]
0|[LSO] modified -> File: /Users/guru/Library/Preferences/Macromedia/Flash Player/#SharedObjects/36QMEH7N/www.hulu.com/BeaconService.sol and object name: BeaconService variable: {visitNumber = (visit => 1, modified => 1253639116241, )}|0|0|0|0|0|1253639092|1253639092|1253639092|1253639092

[/sourcecode]

A noter que Google Chrome est le premier navigateur à avoir ajouté un lien vers la page de gestion des LSO dans sa fonctionnalité de suppression de l’historique de navigation.