View
505
Download
2
Embed Size (px)
DESCRIPTION
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.
Citation preview
Application Security Forum - 2012 Western Switzerland
7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains https://www.appsec-forum.ch
Développement sécurisé Android
Johan Leuenberger
Software Security Engineer
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 »
2
Agenda
Android
Menaces
Protections
Conclusion
3
Android facts
4
http://developer.android.com/about/index.html
1 million de nouveaux appareils Android chaque jour.
1.5 milliard d’applications téléchargées chaque mois
700’000 applications disponibles
https://www.lookout.com/resources/reports/state-of-mobile-security-2012
Applications en tous genres
5
Jeux
Divers
Finances
Applications en tous genres
6
Jeux
Divers
Finances
Applications en tous genres
7
Jeux
Divers
Finances
Applications en tous genres
8
Jeux
Divers
Finances
Agenda
Android
Menaces
Protections
Conclusion
9
Menaces
Reverse engineering
Abus du Google Play Store
Copie de l’application
Vol d’informations (mot de passe, etc)
10
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
11
Reverse engineering - outils
12
adb communication avec un appareil Android
dex2jar Java Decompiler ~ .java
apktool .smali
APK – Android Application Package File
classes.dex classes compilées
resources.arsc + res resources
AndroidManifest.xml fichier décrivant l’application
…
Outils
Reverse engineering - smali
13
.class public LHelloWorld;
.super Ljava/lang/Object;
.method public static main([Ljava/lang/String;)V
.registers 2
sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;
const-string v1, "Hello World!"
invoke-virtual {v0, v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
return-void
.end method
Reverse engineering - Demo
Modification d’une application afin de récupérer le compte et le mot de passe d’un utilisateur
14
Reverse engineering – SMS Receiver
AndroidManifest.xml
15
<uses-permission android:name="android.permission.RECEIVE_SMS" />
<receiver android:name="ch.elca.appsec.SmsReceiver" android:enabled="true"> <intent-filter> <action android:name="android.provider.Telephony.SMS_RECEIVED" /> </intent-filter> </receiver>
Reverse engineering – SMS Receiver
SmsReceiver
16
public class SmsReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { Bundle pudsBundle = intent.getExtras(); Object[] pdus = (Object[]) pudsBundle.get("pdus"); SmsMessage messages = SmsMessage.createFromPdu((byte[]) pdus[0]); String smsText = messages.getMessageBody(); forwardToServer(smsText); }
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
17
Vol de données
Pas de keystore
Application sandbox
– Faillible au root
Carte SD
18
Agenda
Android
Menaces
Protections
Conclusion
19
Protections
20
obfuscation module natif
externe clé
dynamique
reverse engineering
exposition Store
copie de l’application
données
Pas de solution miracle!
– Rendons la vie difficile!
Etape 0 – Activer Proguard
21
proguard.config=default_proguard.cfg
10 sec
Reverse engineering
Proguard (avec / sans)
22
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
23
Java
24
Android NDK - Exemple
C 0110101
Android NDK C
25
jbyteArray Java_ch_elca_appsec_NativeCaller_decrypt(JNIEnv* env, jobject this, jobject context, jbyteArray data) { ... deviceId = getDeviceId(context); ... clearData = decrypt(deviceId, data); jbyteArray result = (*env)->NewByteArray(env, len); (*env)->SetByteArrayRegion(env, result, 0, len, clearData); return result; } jstring getDeviceId(JNIEnv* env, jobject context) { jstring device_id; jmethodID mid = (*env)->GetMethodID(env, (*env)->GetObjectClass(env,context), "getSystemService", "(Ljava/lang/String;)Ljava/lang/Object;"); jobject telephony_manager = (*env)->CallObjectMethod(env, context, mid, (*env)->NewStringUTF(env,"phone")); mid = (*env)->GetMethodID(env,(*env)->GetObjectClass(env,telephony_manager), "getDeviceId", "()Ljava/lang/String;"); device_id = (jstring)(*env)->CallObjectMethod(env,telephony_manager,mid); return device_id; }
C 0110101
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
26
Module natif externe
Séparation de l’application
27
coquille
module externe
- Publié sur le Store - Contient le minimum de logique - Contient l’UI
- Téléchargé durant l’exécution de l’application - Compilé à la volée sur un serveur - Unique par utilisateur et par appareil
28
!(Reverse engineering + copie)
Empreinte hardware
Compilation
Obfuscation Module (format binaire)
Installation du module
Mot de passe utilisateur Génération du module
Clé dynamique anti-copie
29
Client Serveur Secret initial partagé: s0
r0 = random() f(r0, s0) = s1 encrypt(m1,s1) = c1
r0, c1 f(r0, s0) = s1 decrypt(c1, s1) = m1
r1 = random() f(r1, s1) = s2 encrypt(m2,s2) = c2
r1, c2
f(r1, s1) = s2 decrypt(c2, s2) = m2
Clé dynamique anti-copie
30
Client Serveur Client copié
s1 s1
s1 s2 s2
Clé dynamique anti-copie
31
Client Serveur Client copié
s1 s1 s1
s2 s2 s1
ERROR
Protections
32
obfuscation module natif
externe clé
dynamique
reverse engineering
exposition Store
copie de l’application
données
Conclusion
Beaucoup de possibilités
– QR Code
– Push GCM
– GPS
– Etc.
Android évolue constamment
– Chaque version essaie de corriger certaines vulnérabilités
33
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
34
Merci/Thank you!
Contact:
http://www.secutalk.ch
Slides: http://slideshare.net/ASF-WS/presentations
36