SSTIC 2013 - (in)Sécurité des applications Android
Par André Moulu
… constructeurs et backdoors sans permission
Les applications constructeurs sont présentes sur les téléphones des utilisateurs et ne peuvent être supprimés par ces derniers à moins de passer root sur le smartphone. L’orateur nous fait un rappel du fonctionnement des applications Android.
Chaque application à un nom unique (packagename) et est signé par un certificat du développer.
Les applications sont composées d’activités qui représentent les écrans, les broadcast receivers qui viennent réceptionner les évènements du système (sms, connectivité réseau etc). Il y a les content providers qui permettent le stockage et la gestion des données du téléphone (accès aux contacts, etc…). Il y a les services qui peuvent se permettre de ne pas répondre au système Android et donc de rester résidents en mémoire pour pouvoir faire du polling, etc… comme pour une application mail. Les Intent servent de message inter-composants ou inter-applications. Lorsque l’application envoie un message, elle la type, ce qui vient filtrer les Intent via les Intent-filter. ce qui donne par exemple, le choix à l’utilisateur du navigateur à utiliser pour ouvrir une URL.
Par défaut les composants ne sont pas exportés à l’exception des content-providers. C’est comme ça qu’une dizaine de content-providers ont été découverts sur le galaxy S II offrant un accès aux contacts etc… Depuis google à décider de bloquer par défaut l’accès aux content-providers.
Ce jeux d’intent et d’intent-filters contrôle la communication inter-applications et définit la politique de communication du système.
Le modèle de sécurité Android repose sur la sécurité par cloisonnement des droits. 1 appli = 1 user. La même isolation est appliquée pour le filesystem. Il est cependant possible de partager un utilisateur entre plusieurs applications via un « shared user id ». L’autre principe, c’est celui du moindre privilège. donc de base une application n’a pas de permissions. Et donc l’application doit réclamer explicitement les permissions dont elle à besoin.
Les permissions servent à protéger l’appel de certaines fonctions ou la réception de certains intents.
L’orateur cherche à créer une backdoor pour le samsung galaxy SIII. Les éléments de base fournis sur le smartphone Android présent dans /system/app et /system/framework et il faut chercher parmi ces applications celles qui sont vulnérables et qui vont servir l’objectif de l’attaquant. 216 applications, c’est beaucoup, il a donc fallu automatiser tout ça. L’orateur à utilisé le framework Androguard pour coder ses outils.
En cumulant les vulnérabilités dans les applications déjà présentes on va agréger les fonctionnalités dont on a besoin pour créer une backdoor complète.
Pour la lecture/écriture de la carte SD, soit l’utilisateur vous fournit les droits, soit vous déclarez dans le manifest que votre sdk est d’une version 3, et le système vous file les droits automatiquement pour des raisons de rétro-compatibilité.
Ainsi de suite, l’orateur nous présente les appli vulnérables que l’on peut détourner via les Intents pour effectuer les actions qui nous intéressent.
Toutes les failles présentés sont aussi présentes dans d’autres modèles. Samsung est au courant mais le patch n’est pas encore disponible mais ça ne devrais pas tarder. Reste à espérer que ça sera backporté sur les OS Samsung antérieurs.
