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

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

Aluno: Agora, em muitos aplicativos, não há como remover permissões.

Professor: sim, na nova versão do Android, isso não é, há simplesmente descrições de permissão. Mas você pode usar o Gerenciador de Permissões do Android ou o gerenciador de permissões do Android, que permite exibir uma lista de todas as permissões para cada aplicativo e excluir especificamente aquelas que você considera desnecessárias. Mas eu não sei como isso é popular entre os usuários.

Aluno: se os rótulos não corresponderem às permissões exigidas pelo aplicativo, isso leva a um erro grave ou tudo continua funcionando bem?

Professor: Eu acho que depende do que o aplicativo está tentando fazer e do que o rótulo permite. Por exemplo, se um aplicativo enviar Intent e enviá-lo exigir um determinado rótulo do tipo DIALPERM, ele primeiro recorrerá ao monitor de link, que diz: "infelizmente, o sistema não possui um aplicativo pronto para receber sua mensagem". E, em resposta a esta aplicação, está a tomar algumas medidas razoáveis.



Caso contrário, por exemplo, ao acessar a rede. Se você não tem acesso à rede e deseja abrir o soquete ou fornecer o comando para conectar-se ao endereço IP, o kernel responderá com a mensagem EPERM, "operação não permitida", ou seja, você não poderá fazer isso. E quem sabe o que o aplicativo fará neste caso? É possível que de alguma forma lance uma exceção de ponteiro nulo ou faça algo parecido.

Um argumento contra isso é que os aplicativos Android, pelo menos inicialmente, não esperavam que algumas de suas chamadas falhassem, porque foram informados de que o manifesto é tudo ou nada, ou seja, o usuário aprova instalando o aplicativo ou não. Portanto, os desenvolvedores do aplicativo escreveram o código corretamente, o que trava ou faz algo inesperado se o acesso for negado. Talvez, privando a aplicação das permissões de acesso necessárias, você provoque uma falha de operação.

Suponha que você tenha um aplicativo que precise acessar a câmera. E se você tirar o acesso certo, o modelo de imagem simplesmente aparecerá na tela do smartphone ou talvez o aplicativo falhe. Isso não é muito bom. Provavelmente, seria possível criar um sistema mais complexo que, em caso de privação de acesso à câmera, exibisse uma tela preta o tempo todo. O Android não faz isso, mas você pode imaginar situações alternativas nas quais isso poderia acontecer.

Por isso, examinamos de onde vêm essas linhas nos rótulos dos aplicativos Android. Mas quem define essas linhas, de onde elas obtêm o significado? Você pode listar todos os tipos de linhas no arquivo de manifesto, mas como você decide quais linhas são importantes, de onde vêm as linhas INTERNET ou FRIENDVIEW? Quem lhes dá significado no sistema?



Vejo que você não tem idéias. Eu acho que nenhuma dessas linhas deve ser algo mágico ou predeterminado. Quase todas essas linhas são basicamente acordos entre dois aplicativos, quando um deles está pronto para fornecer algo sob a proteção de alguma linha Label e o outro aplicativo deseja solicitar permissão para falar com o aplicativo que este componente fornece.

Portanto, esses rótulos geralmente são definidos por um aplicativo que fornece alguns serviços. Se você tiver permissão DIALPERM, ela deverá ser definida no aplicativo, que define o que significa discar um número de telefone. Aparentemente, o aplicativo para fazer chamadas no seu telefone é o que define essa linha e diz que sim, essa coisa do DIALPERM existe, e meus componentes serão protegidos por ela. Em seguida, outros aplicativos que desejam interagir com o aplicativo de chamada poderão solicitar essa permissão do DIALPERM por si mesmos.

Obviamente, existem algumas coisas embutidas, como permissão para usar a Internet, uma câmera e assim por diante. Mas você pode percebê-los como os aplicativos de origem do tempo de execução do Android, responsável por fornecer acesso a esse recurso e define a linha que protegerá esse recurso.

O que isso significa? O que mais está conectado com o rótulo no Android, além do fato de ser usado pelo aplicativo quando ele precisa solicitar permissão? Acontece que existem várias coisas associadas ao rótulo. Além da string, o rótulo possui várias propriedades interessantes. Em particular, no Android, existem 3 tipos de tags. O primeiro são permissões regulares, o segundo são permissões inseguras e o terceiro são permissões assinadas.



O aplicativo que determina essa permissão, em primeiro lugar, tem a oportunidade de selecionar o tipo e todos os outros campos do rótulo, sobre os quais falaremos em um segundo. Então, quais são esses tipos de tag? Por que os rótulos do Android precisam de tipos?

Aluno: eles servem como um aviso para o usuário?

Professor: exatamente. Então, por que não criar todas as tags de um tipo não seguro? Qual é a semântica desses tipos? Simplificando, um rótulo "perigoso" é usado para permitir um aplicativo que pode estragar alguma coisa. Ele avisa os usuários quando instalam o aplicativo quando o aplicativo solicita acesso a uma permissão não segura. Ao mesmo tempo, o usuário deve olhar para esta mensagem e dizer: "Sim, estou pronto para dar permissão insegura a esse novo aplicativo". Se os aplicativos solicitarem um rótulo do tipo usual, o usuário não receberá uma mensagem sobre a necessidade de conceder permissão para esta ação. Qual é o significado de permissões comuns se todos os aplicativos as receberem? Existe uma razão pela qual devemos usar etiquetas de tipo regulares?

Um exemplo de uma resolução típica no Android é a configuração de papéis de parede na tela. Se você tiver um aplicativo que instalará o papel de parede, eu posso, como desenvolvedor do aplicativo, indicar no meu manifesto que só quero instalar o papel de parede para você. E se você clicar em instalar, nada de interessante acontecerá, porque você não precisa conceder permissões a este aplicativo.

Aluno: mas essas permissões geralmente requerem confirmação de você, certo? Se o aplicativo quiser alterar o papel de parede da área de trabalho, o sistema perguntará se você deseja alterar o papel de parede.

Professor: não.

Aluno: não?

Professor: não, isso mudará apenas o papel de parede porque é apenas o acesso à chamada da API. Se eu tiver essa permissão, basta fazer uma chamada de API.

Aluno: talvez o desenvolvedor do aplicativo queira garantir que os usuários não façam isso por acidente?

Professor: Sim, acho que essa é uma das razões pelas quais você pode precisar dessas permissões. É o desejo de ajudar o desenvolvedor a evitar erros. Se você está preocupado com a possibilidade de seu aplicativo acidentalmente fazer algo errado ou com erros que podem ser usados, a existência de um conjunto de permissões que você pode ou não receber reduzirá a probabilidade de abuso de seu aplicativo. Portanto, se você tiver um aplicativo inofensivo que não precise instalar nenhum papel de parede, não precisará pedir permissão, pois é melhor para o usuário em cujo telefone ele está instalado. Até certo ponto, esse é um tipo de privilégio.

Outra coisa é que a existência de rótulos do tipo usual permite realizar algum tipo de auditoria, tanto do lado do desenvolvedor quanto do lado do usuário. Se o telefone alterar o papel de parede na tela a cada segundo, você poderá entrar e ver qual aplicativo tem permissão para isso. Mesmo se você não aprovou a concessão dessa permissão, ainda poderá verificar qual aplicativo está atualmente envolvido na alteração do papel de parede.

Portanto, essas permissões comuns parecem ser uma boa medida de segurança ou, em maior medida, uma boa oportunidade para auditar a atividade do aplicativo. Normalmente, esse tipo de etiqueta não é usado para coisas realmente importantes, como trabalhar com dados ou acessar serviços que custam dinheiro.

O terceiro tipo de rótulo é a permissão de assinatura. Uma propriedade interessante do Android é a capacidade de fornecer acesso apenas a aplicativos assinados com a mesma assinatura digital que o aplicativo no qual o direito de acesso é declarado. O artigo da palestra descreve um exemplo com FRIENDVIEW. Se a exibição de amigos tiver definido permissão com esse tipo de tag, os aplicativos assinados com a mesma chave de desenvolvedor poderão obter a mesma permissão. Qual é o sentido disso? Por que não apenas marcá-los como inseguros? Por que precisamos de um terceiro tipo de etiquetas?

Aluno: Torna mais fácil para um desenvolvedor gerenciar seus aplicativos?

Professor: sim. Pode ser que esse desenvolvedor tenha APIs internas que ele queira isolar dos efeitos de programas de terceiros, mas ao mesmo tempo queira agrupar seus próprios aplicativos para interação produtiva. Hipoteticamente, os criadores do Facebook poderiam escrever vários aplicativos. Eles poderiam ter um aplicativo que pré-carrega o conteúdo dos servidores do Facebook, outro aplicativo mistura esse conteúdo, um terceiro rastreia sua localização e todos esses componentes interagem entre si. Nesse caso, eles poderiam usar uma permissão assinada.

Um dos motivos pelos quais você não deseja designar esse aplicativo como inseguro é o seguinte. Se você realmente sabe quem pode obter essa permissão, não deseja que o usuário intervenha. Como o usuário sempre pode ser enganado forçando a permissão para fornecer um aplicativo mal-intencionado, é melhor que ele não interfira na provisão de privilégios internos para alguns aplicativos. Portanto, nesse sentido, é melhor usar permissões assinadas.

Os rótulos também têm uma descrição das permissões do usuário. Esta é uma descrição do que essa permissão implica. Esta descrição aparece quando você é solicitado a instalar um novo aplicativo.



Assim, o tempo de execução do Android examinará todas as linhas de etiquetas no manifesto do aplicativo que você instalará e exibirá o usuário com descrições de todas essas linhas marcadas, por exemplo: "você concederá a este aplicativo o privilégio de discar ou permitirá o envio de SMS em seu nome" e assim por diante

