android os - etsmtl.ca · 2018-04-10 · les permissions dans android une application de base...
TRANSCRIPT
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
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
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
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.
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
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