Penser comme un acteur menaçant : une série

Motivation derrière cette série

Se lancer dans la sécurité des applications peut s'avérer intimidant. On trouve une multitude de blogs sur la cybersécurité et des dizaines d'outils d'attaque gratuits et open source. Cependant, les informations permettant d'identifier les éléments clés qui constituent une réelle menace pour les développeurs d'applications restent rares. La plupart des ressources existantes se limitent à des recherches ou à des démonstrations de faisabilité.

Cette série d'articles explorera les menaces les plus importantes, expliquera comment reproduire les attaques d'applications, présentera les bases utilisées par un testeur d'intrusion lors de l'évaluation de votre application et formulera des recommandations pour s'en protéger. Apprendre les meilleures méthodes pour contrer les acteurs malveillants commence par comprendre leur comportement et leurs objectifs. Cette série se concentrera sur la sécurité des applications iOS. Tous les systèmes d'exploitation présentent des menaces et des vecteurs d'attaque similaires. Cependant, iOS possède des caractéristiques uniques, notamment un environnement d'exécution isolé (sandbox) restrictif et un code source du matériel et du système d'exploitation plus verrouillé que sur de nombreux autres systèmes. Ce premier article passera en revue les principaux éléments qui rendent la sécurité des applications iOS unique et abordera les formats de fichiers IPA, la signature d'applications et le chargement latéral d'applications, autant d'éléments fondamentaux pour comprendre les attaques décrites dans les articles suivants.

Motifs de l'acteur menaçant

Les acteurs malveillants peuvent avoir de multiples motivations pour attaquer une application. Ils pourraient simplement vouloir en parler sur leur blog et diffuser des informations ;). Ils pourraient aussi le faire pour prouver leur capacité à le faire. En général, leur objectif est d'en tirer un profit financier ou de nuire financièrement à leurs cibles. Dans un premier temps, un acteur malveillant pourrait chercher à rétroconcevoir et à comprendre les algorithmes sensibles, les protocoles de communication, les API ou la logique métier afin de les réimplémenter dans ses applications. Cependant, ce processus peut rapidement dégénérer et mener au contournement des mécanismes de gestion des droits numériques (DRM) ou de licences, permettant potentiellement la distribution gratuite de l'application. Les fondements de ingénierie inverseLa modification du code et l'analyse de l'application pour ces attaques sont identiques. Comprendre les attaqueset les acteurs de la menace, ce qui permet une meilleure défense contre eux.

Différence entre ordinateur et mobile Application Security

Chaque plateforme et système d'exploitation expose des failles de sécurité différentes. Les systèmes d'exploitation de bureau comme Windows, Linux et macOS offrent le niveau de sécurité le plus faible. Il est donc facile de développer des outils d'attaque ou de modifier des applications pour exploiter cette sécurité réduite. Les applications exécutées sur des systèmes d'exploitation mobiles comme iOS et Android disposent généralement d'un environnement d'exécution plus restrictif que les applications de bureau classiques. Cependant, même si un système d'exploitation intègre des fonctionnalités de sécurité, cela ne garantit pas que les applications qui y sont exécutées seront toujours sécurisées. safeIl existe toujours des attaques contre des applications qui fonctionnent sur tous les systèmes d'exploitation.

Examinons de plus près ce qui rend iOS différent pour les acteurs malveillants :

1. iOS ne fournit aucun accès root ou administrateur. Les systèmes d'exploitation de bureau permettent aux utilisateurs d'étendre leurs autorisations.
2. De nombreux outils d'attaque doivent être exécutés sur le même appareil que le logiciel ciblé. La conception et l'exécution d'outils d'attaque sur des cibles mobiles peuvent s'avérer plus complexes.
3. Les outils d'attaque contre iOS s'exécutent souvent sur un ordinateur de bureau associé plutôt que sur l'appareil iOS lui-même, ce qui les rend plus difficiles à utiliser et à développer.
4. Apple s'efforce de rendre difficile l'obtention d'autorisations élevées. Apple corrige les failles de sécurité permettant le jailbreak et a progressivement affaibli et restreint les jailbreaks. Voir notre blog Pour un historique plus détaillé. Le système d'exploitation Android de la plupart des appareils n'accorde pas les droits root par défaut, mais il est relativement facile pour un acteur malveillant d'obtenir des privilèges élevés.
5. Les fonctionnalités de débogage sont plus limitées sur iOS. Le développement s'effectue principalement dans Xcode ou à l'aide des outils de compilation Xcode. La plupart des outils de débogage sont liés à Xcode et leurs capacités sont restreintes pour une application déjà compilée.
6. Les appareils iOS ne disposent pas par défaut de SSH ni d'une connexion terminale directe.
7. Les utilisateurs finaux mettent rapidement à jour leurs appareils iOS, dont les systèmes d'exploitation, le matériel et les applications évoluent constamment, y compris les correctifs de sécurité. Cela rend les outils d'attaque et les logiciels malveillants inefficaces, obligeant les cybercriminels à investir davantage dans la maintenance.
8. Les appareils iOS sont plus chers, nécessitent un compte développeur Apple et leurs capacités de simulation ou d'émulateur sont limitées afin de réduire les coûts.

