Curso MIT "Segurança de sistemas de computadores". Palestra 20: Segurança de Telefonia Móvel, Parte 1

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Palestra 7: “Sandbox do Cliente Nativo” Parte 1 / Parte 2 / Parte 3
Aula 8: “Modelo de Segurança de Rede” Parte 1 / Parte 2 / Parte 3
Aula 9: “Segurança de aplicativos da Web” Parte 1 / Parte 2 / Parte 3
Palestra 10: “Execução Simbólica” Parte 1 / Parte 2 / Parte 3
Aula 11: “Linguagem de Programação Ur / Web” Parte 1 / Parte 2 / Parte 3
Aula 12: Segurança de rede Parte 1 / Parte 2 / Parte 3
Aula 13: “Protocolos de Rede” Parte 1 / Parte 2 / Parte 3
Palestra 14: “SSL e HTTPS” Parte 1 / Parte 2 / Parte 3
Palestra 15: “Software Médico” Parte 1 / Parte 2 / Parte 3
Palestra 16: “Ataques de Canal Lateral” Parte 1 / Parte 2 / Parte 3
Palestra 17: “Autenticação de Usuário” Parte 1 / Parte 2 / Parte 3
Palestra 18: “Navegação Privada na Internet” Parte 1 / Parte 2 / Parte 3
Palestra 19: “Redes Anônimas” Parte 1 / Parte 2 / Parte 3
Palestra 20: “Segurança do telefone móvel” Parte 1 / Parte 2 / Parte 3

Hoje falaremos sobre segurança do Android. Você pode pensar nisso como um exemplo interessante de um sistema que foi projetado principalmente com a segurança em mente. É possível que, ao contrário de muitos dos sistemas que examinamos até agora, como Unix ou navegadores da Web, onde a segurança tenha sido "danificada" na maioria dos casos após a criação do sistema e seu design não tenha focado nessas questões, os desenvolvedores do Android inicialmente eram muito preocupado com classes de ataque específicas e construções de aplicativos.



Eles criaram uma maneira melhor de estruturar aplicativos Android que nos permitirá aplicar melhor as políticas de segurança. O mais interessante é que este é um sistema bastante utilizado, ao contrário de alguns trabalhos de pesquisa que oferecem apenas uma nova arquitetura, esse sistema é realmente usado na prática e há cada vez mais dispositivos usando o sistema operacional Android.

Hoje falaremos sobre como algumas coisas deram certo ou falharam. Consideraremos quais partes do projeto elas consideraram importantes e o que perderam e qual é o resultado na prática. Isso é bem interessante. Em certo sentido, os desenvolvedores usaram os sistemas existentes sobre os quais falamos, para que o Android seja construído no UNIX, na verdade, é apenas o kernel do Linux que roda no telefone como um todo.

Portanto, de várias maneiras, eles usam alguns dos mecanismos familiares que você lembra do Lab 2, onde você usava IDs de usuário e grupos Unix e outras coisas para separar aplicativos um do outro. Mas no caso do Android, eles têm uma maneira completamente diferente de definir IDs de usuário e permissões de arquivo do que em um sistema Linux típico.

Vamos começar discutindo qual é o nível de ameaça aqui? O que incomoda esses caras no telefone? O que está acontecendo aqui? Do que eles estão tentando se proteger? O que é um modelo de ameaça em um dispositivo móvel?



Aluno: aplicações que podem ser prejudiciais?

Professor: sim, eles estão preocupados que os aplicativos que podem ser instalados no telefone possam ser maliciosos. Eu acho que existem aplicativos francamente maliciosos projetados para ganhar controle sobre você ou roubar seus dados pessoais. Portanto, você deve se preocupar com seus dados e com coisas que custam dinheiro - mensagens SMS, telefonemas, conexão à Internet e assim por diante.

Assim, à direita estão as coisas que você deseja proteger no telefone e, à esquerda, as coisas que podem fazê-las funcionar de maneira diferente. Como existem aplicativos maliciosos, os caras do Android não querem que os usuários possam instalar aplicativos criados por desenvolvedores dos quais o Google nunca ouviu falar. Além disso, esses aplicativos podem ser prejudiciais, não porque o desenvolvedor o desejasse, mas porque simplesmente se esqueceu de fazer algo. E seria bom ajudar esses caras a criar aplicativos seguros, pois muitas vezes o desenvolvedor de aplicativos não é especialista no campo de vulnerabilidades que podem ser usadas por um invasor em seu aplicativo.



Como o Android é generalizado, podemos visualizar relatórios de vulnerabilidade. Há um banco de dados do CVE que cataloga muitas vulnerabilidades nos sistemas operacionais, e isso é realmente interessante. Obviamente, existem mensagens de erro do Android, muitas das quais você se deparou em palestras. O excesso de buffer ainda é possível em algumas partes do Android, existe uma má escolha do sistema de criptografia padrão, as pessoas esquecem de inicializar o gerador de números aleatórios e criar chaves previsíveis. Tudo isso ainda está acontecendo, porque o software não está seguro de nenhum dos problemas conhecidos.

O interessante é que parece que esses problemas são isolados e surgem de tempos em tempos. Em geral, eles podem ser eliminados e o sistema permanece bastante seguro após a correção desses erros. Portanto, de várias maneiras, o design do Android funciona muito bem. Portanto, mais tarde examinaremos mais detalhadamente quais partes do design funcionam melhor e quais são piores. Mas, em geral, essa é uma solução de software bastante bem pensada, ou pelo menos mais pensada do que os aplicativos Unix de desktop que você já viu até agora.

Portanto, uma das maneiras de descobrir como proteger dados e vários serviços que podem custar dinheiro a partir de aplicativos maliciosos é primeiro entender como é o aplicativo para o sistema Android. Depois, falaremos sobre como várias permissões ou privilégios são configurados e aplicados neste aplicativo. Os aplicativos Android são muito diferentes do que você viu até agora em aplicativos de desktop ou aplicativos da Internet.

Em vez de compor a parte indivisível do código com a função principal que você começa a executar, os aplicativos Android são mais modulares. No caso de usar o Android, você pode apresentar um aplicativo como um conjunto de componentes. O artigo da palestra descreve 4 tipos de componentes que a estrutura do Android fornece ao desenvolvedor. O primeiro componente é Atividade, ou atividade. Isso é algo que representa a interface do usuário e permite que o usuário interaja com o aplicativo, exibe informações para ele e recebe pressionamentos de teclas dele, e assim por diante.

Do ponto de vista da segurança, a atividade tem uma propriedade interessante - a entrada do usuário é reduzida a uma ação por vez. A estrutura do Android realmente garante que apenas um tipo de atividade é possível por vez, ou seja, se você executar um aplicativo bancário, nenhum aplicativo funcionará em segundo plano para interceptar o código PIN do aplicativo bancário por meio de cliques de toque. Portanto, a estrutura fornece o uso de alguns recursos de segurança em relação à entrada do usuário. Assim, a atividade é um componente da interface do usuário.

Três outros tipos de componentes ajudam a lógica do aplicativo a interagir com outros componentes. Portanto, o segundo componente é chamado Serviço, ou serviço. Essas coisas funcionam em segundo plano. Por exemplo, você pode ter um serviço que rastreia sua localização, como no aplicativo que esses caras descrevem no artigo. Você pode ter serviços que recuperam informações da rede em segundo plano e assim por diante.
O terceiro componente é o componente do provedor de conteúdo, provedor de conteúdo. Ele pode ser representado como um banco de dados SQL no qual você pode definir várias tabelas com um esquema e assim por diante. Você pode acessar consultas SQL com todos os dados armazenados neste aplicativo. Este componente permite controlar o acesso ao banco de dados, dizendo quem tem permissão para acessá-lo.
No "Android", há algo incomum que não existe em outros sistemas. Este é o quarto componente - receptor de transmissão ou receptor de transmissão. É usado para receber mensagens de outras partes do sistema. Portanto, falaremos sobre como os aplicativos interagem entre si em termos de mensagens.



