Le test d’intrusion d’applications iPhone et iPad : premiers pas

MISC

n°

novembre 2012

Par

Vous venez de remporter un contrat pour une série de tests d'intrusion. Un peu de reconnaissance, d’infrastructure : pas de problème. Une application web ? C’est votre domaine. Et il y a aussi une application iPhone. Comment s'y prendre ? Par quoi commencer ?

1. Introduction

Les mobiles sont devenus des supports incontournables dans l’environnement informatique des entreprises. Les applications mobiles offrent en effet un support innovant et moderne pour communiquer sur son activité, promouvoir ses produits et ses offres, mais aussi ouvrir son système d'information aux collaborateurs et parfois même à ses clients.

Il n’y a pas si longtemps, une entreprise désirant communiquer ou promouvoir un produit créait tout simplement un site web. Aujourd’hui, avec l’essor fulgurant des applications mobiles, les sites web sont petit à petit remplacés avantageusement par ce type d’application offrant notamment plus de confort d'utilisation pour le client final.

De nombreuses personnes pensent à tort que les applications iPhone et iPad sont sûres. Il est vrai que toutes les applications iOS passent à la loupe d'Apple avant publication sur l'App Store. Mais la sécurité des applications n'est actuellement pas un point vérifié. Apple investit des moyens importants pour sécuriser ses appareils et son système d'exploitation iOS, mais la sécurité des applications est totalement du ressort des développeurs.

Dès lors, les « pentesters » sont de plus en plus sollicités pour vérifier la fiabilité et identifier les vulnérabilités de ces applications. Cet article n’a pas pour vocation de balayer de manière exhaustive toutes les techniques ou méthodes utilisées dans le cadre de tests d’intrusion d’application mobile, mais se veut plus être un guide pratique pour mettre en œuvre ce type de tests et identifier par ailleurs les problèmes de sécurité parmi les plus répandus dans les applications iPhone et iPad.

2. Le contexte

Nous supposons ici que le test d'intrusion se fait en « boîte noire » ou « boîte grise ». En effet, dans le cas d’un test « boîte blanche », une revue de code est probablement plus efficace. Notre point de départ est donc une application sur un iPhone ou un iPad, voire juste le lien dans l’App Store.

Nous n’aborderons ici que les applications natives ou hybrides. Les applications HTML s’exécutent simplement dans Mobile Safari et ne sont pas différentes des autres applications web du point de vue d'un test d'intrusion.

3. Préparation

3.1. Choisir un appareil

La première étape est de disposer d’un appareil pour effectuer les tests. Il n'est pas question d’utiliser le simulateur (iOS Simulator) : ce n’est pas un émulateur et il ne peut pas faire tourner d'applications compilées pour le processeur ARM.

Il est fortement recommandé d’utiliser des appareils dédiés exclusivement aux tests et ceci pour deux raisons : si vous utilisez un appareil personnel avec votre email, votre calendrier, etc., vous allez sans arrêt devoir trier entre vos données personnelles (les requêtes au serveur de courrier électronique, par exemple) et les données de l’application. D’autre part, si vous décidez de jailbreaker l’appareil, certaines sécurités mises en place par Apple seront désactivées et vous prendrez alors des risques avec vos données.

La dernière mouture de l’iPod Touch (i.e. la 4ème génération) est particulièrement intéressante pour le « pentester » : à part, bien entendu, la téléphonie, cet appareil est très similaire à un iPhone. Son prix, par contre, est de trois à quatre fois moindre. Dans la pratique, il est cependant préférable d’avoir un échantillon de chaque appareil et de renouveler le parc, au moins partiellement, tous les ans. En effet, même s’il est possible d’installer la dernière version du système d’exploitation sur certains anciens modèles, certaines fonctionnalités ne sont disponibles que sur le dernier matériel. C’est par exemple le cas de Siri qui n’est disponible que sur l’iPhone 4S.

3.2. Jailbreaking

Le jailbreaking consiste à exploiter des failles de sécurité de l’appareil pour en prendre totalement le contrôle et sortir de la cage dorée mise en place par Apple. Les inconvénients du jailbreaking sont nombreux : cette manipulation est interdite par Apple lorsque l’on est membre de l’un de leurs programmes pour développeurs. Comme indiqué précédemment, des pans entiers de la sécurité du mobile sont désactivés (comme la vérification des exécutables). Côté avantages, c’est actuellement la seule méthode pour étudier les applications et leur fonctionnement « in vivo ».

