Curso MIT "Segurança de sistemas de computadores". Aula 21: Rastreamento de Dados, 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
Palestra 21: “Rastreando Dados” Parte 1 / Parte 2 / Parte 3

James Mickens: Ótimo, vamos começar. Obrigado por vir à palestra neste dia especial antes do Dia de Ação de Graças. Estou feliz, rapazes, por serem tão dedicados à segurança dos computadores e tenho certeza de que estarão em demanda no mercado de trabalho. Sinta-se livre para me referir como uma fonte de recomendações. Hoje, falaremos sobre o rastreamento de infecções por rastreamento de Taint, em particular, sobre um sistema chamado TaintDroid, que fornece esse tipo de análise de fluxos de informações no contexto de smartphones Android.



A principal questão levantada na palestra é o fato de que os aplicativos podem recuperar dados. A idéia é que seu telefone contenha muitas informações confidenciais - uma lista de contatos, seu número de telefone, endereço de e-mail e tudo mais. Se o sistema operacional e o telefone não forem cuidadosos, o aplicativo mal-intencionado poderá extrair algumas dessas informações e enviá-las de volta para o servidor doméstico, e o servidor poderá usá-las para todos os tipos de coisas infelizes, sobre as quais falaremos mais adiante.

Em um sentido global, um artigo sobre o TaintDroid oferece uma solução: monitorar dados confidenciais à medida que eles passam pelo sistema e essencialmente pará-los antes de serem transmitidos pela rede. Em outras palavras, devemos impedir a possibilidade de transmitir dados como argumento para as chamadas do sistema de rede. Aparentemente, se podemos fazer isso, podemos essencialmente parar o vazamento no momento em que ele começa a acontecer.

Você pode se perguntar por que as permissões tradicionais do Android não são suficientes para impedir que esse tipo de dados seja extraído. O motivo é que essas permissões não possuem a gramática correta para descrever o tipo de ataque que estamos tentando impedir. As permissões do Android geralmente lidam com as permissões do aplicativo para escrever ou ler algo de um dispositivo específico. Mas agora estamos falando sobre o que está em um nível semântico diferente. Mesmo que o aplicativo tenha o direito de ler informações ou gravar dados em um dispositivo como uma rede, pode ser perigoso permitir que o aplicativo leia ou grave certos dados confidenciais em um dispositivo com o qual ele tem permissão para interagir.

Em outras palavras, usando as políticas de segurança tradicionais do Android, é difícil falar sobre tipos de dados específicos. É muito mais fácil falar se o aplicativo está acessando o dispositivo ou não. Talvez possamos resolver esse problema usando uma solução alternativa, eu o designarei com um asterisco.



Essa solução alternativa é nunca instalar aplicativos que possam ler dados confidenciais e / ou acessar a rede. À primeira vista, o problema parece estar resolvido. Como se um aplicativo não puder fazer as duas coisas ao mesmo tempo, ele não poderá acessar dados confidenciais ou poderá lê-los, mas não poderá enviá-los pela rede. O que você acha que é o problema?

Todo mundo já está pensando no peru festivo, eu vejo nos seus olhos. Bem, a principal razão pela qual essa é uma má idéia é que essa medida pode interromper o trabalho de muitos aplicativos legítimos. Afinal, existem muitos programas, por exemplo, clientes de email, que de fato devem poder ler alguns dados confidenciais e enviá-los pela rede.

Se dissermos que vamos impedir esse tipo de atividade, proibiremos o trabalho de muitos aplicativos no telefone, dos quais os usuários provavelmente não gostarão.
Há outro problema aqui - mesmo se implementássemos esta solução, ela não impediria o vazamento de dados através de vários mecanismos diferentes de canais de terceiros. Por exemplo, em palestras anteriores, consideramos que o cache do navegador, por exemplo, pode contribuir para o vazamento de informações sobre um usuário que visita um site específico. Portanto, mesmo com a implementação dessa política de segurança, não poderemos controlar todos os canais de terceiros. Um pouco mais tarde, falaremos sobre canais de terceiros.

