Cours MIT "Sécurité des systèmes informatiques". Conférence 20: Sécurité des téléphones portables, partie 3

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3
Conférence 9: «Sécurité des applications Web», partie 1 / partie 2 / partie 3
Conférence 10: «Exécution symbolique» Partie 1 / Partie 2 / Partie 3
Conférence 11: «Ur / Web Programming Language» Partie 1 / Partie 2 / Partie 3
Conférence 12: Sécurité du réseau, partie 1 / partie 2 / partie 3
Conférence 13: «Protocoles réseau», partie 1 / partie 2 / partie 3
Conférence 14: «SSL et HTTPS» Partie 1 / Partie 2 / Partie 3
Conférence 15: «Logiciel médical» Partie 1 / Partie 2 / Partie 3
Conférence 16: «Side Channel Attacks» Partie 1 / Partie 2 / Partie 3
Conférence 17: «Authentification des utilisateurs», partie 1 / partie 2 / partie 3
Conférence 18: «Navigation privée sur Internet» Partie 1 / Partie 2 / Partie 3
Conférence 19: «Réseaux anonymes» Partie 1 / Partie 2 / Partie 3
Conférence 20: «Sécurité des téléphones portables» Partie 1 / Partie 2 / Partie 3

Étudiant: Désormais, dans de nombreuses applications, il n'y a aucun moyen de supprimer les autorisations.

Professeur: oui, dans la nouvelle version d'Android, ce n'est pas le cas, il y a simplement des descriptions de permission. Mais vous pouvez utiliser le gestionnaire d'autorisations Android ou le gestionnaire d'autorisations Android, qui vous permet d'afficher une liste de toutes les autorisations pour chaque application et de supprimer spécifiquement celles que vous jugez inutiles. Mais je ne sais pas comment cette chose est populaire parmi les utilisateurs.

Étudiant: si les étiquettes ne correspondent pas aux autorisations requises par l'application, cela entraîne-t-il une erreur grave ou tout fonctionne-t-il correctement?

Professeur: Je pense que cela dépend de ce que l'application essaie de faire et de ce que l'étiquette autorise. Par exemple, si une application va envoyer Intention et que l'envoi de cette intention nécessite une certaine étiquette de type DIALPERM, elle se tourne d'abord vers le moniteur de liens, qui dit: «malheureusement, le système n'a pas d'application prête à recevoir votre message.» Et en réponse à cette demande, elle prend des mesures raisonnables.



Sinon, par exemple, lors de l'accès au réseau. Si vous n'avez pas accès au réseau et que vous allez ouvrir le socket ou donner la commande pour vous connecter à l'adresse IP, le noyau vous répondra avec le message EPERM, «opération non autorisée», c'est-à-dire que vous ne pouvez pas le faire. Et qui sait ce que l'application va faire dans ce cas? Il est possible qu'il lance en quelque sorte une exception de pointeur nul ou fasse quelque chose comme ça.

Un argument contre cela est que les applications Android, au moins initialement, ne s'attendaient pas à ce que certains de leurs appels échouent, car on leur a dit que le manifeste est tout ou rien, c'est-à-dire que l'utilisateur approuve l'installation de l'application ou non. Les développeurs d'applications ont donc correctement écrit le code, ce qui se bloque ou fait quelque chose d'inattendu si l'accès est refusé. Peut-être qu'en privant l'application des autorisations d'accès dont elle a besoin, vous provoquerez ainsi un échec de son fonctionnement.

Supposons que vous ayez une application qui a besoin d'accéder à la caméra. Et si vous lui retirez son droit d'accès, le modèle d'image apparaîtra simplement sur l'écran du smartphone, ou peut-être que l'application plantera. Ce n'est pas très bon. Il serait probablement possible de créer un système plus complexe qui, en cas de privation d'accès à la caméra, afficherait simplement un écran noir tout le temps. Android ne fait pas cela, mais vous pouvez imaginer des situations alternatives dans lesquelles cela pourrait se produire.

Nous avons donc examiné la provenance de ces lignes dans les étiquettes des applications Android. Mais qui définit ces lignes, d'où tirent-elles leur sens? Vous pouvez répertorier toutes sortes de lignes dans le fichier manifeste, mais comment décidez-vous quelles lignes sont importantes, d'où viennent les lignes INTERNET ou FRIENDVIEW? Qui leur donne un sens dans le système?



