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

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

Aujourd'hui, nous allons parler de la sécurité Android. Vous pouvez le considérer comme un exemple intéressant d'un système qui a été principalement conçu avec la sécurité à l'esprit. Il est possible que, contrairement à de nombreux systèmes que nous avons examinés jusqu'à présent, comme Unix ou les navigateurs Web, où la sécurité était dans la plupart des cas «vissée» après la création du système et sa conception ne se concentrait pas sur ces problèmes, les développeurs Android étaient initialement très préoccupé par les classes d'attaque spécifiques et les constructions d'application.



Ils ont trouvé une meilleure façon de structurer les applications Android qui nous permettront de mieux appliquer les politiques de sécurité. Le plus cool est que c'est un système assez largement utilisé, contrairement à certains documents de recherche qui ne peuvent offrir qu'une nouvelle architecture, ce système est en fait utilisé dans la pratique, et il y a de plus en plus d'appareils utilisant le système d'exploitation Android.

Aujourd'hui, nous allons parler de la façon dont certaines choses ont fonctionné ou échoué. Nous examinerons quelles parties de la conception ils ont jugées importantes et ce qu'ils ont manqué, et quel est le résultat dans la pratique. C'est assez intéressant. Dans un sens, les développeurs ont utilisé les systèmes existants dont nous avons parlé, afin qu'Android soit construit sur UNIX, en fait, c'est juste le noyau Linux qui fonctionne sur le téléphone dans son ensemble.

Ainsi, à bien des égards, ils utilisent certains des mécanismes familiers dont vous vous souvenez dans le laboratoire 2, où vous avez utilisé des ID utilisateur et des groupes Unix et d'autres choses pour séparer les applications les unes des autres. Mais dans le cas d'Android, ils ont une façon complètement différente de définir les ID utilisateur et les autorisations de fichier que dans un système Linux typique.

Commençons par discuter du niveau de menace ici? Qu'est-ce qui dérange ces gars au téléphone? Que se passe-t-il ici? De quoi essaient-ils de se protéger? Qu'est-ce qu'un modèle de menace dans un appareil mobile?



Etudiant: des applications qui pourraient être nuisibles?

Professeur: oui, ils craignent que les applications qui peuvent être installées sur le téléphone soient malveillantes. Je pense qu'il existe des applications franchement malveillantes conçues pour prendre le contrôle de vous ou voler vos données personnelles. Vous devez donc vous soucier de vos données et des choses qui coûtent de l'argent - SMS, appels téléphoniques, connexion Internet, etc.

Ainsi, à droite se trouvent les choses que vous souhaitez protéger sur votre téléphone et à gauche, les choses qui peuvent les faire fonctionner différemment. Puisqu'il y a des applications malveillantes, les gars d'Android ne veulent pas que les utilisateurs puissent installer des applications écrites par des développeurs dont Google n'a jamais entendu parler. De plus, de telles applications peuvent être nuisibles, non pas parce que le développeur le souhaitait, mais parce qu'il a simplement oublié de faire quelque chose. Et ce serait bien d'aider ces gars à créer des applications sûres, car souvent le développeur de l'application n'est pas un expert dans le domaine des vulnérabilités qui peuvent ensuite être utilisées par un attaquant dans son application.



Étant donné qu'Android est répandu, nous pouvons afficher les rapports de vulnérabilité. Il existe une base de données CVE qui répertorie de nombreuses vulnérabilités dans les systèmes d'exploitation, ce qui est en fait intéressant. Bien sûr, il y a des messages d'erreur Android, dont beaucoup sont apparus lors de conférences. Les débordements de tampon sont toujours possibles dans certaines parties d'Android, il y a un mauvais choix de cryptosystème par défaut, les gens oublient d'initialiser le générateur de nombres aléatoires et de créer des clés prévisibles. Tout cela se produit toujours, car le logiciel n'est à l'abri d'aucun des problèmes connus.

Ce qui est intéressant, c'est qu'il semble que ces problèmes soient isolés et surviennent de temps en temps. Dans l'ensemble, ils peuvent être éliminés et le système reste assez sûr après avoir corrigé ces erreurs. Donc, à bien des égards, la conception Android fonctionne très bien. Par conséquent, plus tard, nous examinerons plus en détail quelles parties de la conception fonctionnent mieux et lesquelles sont pires. Mais en général, il s'agit d'une solution logicielle assez bien pensée, ou du moins plus réfléchie que les applications Unix de bureau que vous avez vues jusqu'à présent.

