ASFWS 2012 - Le développement d’applications sécurisées avec Android par Johan Leuenberger
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 837 views

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 ...

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.

Statistics

Views

Total Views
837
Views on SlideShare
837
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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. 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. 3AgendaAndroidMenacesProtectionsConclusion
  • 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. 5Applications en tous genresJeuxDiversFinances
  • 6. 6Applications en tous genresJeuxDiversFinances
  • 7. 7Applications en tous genresJeuxDiversFinances
  • 8. 8Applications en tous genresJeuxDiversFinances
  • 9. 9AgendaAndroidMenacesProtectionsConclusion
  • 10. 10Menaces Reverse engineering Abus du Google Play Store Copie de l’application Vol d’informations (mot de passe, etc)
  • 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. 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 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. 14Reverse engineering - Demo Modification d’une application afin de récupérer le compte et le mot de passe d’un utilisateur
  • 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. 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 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. 18Vol de données Pas de keystore Application sandbox – Faillible au root Carte SD
  • 19. 19AgendaAndroidMenacesProtectionsConclusion
  • 20. 20Protections exposition données Store reverse copie de engineering l’application module natif clé obfuscation externe dynamique
  • 21. 21Reverse engineering Pas de solution miracle! – Rendons la vie difficile! Etape 0 – Activer Proguard proguard.config=default_proguard.cfg 10 sec
  • 22. 22Proguard (avec / sans)
  • 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. 24Android NDK - Exemple Java C 0110101
  • 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. 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. 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 !(Reverse engineering + copie) Empreinte hardware Mot de passe utilisateur Génération du module Compilation Obfuscation Module (format binaire)Installation du module
  • 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. 30Clé dynamique anti-copie Client Serveur Client copié s1 s1 s2 s2 s1
  • 31. 31Clé dynamique anti-copie Client Serveur Client copié s1 s1 s1 s2 s2 s1 ERROR
  • 32. 32Protections exposition données Store reverse copie de engineering l’application module natif clé obfuscation externe dynamique
  • 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. 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 Questions?johan.leuenberger@elca.ch
  • 36. 36Merci/Thank you!Contact: johan.leuenberger@elca.ch http://www.secutalk.ch Slides: http://slideshare.net/ASF-WS/presentations