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.

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 »

3. 3
Agenda
Android
Menaces
Protections
Conclusion

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

5. 5
Applications en tous genres
Jeux
Divers
Finances

6. 6
Applications en tous genres
Jeux
Divers
Finances

7. 7
Applications en tous genres
Jeux
Divers
Finances

8. 8
Applications en tous genres
Jeux
Divers
Finances

9. 9
Agenda
Android
Menaces
Protections
Conclusion

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

12. 12
Reverse 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. 14
Reverse engineering - Demo
 Modification d’une application afin de récupérer
le compte et le mot de passe d’un utilisateur

15. 15
Reverse 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
Reverse engineering – SMS Receiver
 SmsReceiver
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);
}

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

19. 19
Agenda
Android
Menaces
Protections
Conclusion

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

22. 22
Proguard (avec / sans)

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

24. 24
Android NDK - Exemple
 Java C
0110101

25. 25
Android NDK C
0110101
C
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;
}

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

29. 29
Clé dynamique anti-copie
Client Serveur
Secret initial partagé: s0
r0 = random()
r0, c1 f(r0, s0) = s1
f(r0, s0) = s1 encrypt(m1,s1) = c1
decrypt(c1, s1) = m1
r1 = random()
r1, c2
f(r1, s1) = s2
encrypt(m2,s2) = c2
f(r1, s1) = s2
decrypt(c2, s2) = m2

30. 30
Clé dynamique anti-copie
Client
Serveur Client copié
s1 s1
s2 s2 s1

31. 31
Clé dynamique anti-copie
Client
Serveur Client copié
s1 s1 s1
s2 s2
s1
ERROR

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

35. 35
Questions?
johan.leuenberger@elca.ch

36. 36
Merci/Thank you!
Contact:
johan.leuenberger@elca.ch
http://www.secutalk.ch
Slides:
http://slideshare.net/ASF-WS/presentations