Emballage binaire iOS

Les fichiers IPA iOS sont compressés au format ZIP et contiennent tous les éléments nécessaires à l'exécution de l'application. Il suffit de décompresser un fichier IPA pour accéder aux fichiers binaires de l'application. C'est la première étape du rétro-ingénierie de l'application par analyse statique. L'exemple ci-dessous porte sur l'application Job Dispatcher, qui sera analysée dans les prochains articles de cette série. L'application est disponible à l'adresse suivante : https://github.com/digitalai-opensource/job-dispatcher.

% décompression de l'archive Job\ Dispatcher.ipa : Job Dispatcher.ipa création : Payload/ création : Payload/Job Dispatcher.app/ création : Payload/Job Dispatcher.app/_CodeSignature/ décompression : Payload/Job Dispatcher.app/_CodeSignature/CodeResources décompression : Payload/Job Dispatcher.app/AppIcon60x60@2x.png décompression : Payload/Job Dispatcher.app/Assets.car décompression : Payload/Job Dispatcher.app/AppIcon76x76@2x~ipad.png décompression : Payload/Job Dispatcher.app/Job Dispatcher décompression : Payload/Job Dispatcher.app/embedded.mobileprovision décompression : Payload/Job Dispatcher.app/Info.plist décompression : Payload/Job Dispatcher.app/PkgInfo

Il s'agit d'une petite application ; les applications plus importantes contiennent de nombreux fichiers binaires, ainsi que de nombreuses ressources, frameworks et autres composants. Cette application ne contient qu'un seul fichier binaire exécutable, nommé comme le fichier IPA principal « Job Dispatcher ». On peut vérifier qu'il s'agit bien d'un fichier exécutable à l'aide de la commande « file ».

% fichier Job\ Dispatcher Job Dispatcher : exécutable Mach-O 64 bits arm64

Mach-O est le format de fichier binaire utilisé par les systèmes d'exploitation Apple, et tous les appareils iOS récents utilisent des processeurs ARM64.

Nous avons désormais accès au fichier que nous souhaitons analyser et modifier dans les prochains articles de cette série. Une fois l'analyse de l'application terminée, nous pourrons compresser son contenu et renommer l'archive en .ipa afin de créer le fichier IPA. Si des fichiers sont modifiés, nous devrons resigner correctement l'application ou l'installer manuellement.

Signature d'applications iOS modifiées

La signature des applications iOS s'effectue généralement via l'interface graphique d'Xcode lors de la compilation, ou à l'aide de l'outil en ligne de commande `cosign`. Ces outils présentent des limitations lorsqu'il s'agit de resigner une application après modification des binaires compilés et signés, ce qui constitue le cas d'utilisation typique d'un acteur malveillant. Pour resigner une application modifiée, un outil comme iOS App Signer peut parcourir récursivement tous les fichiers d'un fichier IPA et les resigner. Cette méthode nécessite un compte développeur Apple, et Xcode générera une erreur lors de l'installation d'une application resignée avec un certificat différent sur un appareil jail. Attention : attaquer des applications iOS implique souvent le téléchargement et l'exécution de code potentiellement dangereux. Soyez vigilant !

Installation latérale d'applications iOS modifiées

Une autre méthode pour resigner et installer des applications modifiées consiste à utiliser un outil de chargement latéral. Le chargement latéral contourne les restrictions de sécurité liées à la resignature des applications et permet de s'affranchir des limitations de compatibilité entre les appareils et les versions d'iOS. Sideloadly est un outil performant pour le chargement latéral d'applications iOS. Soyez prudent lorsque vous téléchargez et installez des applications précompilées dont vous ne pouvez pas consulter le code source.

À emporter

Comprendre les acteurs malveillants et leurs vecteurs d'attaque vous aidera à concevoir des applications plus sécurisées. Au cours des prochains mois, consultez régulièrement cette page pour découvrir une série d'articles détaillant différents vecteurs d'attaque. Dans de nombreux cas, les attaques s'appuient les unes sur les autres. Par exemple, les acteurs malveillants doivent… Débridez leur appareil Avant de pouvoir installer et exploiter pleinement les fonctionnalités de Frida, les acteurs malveillants doivent également resigner ou charger manuellement des applications pour tester les modifications. Le premier article sur les attaques (à paraître prochainement !) expliquera comment modifier une application d'exemple pour contourner une fonction d'authentification.

 

Cliquez à nouveau ici pour une évaluation gratuite des menaces pesant sur votre application.