Je vois que tu n'as aucune idée. Je pense qu'aucune de ces lignes ne doit être magique ou prédéterminée. Presque toutes ces lignes sont essentiellement des accords entre deux applications, lorsque l'une des applications est prête à fournir quelque chose sous la protection d'une ligne d'étiquette et que l'autre application souhaite demander l'autorisation de parler avec l'application fournie par ce composant.

Par conséquent, ces étiquettes sont généralement définies par une application qui fournit certains services. Si vous disposez de l'autorisation DIALPERM, celle-ci doit être définie dans l'application, qui définit ce que signifie composer un numéro de téléphone. Apparemment, l'application pour passer des appels sur votre téléphone est ce qui définit cette ligne et dit que oui, cette chose DIALPERM existe et que mes composants seront protégés par elle. Ensuite, d'autres applications qui souhaitent interagir avec l'application appelante pourront demander cette autorisation DIALPERM pour elles-mêmes.

Bien sûr, il existe des éléments intégrés, tels que la permission d'utiliser Internet, une caméra, etc. Mais vous pouvez les percevoir comme les applications source du runtime Android, qui est responsable de fournir l'accès à cette ressource et définit la ligne qui protégera cette ressource.

Qu'est-ce que cela signifie? Quoi d'autre est lié à l'étiquette dans Android, outre le fait qu'elle est utilisée par l'application lorsqu'elle doit demander une autorisation? Il s'avère que plusieurs éléments sont associés à l'étiquette. En plus de la chaîne, l'étiquette possède plusieurs propriétés intéressantes. En particulier, dans Android, il existe 3 types de balises. Le premier est des autorisations régulières, le second est des autorisations non sécurisées et le troisième est des autorisations signées.



L'application qui détermine tout d'abord cette autorisation a la possibilité de sélectionner le type et tous les autres champs de l'étiquette, dont nous parlerons dans un instant. Alors, quels sont ces types de balises? Pourquoi les étiquettes Android ont-elles besoin de types?

Etudiant: sert-il d'avertissement à l'utilisateur?

Professeur: exactement. Alors pourquoi ne pas créer toutes les balises d'un type dangereux? Quelle est la sémantique de ces types? En termes simples, une étiquette «dangereuse» est utilisée pour autoriser une application qui pourrait ruiner quelque chose. Il avertit les utilisateurs lors de l'installation de l'application lorsque l'application demande l'accès à une autorisation non sécurisée. En même temps, l'utilisateur devrait regarder ce message et dire: "Oui, je suis prêt à donner une autorisation non sécurisée à cette nouvelle application." Si les applications demandent une étiquette du type habituel, l'utilisateur ne reçoit pas de message sur la nécessité d'accorder l'autorisation pour cette action. Quelle est la signification des autorisations ordinaires si toutes les applications les reçoivent? Y a-t-il une raison pour laquelle nous devrions utiliser des étiquettes de type régulières?

Un exemple de résolution typique sous Android est la définition de fonds d'écran à l'écran. Si vous avez une application qui va installer le fond d'écran, je peux, en tant que développeur d'application, indiquer dans mon manifeste que je veux juste installer le fond d'écran pour vous. Et si vous cliquez sur installer, rien d'intéressant ne se produira, car vous n'avez pas besoin de donner des autorisations à cette application.

Étudiant: mais ces autorisations nécessitent généralement une confirmation de votre part, non? Si l'application souhaite changer le fond d'écran du bureau, le système vous demandera si vous souhaitez changer le fond d'écran.

Professeur: non.

Étudiant: non?

Professeur: non, cela changera simplement le fond d'écran car il s'agit simplement d'un accès à l'appel API. Si j'ai cette autorisation, je fais simplement un appel API.

Étudiant: peut-être que le développeur de l'application veut s'assurer que les utilisateurs ne le font pas par accident?

Professeur: oui, je pense que c'est l'une des raisons pour lesquelles vous pourriez avoir besoin de ces autorisations, c'est le désir d'aider le développeur à éviter les erreurs. Si vous craignez que votre application ne fasse accidentellement quelque chose de mal ou qu'il puisse y avoir des erreurs qui peuvent être utilisées, alors l'existence d'un ensemble d'autorisations que vous pouvez ou non recevoir réduira le risque d'abus de votre application. Donc, si vous avez une application inoffensive qui n'a pas besoin d'installer de papier peint, vous n'aurez pas besoin de demander d'autorisation, car c'est mieux pour l'utilisateur sur le téléphone duquel elle est installée. Dans une certaine mesure, c'est une sorte de privilège.

