La surface d'attaque critique des applications mobiles

LiveOverflow a publié une vidéo intéressante sur la sécurité des applications mobiles, dans laquelle il aborde la surface d'attaque des applications mobiles et le cas d'un « chercheur » en sécurité qui surestime les résultats de son travail.

Les applications mobiles sont construites sur un environnement conçu dans une logique de réduction de la surface d'attaque, grâce au sandboxing, à un modèle de permissions explicites, aux mises à jour automatiques et à une API qui cherche à être sécurisée par défaut.

Cependant, certaines applications mobiles exposent une surface d'attaque critique qui demande une attention particulière, que ce soit en raison de la pile technologique sur laquelle elles reposent, du type d'usages qu'elles proposent ou des interactions qu'elles ont avec d'autres composants. Un autre facteur clé à prendre en compte est le besoin pour ces environnements d'ajouter toujours plus de fonctionnalités. Ces fonctionnalités laissent aux développeurs la liberté d'inventer de nouvelles façons d'utiliser nos téléphones, mais augmentent en même temps la surface d'attaque. Prenons par exemple les App Extensions d'iOS, une fonctionnalité similaire aux intents Android, qui a été ajoutée plus tard à l'écosystème iOS.

Voici quelques exemples de vulnérabilités que nous avons déjà vues comme critiques pour la sécurité, mais qui sont très spécifiques à l'environnement mobile :

Injection JavaScript exploitable à distance dans les applications basées sur JavaScript :

Les applications développées avec un framework JavaScript, comme Cordova ou Ionic, peuvent être vulnérables à l'injection de JavaScript ou de HTML. Ces vulnérabilités peuvent être transformées en injection de code à distance en raison de la nature de l'API exposée par ces frameworks.

Pour qu'une telle vulnérabilité soit considérée comme critique, l'attaquant doit pouvoir envoyer l'entrée malveillante à d'autres utilisateurs sans aucune interaction particulière.

Par exemple, prenons une application de sport qui permet aux utilisateurs de partager leur progression sur un mur personnel. Si ce mur est vulnérable à l'injection de JavaScript (XSS), tout utilisateur qui consulte le mur de l'attaquant sera compromis.

Même des vulnérabilités d'injection HTML peuvent être transformées en injection JavaScript via une attaque de type JavaScript Gadget.

Corruption de mémoire dans du code natif via une entrée non fiable :

Plusieurs applications gèrent l'analyse de formats binaires comme l'audio, la vidéo et les images avec des bibliothèques natives. Une vulnérabilité de corruption de mémoire dans ces bibliothèques, déclenchée par une entrée non fiable, entraînera une exécution de code à distance.

Par exemple, si une application de messagerie qui permet d'envoyer des enregistrements vocaux au format MP4 souffre d'une vulnérabilité de corruption de mémoire, cela entraînera une exécution de code à distance dans le contexte de l'application.

Java, Kotlin, Objective C et Swift sont tous des langages sûrs en mémoire tant que des API non sécurisées ne sont pas utilisées ; en revanche, lier l'application à des bibliothèques en C et C++ ouvre la porte à ce type de vulnérabilités.

Injection d'intent dans des Activities browsable, exploitée par des attaques drive-by dans Chrome :

Chrome permet d'envoyer des intents avec des paramètres supplémentaires vers des activities de la catégorie Browsable. Une application vulnérable à l'injection via les paramètres supplémentaires d'un intent est vulnérable à une exploitation de type drive-by.

L'attaquant peut soit attirer la victime sur sa page malveillante, soit diffuser l'attaque par le biais de publicités, par exemple. Le navigateur Firefox exige une interaction supplémentaire de l'utilisateur pour déclencher l'envoi d'un intent, tandis que la plupart des autres navigateurs mobiles ne prennent pas en charge cette fonctionnalité.

Communication en clair ou avec une validation non sécurisée du certificat serveur TLS/SSL :

L'impact de cette vulnérabilité dépend de la nature des données échangées. Par exemple, si la phase d'authentification ou toute action liée à la session est effectuée sur des canaux non sécurisés, la session de l'utilisateur sera compromise.

Si l'application est développée avec des frameworks JavaScript, la récupération de JavaScript ou de HTML à distance entraînera une exécution de code à distance. Si l'application télécharge une bibliothèque partagée (.so, .dex, .jar) sur des canaux non sécurisés, cela entraînera également une exécution de code à distance.

Un exemple de cette vulnérabilité est l'utilisation de ALLOW_ALL_HOSTNAME_VERIFIER :

L'implémentation de ALLOW_ALL_HOSTNAME_VERIFIER n'effectue aucune validation :

Gestion de session partagée entre l'application mobile et l'application web, et absence de protections liées au web sur le backend mobile :

Les applications web partagent le même navigateur avec d'autres applications web, ce qui crée des possibilités pour un ensemble d'attaques qui ne s'appliquent pas aux applications mobiles, comme le CRSF, le détournement de session par toutes sortes de XSS et même le clickjacking.

En général, ces vecteurs d'attaque sont absents des applications mobiles ; les développeurs n'ont donc pas besoin d'implémenter de protection de sécurité contre ces attaques.

Certains backends d'applications mobiles partagent cependant le système de gestion de session entre le web et le backend mobile, ce qui permet à un attaquant de se connecter au backend mobile depuis le navigateur et d'exploiter ces vulnérabilités.