Nous ne discuterons pas plus ici du jailbreaking, des centaines de sites web [JB] expliquent cela en détail.À noter que certaines applications tentent de détecter le jailbreaking (Apple a même fourni une API publique à une époque avant de se raviser). C'est en particulier le cas des applications liées aux systèmes de gestion de mobiles (MDM) comme MobileIron ou Good.

3.3 Préparer l’appareil

Il est préférable d’enlever la carte SIM : il n’y a rien de plus désagréable que d’avoir un appareil qui vibre ou qui sonne au beau milieu d’un test difficile. Il est aussi préférable de désactiver les comptes emails et autres iCloud qui peuvent perturber les captures réseau, ainsi que les options telles que le « Auto-Lock ». Avec un appareil dédié, ces manipulations sont plus simples.

3.3.1. APT

Dans le cas d’un appareil jailbreaké, il y a un peu plus de travail. En effet, nous allons installer un certain nombre d’outils. Pour cela, il y a deux écoles : utiliser Cydia, l’interface graphique installée par la majorité des logiciels de jailbreaking, ou utiliser la ligne de commandes à travers une session SSH. Et là, surprise, on utilise la commande apt-get. En effet, bien que iOS soit plutôt un cousin de FreeBSD, c’est le système de Debian qui a été choisi et adapté par la communauté du jailbreaking [SAURIK]. Le tableau 1 donne les commandes APT les plus utilisées (la dernière, respring, n’est pas vraiment une commande APT mais est très utile dans ce contexte).

Commande	Signification
apt-get update	Met à jour les référentiels (repositories)
apt-get upgrade	Installe les mises à jour disponibles
apt-get install	Installe un paquet
apt-get remove	Enlève un paquet
dpkg -l	Donne la liste des paquets installés
respring	Rafraîchît l’écran (« springboard ») en tuant et en redémarrant le processus associé

Tableau 1

Pour utiliser ces commandes, vous devez d’abord installer le bon paquet. Dans Cydia, sélectionnez un profil Hacker ou Developer (lors de la première ouverture), sinon le paquet n’apparaîtra pas. Ensuite, dans « Search », faites une recherche de « APT 0.7 Strict ». Vous devez trouver un paquet avec ce nom exact. Il y a aussi un paquet « APT 0.7 Strict (lib) », ce n’est pas le bon.

3.3.2. OpenSSH

Bien entendu, il vous faut aussi OpenSSH avec le paquet du même nom. Il est alors indispensable de changer immédiatement les mots de passe des comptes de l’iPhone sous peine de se faire pirater. Il y a deux utilisateurs, root et mobile, avec le même mot de passe sur tous les appareils : alpine. Pour changer ces mots de passe, connectez-vous en SSH et entrez les commandes :

passwd

passwd mobile

3.3.3. Installer les autres paquets

Vous pouvez installer d'autres paquets en ligne de commandes, ce qui est nettement plus rapide que Cydia. Le tableau 2 donne une liste d’outils utiles dans le contexte du test d’intrusion :

Paquet	Description
odcctools	Commandes otool, … portées depuis Mac OS X
gdb	Portage de GDB sur iOS. Attention, actuellement, cette version ne marche pas. Il faut éviter d'installer ce paquet tant que le problème n'est pas réglé (voir plus loin)
inetutils	ftp, ping, telnet, tftp
lsof	Montre la liste des fichiers ouverts
netcat	Pour connecter tcpdump à Wireshark, par exemple
adv-cmds	Commandes ps, etc.
developer-cmds	Principalement pour hexdump
network-cmds	arp, ifconfig, netstat, route et traceroute
nmap	Scan réseau, pas vraiment indispensable pour le pentest de l’application mais utile pour les pentests en général
tcpdump	Pour les captures réseau
top	Pour voir les processus
wget	Pour télécharger des fichiers
nano	Pour éditer les fichiers
less	La commande less
sqlite3	Pour lire les bases de données SQlite

Tableau 2

3.3.4. Invite bash

C’est un goût personnel, mais je préfère aussi changer la ligne d’invite de bash. Il faut éditer (par exemple avec nano) le fichier /etc/profile et remplacer la ligne PS1 par quelque chose comme :

