Les plateformes mobiles prolifèrent et sont maintenant utilisées pour accéder à toutes sortes de données, dont certaines assez sensibles (par exemple bancaires). Les Smartphones deviennent logiquement une cible pour les “hackers”.
La plateforme Android largement majoritaire, n’a pas été initialement conçue en mettant en avant la sécurité, ce que Google tente peu à peu de corriger. Les menaces sur le système Android sont nombreuses.
En particulier, les applications développées en Java puis ensuite distribuées sous forme de bytecode offrent peu de résistance au “reverse engineering” et les solutions d’obfuscation (comme Proguard) restent limitées.
Dans le même temps, la publication d’applications sur le Google Play Store n’est pas soumise à validation comme par exemple dans l’Apple Store. Les applications mal intentionnées ne sont retirées qu’après coup. Dans ce contexte, les hackers peuvent alors tranquillement étudier le comportement interne d’une application, la copier, lui injecter du code malicieux, la republier puis attendre qu’elle opère jusqu’à ce qu’elle soit retirée.
Si les mécanismes de sécurité Android sont encore incomplets, l’ouverture de la plateforme offre, en revanche, de nouvelles possibilités très intéressantes. En utilisant judicieusement ces dernières, il devient possible de diminuer drastiquement la surface d’attaque, notamment dans le contexte de la menace précitée.
La présentation décrira et illustrera la liste de mesures que nous avons mises en oeuvre pour protéger notre application d’authentification forte. Nous montrerons dans notre exposé comment obtenir une application unique pour chaque utilisateur et comment la lier fortement au hardware de manière à rendre la copie et la modification fortement improbables. Les techniques que nous présenterons sont innovantes et encore peu utilisées… mis à part par certains malwares avancés.
ASFWS 2012 - Le développement d’applications sécurisées avec Android par Johan Leuenberger
1. Développement sécurisé Android
Johan Leuenberger
Software Security Engineer
Application Security Forum - 2012
Western Switzerland
7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains
https://www.appsec-forum.ch
2. 2
Bio
Software security engineer chez ELCA
Spécialisé dans le développement Android
Réalisation d’elcardm Android
– Solution d’authentification forte sur smartphone
« Android Fanboy »
4. 4
Android facts
1 million de nouveaux appareils Android chaque jour.
1.5 milliard d’applications téléchargées chaque mois
700’000 applications disponibles
http://developer.android.com/about/index.html
https://www.lookout.com/resources/reports/state-of-mobile-security-2012
10. 10
Menaces
Reverse engineering
Abus du Google Play Store
Copie de l’application
Vol d’informations (mot de passe, etc)
11. 11
Scénario
1) Récupération d’une application existante et
décompilation
2) Ajout de fonctionnalités
3) Packaging de la nouvelle application
4) Publication de l’application sur le Google Play
Store
17. 17
Abus du Google Play Store
Les applications sont «self-signed»
Publication aisée
Validation pré-publication
– Google Bouncer (BH2012 Bypassing Google’s Bouncer)
Retrait post-publication
– Remote removal
18. 18
Vol de données
Pas de keystore
Application sandbox
– Faillible au root
Carte SD
20. 20
Protections
exposition données
Store
reverse copie de
engineering l’application
module natif clé
obfuscation
externe dynamique
21. 21
Reverse engineering
Pas de solution miracle!
– Rendons la vie difficile!
Etape 0 – Activer Proguard
proguard.config=default_proguard.cfg
10 sec
23. 23
Module natif
Android NDK (Native Development Kit)
– Code natif exécutable sous Android
– Basé sur JNI (Java Native Interface)
– Code accessible sous forme binaire uniquement
– Code binaire peut également être obfusqué
Comment ca marche?
– Code écrit en C / C++
– Compilé via les outils fournis par Google (ndk-build)
=> libMyModule.so
26. 26
Module natif externe
La librairie est chargée lors de l’exécution
Elle n’a pas besoin d’être packagée dans
l’application
Uniquement disponible aux utilisateurs légitimes
27. 27
Séparation de l’application
coquille
module externe
- Publié sur le Store - Téléchargé durant l’exécution de l’application
- Contient le minimum de logique - Compilé à la volée sur un serveur
- Contient l’UI - Unique par utilisateur et par appareil
28. 28
!(Reverse engineering + copie)
Empreinte hardware
Mot de passe utilisateur
Génération du module
Compilation
Obfuscation
Module (format binaire)
Installation du module
32. 32
Protections
exposition données
Store
reverse copie de
engineering l’application
module natif clé
obfuscation
externe dynamique
33. 33
Conclusion
Beaucoup de possibilités
– QR Code
– Push GCM
– GPS
– Etc.
Android évolue constamment
– Chaque version essaie de corriger certaines
vulnérabilités
34. 34
Conclusion
Le port d’une application sur Android n’est
généralement pas direct (par exemple à partir
d’une application iPhone) un certain
raisonnement est nécessaire
Le développement d’applications sécurisées
demande du temps et de l’effort