Ainsi, l'une des façons de savoir comment protéger les données et les divers services qui peuvent vous coûter de l'argent à partir d'applications malveillantes consiste à comprendre d'abord à quoi ressemble l'application pour le système Android. Ensuite, nous parlerons de la façon dont les différentes autorisations ou privilèges sont configurés et appliqués dans cette application. Les applications Android sont très différentes de ce que vous avez vu jusqu'à présent dans les applications de bureau ou dans les applications Internet.

Au lieu de composer la partie indivisible du code avec la fonction principale que vous commencez à exécuter, les applications Android sont plus modulaires. Dans le cas de l'utilisation d'Android, vous pouvez présenter une application comme un ensemble de composants. L'article de la conférence décrit 4 types de composants que le framework Android fournit au développeur. Le premier composant est Activité ou activité. Il s'agit d'une chose qui représente l'interface utilisateur et permet à l'utilisateur d'interagir avec l'application, de lui afficher des informations et de recevoir des frappes de sa part, etc.

Du point de vue de la sécurité, l'activité a une propriété intéressante - la saisie de l'utilisateur est réduite à une action à la fois. Le cadre Android garantit en fait qu'un seul type d'activité est possible à la fois, c'est-à-dire que si vous exécutez une application bancaire, aucune application ne fonctionnera en arrière-plan pour intercepter le code PIN de l'application bancaire via des clics tactiles. Le cadre prévoit donc l'utilisation de certaines fonctions de sécurité concernant la saisie des utilisateurs. Ainsi, l'activité est un composant de l'interface utilisateur.

Trois autres types de composants aident la logique d'application à interagir avec d'autres composants. Ainsi, le deuxième composant est appelé Service, ou service. Ces choses fonctionnent en arrière-plan. Par exemple, vous pouvez avoir un service qui suit votre position, comme dans l'application que ces gars-là décrivent dans l'article. Vous pouvez avoir des services qui récupèrent des informations du réseau en arrière-plan, etc.
Le troisième composant est le composant du fournisseur de contenu, le fournisseur de contenu. Il peut être représenté comme une base de données SQL dans laquelle vous pouvez définir plusieurs tables avec un schéma, etc. Vous pouvez accéder aux requêtes SQL avec toutes les données stockées dans cette application. Ce composant vous permet de contrôler l'accès à la base de données, en indiquant qui est autorisé à y accéder.
Dans «Android», il y a autre chose d'inhabituel qui ne se trouve pas dans d'autres systèmes. Il s'agit du quatrième composant - récepteur de diffusion ou récepteur de diffusion. Il est utilisé pour recevoir des messages d'autres parties du système. Par conséquent, nous parlerons de la façon dont les applications interagissent entre elles en termes de messages.



C'est donc une idée très logique de ce que sont les applications Android. Mais en réalité, ce ne sont que des classes Java ou du code Java écrit par un développeur.

Il n'y a qu'une certaine interface standard que vous implémentez pour l'activité, pour les services, pour le récepteur de diffusion et pour le fournisseur de contenu, et il est clair que ce n'est que du code Java. Et tous les composants placés dans le rectangle ne sont qu'un runtime Java qui s'exécute sur votre téléphone, c'est juste un processus de noyau Linux unique qui s'exécute sur votre téléphone. Et tous ces composants sont des classes ou des morceaux de code différents qui s'exécutent dans le processus d'exécution Java. Voici comment cela peut être réduit à des processus traditionnels, plus compréhensibles pour vous.

Une autre chose qui interagit avec l'application est appelée le manifeste. Le code de tous les composants est écrit ou compilé par le développeur de l'application, mais en plus de cela, il existe également un manifeste dans le système qui est en dehors des composants de l'application. Il s'agit de texte ou d'un fichier XML qui décrit tous ces composants et comment les autres parties du système doivent interagir avec les composants de cette application.