Une autre chose est que l'existence d'étiquettes du type habituel vous permet d'effectuer une sorte d'audit, à la fois du côté du développeur et du côté de l'utilisateur. Si votre téléphone change le fond d'écran à l'écran toutes les secondes, vous pouvez entrer et voir quelle application est autorisée à le faire. Même si vous n'avez pas approuvé l'octroi d'une telle autorisation, vous pouvez toujours vérifier quelle application est actuellement engagée dans la modification du fond d'écran.

Ainsi, ces autorisations communes semblent être une bonne mesure de sécurité ou, dans une plus large mesure, une bonne opportunité pour auditer l'activité des applications. Habituellement, ce type d'étiquette n'est pas utilisé pour des choses vraiment importantes, telles que travailler avec des données ou accéder à des services coûteux.

Le troisième type d'étiquette est l'autorisation de signature. Une propriété intéressante d'Android est la possibilité de fournir un accès uniquement aux applications signées avec la même signature numérique que l'application dans laquelle le droit d'accès est déclaré. L'article de la conférence décrit un exemple avec FRIENDVIEW. Si l'affichage d'amis a défini une autorisation avec ce type de balise, les applications signées avec la même clé de développeur pourront obtenir la même autorisation. Quel est l'intérêt de cette chose? Pourquoi ne pas simplement les marquer comme dangereux? Pourquoi avons-nous besoin d'un troisième type d'étiquettes?

Étudiant: facilite- t- il pour un développeur la gestion de ses applications?

Professeur: oui. Il se peut que ce développeur dispose d'API internes qu'il souhaite isoler des effets des programmes tiers, mais qu'il souhaite en même temps regrouper ses propres applications pour une interaction productive. Hypothétiquement, les créateurs de Facebook pourraient écrire plusieurs applications. Ils pourraient avoir une application qui précharge le contenu des serveurs Facebook, une autre application mélange ce contenu, une troisième suit votre emplacement et tous ces composants interagissent les uns avec les autres. Dans un tel cas, ils pourraient utiliser un permis signé.

L'une des raisons pour lesquelles vous ne souhaitez pas désigner cette application comme non sûre est la suivante. Si vous savez vraiment qui peut obtenir cette autorisation, vous ne voulez pas que l'utilisateur intervienne. Parce que l'utilisateur peut toujours être trompé en forçant l'autorisation de donner une application malveillante, il est donc préférable qu'il n'interfère pas du tout avec l'octroi de privilèges internes à certaines applications. Dans ce sens, il est donc préférable d'utiliser des autorisations signées.

Les étiquettes contiennent également une description des autorisations utilisateur. Ceci est une description de ce que cette autorisation implique. Cette description apparaît lorsque vous êtes invité à installer une nouvelle application.



Ainsi, le runtime Android examinera toutes les lignes d'étiquettes dans le manifeste de l'application que vous allez installer et affichera à l'utilisateur des descriptions de toutes ces lignes marquées, par exemple: "vous allez donner à cette application le privilège de numéroter, ou autoriser l'envoi de SMS en votre nom" et ainsi de suite.

Une question intéressante: que se passe-t-il si une application malveillante modifie le libellé d'une autre application? Après tout, ces marques ne sont que des chaînes de forme libre. Que se passe-t-il si vous êtes une application malveillante qui dit: «Oh, j'ai cette nouvelle grande résolution! Cela s'appelle DIALPERM. " Il n'a pas d'étiquette dangereuse et sa description ne donne rien. Est-ce dangereux?

Etudiant: il ne sera probablement pas en mesure d'affecter la structure du nom de domaine de l'application.

Professeur: oui, cela peut être espéré, mais, malheureusement, ce n'est pas obligatoire. En règle générale, toutes les chaînes d'autorisation doivent avoir des noms de domaine de style Java, mais il n'y a pas de relation stricte entre les étiquettes définies par l'application et le propre nom de l'application de style Java. Rien n'oblige le nom de l'application de style Java à être lié à quelque chose. Nous n'avons donc pas la possibilité de savoir si la clé publique du développeur qui signe l'application spécifique correspond à quelque chose sur com.google.something ou edu. avec quelque chose.

Il y a un inconvénient dans Android, ou du moins existait lorsque j'ai récemment exploré cette question. Ainsi, lors de la définition des étiquettes, le principe «qui est venu en premier, est servi». Autrement dit, lorsque vous installez l'application, elle définit une étiquette spécifique et vous pouvez décider de quel type d'étiquette il s'agit et de sa description. Pour les autorisations système, ce n'est probablement pas un gros problème, car les autorisations système ou les applications intégrées, comme un numéroteur, sont définies au tout début. Mais les applications installées ultérieurement ne peuvent pas remplacer les autorisations, car cela est dû au cadre.

