Développement sécurisé AndroidJohan LeuenbergerSoftware Security Engineer                                 Application Secu...
2Bio Software security engineer chez ELCA Spécialisé dans le développement Android Réalisation d’elcardm Android  – Sol...
3AgendaAndroidMenacesProtectionsConclusion
4  Android facts 1 million de nouveaux appareils Android chaque jour. 1.5 milliard d’applications téléchargées chaque mois...
5Applications en tous genresJeuxDiversFinances
6Applications en tous genresJeuxDiversFinances
7Applications en tous genresJeuxDiversFinances
8Applications en tous genresJeuxDiversFinances
9AgendaAndroidMenacesProtectionsConclusion
10Menaces   Reverse engineering   Abus du Google Play Store   Copie de l’application   Vol d’informations (mot de pass...
11Scénario1) Récupération d’une application existante et   décompilation2) Ajout de fonctionnalités3) Packaging de la nouv...
12Reverse engineering - outils                         APK – Android Application Package File                      classe...
13 Reverse engineering - smali.class public LHelloWorld;.super Ljava/lang/Object;.method public static main([Ljava/lang/St...
14Reverse engineering - Demo Modification d’une application afin de récupérer  le compte et le mot de passe d’un utilisat...
15Reverse engineering – SMS Receiver AndroidManifest.xml <uses-permission android:name="android.permission.RECEIVE_SMS" /...
16Reverse engineering – SMS Receiver SmsReceiverpublic class SmsReceiver extends BroadcastReceiver {    @Override    publ...
17    Abus du Google Play Store Les applications sont «self-signed» Publication aisée Validation pré-publication  – Goo...
18Vol de données Pas de keystore Application sandbox  – Faillible au root Carte SD
19AgendaAndroidMenacesProtectionsConclusion
20Protections                 exposition              données                   Store     reverse                         ...
21Reverse engineering Pas de solution miracle!  – Rendons la vie difficile! Etape 0 – Activer Proguard  proguard.config=...
22Proguard (avec / sans)
23Module natif Android NDK (Native Development Kit)  – Code natif exécutable sous Android  – Basé sur JNI (Java Native In...
24Android NDK - Exemple Java                   C                        0110101
25Android NDK                                                                      C                                      ...
26Module natif externe La librairie est chargée lors de l’exécution Elle n’a pas besoin d’être packagée dans  l’applicat...
27Séparation de l’application                       coquille                             module externe - Publié sur le St...
28 !(Reverse engineering + copie)                             Empreinte hardware                         Mot de passe util...
29Clé dynamique anti-copie        Client                                      Serveur                       Secret initial...
30Clé dynamique anti-copie   Client                Serveur    Client copié    s1           s1    s2           s2          s1
31Clé dynamique anti-copie   Client                    Serveur   Client copié    s1               s1         s1           ...
32Protections                 exposition              données                   Store     reverse                         ...
33Conclusion Beaucoup de possibilités  – QR Code  – Push GCM  – GPS  – Etc. Android évolue constamment  – Chaque version...
34Conclusion Le port d’une application sur Android n’est  généralement pas direct (par exemple à partir  d’une applicatio...
35 Questions?johan.leuenberger@elca.ch
36Merci/Thank you!Contact:   johan.leuenberger@elca.ch   http://www.secutalk.ch   Slides:      http://slideshare.net/ASF-W...
Prochain SlideShare
Chargement dans…5
×

ASFWS 2012 - Le développement d’applications sécurisées avec Android par Johan Leuenberger

870 vues

Publié le

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.

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
870
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
17
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

ASFWS 2012 - Le développement d’applications sécurisées avec Android par Johan Leuenberger

  1. 1. Développement sécurisé AndroidJohan LeuenbergerSoftware Security Engineer Application Security Forum - 2012 Western Switzerland 7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains https://www.appsec-forum.ch
  2. 2. 2Bio 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 »
  3. 3. 3AgendaAndroidMenacesProtectionsConclusion
  4. 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 disponibleshttp://developer.android.com/about/index.htmlhttps://www.lookout.com/resources/reports/state-of-mobile-security-2012
  5. 5. 5Applications en tous genresJeuxDiversFinances
  6. 6. 6Applications en tous genresJeuxDiversFinances
  7. 7. 7Applications en tous genresJeuxDiversFinances
  8. 8. 8Applications en tous genresJeuxDiversFinances
  9. 9. 9AgendaAndroidMenacesProtectionsConclusion
  10. 10. 10Menaces Reverse engineering Abus du Google Play Store Copie de l’application Vol d’informations (mot de passe, etc)
  11. 11. 11Scénario1) Récupération d’une application existante et décompilation2) Ajout de fonctionnalités3) Packaging de la nouvelle application4) Publication de l’application sur le Google Play Store
  12. 12. 12Reverse engineering - outils APK – Android Application Package File  classes.dex  classes compilées  resources.arsc + res  resources  AndroidManifest.xml  fichier décrivant l’application  … Outils  adb  communication avec un appareil Android  dex2jar  Java Decompiler  ~ .java  apktool  .smali
  13. 13. 13 Reverse engineering - smali.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
  14. 14. 14Reverse engineering - Demo Modification d’une application afin de récupérer le compte et le mot de passe d’un utilisateur
  15. 15. 15Reverse engineering – SMS Receiver AndroidManifest.xml <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>
  16. 16. 16Reverse engineering – SMS Receiver SmsReceiverpublic 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); }
  17. 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. 18Vol de données Pas de keystore Application sandbox – Faillible au root Carte SD
  19. 19. 19AgendaAndroidMenacesProtectionsConclusion
  20. 20. 20Protections exposition données Store reverse copie de engineering l’application module natif clé obfuscation externe dynamique
  21. 21. 21Reverse engineering Pas de solution miracle! – Rendons la vie difficile! Etape 0 – Activer Proguard proguard.config=default_proguard.cfg 10 sec
  22. 22. 22Proguard (avec / sans)
  23. 23. 23Module 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
  24. 24. 24Android NDK - Exemple Java C 0110101
  25. 25. 25Android NDK C 0110101CjbyteArray 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;}
  26. 26. 26Module 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. 27Sé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. 28 !(Reverse engineering + copie) Empreinte hardware Mot de passe utilisateur Génération du module Compilation Obfuscation Module (format binaire)Installation du module
  29. 29. 29Clé dynamique anti-copie Client Serveur Secret initial partagé: s0 r0 = random() r0, c1 f(r0, s0) = s1f(r0, s0) = s1 encrypt(m1,s1) = c1decrypt(c1, s1) = m1r1 = random() r1, c2f(r1, s1) = s2encrypt(m2,s2) = c2 f(r1, s1) = s2 decrypt(c2, s2) = m2
  30. 30. 30Clé dynamique anti-copie Client Serveur Client copié s1 s1 s2 s2 s1
  31. 31. 31Clé dynamique anti-copie Client Serveur Client copié s1 s1 s1 s2 s2 s1 ERROR
  32. 32. 32Protections exposition données Store reverse copie de engineering l’application module natif clé obfuscation externe dynamique
  33. 33. 33Conclusion Beaucoup de possibilités – QR Code – Push GCM – GPS – Etc. Android évolue constamment – Chaque version essaie de corriger certaines vulnérabilités
  34. 34. 34Conclusion 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
  35. 35. 35 Questions?johan.leuenberger@elca.ch
  36. 36. 36Merci/Thank you!Contact: johan.leuenberger@elca.ch http://www.secutalk.ch Slides: http://slideshare.net/ASF-WS/presentations

×