A solução proposta não interromperá o conluio de aplicativos quando dois aplicativos puderem trabalhar juntos para quebrar o sistema de segurança. Por exemplo, e se um aplicativo não tiver acesso à rede, mas puder se comunicar com o segundo aplicativo que o possui? Afinal, é possível que o primeiro aplicativo possa usar os mecanismos do IPC Android para transferir dados confidenciais para um aplicativo que tenha permissões de rede e esse segundo aplicativo possa carregar essas informações no servidor. Mas mesmo que os aplicativos não estejam em conluio, pode haver algum truque quando um aplicativo pode forçar outros aplicativos a fornecer dados confidenciais acidentalmente.



É possível que exista algum tipo de falha no programa de email, devido ao qual ele recebe muitas mensagens aleatórias de outros componentes do sistema. Em seguida, poderíamos criar uma intenção especial para a Intent enganar o programa de e-mail e forçar o aplicativo Gmail a enviar algo importante por e-mail para fora do telefone. Portanto, essa solução alternativa não funciona bem o suficiente.

Portanto, estamos muito preocupados com o fato de os dados confidenciais estarem saindo do telefone. Considere o que, na prática, aplicativos maliciosos para Android fazem. Existem ataques no mundo real que podem ser evitados com o rastreamento de infecções por contaminação? A resposta é sim. Programas maliciosos estão se tornando um problema crescente para telefones celulares. A primeira coisa que aplicativos maliciosos podem fazer é usar sua localização ou IMEI para anunciar ou impor serviços.

Software malicioso pode determinar sua localização física. Por exemplo, você não está longe do campus do MIT, por isso é um estudante faminto, por que não visitar minha lanchonete com rodas, localizada muito perto?

IMEI é um número inteiro que representa o identificador exclusivo do seu telefone. Ele pode ser usado para o seu rastreamento em locais diferentes, especialmente naqueles em que você não deseja "acender". Assim, na natureza, existem programas maliciosos que podem fazer essas coisas.

A segunda coisa que o malware faz é roubar seus dados pessoais. Eles podem tentar roubar seu número de telefone ou lista de contatos e tentar fazer o upload desses itens para um servidor remoto. Isso pode ser necessário para personificá-lo, por exemplo, em uma mensagem que posteriormente será usada para enviar spam.

Talvez a pior coisa que o malware possa fazer, pelo menos para mim, seja transformar seu telefone em um bot.



É claro que esse é um problema que nossos pais não tiveram que enfrentar. Os telefones modernos são tão poderosos que podem ser usados ​​para enviar spam. Existem muitos programas maliciosos direcionados a determinados ambientes corporativos que fazem exatamente isso. Uma vez no telefone, eles começam a usá-lo como parte de uma rede de spam.

Estudante: é um malware que visa especificamente invadir o sistema operacional Android ou é apenas um aplicativo típico? Se esse é um aplicativo típico, talvez possamos protegê-lo com permissões?

Professor: Essa é uma pergunta muito boa. Existem dois tipos de malware. Como se viu, é muito fácil fazer com que os usuários cliquem em botões diferentes. Vou dar um exemplo que diz respeito tanto a malwares quanto ao comportamento descuidado das pessoas.
Existe um jogo popular Angry Birds, você vai à App Store e o procura na barra de pesquisa de aplicativos. O primeiro nos resultados da pesquisa, você receberá o jogo Angry Birds original, e a segunda linha pode conter o aplicativo Angry Birdss, com dois s no final. E muitas pessoas preferem baixar esse segundo aplicativo, porque pode custar menos do que a versão original. Além disso, durante a instalação, este aplicativo escreverá que, após a instalação, você poderá fazer isso e aquilo e aquilo, e você dirá: "é claro, não há problema!" Porque você recebeu o Angry Birds desejado por meros centavos. Após esse "boom" - e você está no gancho de um hacker!

