Auditer la sécurité d’une application iOS avec Needle – Partie 2/2

Malheureusement la version de class_dump fournie ne supporte pas les applications 64bits. Un contournement possible est d’utiliser le module hooking/frida/script_enum_all-methods ou tout simplement de récupérer le fichier ipa (l’archive de l’application) avec binary/installation/pull_ipa pour ensuite utiliser une version plus récente de class_dump sur sa machine.

Ici l’opération est lancée sur Damn Vulnerable iOS Application [dvia], une application à visée éducative.

Le fichier ipa est récupéré.

Puis class_dump est lancé.

Pour finalement analyser les en-têtes récupérées.

Ces en-têtes (voir encart « Interfaces/méthodes ») seront utiles pour identifier les objets utilisés, en déduire les fonctions de sécurité et finalement tenter de les contourner.


Interfaces/méthodes

Objective-C, un langage orienté objet qui date des années 80 créé à l’époque de la société NeXT (la parenthèse hors Apple de Steve Jobs) est utilisé pour développer les applications natives sur iOS.

Dans ce langage qui est une évolution du C, le code est découpé en deux parties :

  • les fichiers .h qui sont les en-têtes et qui contiennent les interfaces de classes définissant la manière dont les objets doivent être utilisés ;
  • les fichiers .m qui contiennent les méthodes et les implémentations, le code proprement dit.

4.2 Sécurité des données

De par leur nature, les terminaux peuvent facilement être volés. Les développeurs d’applications sensibles à la sécurité doivent donc être vigilants avec les données que leurs applications manipuleront et qui seront persistantes sur les terminaux. L’auditeur peut donc vérifier avec quelles précautions les données sensibles sont stockées en essayant d’identifier le contenu stocké en clair, de manière chiffrée, mais en utilisant un algorithme de chiffrement maison ou encore avec une classe de protection des données inappropriée (voir encart « Data Protection Class »).


Data Protection Class

Sur iOS, l’ensemble des fichiers est chiffré. Les classes de protection de données définissent les conditions de déchiffrement des fichiers. Les fichiers appartenant à la classe la plus restrictive, NSProtectionComplete, ne sont accessibles que lorsque le terminal est déverrouillé, en effet ils sont chiffrés avec une clé dérivée du code PIN de l’utilisateur et la clé AES du terminal. Ceux appartenant à la classe la moins restrictive, No Protection, sont accessibles même si le terminal est verrouillé. NSFileProtectionCompleteUntifFirstUserAuthentication offre la même protection que NSProtectionComplete à ceci près que la clé de chiffrement n’est pas supprimée lorsque le terminal est verrouillé. C’est-à-dire que les fichiers sont inaccessibles uniquement tant que l’utilisateur n’a pas démarré son terminal puis tapé au moins une fois son code PIN. Finalement, Protected Unless Open laisse accès aux fichiers tant qu’ils sont ouverts.


Les modules dédiés à ce travail sont très logiquement classés sous l’arborescence storage.

La mise en cache de frappes clavier sensibles (ex. : identifiants) est un cas d’école. Le module storage/caching/keyboard_autocomplete qui va extraire toutes les frappes clavier mises en cache (automatiquement par le système pour personnaliser l’autocorrection) permet de procéder à cette vérification.

Aucun identifiant ne semble avoir été mis en cache ici, mais si c’était le cas les développeurs pourraient se prémunir de ce comportement en spécifiant la déclaration UITextAutocorrectionTypeNo.

À noter que seul le clavier standard (blanc) est concerné par cette mise en cache, le noir, utilisé notamment par iTunes, ne l’est pas.

Sur iOS lorsque l’utilisateur passe d’une application à une autre, une capture d’écran est réalisée par défaut, ce qui permet de les afficher toutes en appuyant deux fois sur le bouton principal (Home).

Dans le cas où des informations sensibles sont manipulées (application bancaire par exemple ou gestionnaire de mots de passe), cette fonctionnalité peut toutefois être désactivée (le développeur peut, par exemple, désigner une image statique qui sera utilisée systématiquement pour la capture d’écran).

Le module storage/caching/screenshot permet de vérifier le comportement de l’application en récupérant l’image qui a été stockée.

Fig. 5 : Capture d’écran récupérée avec le module « storage/caching/screenshot ».


Les modules
storage/data/files_xxx vont rapatrier puis afficher les fichiers de cache, les cookies, les fichiers plist ou les bases sqlite.

L’application Skype stocke les conversations dans une base sqlite (DataStore.sqlite).

On peut constater que le fichier utilise la classe de protection  NSFileProtectionCompleteUntifFirstUserAuthentication et qu’au sein de la base SQLite les conversations ne sont pas chiffrées (voir le dump SQLite et la capture d’écran du terminal). Par ailleurs, les conversations sont également sauvegardées par iTunes, mais c’est un autre sujet.

Fig. 6 : Extrait d’une conversation récupérée avec le module « storage/caching/files_sql ».

 

Fig. 7 : Capture d’écran d’une conversation ».