En particulier, ce manifeste parle des étiquettes dites Lables, dont nous parlerons dans une seconde, qui déterminent les privilèges de cette application en termes de ce qu'elle est autorisée à faire, et déterminent également les restrictions sur qui d'autre peut interagir avec divers composants de ce applications. Voulez-vous demander comment cela fonctionne?

Étudiant: le libellé définit-il «cette application ne peut pas passer un appel téléphonique» ou «cette application peut envoyer un message»?

Professeur: oui, ces marques établissent si cette application peut passer un appel, envoyer des SMS ou utiliser Internet. Il existe deux types d'étiquettes, je vais les dessiner ici. Chaque application possède une liste d'étiquettes décrivant les privilèges dont elle dispose. Cela ressemble à des autorisations pour composer un numéro de téléphone, activer la connexion Internet, etc. Plus tard, je vous dirai comment ils fonctionnent.

Ce sont donc les privilèges dont dispose l'application. De plus, vous pouvez également attacher des étiquettes à des composants individuels, et là, ils prennent une signification différente - ce sont des privilèges pour une application particulière. Si vous avez un composant avec une étiquette, alors pour interagir avec lui, tout autre composant doit également avoir une étiquette correspondante.
Par exemple, vous pouvez avoir une balise avec le privilège Afficher les amis que vous pouvez utiliser pour afficher l'emplacement de vos amis. Il s'agit d'un privilège qu'une application peut avoir. Mais pour garantir ce privilège, vous devez attacher cette étiquette à un composant spécifique, dans ce cas, au composant Content Provider, à sa base de données, où il y a des informations sur l'emplacement de vos amis. Et maintenant, quiconque souhaite accéder à cette base de données doit avoir la même étiquette dans ses privilèges.



C'est ainsi que vous définissez les autorisations. Vous pouvez le considérer comme des ID utilisateur ou des ID de groupe sous Unix, à l'exception des chaînes arbitraires qui les rendent un peu plus flexibles. Autrement dit, vous ne manquerez jamais de ces identifiants et vous ne vous inquiétez pas si quelqu'un les manque.

Il s'avère que les développeurs d'Android n'ont pas été particulièrement attentifs à déterminer la portée de ces labels. Vous pouvez avoir deux applications qui choisissent d'étiqueter la même chose. Ainsi, ces étiquettes sont partiellement définies par l'application. Supposons que vous ayez deux applications sur votre téléphone - Facebook et Google+, et qu'ils déclarent tous deux qu'ils aimeraient une nouvelle ligne d'autorisation pour la fonction "Voir les amis" sur le réseau social. Vous dites: "pas de problème, c'est la même ligne."

Bien sûr, en réalité, cette ligne avec la liste des étiquettes est beaucoup plus longue que celle que j'ai dessinée. Il existe un domaine de style application Java qui définit le nom en minuscule de l'étiquette. Par exemple, l'autorisation d'appel DIALPERM que j'ai peinte ressemble à com.google.android.dialperm. Mais en gros, ce sont les lignes qui apparaissent dans les autorisations. Par conséquent, si vous avez des applications bien intentionnées, elles n'entreront pas en conflit avec ces lignes d'autorisation.

Mais il s'avère que, malheureusement, dans le système d'exploitation Android, rien n'oblige l'application à un tel comportement, ce qui crée des problèmes potentiels. Je ne sais pas pourquoi ils n'ont pas été réparés. Nous verrons ce qui se passe si nous avons deux applications en conflit avec les noms d'étiquette.

Voici donc à quoi ressemble l'application: c'est un ensemble de programmes Java qui forment des composants, un manifeste décrivant les autorisations pour les applications et les restrictions nécessaires pour tous les composants. L'interaction entre les applications est réalisée en utilisant ce qui a été inventé par les développeurs d'Android et s'appelle Intent - Intention. L'intention est un message structuré, et dans une seconde, nous verrons comment il est utilisé. Pour l'instant, je dirai que l'intention a trois éléments clés. Bien sûr, l'intention contient d'autres champs, mais le plus important est le nom du composant Component auquel vous souhaitez envoyer un message. Ceci est suivi de l'action Action que le composant doit effectuer et des données de données avec le type MIME que vous souhaitez envoyer à l'autre composant.