Mas você está absolutamente certo ao assumir que, se o modelo de segurança do Android estiver correto, a instalação do malware dependerá inteiramente da estupidez ou ingenuidade dos usuários que fornecem acesso à rede, por exemplo, quando o jogo "Tic Tac Toe" não deve ter acesso a rede.

Assim, você pode transformar seu telefone em um bot. Isso é terrível por vários motivos, não apenas porque o telefone envia spam, mas também porque, talvez, você pague pelos dados de todas as cartas enviadas pelo telefone. Além disso, a bateria acaba rapidamente, porque seu telefone está constantemente ocupado enviando spam.

Existem aplicativos que usarão suas informações pessoais para causar danos. O que é especialmente ruim nesse bot é que ele pode realmente visualizar sua lista de contatos e enviar spam em seu nome para pessoas que o conhecem. Além disso, a probabilidade de que eles cliquem em algo malicioso nesta carta aumenta muitas vezes.



Portanto, impedir a extração de informações é uma coisa boa, mas não impede a possibilidade de hackers. Existem mecanismos que devemos prestar atenção em primeiro lugar, porque eles impedem que um invasor capture seu smartphone, instruindo os usuários sobre o que eles podem clicar e não devem clicar de forma alguma.

Portanto, o rastreamento de manchas sozinho não é uma solução suficiente para evitar uma situação que ameaça apreender seu telefone.

Vamos ver como o TaintDroid funciona. Como eu mencionei, o TaintDroid rastreará todas as suas informações confidenciais conforme elas se espalham pelo sistema. Portanto, o TaintDroid distingue entre o que é chamado de "fontes de informação" Fontes de informação e "coletores de informações" Coletores de informações. Fontes de informação geram dados confidenciais. Geralmente estes são sensores - GPS, acelerômetro e similares. Pode ser sua lista de contatos, IMEI, tudo o que pode conectar você, um usuário específico, ao seu telefone real. Estes são dispositivos que geram informações infectadas, chamadas fontes de dados infectados - fonte Taint.

Nesse caso, os coletores de informações são locais onde os dados infectados não devem vazar. No caso do TaintDroid, o principal absorvedor é a rede. Mais tarde, falaremos sobre o fato de que você pode imaginar mais lugares onde a informação vaza, mas a rede ocupa um lugar especial no TaintDroid. Pode haver outros coletores de informações em um sistema de uso mais geral do que um telefone, mas o TaintDroid foi projetado para evitar vazamentos na rede.

O TaintDroid usa um vetor de 32 bits para representar uma infecção por Taint. Isso significa que você não pode ter mais de 32 fontes separadas de infecção.



Portanto, cada informação confidencial terá uma unidade localizada em uma determinada posição se tiver sido infectada por qualquer fonte específica de infecção. Por exemplo, foi obtido a partir de dados de GPS, de algo da sua lista de contatos e assim por diante.

Curiosamente, 32 fontes de infecção na verdade não são tantas. A questão é se esse número é grande o suficiente para esse sistema específico e se é grande o suficiente para sistemas gerais que sofrem vazamentos de informações. No caso especial do TaintDroid, 32 fontes de infecção são uma quantidade razoável, porque esse problema diz respeito a um fluxo limitado de informações.

Considerando todos os sensores presentes no telefone, bancos de dados confidenciais e similares, 32 parece ser a quantidade certa em termos de armazenamento desses sinalizadores infectados. Como veremos na implementação deste sistema, 32 é realmente um número muito conveniente, porque corresponde a 32 bits, um número inteiro com o qual você pode efetivamente construir esses sinalizadores.

No entanto, como discutiremos mais adiante, se você deseja dar aos programadores a capacidade de controlar o vazamento de informações, ou seja, especificar suas próprias fontes de infecção e seus próprios tipos de vazamentos, 32 bits podem não ser suficientes. Nesse caso, considere adicionar um suporte de tempo de execução mais sofisticado para indicar mais espaço.

Grosso modo, quando você olha como uma infecção flui através de um sistema, em um sentido geral, ocorre da direita para a esquerda. Vou dar um exemplo simples. Se você tem algum tipo de operador, por exemplo, declara uma variável inteira igual ao valor de latitude da sua localização: Int lat = gps.getLat (), então essencialmente a coisa localizada à direita do sinal de igual gera um valor que tem algum tipo de limite com a infecção dela.