Finalement, le module
storage/data/keychain_dump va récupérer le trousseau d’accès (bien veiller à l’utiliser avec un terminal déverrouillé, car le trousseau n’est pas accessible lorsque le terminal est verrouillé).

L’auditeur pourra y trouver des identifiants, des jetons de session et d’autres informations sensibles.

4.3 Analyse à l’exécution

Le principal intérêt de cette partie de l’analyse est de comprendre l’impact de l’application sur le système et de contourner certaines fonctions de sécurité comme la détection de jailbreak ou d’un code PIN.

Concernant le contournement de fonctions de sécurité, trois approches sont possibles :

  • instrumenter les méthodes avec Cycript, Frida, Theos ou Snoop-It (ce dernier ne supporte pas les applications 64 bits) ;
  • patch du binaire avec Hopper ou IDA ;
  • patch du runtime avec gdb.

Needle présente un intérêt uniquement pour la première approche. La deuxième consiste à modifier le binaire à la main avec un désassembleur et la troisième a modifier directement l’application en mémoire avec un débogueur.

L’instrumentation consiste aussi à déboguer l’application, comme pour le patch d’un binaire, mais sans pour autant descendre au niveau assembleur. Un autre avantage est qu’il est possible de travailler avec un terminal non débridé. D’autres prérequis sont toutefois nécessaires : disposer du logiciel Xcode, l’environnement de développement d’Apple et donc… d’un Mac. 

Les outils Cycript et Frida, permettant d’instrumenter les applications iOS (mais pas seulement) en JavaScript (ainsi qu’en Objective-C pour Cycript) sont intégrés dans Needle sous les modules hooking/cycript/cycript_shell et hooking/frida/friday_shell.

Ils fonctionnent en s’injectant dans le processus de l’application et en fournissant une console dans laquelle il est possible d’interagir en appelant des méthodes voire en les modifiant à la volée.

Exemple d’appel à une méthode de validation d’un code PIN :

Après avoir injecté Cycript, il est possible d’effectuer un appel à la méthode validateCode de l’interface RuntimeManipulateDetailsVC pour vérifier si le code PIN est correct.

Avec quelques lignes de code, il est possible d’effectuer une attaque par force-brute pour le découvrir.

Attention, si un mécanisme de blocage au bout de plusieurs tentatives infructueuses est en place, il faudra préalablement l’identifier et le désactiver.

D’autres modules sont utiles pour surveiller le presse-papier dynamic/monitor/pasteboard ou les journaux du système dynamic/monitor/syslog, qui parfois contiennent des informations sensibles comme des identifiants, des jetons de sessions ou encore des informations de débogage.

Finalement, le module dynamic/monitor/files servira à identifier les fichiers qui sont créés sur le système, par exemple suite au renseignement d’un formulaire d’authentification.

4.4 Analyse des communications

Cette partie de l’analyse se résume en grande partie par la configuration d’un proxy, comme Burp Suite, sur le terminal préalablement libéré des contraintes du certificate pinning avec SSL Kill Switch 2 [sslkillswitch2] puis par l’examen des communications.

Il peut être utile de modifier les requêtes et/ou les réponses et d’étudier le comportement de l’application.

Par exemple, le client Skype tolère bien l’interception et la modification de messages. Ainsi il est possible de modifier un message reçu par un destinataire sans que l’émetteur soit averti de sa modification, ce qui peut aboutir à quelques quiproquos.

Seuls quelques modules Needle, la plupart traitant des certificats (pour les lister, les supprimer, les installer), aident le travail de l’analyste sur cette partie.

Conclusion

Il est impossible de couvrir l’ensemble de l’outil dans ce seul article, mais j’espère avoir éveillé votre curiosité avec ces quelques cas pratiques et pour ceux qui veulent approfondir le sujet, l’excellent Mobile Application Hacker’s Handbook [mahh] est l’ouvrage de référence à avoir sous la main, qui, même s’il n’aborde pas Needle (l’outil n’existait pas au moment de sa rédaction) couvre tous les sujets du spectre de la sécurité des applications mobiles.

Remerciements

Merci à Marco Lancini pour l’outil et le workshop à Deepsec.

Références

[needle] https://github.com/mwrlabs/needle
[installation] https://github.com/mwrlabs/needle/wiki/Installation-Guide
[burpsuite] https://portswigger.net/burp/
[iphonewiki] https://www.theiphonewiki.com/wiki/Jailbreak
[skype] https://itunes.apple.com/us/app/skype-for-business-formerly-lync-2013/id605841731
[iicontact] https://itunes.apple.com/fr/app/iicontact/id1072100138
[dvia] http://damnvulnerableiosapp.com/
[frida] https://www.frida.re/docs/ios/#without-jailbreak
[sslkillswitch2] https://github.com/nabla-c0d3/ssl-kill-switch2
[mahh] http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118958500.html

RandoriSec – Davy DOUHINE (@ddouhine)

Retrouvez cet article (et bien d’autres) dans MISC n°91, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !