Modèle de sécuritéAndroid OS

Menaces?

Jailbreak / rooting

Définition

Motivation

Implication de sécurité

Historique

Système d’exploitation open source

Conçu par Android et rachetée par Google

(5 novembre 2007)

Introduit en 2008

Distribution Linux

Utilise la sécurité de Linux

Les applications Android sont livrées sous forme de PacKage, doit des .apk

Les applications sont développées en Java et permette aussi l’utilisation de code natif.

Dispositifs de Sécurité d’Android

Il existe 2 catégories :

Mécanisme de sécurité au niveau de Linux (SandBoxing)

Mécanismes spécifiques à Android

Mécanismes de Linux - Sandboxing

Les mécanismes de linux isolent les applications les unes des autres ainsi que des ressources systèmes

Les fichiers système sont la propriété des utilisateurs « System» ou « Root»

Le « Sandboxing» est assuré au niveau du noyau de l’OS Le code de chaque application est exécuté par une machine virtuelle

DalviK VM séparée dans un processus portant un UID unique

Mécanismes de Linux - Sandboxing

Mécanismes de Linux

Portable Operating System Interface user (POSIX)➢ Chaque application se voit attribuer un UID différent➢ Chaque processus se voit attribuer un environnement d’exécution isolé

Linux File Access➢ Chaque application possède son propre répertoire, et elle est la seule à

pouvoir y accéder.➢ Empêche l’accès non autorisé aux données privées des applications

Mécanismes de Linux

Discretionary Access Control - DAC➢ Les Applications (Sujet) se voit attribuer un UID , GID et un ou plusieurs

groupe d’utilisateurs

➢ Les règles d’accès sont spécifiées pour chaque fichier(Objet) ➢ Lecture/écriture/Exécution pour le Owner / les utilisateurs du même

groupe / et le reste des utilisateurs➢ Ce schéma est utilisé par le Kernel de linux pour renforcer les règles

d’accès aux fichiers et ressources systèmes

Mécanismes au niveau de l’application

Signature du code des applications Les systèmes de permissions pour les applications Composant public vs. Privée

Signature du code des applications

Chaque application Android (fichiers. apk) doit être signée avec un certificat dont la clé privée est détenue par le développeur

➢ Ce certificat identifie l'auteur de l’application.

➢ Le certificat n'a pas besoin d'être signée par une autorité de

certification: il est parfaitement admissible, et typique, pour des

applications Android d’utiliser des certificats auto-signés

Signature du code des applications

Le certificat est utilisé uniquement pour établir une relation de confiance entre les applications, mais non pas pour déterminer si une application peut être installée ou non

Le système d’exploitation vérifie que la mise-à-jour d’une application porte la même signature numérique que celle de l’application déjà installée

Les mise-à-jour de l’OS sont aussi signées

La logique du contrôle d’accès

Le modèle de sécurité d’Android se résume à ce qui suit:

➢ La capacité du composant A d'accéder aux composants B et C est déterminée par le Reference

Monitor qui compare les étiquettes d'autorisation d'accès de B et C à la collection

d'étiquettes(Permissions) attribué à l'application 1.

Les permissions dans Android

Une application de base Android n'a pas de permissions qui lui sont associées.

Pour faire usage de fonctionnalités protégées de l'appareil, le développeur doit

inclure dans le AndroidManifest.xml une ou plusieurs balises

<uses-permission> déclarant les permissions requises.

(*) Les permissions ne peuvent être attribuées par sous ensemble. Ainsi, l’installation de l’application est annulée si l’une des permissions requises est refuse.

C’est le TOUT ou RIEN ! jusqu’à la version 6

Les permissions dans Android - Exemple

Par exemple, une application qui a besoin de surveiller les messages SMS entrants devraient préciser:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"package="com.android.app.myapp" >

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

</manifest>

Les permissions dans Android – Quand?

Au moment de l’installation, le Package Manager est en charge d’accorderles permissions aux applications en se basant sur :➢ L’interaction avec l’utilisateur : l’utilisateur accorde les permissions

exigées par l’application Ou/et

➢ La signature numérique de l’applicationo Une application ayant la même signature qu’une application déjà

installée (même développeur) , obtient les mêmes droits que celle-ci (sans interaction avec l’usager)

o Au moment de l’exécution, à partir de la version 6.

Les permissions dans Android

Les permissions sont aussi utilisées par les développeurs pour contrôler l’accès aux différentes composantes de l’application

Pour appliquer les permissions, le développeur les déclaredans le AndroidManifest.xml utilisant un ou plusieurstags <permission>.