Portanto, um sinalizador específico será definido, que diz: “ei, esse valor que retorno vem de uma fonte confidencial”! Então a infecção virá daqui, no lado direito, e vai aqui, à esquerda, para infectar essa parte do lat. É assim que parece nos olhos de um desenvolvedor que escreve o código fonte. No entanto, a máquina virtual Dalvik usa esse formato de registro em minúsculas para criar programas, e é assim que a semântica da contaminação é implementada na realidade.

Na tabela de um dos artigos da palestra, há uma grande lista de comandos com uma descrição de como a infecção afeta esses tipos de comandos. Por exemplo, você pode imaginar que possui uma operação de movimentação que aponta para o destino dst e os srs de origem. Em uma máquina virtual Dalvik, em um mecanismo de computação abstrato, isso pode ser considerado registrador. Como eu disse, a infecção vai do lado direito para o esquerdo, portanto, neste caso, quando o intérprete Dalvik executa instruções do lado direito, ele considera o rótulo de contaminação do parâmetro sourse e o atribui ao parâmetro dst.

Suponha que tenhamos outra instrução na forma de uma operação binária de operação binária que faça algo como adição. Temos um destino dst e duas fontes: srs0 e srs1. Nesse caso, quando o intérprete Dalvik processa essa instrução, ela é contaminada pelas duas fontes, as combina e depois atribui essa união ao dst de destino.



É bem simples. A tabela mostra os vários tipos de instruções que você verá, mas, para uma primeira aproximação, essas são as formas mais comuns de disseminar a infecção no sistema. Vejamos alguns casos particularmente interessantes mencionados no artigo. Um desses casos especiais são matrizes.

Suponha que você tenha um comando char c que atribua um valor a C. Ao mesmo tempo, o programa declara algum array upper [] que conterá as letras maiúsculas "A", "B", "C": char upper [] = ["A "," B "," C "]

Uma coisa muito comum no código é a indexação em uma matriz como essa, usando C diretamente, porque, como todos sabemos, Kernigan e Ritchie aprendem que a maioria dos caracteres é um número inteiro. Portanto, você pode imaginar que existe algum código char upperC que diz que as versões em maiúsculas desses caracteres "A", "B", "C" correspondem aos índices específicos nesta tabela: char upperC = upper [C]



Isso levanta a questão de qual infecção deve atingir C neste caso. Parece que, nos casos anteriores, tudo era simples conosco, mas, neste caso, temos muitas coisas acontecendo. Temos uma matriz ["A", "B", "C"], que pode ter um tipo de infecção e temos esse símbolo C, que também pode ter seu próprio tipo de infecção. Dalvik , binary-op. upperC [C] .

, upperC - upper [ ]. - [C]. , , upperC , .

: , taint move op binary op?

: move op. , srs… -, . , , , , , taint. , , .
, srs , , . srs : « , 2 , srs». .

– , taint. , srs0 srs1, taint, :

\

dst :

\

, , 32- , , . , . taints, , .
, , , binary-op. upperC [C] [«», «», «»]. TaintDroid , taint . , . , 32- , «» , .

, taint. — , , ? , taint , , . , , , , . - , .

, . , , - , , . , , – , , . .

, – , , Native methods, - . Native- . , Dalvik , system.arraycopy(), - , C C++. Native method, .

- JNI. JNI, Java Native Interface — C C++ Java. , Java , Java. x86, ARM , .

- taint , Dalvik. Java-, C C++ . , Native-, TaintDroid , Java.

\

, « », , taint. , – . - , . , Dalvik , system.arraycopy(), , taint. arraycopy() : « , , , , ».

? , , . , , Dalvik , , , .

- JNI , . , , , C C++, .

, , . , - , , , . .

26:25

Curso MIT "Segurança de sistemas de computadores". 21: « », 2


.

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

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

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?