À titre d'exemple abstrait, vous pouvez imaginer que ce composant est com.android.dialer / Dial - c'est ainsi que le nom du composant est indiqué dans Android, c'est une sorte de nom de domaine Java. Ainsi, com.android.dialer est le nom de l'application dans son ensemble, à laquelle vous souhaitez envoyer l'intention, et à travers une barre oblique, vous écrivez le nom du composant de l'application cible à laquelle vous envoyez ce message - / Dial. De cette façon, vous nommez le composant spécifique auquel le message est adressé. L'action représente un ensemble spécifique d'actions qui peuvent ressembler à android.intend.Dial.

Il s'agit d'une chaîne prédéfinie que les applications mettent dans le champ d'action Action si elles souhaitent que le numéroteur téléphonique appelle un numéro spécifique. Par exemple, si vous souhaitez afficher une sorte de document sur le téléphone, dans le champ Action, vous insérez une ligne d'action comme android.intend.ViewDoc. Cela indique au composant récepteur que vous souhaitez simplement regarder le contact appelé avant de composer son numéro de téléphone.
Enfin, les données de données sont fondamentalement une URL arbitraire ou l'URL des données que vous souhaitez envoyer avec ce message. Il peut s'agir d'un numéro de téléphone ou d'une URL HTTP que vous souhaitez afficher ou ouvrir, ou de toute autre application indiquée par une URL dans le système.



C'est ainsi que vous envoyez des messages qui sont envoyés via le système en utilisant le runtime Android lui-même, qui se trouve sous toutes ces applications. Ainsi, le runtime Android peut être perçu comme un croisement entre les applications et le noyau. Ce n'est pas tout à fait correct, mais nous allons essayer de dessiner une sorte d'image afin de clarifier à quoi ressemble l'architecture de cette chose.

Disons que nous avons une application qui fonctionne sur Android et une autre application. Ces rectangles sont App1 et App 2, et chacun représente ce qui est montré dans l'image du haut - composants, manifeste, étiquettes.



Ce sont tous des processus qui s'exécutent au-dessus du noyau Linux, ce qui fournit un certain degré d'isolement entre les applications. Il y a aussi ce que l'article de conférence appelle le moniteur de référence. Il assurera la médiation de toutes les interactions intentionnelles entre différentes applications. Par conséquent, si l'appendice 1 souhaite envoyer un message à l'appendice 2, il envoie d'abord un message au moniteur de liaison.
Ainsi, la façon dont vous envoyez toutes les intentions d'intention à Android consiste à créer l'un de ces messages d'intention et à le router via un canal vers ce moniteur de référence.



Le système Android a sa propre implémentation de canaux pour envoyer de telles intentions, qui s'appelle Binder ou Bundle. Chaque application Android, par accord, va ouvrir Binder - se connectant à un moniteur de liens afin de pouvoir recevoir les intentions de cette application, ainsi que d'envoyer des messages à cette application.

Dans notre cas, si l'appendice 1 écrit l'intention de l'appendice 2 au moniteur de liaison, le moniteur de liaison découvrira d'abord où cette intention devrait aller, puis il la transmettra à l'appendice 2. Ensuite, l'appendice 2 peut déclencher une action, recevoir un message ou exécuter une demande SQL pour Application 1.



: – Reference Monitor?

: , — , . , , , RM, ? ? , 1. ?

: , - , , .

: , . , , , . , , . . , 2?

: , PKI. .

: , , . , , , , RM , App 1. PKI . . , , , . , , . , ?

: , , .

: . , «» , . , , , . , Labels. ?

: , , . , , , , « ».

: , , . , RM , . , - . .

, 2 , . – , . , , , . .

, . , . — , , . , , , . , , - .

Android , , , , . , , , «» . , Google Voice, VoIP, Skype , . : « , - ». , , — , PDF JPEG .



. , PDF , , . RM .

: « , , , , ». , , .

: ?

: . , , . , , . , , .

Android RPC. , , Bind intent, , : « ». , , .



, - , , Bind intent.

: , ?

: , 2. , , 2. , - .

, 2 bind, - , . , , .



, , , , Service, . , , .
: , , . , .

: , , , . . , bind. RPC , .

, . , , RM . , RPC , , , , , RPC .

, , RPC, RPC, RPC .

27:40

Cours MIT "Sécurité des systèmes informatiques". 20: « », 2


.

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