Les permissions dans Android• Par exemple, une application qui veut contrôler qui peut

démarrer l'une de ses activités pourrait déclarer la permission requise pour cette opération comme suit:

<manifest xmlns:android=http://schemas.android.com/apk/res/android package="com.me.app.myapp" ><permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY "android:protectionLevel="dangerous" /><application . . .>

<activity android:name="com.me.app.myapp.FreneticActivity"android:permission="com.me.app.myapp.permission.DEADLY_ACTIVITY" >

</activity></application>

</manifest>

Composante public vs. Privée

Les applications contiennent souvent des éléments qu'uneautre application ne doit jamais avoir accès.

Par exemple, composante liée au stockage de mot de passe.Example : Activité FriendMap dans notre exemple. La

solution consiste à définir la composante privée en définissantl’attribut « Exported » de la composante dans le fichierAndroidmanifest.xml

<activity android:name=" FriendMap" android:exported ="false"></activity>

Composantes implicitement Ouvertes (accessibles)

Au temps de développement, si la décision de l'autorisation d'accès n'est

pas claire, le développeur peut permettre l'accès à la fonctionnalité et ne

pas attribuer une autorisation d'accès.

Si une composante publique ne possède pas une liste d’autorisations

requises, énumérées explicitement dans sa définition dans le

AndroidManifest.xml, Android permet à toutes les applications d'y accéder.

“INote that in Android before 4.2, the Content Provider is automatically

exported unless it has been explicitly declared as NOT exported. “

Les permissions sur la diffusion des intentions

Dans le modèle de sécurité de base , chaque application Android installée pouvait accéder à l’objet « Intent »➢ Risque de perte de confidentialité

L’API Android permet désormais au développeur de specifier une étiquette d’autorisation (Permission requise) afin de restreindre l'accès à l'objet « explicit Intents »

Les permissions sur les Fournisseurs de contenu

En suivant le modèle de base, les Fournisseurs de contenu sont soit accessibles (en lecture et écriture) , soit non.

Désormais, le développeur a la possibilité de spécifier qui a le droit en lecture et/ou en écriture sur les données de l’application➢ Exemple :si le développeur veut que son application soit la seule à pouvoir

mettre à jour les contenus, tout en gardant les droits de lecture pour les autres applications.

Android permet une telle politique de sécurité en attribuant des autorisations de lecture et d’écriture sur les Fournisseurs de contenu

Références

Asaf Shabtai, Yuval Fledel, Uri Kanonov, Yuval Elovici, Shlomi Dolev, and Chanan Glezer. « Google Android: A comprehensive security assessment ». IEEE Security and Privacy, 2010.

http://www.developer.android.com « Understanding Android Security ». Yinshu Wu. William Enck, Machigar

Ongtang, and PatrickMcDaniel. Pennsylvania State University .

Lollipop 5.0

Marshmallow 6.0

Nougat 7.0

https://source.android.com/security/enhancements/enh

ancements60.html

• Runtime Permissions. • Verified Boot.

• Hardware-Isolated Security.

• Fingerprints.

• SD Card Adoption.

• Clear Text Traffic.

• System Hardening.

• USB Access Control.

https://source.android.com/security/enhancements/enhancements80

Classifications des applications malveillantes

Arbre de classification des applications

Appplication Android

Honnêtes Malveillantes

Déclarées

Demandent des permissions

additionnelles qui ne sont pas nécessaires au

fonctionnement déclaré de

l'application.

Surnoises

Exploitent une vulnérabilité de

l'OS(pouvant être

patchées)

Exploitent une vulnérabilité

d'une application(Erreurs de

développement,etc..)

Exploitent une erreur de

conception de l'OS

Exploitent les failles de sécurité présentes dû au

fait que l'appareil a été "Rooté"

Application malveillante –Type 1

Ce type d’application malveillante est le plus répandu L’application cherche a obtenir des permissions qu’elle utilise par la suite

dans des activités suspicieuses L’application ne réussi que si l’utilisateur lui accorde les permissions qu’elle

demande durant le processus d’installation. Ces applications réussissent à se propager sur Android Market qui,

contrairement à Apple Store, ne met aucun mécanisme de contrôle du code des applications qu’il héberge. *

http://www.androidcentral.com/look-application-permissions

Exemple- TapSnake

TapSnake est une application qui dans son apparence est une simple version du fameux jeu Snake pour Android

TapSnake était disponible gratuitement sur Android market et a été téléchargé par plus de 300,000 utilisateurs

Au moment de l’installation, TapSnake demade la permission pour accéder au données de l’emplacement GPS de l’appareil ainsi que la permission d’accéder à internet

Exemple- TapSnake

Une fois l’application installée, TapSnake obtient l’emplacement GPS de l’appareil et l’envoi à un serveur externe chaque quinze minutes

Ces informations peuvent être consultées par les utilisateurs de la version payante de TapSnake

Exemple- TapSnake

Hmmm…

Aplication Malveillante – Type 2

Ce type d’application cherche à exploiter une vulnérabilité de l’OS ,souvent pour gagner un accès Root au système lui permettant de contrôler l’appareil

Exemple – DroidDream (début 2011)

Mayournet, baptisé par la suite DroidDream est le premier malware ciblant Android qui exploite une vulnérabilité de l’OS

Les vulnérabilité exploitées sont connues sous le nom de « RageAgainstTheCage » et « Exploid »

Ces vulnérabilités permettent à DroidDream de rooter l’appareil et gagner un accès Root au système

Ces vulnérabilités ont été patchées avec la version 2.3 d’Android (nov. 2010)➢ Cepandant , moins de 1% des utilisateurs Android ont mis-à-jour l’OS

Exemple - DroidDream

DroidDream est capable de :➢ Gagner un accès Root au système➢ Installer d’autre applications malveillantes sans l’intervention de

l’utilisateur➢ Capturer les informations sensibles sur l’appareil ➢ Envoie ces informations à des serveur externes➢ Effectuer des appels à des numéros à haut frais

➢Etc.. Le malware est programmé pour effectuer ces tâches entre 23h et 8h du

matin, d’où son appellation DroidDream

Application malveillante – Type 3

Ce type d’application exploite les vulnérabilités des applications déjà installées sur l’appareil

Ces vulnérabilités sont souvent dues à des erreurs de développement et l’oubli d’appliquer certaines mesures de sécurité offertes par Android

L’exemple d’application vulnérable est celui de l’application Skype pour Android, qui s’est avéré vulnérable et risque de compromettre la confidentialité de l’utilisateur

Exemple - Skype

L’application Skype contient une vulnérabilité qui peut être exploitée par une application malicieuse afin d’obtenir les informations privées de l’utilisateur

Les informations pouvant être obtenues sont :➢ Les informations du profil de l’utilisateur➢ Sa liste de contacts➢ L’historique des conversations de l’utilisateur

Un développeur malicieux pourrait créer une application malicieuse qui accède à ces informations et les envoie à des serveurs externes ainsi qu’aux utilisateurs skype qui apparaissent sur la liste de contacts de la victime.

Exemple - Skype

Skype stocke les données relatives à un utilisateur dans plusieurs bases de données SQLite3 stockées /system/app/Skype/<nom-d’utilisateur>

Par erreur, Skype a laissé ces fichiers avec des autorisations incorrectes, permettant à n'importe qui ou n'importe quelle application de les lire.

Non seulement ils sont accessibles, mais aussi non chiffrés.

#ls -l /data/data/com.skype.merlin_mecha/files/jcaseap-rw-rw-rw- app_152 app_152 331776 2011-04-13 00:08 main.db-rw-rw-rw- app_152 app_152 119528 2011-04-13 00:08 main.db-journal-rw-rw-rw- app_152 app_152 40960 2011-04-11 14:05 keyval.db-rw-rw-rw- app_152 app_152 3522 2011-04-12 23:39 config.xmldrwxrwxrwx app_152 app_152 2011-04-11 14:05 voicemail-rw-rw-rw- app_152 app_152 0 2011-04-11 14:05 config.lck

Application Malveillante-Type 4

Ce type d’application malveillante exploite les erreurs de conception de l’OS.

Contrairement aux vulnérabilités de l’OS , les erreurs de conception ne sont pas patchables , et peuvent nécessiter des changements majeurs dans le système

Un exemple de ce type d’erreurs de conception à été découvert dans la nouvelle version de Android Market

Le malware DroidDream exploite cette vulnérabilité pour installer des applications malveillantes à distance et sans aucune interaction avec l’utilisateur

Exemple – Android market

Avec l’ancienne version de Android Market, l’utilisateur devait télécharger le package *.apk sur l’appareil puis l’installer en utilisant le Package Manager, qui demande à l’utilisateur de confirmer l’installation et les permissions requises par l’application

La nouvelle version de Android market introduit une nouvelle méthode d’installation des applications, qui est supposée rendre l’installation plus simple

La nouvelle version de Android Market permet aux propriétaires des appareils Android de consulter les applications disponibles , acheter et installer les applications directement à partir du Android Market à distance en utilisant un navigateur sur un ordinateur ou l’appareil directement

Exemple – Android market

Les étapes d’installation : Se connecter sur Android Market en utilisant un compte Gmail. Un

appareil Android doit être associé à ce compte afin de pouvoir utiliser cette méthode

Choisir l’application à télécharger et cliquer sur le lien « Installer »

Les permissions requises par l’application s’affichent dans une fenêtre et demande la confirmation de l’utilisateur pour commencer l’installation

Exemple – Android market

Une fois l’utilisateur clique sur « install », les serveurs de Google envoient une requête INSTALL_ASSET

A la réception de la requête, l ’appareil téléchargel’application L’installation de l’application ne demande aucuneinteraction supplémentaire de l’utilisateur (Pas de confirmation de permissions)

Impact sur la sécurité de l’appareil(1/2)

Android est constamment connecté aux serveurs de google à travers le service GTalkService responsable de résoudre les requêtes:➢ INSTALL_ASSET : pour demander à Android de télécharger et installer une

application➢ REMOVE_ASSET: pour demander la suppression d’une application

malicieuse La connexion avec les Serveur de Google est protégée par SSL

Impact sur la sécurité de l’appareil(2/2)

Cepandant, les messages ne sont pas signés numériquement :➢ Risque de Man-in-the-middle, changement du payload du message pour

forcer Android à télécharger une application malveillante Une application malveillante peut forcer l’utilisateur à cliquer sur un lien

lorsqu’il est connecté sur son compte de Google Market ➢ Ce lien amorcera l’envoi d’une requête INSTALL_ASSERT par les serveurs

de google forçant android à télécharger une application malicieuse choisit par l’attaquant et l’installer silencieusement.

Applications malveillantes - Type 5

Ce type d’application malveillante exploite les vulnérabilités causées par le rooting de l’OS (voir Android Rooting)

Ces applications profitent de l’accès Root , normalement impossible sur un Android régulier, pour effectuer des tâches dangereuses, qui peuvent compromettre la sécurité de l’appareil ainsi que la confidentialité et la vie privée de l’utilisateur.

Compléments :Les objectifs des attaques

Les vulnérabilités comme porte d’entrée

Nouveauté et divertissement

Les applications malveillantes de ce type ne cherchent pas à causer des dommages

Conçus pour l’amusement de son développeur De moins en moins observées

Vol et vente des informations de l’utilisateur

Présente une menace à la vie privée de l’utilisateur du téléphone Cherche à obtenir des informations sensibles telles que:➢ IMEI de l’appareil➢ Historique de navigation web➢ Liste de contact➢ L’emplacement géographique de l’utilisateur

Vol et vente des informations de l’utilisateur

Ces informations sont vendues par les attaquants Exemple : L’IMEI a une grande valeur pour les marchands de téléphones sur le

marché noiro Utilisé pour réactiver les téléphones volés

Les compagnies de marketing s’intéressent davantage aux informations de géo-localisation

Abus des service payants

Effectuer des appels téléphoniques et envoyer des SMS à des numéro surtaxés.

Causer des dommages financiers à l’utilisateur L’attaquant reçoit des gains financiers pour chaque appel ou SMS

Spam via SMS

Le spam par SMS est illégal dans nombreux pays Les attaquants voient dans les appareils mobiles une opportunité pour

distribuer du spam sans être retracés

Vol d’informations d’authentification (1/2)

Utiliser des technique d’hammeçonnage , Keyloggers et autres moyens afin de voler les login/mots de passe stocké sur l’appareil

Exemple : Compte Gmail Comptes sur les réseaux sociaux (Facebook, Twitter) Numéro de carte de crédit Comptes bancaire

Vol d’informations d’authentification (2/2)

Certaines applications malveillantes visent à contourner l’authentification à double facteur, utilisé par les applications bancaires

Exemple : Intercépter les SMS contenant le numéros d’identification de transaction envoyé aux utilisateurs lors d’une transaction (nTAN)

Chantage

Voler les informations sensibles de l’utilisateur :o Historique de navigation sur interneto Contenu des SMSo Historique de messagerie instantanéeo Enregistrer les conversations téléphoniques

Menacer la victime de rendre ces informations publiques sur le WEB Demander une rançon

Adware

Consiste à décompiler les applications légitimes (souvant les jeux) et les recompiler en insérant des bibliothèque de publicité appartenant à l’attaquant

L’attaquant génère du profit à chaque fois que l’application est exécutée

Empoisonner les moteurs de recherches

Émettre des requêtes à partir des applications malveillantes vers des sites Web appartenant à l’attaquant

Cette technique améliore le rang des sites Web de l’attaquant dans les moteurs de recherche

Compléments :Quelques bonnes pratiques.

Composant Public vs Privé

Les composants peuvent être publique ou privé➢ L’API définit un attribut exported➢ Un composant est par défaut privé(exported = false)➢ Cependant il peut être accessible par son nom

Pourquoi : protéger les composants internes d’une application➢ Particulièrement utille lorsqu’une activité retourne un résultat

Implication : Les composants peuvent devenir implicitement accessibles Meilleur pratique : Toujours définir l’attribut « exported »

Composant Public vs Privé

<activity android :name = “etsmtl.MyActivity”

android:exported=”false”></activity>

Composants Implicitement Ouverts

Si le fichier Manifest ne définit aucune permission d’accès sur un composant publique , alors n’importe quel composant dans n’importe quelle application peut y accéder

Pourquoi : Certains composant doivent fournir un accès global➢ Exemple : L’activité principale d’une application

Implication: Les applications sans privilèges particuliers peuvent y accéder Meilleur pratique : L’utilisation de composantes sans droit d’accès ne doit

être autorisée que dans des cas limités, et les entrées doivent être filtrées. Aussi, diviser les composantes de l’application.

Composants Implicitement Ouverts

<activity android :name = “ca.etsmtl.MyActivity” >

<intent-filter>

<action android :name = “android.intent.action.MAIN” />

<category android :name =“android.intent.catrgory.LAUNCHER” />

</intent-filter>

</activity>

<receiver android :name = “ca.etsmtl.SmsReceiver”

android:permission= “sendSmsNotification”>

<intent-filter>

<action android :name =“"android.intent.action.DATA_SMS_RECEIVED"”/>

</intent-filter>

</receiver>

Permissions sur les Intents

L’application qui envoie un Intent peut définir une permission d’accès en vue de restreindre les Broadcasts Receivers qui peuvent accéder à l’Intent

Pourquoi : Définir quelle application peut lire les Intents envoyés Implication : Si l’Intent n’est pas accompagné d’une permission d’accès ,

n’importe quelle application peut l’intercepter et lire son contenu Meilleur pratique: Toujours définir les permissions d’accès pour les Intents

(surtout s’il s’agit d’un Intent implicite)

Permissions sur les Intents

//Android se charge de choisir l’applicaion capable d’envoyer des

SMS

Intent smsIntent = new Intent(Intent.SENS_SMS);

smsIntent.setType("vnd.android-dir/mms-sms");

smsIntent.putExtra("address", "12125551212");

smsIntent.putExtra("sms_body","Body of Message");

sendBroadcast(smsIntent,“ca.etsmtl.permission.SEND_SMS_PERM”);

Pending Intents En envoyant un Pending Intent à une autre application, vous lui accordez le droit d'effectuer

l'opération que vous avez spécifié, comme si cette application était votre propre application (avec les mêmes permissions et identité).

Pourquoi : Permettre à une application d’envoyer des informations au composant internes de l’application

Implication : l’application destinatrice peut abuser des permissions de votre application pour effectuer des tâches malveillantes➢ Peut également vous renvoyer des faux résultats et influencer l’intégrité des données de

votre app. Meilleur pratique : Utiliser les Pending Intents seulement comme des callback retardé pour les

composants privés de votre application. Faire une attention particulière lors de la création de votre Intent et spécifier le nom de votre composant privé afin que l’Intent ne soit dirigé qu’à celui-ci

Permissions sur les content providers

Les Content Providers possèdent deux mesures de sécurité additionnels➢ Séparer les droits en écriture et en lecture➢ Les permissions URI permettant la lecture restreinte de la base de

données Pourquoi: Améliorer le contrôle sur les données des applications Implication : Le droit d’accès aux données ne doit pas être TOUT ou RIEN Meilleur pratique: Toujours définir les droit en lecture et écriture

séparément et permettre les permissions URI selon le besoin

Permissions sur les content providers

<provider android :authorities = “accounts” android :name = “AccountProvider”

android :readPermissions = “caetsmtl.permission.READ_ACCOUNT”

android :WritePermissions = “caetsmtl.permission.WRITE_ACCOUNT”

>

</provider>