Uma pergunta interessante: o que acontece se um aplicativo mal-intencionado alterar o rótulo de outro aplicativo? Afinal, essas marcas são apenas cadeias de forma livre. Então, o que acontece se você é um aplicativo malicioso que diz: “Ah, eu tenho essa nova e grande resolução! É chamado DIALPERM. " Não possui rótulo inseguro e sua descrição não fornece nada. Isso é perigoso?

Aluno: provavelmente não poderá afetar a estrutura do nome de domínio do aplicativo.

Professor: sim, isso pode ser esperado, mas, infelizmente, isso não é obrigatório. Normalmente, todas as cadeias de permissão devem ter nomes de domínio no estilo Java, mas não há relacionamento estrito entre os rótulos que o aplicativo define e o próprio nome do aplicativo no estilo Java. Não há nada que force o nome do aplicativo no estilo Java a estar vinculado a algo. Portanto, não temos a oportunidade de descobrir se a chave pública do desenvolvedor que assina o aplicativo específico corresponde a algo em com.google.something ou edu. mit.something.

Há uma desvantagem no Android, ou pelo menos existia quando recentemente me aprofundei nessa questão. Assim, ao definir os rótulos, o princípio “quem veio primeiro, é atendido”. Ou seja, quando você instala o aplicativo, ele define um rótulo específico e pode decidir que tipo de rótulo é e qual é sua descrição. Para permissões do sistema, isso provavelmente não é um grande problema, porque as permissões do sistema ou aplicativos incorporados, como um discador, são definidos no início. Mas os aplicativos instalados posteriormente não podem substituir as permissões, porque isso ocorre devido à estrutura.

O problema é que, se você instalar primeiro um aplicativo mal-intencionado e, em seguida, algum aplicativo importante, ele poderá distorcer os rótulos usados ​​posteriormente pelo aplicativo bem-intencionado. O artigo da palestra descreve um caso em que um invasor obriga um usuário a instalar um aplicativo mal-intencionado que altera o tipo de rótulo do aplicativo FRIENDVIEW para um tipo normal com uma linha de descrição como "não há nada interessante". Posteriormente, quando você instala o miniaplicativo FRIENDVIEW, ele não pode mais substituir esse rótulo, porque já está definido e agora o usuário não poderá impedir que outros aplicativos usem a permissão de visualização de amigos.

Estudante: talvez o sistema possa avisar sobre tentativas de alterar a resolução?

Professor: em princípio, o framework é capaz disso, mas quando tentei fazer isso, nenhuma mensagem foi emitida. Se você instalar um aplicativo que define um rótulo que já está definido, o sistema não fará nada, ele simplesmente ignorará a nova definição de rótulo e utilizará a antiga. Talvez este seja o problema, pelo qual tudo pode dar errado. No mínimo, o sistema teria que dizer: "Eu me recuso a instalar este aplicativo porque ele possui uma definição de rótulo que já existe".

Aluno: ... e pertence a outro aplicativo.

Professor: sim, e pode até pertencer a outra chave. Então, pelo menos potencialmente, há uma chance de consertar tudo. Não acompanhei esse problema, talvez ele já tenha sido corrigido. De qualquer forma, esse é um problema interessante, quando você realmente precisa acompanhar esses nomes e descobrir quem é o proprietário desse nome e obter o direito de cometer essas ações é realmente muito importante.

Outro problema interessante do Android está relacionado ao receptor de transmissão ou ao receptor de mensagens de transmissão. Ele cria a capacidade de receber e responder a mensagens de outros aplicativos, implementando algo como enviar mensagens entre aplicativos. Primeiro eu tenho que descrever como essas mensagens interagem com o receptor. Os receptores de transmissão são usados ​​para um aplicativo, capaz de anunciar alguns eventos para qualquer outro aplicativo no sistema.



Como sabemos, as intenções geralmente são direcionadas a um componente específico, por exemplo, um visualizador de imagens JPEG. Mas sobre eventos como carregamento do sistema ou "Meus amigos por perto", você pode anunciar para todos os aplicativos que o interessam. É para isso que serve o receptor de transmissão.

Há duas coisas que lhe dizem respeito. Em primeiro lugar, a autenticação da fonte da mensagem, ou seja, você deseja saber quem enviou essa mensagem e se pode confiar nela. Em segundo lugar, você deseja controlar a quem essa mensagem é endereçada e quem pode recebê-la.

Parece-me que os desenvolvedores do Android não implementaram essas coisas corretamente. De qualquer forma, na versão inicial do Android, quando você envia uma mensagem de difusão para todos os outros componentes do sistema, esses aplicativos podem ou não suportar essa mensagem. Portanto, se você tiver o aplicativo Friends Viewer, ele oferecerá suporte a essas mensagens usando os componentes apropriados, como Ação ou Data / MIME, no filtro Intent Intent. Mas a maioria dos aplicativos sempre pode suportar todos os eventos de transmissão no sistema e você pode ver tudo o que acontece no telefone ou tudo o que é transmitido.

Assim, a estrutura do Android adicionou um argumento adicional para os aplicativos para indicar quem pode ver a mensagem de difusão.



, , – , , . , , , , .

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