Portanto, essa é uma ideia muito lógica do que são os aplicativos Android. Mas, na realidade, tudo isso são apenas classes Java ou código Java escrito por um desenvolvedor.

Há apenas uma certa interface padrão que você implementa para atividade, serviços, para o receptor de transmissão e para o provedor de conteúdo, e é claro que isso é apenas código Java. E todos os componentes colocados no retângulo são apenas um tempo de execução Java que é executado no seu telefone, é apenas um único processo do kernel Linux que é executado no seu telefone. E todos esses componentes são diferentes classes ou partes de código que são executadas no processo de tempo de execução Java. Veja como isso pode ser reduzido aos processos tradicionais e mais compreensíveis para você.

Outra coisa que interage com o aplicativo é chamada manifesto. O código para todos os componentes é gravado ou compilado pelo desenvolvedor do aplicativo, mas além disso, também há um manifesto no sistema que está fora dos componentes do aplicativo. É um texto ou um arquivo XML que descreve todos esses componentes e como outras partes do sistema devem interagir com os componentes deste aplicativo.



Em particular, este manifesto fala dos chamados rótulos Lables, sobre os quais falaremos em um segundo, que determinam os privilégios desse aplicativo em termos do que é permitido fazer e também determinam as restrições sobre quem mais pode interagir com vários componentes deste. aplicações. Você quer perguntar como isso funciona?

Aluno: o rótulo é algo que define "este aplicativo não pode fazer uma ligação telefônica" ou "este aplicativo pode enviar uma mensagem"?

Professor: sim, essas marcas estabelecem se esse aplicativo pode fazer uma chamada, enviar SMS ou usar a Internet. Existem dois tipos de etiquetas, vou desenhá-las aqui. Cada aplicativo possui uma lista de rótulos que descrevem os privilégios que o aplicativo possui. É como permissões para discar um número de telefone, ativar a conexão com a Internet e assim por diante. Mais tarde vou lhe dizer como eles funcionam.

Portanto, esses são os privilégios que o aplicativo possui. Além disso, você também pode anexar etiquetas a componentes individuais, e elas assumem um significado diferente - esses são privilégios para um aplicativo específico. Se você tiver um componente com um rótulo, para interagir com ele, qualquer outro componente também deverá ter um rótulo correspondente.
Por exemplo, você pode ter uma tag com o privilégio Visualizar amigos que pode ser usado para exibir a localização de seus amigos. Este é um privilégio que um aplicativo pode ter. Mas, para garantir esse privilégio, você deve anexar esse rótulo a um componente específico, nesse caso, ao componente Provedor de Conteúdo, ao banco de dados, onde há informações sobre a localização de seus amigos. E agora quem quiser acessar esse banco de dados precisa ter o mesmo rótulo em seus privilégios.



É assim que você define as permissões. Você pode pensar nisso como IDs de usuário ou de grupo no Unix, com exceção de seqüências arbitrárias que os tornam um pouco mais flexíveis. Ou seja, você nunca ficará sem esses IDs e não se preocupará com a falta de alguém.

Acontece que os desenvolvedores do Android não foram particularmente cuidadosos ao determinar o escopo desses rótulos. Você pode ter dois aplicativos que optam por rotular o mesmo. Assim, esses rótulos são parcialmente definidos pelo aplicativo. Suponha que você tenha dois aplicativos em seu telefone - Facebook e Google+, e ambos declaram que gostariam de uma nova linha de permissão para a função “Ver amigos” na rede social. Você diz: "não há problema, esta é a mesma linha".

É claro que, na realidade, essa linha da lista de marcadores é muito mais longa do que eu desenhei. Há um domínio no estilo de aplicativo Java que define o nome em minúscula do rótulo. Por exemplo, a permissão de chamada DIALPERM que pintei se parece com com.google.android.dialperm. Mas, grosso modo, essas são as linhas que aparecem nas permissões. Portanto, se você tiver aplicativos bem-intencionados, eles não entrarão em conflito com essas linhas de permissão.

Mas acontece que, infelizmente, no sistema operacional Android, nada força o aplicativo a esse comportamento, e isso cria problemas em potencial. Eu não sei por que eles não foram corrigidos. Vamos ver o que acontece se tivermos dois aplicativos em conflito com os nomes dos rótulos.

Portanto, eis a aparência do aplicativo: é um conjunto de programas Java que formam componentes, um manifesto que descreve permissões para aplicativos e restrições necessárias para todos os componentes. A interação entre os aplicativos é realizada usando o que foi inventado pelos desenvolvedores do Android e é chamado de Intenção - Intenção. A intenção é uma mensagem estruturada e, em um segundo, veremos como é usada. Por enquanto, direi que a intenção tem três coisas principais. Obviamente, a intenção contém outros campos, mas o mais importante é o nome do componente Component ao qual você deseja enviar uma mensagem. Isso é seguido pela ação Ação que o componente precisa executar e os dados dos Dados, juntamente com o tipo MIME que você deseja enviar para o outro componente.



Como um exemplo abstrato, você pode imaginar que esse componente é com.android.dialer / Dial - é assim que o nome do componente é indicado no Android; esse é um tipo de nome de domínio Java. Portanto, com.android.dialer é o nome do aplicativo como um todo, para o qual você deseja enviar a intenção e, através de uma barra, você escreve o nome do componente do aplicativo de destino para o qual você envia esta mensagem - / Dial. Dessa forma, você nomeia o componente específico ao qual a mensagem é endereçada. Ação representa um conjunto específico de ações que podem se parecer com android.intend.Dial.

Essa é uma sequência predefinida que os aplicativos colocam no campo de ação Ação se desejam que o discador telefônico ligue para um número específico. Por exemplo, se você deseja visualizar algum tipo de documento no telefone, no campo Ação, insere uma linha de ação como android.intend.ViewDoc. Isso informa ao componente receptor que você deseja apenas examinar o contato chamado antes de discar seu número de telefone.
Finalmente, os dados dos dados são basicamente uma URL arbitrária ou a URL dos dados que você deseja enviar com esta mensagem. Pode ser algo como um número de telefone ou um URL HTTP que você deseja exibir ou abrir ou qualquer outro aplicativo indicado por um URL no sistema.



É assim que você envia mensagens enviadas pelo sistema usando o próprio tempo de execução do Android, localizado em todos esses aplicativos. Assim, o tempo de execução do Android pode ser percebido como um cruzamento entre aplicativos e o kernel. Isso não está totalmente correto, mas tentaremos desenhar algum tipo de imagem para esclarecer como é a arquitetura dessa coisa.

Digamos que temos um aplicativo que roda no Android e outro. Esses retângulos são App1 e App 2, e cada um representa o que é mostrado na figura superior - componentes, manifesto, rótulos.



Todos esses são processos em execução no kernel do Linux, o que fornece algum grau de isolamento entre os aplicativos. Há também o que o artigo da palestra chama de Monitor de Referência. Ele mediará todas as interações intencionais entre diferentes aplicativos. Portanto, se o Apêndice 1 quiser enviar uma mensagem para o Apêndice 2, ele primeiro enviará uma mensagem para o monitor de link.
Portanto, a maneira como você envia todas as intenções do Intend para o Android é criar uma dessas mensagens de intenção e encaminhá-la através de algum canal para este Monitor de referência.



O sistema Android possui sua própria implementação de canais para o envio de tais intenções, chamada Binder, ou Bundle. Cada aplicativo Android, por contrato, abrirá o Binder - conectando-se a um monitor de link para que ele possa receber intenções desse aplicativo, além de enviar mensagens para esse aplicativo.

No nosso caso, se o Apêndice 1 gravar o Intent para o Apêndice 2 no monitor de link, primeiro o monitor de link descobrirá para onde essa intenção deve ir e depois a transmitirá ao Apêndice 2. Em seguida, o Apêndice 2 pode desencadear alguma ação, receber uma mensagem ou executar uma solicitação SQL para aplicação 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

Curso MIT "Segurança de sistemas de computadores". 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 ?