export PS1='[\W] $ '

Dans cet exemple, cela permet d'afficher uniquement le nom du répertoire courant entre crochets, plutôt que le chemin complet.

3.3.5. GDB

La situation de GDB, le debugger GNU, est assez confuse. C'est un outil indispensable, nous allons donc détailler les options :

- Il existe une version de GDB dans Cydia, mais elle ne marche plus avec les versions récentes de iOS (à partir de 4.3). Cette situation perdure depuis des mois pour une raison inconnue.

- Il est possible de trouver sur Internet des versions mises à jour, mais il n'est pas toujours évident d'en vérifier la provenance ni de s'assurer de l'intégrité de ces versions.

- L'option la plus sûre est de compiler soi-même GDB. Pour cela, il vous faut Xcode. La procédure est documentée par pod2g [POD2G].

- Malheureusement, et pour ajouter à la confusion, la procédure de pod2g ne s'applique qu'aux versions de Xcode antérieures à la version 4.3 (de Xcode, pas d'iOS). Pour la version 4.3 (ou postérieure), le chemin de GDB est le suivant :

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin.

3.4. Préparer une station de travail

Une station est indispensable pour se connecter à l’iPhone, visualiser les captures réseau, étudier les exécutables et les différents fichiers. La meilleure option est de disposer d’un Macintosh sous Lion (Mac OS X 10.7) ou Mountain Lion (Mac OS X 10.8). C’est même indispensable si l’on veut utiliser les outils de développement pour iPhone comme Xcode. Àpart ce dernier point, Windows est une alternative tout à fait viable. On trouve quasiment tous les outils nécessaires. Par contre, il est plus difficile d’utiliser un système d’exploitation ouvert comme Linux ou FreeBSD. C’est possible, mais les outils sont peu nombreux et limités. Par exemple, il n’existe pas d’éditeur sous Linux permettant d’éditer directement les plists (Property Lists utilisées en particulier pour les préférences de l'utilisateur) en format binaire. On peut les convertir en XML avec un script Perl [PLUTIL], mais cela n’est pas du tout pratique.

3.4.1. Les outils

Le tableau 3 donne une liste d’outils utiles, certains sont gratuits, d’autres commerciaux. Cette liste n’est pas exhaustive mais donne un bon point de départ.

Nom	Plate-forme	Type	Desc
SecureCRT	Win/Mac/Linux	Commercial	Client SSH
Putty	Win/Mac/Linux	Libre	Client SSH
WinSCP	Win	Libre	Client FTP, SFTP, … pour le transfert de fichiers
Cyberduck	Mac	Shareware	Client SFTP (entre autres) pour le transfert de fichiers
Plist Editor for Windows	Win	Freeware	Éditeur de « plists » sous Windows
Xcode	Mac	Gratuit	Outil de développement pour iOS et Mac OS X
SQLite Database Browser	Win/Mac	Libre	Outil graphique pour visualiser et éditer les bases de données SQLite 3
Apple iPhone Configuration Utility	Win/Mac	Gratuit	Outil de gestion des iPhones et des iPads
Wireshark	Win/Mac/Linux	Libre	Outil graphique de capture et d'analyse réseau
Burp Suite Pro	Win/Mac/Linux	Freeware	Proxy spécialisé pour le test d'intrusion
WebScarab	Win/Mac/Linux	Libre	Proxy spécialisé pour le test d'intrusion
IDA Starter ou Pro	Win/Mac/Linux	Commercial	Outil pour la rétro-ingénierie
ARM decompiler	IDA	Commercial	Décompilateur pour les processeurs ARM
ADVsock2pipe	Win	Libre	Outil permettant de « connecter » un socket avec un « named pipe » Windows

Tableau 3

3.4.2. IDA

IDA de la société belge Hex-Rays est l'outil de référence pour la rétro-ingénierie quelle que soit la plate-forme. Depuis peu (version 6.2), Hex-Rays a considérablement amélioré son support des binaires Mach-O (le format utilisé par iOS and Mac OS X) et d'Objective-C (le langage principalement utilisé sur iOS). Hex-Rays fournit une version gratuite et une version démo d’IDA. Il est possible de s'exercer avec la démo, mais la version gratuite est trop ancienne pour être utilisable dans ce contexte.

3.4.3. Décompilateur

Hex-Rays propose également un décompilateur qui s'intègre à IDA. Son prix peut décourager. Avec un peu d’habitude, il n’est pas si difficile de lire le code machine ARM directement : l’Objective-C génère souvent une succession d’appels à des méthodes (messages) facilement identifiables. Mais si vous n’avez pas l’habitude du code ARM, si vous voulez gagner du temps ou si le code contient des portions codées en C ou en C++, c’est une aide indéniable.

3.5. Préparer un réseau

L’étape suivante consiste à connecter l’iPhone et la station de travail. Il est souvent indispensable de connecter également l’iPhone à Internet. Le plus simple est de mettre en place un réseau Wi-Fi dédié. Même si l’on configure du WPA ou du WPA2 avec une clé complexe, il est préférable d’être prudent et d’isoler la station de travail de ce réseau Wi-Fi par un pare-feu et de ne permettre que le trafic sortant. Interdisez les connexions directes de ce réseau Wi-Fi vers votre station ou votre LAN. Assurez-vous aussi de respecter la politique de sécurité de votre entreprise, en particulier concernant ce Wi-Fi dédié.

4. Le test d’intrusion

4.1 Capture réseau passive

Avant toute chose, il est préférable de faire une reconnaissance : que fait l’application, avec quels serveurs communique-t-elle, avec quels protocoles, etc. ?

4.1.1 Tcpdump

Une capture réseau avec tcpdump sur l'iPhone va nous fournir les informations recherchées. Il est même possible de voir en temps réel la capture en connectant tcpdump sur l’iPhone avec Wireshark sur la station. Sur la station (Macintosh ou Linux), ouvrir un terminal :

mkfifo wireshark

ssh root@10.22.1.199 'tcpdump -nn -w - -U -s 0 "not port 22"' > ./wireshark

La première commande crée un fifo et la deuxième lance, par SSH, la commande tcpdump sur l’iPhone. Le résultat de la capture est transmis dans la sortie de SSH et est redirigé vers le fifo. L’adresse IP est celle de l’iPhone que vous pouvez trouver dans les paramètres de la connexion Wi-Fi.

Il faut ensuite ouvrir Wireshark. Au lieu de capturer depuis une interface physique, il faut spécifier le chemin complet du fifo et lancer la capture. Attention, la capture ne démarre pas tout de suite car vous devez d’abord entrer le mot de passe SSH : revenez dans le Terminal et entrez le mot de passe root de l’iPhone. Après quelques instants, les paquets réseau apparaissent dans Wireshark.

4.1.2. Et Windows ?

Sous Windows, cette technique ne marche pas. Cependant, une capture à distance reste possible en utilisant netcat et un outil comme ADVsock2pipe qui permet de connecter un « socket » TCP à un « named pipe » Windows.

4.1.3. Autres techniques

Bien entendu, il existe d'autres techniques. La plus simple est de faire une capture, depuis la station de travail, de tout le trafic Wi-Fi. Une autre technique, plus sophistiquée, est d'utiliser des interfaces réseau virtuelles introduites avec iOS 5 et la commande rvictl [RVI] sous Mac OS X. L'avantage de ces techniques est qu'elles sont utilisables sur des appareils qui ne sont pas jailbreakés.

4.1.4. Données à repérer

Lors de cette phase, il est utile de repérer dans Wireshark les requêtes DNS, les IP des serveurs, les protocoles utilisés et le type de chiffrement (comme SSL). Il est même possible de découvrir des problèmes de sécurité comme la transmission de mots de passe sans chiffrement ou la transmission de données personnelles à des tiers.

4.2. Interception des communications

L’étape précédente a permis d’avoir une vue de l’écosystème de l’application. Mais elle est passive et l’étape suivante est active. Elle consiste à intercepter les communications, voire à modifier les requêtes et les réponses. Il y a plusieurs méthodes qui dépendent du comportement de l’application. La méthode la plus simple est d’utiliser un proxy spécialisé, comme Burp ou WebScarab. La démarche est similaire au test d’un service web à une différence près : le SSL. En effet, l’API d’Apple ne permet pas par défaut une attaque « man-in-the-middle » contre le SSL, car le certificat et la chaîne de certification sont vérifiés et la communication est coupée en cas de problème.

Ànoter que de nombreux développeurs désactivent cette vérification pour des raisons pratiques. Cela introduit une faille de sécurité importante. La présence des fonctions allowsAnyHTTPSCertificateForHost ou canAuthenticateAgainstProtectionSpace dans le binaire d'une application est souvent un indice de cette désactivation. Pire, la bibliothèque ASIHTTPRequest[ASI] (encore très utilisée bien que plus supportée par son auteur) a introduit la méthode setValidatesSecureCertificate pour cela.

4.2.1. Injection de certificat SSL

Si l’application fait correctement son travail, la communication sera coupée par iOS et l’on ne verra rien dans Burp. L’astuce pour aller plus loin est de générer ses propres certificats et d’injecter le certificat racine dans l’iPhone. Cela peut être fait très simplement avec un outil d’Apple (et donc sans jailbreak) : iPhone Configuration Utility [APPLEUTIL]. Dans le cas de l’utilisation de Burp, par exemple, il faut d’abord extraire le certificat racine [CA], créer un nouveau « Configuration Profile » et importer le certificat sous la rubrique « Credentials ». On connecte ensuite l’iPhone par USB et on installe le profil. Pour un déploiement à distance, la fonction « Share » permet de créer un fichier .mobileconfig et de l'envoyer par mail. La fonction « Export » est similaire mais permet d'installer le fichier sur un serveur web. Dans ce cas, il faut s'assurer que le type MIME « application/x-apple-aspen-config » est bien configuré pour l'extension .mobileconfig. Si l’appareil est géré par un MDM (Mobile Device Managment), il est possible de « pousser » l'installation du profil et d'automatiser cette procédure.

Il est alors possible de déchiffrer les communications, de modifier les requêtes, etc. Certaines applications poussent plus loin la vérification des certificats, mais c’est rare. Et même dans ce cas, on arrive en général à ses fins en utilisant OpenSSL pour générer des certificats très proches des originaux (même numéro de série, mêmes attributs, etc.) ou en utilisant certaines techniques avancées comme celle présentée lors du dernier BlackHat [BLACKHAT].

4.3. Études des données

L’étape suivante est la vérification des données produites par l’application, principalement des fichiers. Les applications iOS résidant dans un bac à sable, il est très facile d’isoler ces fichiers. Tout d’abord, il faut identifier le répertoire d’installation de l’application. La commande suivante donne la liste des applications installées :

find /private/var/mobile/Applications -iname '*.app'

Chaque application se trouve dans son propre répertoire avec un nom aléatoire.

Le tableau 4 donne la liste des sous-répertoires ou des fichiers intéressants pour une analyse.

Nom	Contenu
Documents	Contient les documents de l’application qui peuvent être synchronisés avec iTunes
Library/Application Support	Contient parfois des fichiers de l’utilisateur d’une application (à partir de iOS 5.0.1)
Library/Caches	Contient les données mises dans le cache (bases de données, données téléchargées, etc.)
Library/Preferences	Contient les préférences de l’utilisateur, en particulier quand l’application utilise la classe NSUserDefaults. On trouve de nombreuses informations comme des mots de passe
xxxx.app	Contient l’application elle-même (le « bundle »), y compris le binaire et les ressources
tmp	Contient les données temporaires. Suivant le cas, on peut trouver des données déchiffrées, par exemple

Tableau 4

Le système de fichiers est détaillé dans la documentation d’Apple [FS]. Les données générées par l’application peuvent être de n’importe quel type. En pratique, on trouve très souvent des « plists » ou des bases de données SQLite3. Il est possible de lire les plists directement sur l’iPhone avec la commande plutil ou sur la station avec Plist Editor ou Xcode. Quant aux bases de données, on peut les étudier en ligne de commandes avec sqlite3 ou avec l’outil graphique SQLite Database Browser.

Ànoter que chaque fichier peut être protégé par l'iOS en utilisant des clés de chiffrement. C'est le « File Data Protection ». Il est important lors d'un audit de s'assurer que le développeur a utilisé le bon mode. Par exemple, un fichier critique ne doit pas être accessible lorsque l'appareil est verrouillé.

4.4. Le porte-clés

L'iOS (ainsi que Mac OS X) possède un mécanisme permettant de stocker des secrets (comme des mots de passe ou des certificats) : le porte-clés (« keychain »). Il repose essentiellement sur une base de données SQLite et sur des clés de chiffrement gérées par iOS. Certaines de ces clés sont dérivées du code verrouillant l'appareil (s'il y en a un). Ce mécanisme offre un bon niveau de sécurité pour peu que le code de verrouillage soit assez long ou complexe (le mode « code simple » est clairement insuffisant) et que le développeur ait choisi le bon mode (« key protection », qui correspond à une clé de chiffrement).

L'API de ces porte-clés n'étant pas simple à utiliser, il est assez fréquent de trouver des erreurs. Il est malheureusement encore plus fréquent de trouver des mots de passe en clair dans les préférences de l'utilisateur, sans utilisation d'un porte-clés. L'institut Fraunhofer [FRAUNHOFER] a publié en 2011 (mis à jour en 2012) un document décrivant les faiblesses des porte-clés.

4.5. Étude du binaire

Àce stade, nous avons une bonne compréhension du fonctionnement en surface de l’application. Mais dans certains cas, il est nécessaire d’aller plus loin et d’étudier le binaire lui-même. Toutes les applications iOS sont chiffrées mais les processeurs ARM n’étant pas capables d’exécuter du code chiffré, il est déchiffré lors du chargement. Il suffit donc de copier ce code depuis la mémoire pour pouvoir l’étudier. On trouve facilement des guides pour réaliser cette opération [BACHMANN]. À noter que la majorité de ces guides supposent que l’adresse de départ de l’application est 0x2000, ce qui est loin d’être le cas avec iOS 5. En effet, l’adresse est choisie aléatoirement pour chaque application. Une bonne technique est de mettre un point d’arrêt sur la fonction doModInitFunctions. Cela a aussi l'avantage de rendre inopérantes certaines techniques anti-debug et anti-reverse. Il existe aussi une autre méthode très simple et rapide : utiliser Crackulous [CRACKULOUS].

4.5.1. IDA

Il existe quelques outils permettant d’étudier les binaires iOS comme class_dump_z [CLASSDUMPZ], otool, nm ou même une simple commande strings. Mais l’outil de référence est IDA. Un guide d’utilisation d’IDA sort du cadre de cet article, mais voici quelques conseils :

- Le décompilateur d’Hex-Rays est très pratique et permet de gagner du temps. Mais il est tout à fait possible de s’en passer.

- La version de démo d’IDA permet de s’exercer sur les binaires iOS et parfois de mener une bonne partie de l’analyse. Mais cette version ne permet pas de sauvegarder son travail et n’est donc pas adaptée à une analyse professionnelle.

- Il est fortement conseillé d'utiliser la dernière version disponible (6.3 actuellement, y compris pour la version de démo) car sinon, vous ne pourrez pas bénéficier des dernières améliorations introduites par Hex-Rays pour iOS et les processeurs ARM. En particulier, IDA est capable de correctement interpréter le code généré par le compilateur LLVM (le remplaçant de GCC) depuis la version 6.2.

- Pour iOS, la version « Starter » (anciennement « Pro Standard ») d'IDA est suffisante. Par contre, si vous voulez l'utiliser pour d'autres plates-formes et en particulier x64, la version Professionnelle (anciennement « Pro Advanced ») est indispensable.

- L’étude complète d’un binaire en partant du point d’entrée (main) ou du « delegate » de l’application (qui est l'équivalent logique d'un point d'entrée dans le monde iOS) est très longue avec des résultats mitigés. Il est, en général, bien plus efficace de partir des données collectées lors des phases précédentes, en particulier des URL, de chercher la chaîne de caractères correspondante et de demander à IDA le code référençant ces chaînes. On se concentrera alors sur ces parties pour, par exemple, comprendre un algorithme de chiffrement.

4.6. Les tests plus avancés

Les paragraphes précédents ne donnent que les éléments de base pour mettre en place un test d’intrusion d’une application iPhone ou iPad. Il existe des techniques plus avancées, comme le cassage des keychains, les attaques par Cross-Site Scripting sur les applications intégrant WebKit, les injections SQL et sur Core Data, les attaques contre les bibliothèques XML et les débordements de tampon pour ne citer que quelques exemples. À noter une technique intéressante, quoique pas très simple à mettre en œuvre : l’injection de code avec Cycript [CYCRIPT]. Cette technique est bien documentée dans le chapitre 7 de l’excellent livre de Jonathan Zdziarski « Hacking and Securing iOS Applications » [ZDZIARSKI].

5. Les vulnérabilités communes

iOS est un système d'exploitation moderne et incorpore de nombreuses fonctions de sécurité avancées telles que l’ASLR (« address space layout randomization »), la signature de code, un circuit cryptographique embarqué, la compartimentation des applications, etc. D'autre part, l'Objective-C est un sur-ensemble du C et de ce fait, il souffre théoriquement de certains des mêmes maux : les débordements de tampon sont toujours d'actualité dans le monde iOS. Mais en pratique, ce sont bien d'autres problèmes de sécurité que l'on trouve fréquemment lors d'audits.

5.1. Absence de SSL

Cela peut paraître étonnant a priori, mais de nombreuses applications, et pas des moindres, oublient le SSL. Ou alors elles l’utilisent lors de l’authentification et l’oublient lors du passage d’une commande et transmettent ainsi en clair le mot de passe de l’utilisateur. Pour peu que celui-ci soit connecté à un réseau Wi-Fi public, n'importe qui peut alors voler ses identifiants.

5.2. SSL mais sans vérification

Comme évoqué précédemment, les développeurs désactivent souvent la vérification des certificats SSL pour des raisons pratiques : ils n’ont pas de certificat valide lors des développements et ne savent pas injecter leur propre certificat dans l’iPhone ou dans le simulateur. Lors de la publication, la désactivation reste par erreur.

5.3. Mots de passe en clair

Les mots de passe sont très fréquemment en clair dans les préférences de l’utilisateur. Parfois, ils sont encodés (en base 64, par exemple), mais c’est un jeu d’enfant de les reconnaître.

5.4. Pseudo chiffrement

iOS possède une bonne palette de primitives cryptographiques, en particulier AES. Et pourtant, on trouve souvent des pseudo-chiffrements ou des pseudo-hachages comme des CRC-64. Une étude rapide avec IDA permet souvent de reconnaître l’algorithme. Quand la méthode s’appelle simplement « crc », il ne faut pas beaucoup de temps pour en déduire l’algorithme.

5.5. Erreurs logiques

Très souvent, les services web et les applications iOS ne sont pas développés par les mêmes équipes. Et cela donne lieu à des erreurs logiques, en particulier dans les phases d’authentification et d’autorisation. Dans cette même catégorie, on classera les décisions logiques prises dans l’application alors qu’elles devraient l’être au niveau du serveur : les développeurs ne réalisent souvent pas qu’un attaquant peut modifier le comportement d’une application à la volée, soit en manipulant le trafic réseau, soit directement avec des outils comme Cyscript [CYCRIPT] ou MobileSubstrate [SUBS].

Conclusion

Cet article ne se veut en aucun cas une revue exhaustive du test d'intrusion d’applications iOS, mais une introduction pratique à cet exercice. L’iOS, l’iPhone et l’iPad sont de très bonnes plates-formes au niveau sécurité, avec beaucoup de fonctions avancées comme l’ASLR, la signature de code, un circuit cryptographique embarqué, etc. Mais aujourd’hui, les applications iOS ne sont pas à la hauteur, même si les choses progressent dans certaines entreprises : les applications Facebook et LinkedIn utilisent enfin le SSL. Ce n’était pas le cas il y a quelques mois.

L'absence flagrante de publications à propos des failles de sécurité des applications iOS et plus généralement des applications mobiles n'est également pas étrangère à cette situation. Certaines failles connues n'ont été corrigées qu'après une série d'articles dans les journaux en ligne. L'absence de méthodologie est aussi à déplorer. Certaines initiatives comme OWASP Mobile [OWASP] ou Intrepidus [INTREPIDUS] sont encourageantes, mais avancent lentement et leurs recommandations sont difficilement applicables en pratique.

Mais l'on peut raisonnablement parier que la situation va évoluer et suivre exactement le même chemin que les sites web il y a plusieurs années : les sociétés, volontairement ou non, réalisent petit à petit qu’elles doivent se préoccuper de la sécurité de leurs applications mobiles et de nos données personnelles.

Remerciements

Mes remerciements à Flora Bottaccio, Annika Meyer, Dominique Bongard, Michel Dubois, Michaël Chochois, Renaud Deraison et Britney pour leur relecture et leurs précieux conseils.