Le problème est que si vous installez d'abord une application malveillante, puis une application importante, l'application malveillante peut potentiellement déformer les étiquettes utilisées ultérieurement par l'application bien intentionnée. L'article de conférence décrit un cas où un attaquant force un utilisateur à installer une application malveillante qui change le type d'étiquette pour l'application FRIENDVIEW en un type normal avec une ligne de description comme «il n'y a rien d'intéressant du tout». Plus tard, lorsque vous installez l'applet FRIENDVIEW, il ne peut plus remplacer cette étiquette, car elle est déjà définie, et maintenant l'utilisateur ne pourra pas empêcher d'autres applications d'utiliser l'autorisation de visualisation d'amis.

Étudiant: le système pourrait peut-être avertir des tentatives de modification de la résolution?

Professeur: en principe, le cadre est capable de cela, mais quand j'ai essayé de le faire, aucun message n'a été émis. Si vous installez une application qui définit une étiquette déjà définie, le système ne fait rien, il ignore simplement la nouvelle définition d'étiquette et utilise l'ancienne. C'est peut-être le problème, à cause duquel tout peut mal tourner. À tout le moins, le système devrait dire: "Je refuse d'installer cette application car elle a une définition d'étiquette qui existe déjà."

Etudiant: ... et appartient à une autre application.

Professeur: oui, et peut même appartenir à une autre clé. Ensuite, au moins potentiellement, il y a une chance de tout réparer. Je n'ai pas suivi ce problème, il a peut-être déjà été corrigé. Dans tous les cas, c'est un problème intéressant, quand vous devez vraiment garder une trace de ces noms et savoir à qui appartient ce nom, et obtenir le droit de commettre de telles actions est vraiment très important.

Un autre problème Android intéressant est lié au récepteur de diffusion ou au récepteur de messages de diffusion. Il crée la possibilité de recevoir et de répondre aux messages d'autres applications, implémentant quelque chose comme l'envoi de messages entre les applications. Je dois d'abord décrire comment ces messages interagissent avec le récepteur. Les récepteurs de diffusion sont utilisés pour une application, qui peut annoncer certains événements pour toute autre application du système.



Comme nous le savons, les intentions sont généralement adressées à un composant spécifique, par exemple, une visionneuse d'images JPEG. Mais à propos d'événements tels que le chargement du système ou «Mes amis à proximité», vous pouvez annoncer à chaque application qui le concerne. C'est à cela que sert le récepteur Broadcast.

Il y a deux choses qui vous préoccupent. Tout d'abord, l'authentification de la source du message, c'est-à-dire que vous voulez savoir qui a envoyé ce message et si vous pouvez lui faire confiance. Deuxièmement, vous voulez contrôler à qui ce message est adressé et qui peut le recevoir.

Il me semble que les développeurs Android n'ont pas implémenté ces choses correctement. Dans tous les cas, dans la version initiale d'Android, lorsque vous envoyez un message de diffusion à tous les autres composants du système, ces applications peuvent ou non prendre en charge ce message. Par conséquent, si vous avez l'application Friends Viewer, elle prendra en charge ces messages en utilisant les composants appropriés, tels que Action ou Date / MIME, dans son filtre d'intention d'intention. Mais la plupart des applications peuvent toujours prendre en charge tous les événements de diffusion du système et vous pouvez voir tout ce qui se passe sur le téléphone ou tout ce qui est diffusé.

Ainsi, le cadre Android a ajouté un argument supplémentaire pour que les applications indiquent qui peut voir le message diffusé.



, , – , , . , , , , .

, , , , , , . Android, , , , .

, ? , « » , . , ? ?

: ? ?

: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?

, . , , . , . ? , « »?

: , , ?
: . , — . , , « ».



Broadcast receiver, , , . , , , Label.

. Android , . « », . , . , , , .

RPC , RPC-, , . , .

: ?

: , , .

: , …

: , . – . . : « ».

: ?

: .

: , ?

: , , . . , , , . , — . , : « , », , , Dangerous Description.



, : „ , ». , , , , . , Android , .

, , Android. , , . , «», « ». , , .



, , . , , , , , . , Java. , , , , .

Android . - , , , , . «» , RPC . , .

, , . , Android , 5 6 . , , , - «». , , .

, Android , , Apple . , Apple iPhone , .

«», «», , , , , , , . , . , , Android, . , - .

, Android .


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?