>> [Seminário] [Defender Atrás do dispositivo: Segurança de Aplicações Mobile]
[Chris Wysopal] [Universidade de Harvard]
[Isto é CS50.] [CS50.TV]
>> Boa tarde. Meu nome é Chris Wysopal.
Eu sou o CTO e co-fundador da Veracode.
Veracode é uma empresa de segurança do aplicativo.
Testamos todos os tipos de aplicações diferentes,
eo que eu vou falar hoje é a segurança de aplicativos móveis.
Minha experiência é que eu venho fazendo pesquisa de segurança
por um tempo muito longo, provavelmente quase tão longo quanto qualquer um.
I começou em meados dos anos 90,
e foi um tempo que foi muito interessante porque
tivemos uma mudança de paradigma em meados dos anos 90.
Todas computador repente de todos estava ligado à internet,
e, em seguida, tivemos o início de aplicações web,
e é isso que eu me concentrei em muito, então.
É interessante.
Agora temos uma outra mudança de paradigma acontecendo com a computação,
que é a mudança para aplicações móveis.
>> Eu sinto que é uma espécie de tempo similar, em seguida, foi no final dos anos 90
quando estávamos investigando aplicações web e encontrar defeitos como
erros de gestão sessão e injeção de SQL
que realmente não existia antes, e de repente eles estavam por toda parte
em aplicações web, e agora uma grande parte do tempo eu passo
está olhando para aplicações móveis e olhando para o que está acontecendo lá fora na selva.
As aplicações móveis são realmente vai ser a plataforma de computação dominante,
então nós realmente precisa gastar um monte de tempo, se você está no setor de segurança
com foco em aplicações web.
Havia 29 bilhões de aplicativos móveis baixados em 2011.
Está previsto em 76 mil milhões de aplicações em 2014.
Há 686 milhões de dispositivos que vão ser comprados este ano,
de modo que este é o lugar onde as pessoas vão estar fazendo
a maioria dos seus computação cliente daqui para frente.
>> Eu estava conversando com um vice-presidente da Fidelity Investments
um par de meses atrás, e ele disse que só vi mais tráfego
fazendo transações financeiras a partir de sua base de clientes
sobre a sua aplicação móvel do que em seu site,
assim um uso comum para a Web no passado foi
verificando suas cotações de ações, o gerenciamento de sua carteira,
e nós estamos realmente vendo que em 2012 mais de interruptor
para ser mais dominante na plataforma móvel.
Certamente, se não vai ser qualquer atividade criminal,
qualquer atividade maliciosa, que vai começar a ser focado na plataforma móvel
ao longo do tempo como as pessoas passar a isso.
Se você olhar para a plataforma móvel,
olhar para os riscos da plataforma é útil dividi-la em diferentes camadas,
assim como você faria em um computador desktop,
e você pensa sobre as diferentes camadas, software, sistema operacional,
camada de rede, camada de hardware, e, claro, há vulnerabilidades em todas as camadas.
>> A mesma coisa acontece no celular.
Mas móvel, parece que algumas dessas camadas estão em situação pior.
Por um lado, a camada de rede é mais problemático no celular
porque um monte de pessoas têm em seu escritório ou em casa
conexões com fio ou eles têm conexões Wi-Fi seguras,
e com um monte de dispositivos móveis que você está, obviamente, fora de casa
ou fora do escritório muito, e se você estiver usando Wi-Fi lá
você pode estar usando uma conexão Wi-Fi insegura,
algo que é uma conexão Wi-Fi público,
por isso, quando pensamos sobre aplicativos móveis que temos de ter em conta
que o ambiente de rede é mais arriscado para as aplicações
quando o Wi-Fi está sendo utilizado.
E quando eu entrar em mais dos riscos de aplicativos móveis
você vai ver por que isso é mais importante.
Há riscos a nível de hardware em dispositivos móveis.
Esta é uma área de investigação em curso.
As pessoas chamam esses ataques de banda larga ou de banda base de ataques
onde você está atacando o firmware que está escutando no rádio.
>> Estes são realmente assustadores ataques porque
o usuário não precisa fazer nada.
Você pode bater vários dispositivos dentro da faixa de RF
de uma vez, e parece que sempre que esta pesquisa borbulha
ele rapidamente se classificam onde
pessoas rusga em volta e dizer: "Aqui, conte-nos sobre isso, e por favor, pare de falar sobre isso."
Há alguma investigação em curso na área de banda larga,
mas parece ser muito silêncio silêncio.
Eu acho que é mais de um tipo de Estado-nação de pesquisa que está acontecendo.
Uma área de pesquisa ativa, porém, é a camada de sistema operacional,
e, novamente, isso é diferente do que no mundo da computação de desktop
porque no espaço móvel você tem essas equipes de pessoas chamadas jailbreakers,
e jailbreakers são diferentes do que os pesquisadores de vulnerabilidades comuns.
Eles estão tentando encontrar vulnerabilidades no sistema operacional,
mas a razão pela qual eles estão tentando encontrar as vulnerabilidades não é
invadir máquina de outra pessoa e comprometê-lo.
É de quebrar em seu próprio computador.
>> Eles querem invadir seu próprio celular, modificar o sistema operacional do seu próprio celular
para que eles possam executar os aplicativos de sua escolha
e mudar as coisas com permissões administrativos totais,
e eles não querem dizer o vendedor sobre isso.
Eles não são como um pesquisador de segurança, que é um pesquisador de segurança chapéu branco
que vai fazer a divulgação responsável e dizer ao vendedor sobre isso.
Eles querem fazer essa pesquisa, e eles querem realmente publicá-lo
em um ataque ou um rootkit ou um código de jailbreak,
e querem fazê-lo estrategicamente, como logo após
os navios de fornecedores do novo sistema operacional.
Você tem essa relação conflituosa
com vulnerabilidades de nível de sistema operacional no celular,
que eu acho que é bastante interessante, e um lugar que vê-lo
é isso que o torna tão bom que não há código publicado explorar lá fora
de vulnerabilidades no nível do kernel,
e vimos aqueles realmente ser usado por escritores de malware.
É um pouco diferente do que o mundo do PC.
E, em seguida, a camada final é a camada superior, a camada de aplicação.
Isso é o que eu vou falar hoje.
>> Existir As outras camadas, e as outras camadas de jogar nele,
mas eu estou indo principalmente para falar sobre o que está acontecendo na camada de aplicação
onde o código está sendo executado na caixa de areia.
Ele não tem privilégios administrativos.
Tem que usar as APIs do dispositivo,
mas ainda assim, uma grande quantidade de atividades maliciosas e um monte de risco pode acontecer a essa camada
porque essa é a camada onde toda a informação é.
Aplicativos podem acessar todas as informações sobre o dispositivo
se eles têm as permissões adequadas,
e eles podem acessar os diferentes sensores no dispositivo,
Sensor GPS, microfone, câmera, o que você tem.
Mesmo que nós só estamos falando na camada de aplicação
temos um monte de risco lá.
A outra coisa que é diferente sobre o ambiente móvel
é todos os jogadores do sistema operacional, seja BlackBerry ou Android
ou iOS ou Windows Mobile, todos eles têm um modelo de permissão de grão fino,
e esta é uma das maneiras que eles incorporados ao sistema operacional
a idéia de que não é tão arriscado quanto você pensa.
Mesmo que você tenha todos os seus contatos sobre lá, toda a sua informação pessoal,
você tem as suas fotos, você tem a sua localização no lá,
você está armazenando a sua senha do banco para auto login lá, é seguro porque
aplicativos tem que ter certas permissões para chegar a certas partes
de a informação sobre o dispositivo, e o utilizador tem de ser apresentado com
essas permissões e dizer bem.
>> O problema com isso é que o usuário sempre diz tudo bem.
Como uma pessoa de segurança, eu sei que você pode solicitar que o usuário,
dizer algo muito ruim vai acontecer, que você quer que aconteça?
E se eles estão em uma corrida ou há algo realmente atraente do outro lado de que,
como um jogo vai ser instalado que você estava esperando,
eles estão indo para clicar bem.
É por isso que eu digo no meu slides aqui, deixe-me atirar pássaros em porcos já,
e você pode ver no slide aqui há exemplos de uma caixa de permissão BlackBerry.
Ele diz: "Por favor, defina as permissões de aplicativos BlackBerry Viagem
após o botão clicando abaixo ", e, basicamente, o usuário está indo só para dizer
definir as permissões e salvar.
Aqui está uma linha de Android, onde ele mostra as coisas,
e ele realmente coloca algo que quase se parece com um aviso.
Tem uma espécie de sinal de rendimento lá dizendo comunicação de rede, chamada de telefone,
mas o usuário vai clicar instalar, certo?
E então o que a Apple é completamente inócuo.
Ele não dá qualquer tipo de aviso.
É só a Apple gostaria de usar sua localização atual.
Claro que você vai clicar tudo bem.
>> Existe esse modelo de permissão de grão fino,
e os aplicativos tem que ter um arquivo de manifesto onde eles declaram
as permissões que eles precisam, e que vai ser exibida para o usuário,
e que o usuário vai ter que dizer que eu conceder essas permissões.
Mas vamos ser honestos.
Os utilizadores estão indo só para dizer sempre tudo bem.
Vamos dar uma rápida olhada nas permissões que esses aplicativos estão pedindo
e algumas das permissões que estão lá.
Esta empresa pretoriana fez uma pesquisa no ano passado
de 53.000 aplicações analisadas nos mercados de mercado e 3rd party para Android,
então isso é tudo o Android.
E o app média solicitado 3 permissões.
Alguns aplicativos solicitado 117 permissões,
então, obviamente, estes são muito grão fino e demasiado complexo para um usuário para entender
se eles são apresentados com este aplicativo que precisa desses 117 permissões.
É como se o acordo de licença do usuário final que é 45 páginas.
Talvez em breve eles terão uma opção onde é como
imprimir as permissões e enviar-me um e-mail.
>> Mas se você olhar para algumas das principais permissões interessantes
24% dos aplicativos que baixaram de 53.000 a
informações de GPS solicitada a partir do dispositivo.
8% ler os contatos.
4% enviaram SMS, e 3% receberam SMS.
2% registrados áudio.
1% processadas chamadas de saída.
Eu não sei.
Eu não acho que 4% dos aplicativos na App Store realmente precisa para enviar mensagens de texto SMS,
então eu acho que isso é um indício de que algo desagradável está acontecendo.
8% dos aplicativos precisa ler a sua lista de contatos.
Provavelmente não é necessário.
Uma das outras coisas interessantes sobre permissões é
se você ligar em bibliotecas compartilhadas em sua aplicação
aqueles herdar as permissões do aplicativo,
por isso, se o seu aplicativo precisa da lista de contatos ou precisa da localização GPS a funcionar
e você ligar em uma biblioteca de publicidade, por exemplo,
essa biblioteca anúncio também será capaz de acessar os contatos
e também ser capaz de acessar o local de GPS,
eo desenvolvedor do app não sabe nada sobre o código que está sendo executado na biblioteca anúncio.
Eles estão apenas ligando em que, porque eles querem rentabilizar o seu aplicativo.
>> Este é o lugar onde, e eu vou falar sobre alguns exemplos deste com
um aplicativo chamado Pandora, onde um desenvolvedor de aplicativos
pode inadvertidamente estar vazando informações
de seus usuários por causa de bibliotecas eles ligados dentro
Examinando a paisagem lá fora, olhando para todas as diferentes aplicações
que foram relatados na notícia como algo que os usuários mal-intencionados ou fazendo não queria
e depois de inspecionar um monte de aplicativos de que fazemos um monte de análise binária estática em aplicativos móveis,
por isso temos inspecionado-los e olhou para o próprio código-
que surgiu com o que chamamos de nossa lista top 10 dos comportamentos de risco nas aplicações.
E é dividido em duas seções, código malicioso,
assim que estas são coisas ruins que os aplicativos podem estar fazendo isso
tendem a ser algo que um indivíduo malicioso
tem especificamente colocar na aplicação, mas é um pouco confuso.
Poderia ser algo que um desenvolvedor pensa é bom,
mas acaba sendo visto como mal-intencionado pelo usuário.
>> E então a segunda parte é o que chamamos de codificação vulnerabilidades,
e estas são as coisas em que o desenvolvedor, basicamente, é cometer erros
ou simplesmente não entende como escrever o aplicativo com segurança,
e que está colocando o usuário de aplicativo em risco.
Eu vou passar por isso em detalhes e dar alguns exemplos.
Para referência, eu queria colocar a lista móvel top 10 da OWASP.
Estas são as 10 questões que um grupo da OWASP,
o Projeto Open Web Application Security, eles têm um grupo de trabalho
trabalhando em um móvel lista top 10.
Eles têm uma lista muito famoso web top 10, que é o top 10
coisas mais arriscadas que você pode ter em uma aplicação web.
Eles estão fazendo a mesma coisa para celular,
e sua lista é um pouco diferente da nossa.
6 dos 10 são a mesma.
Têm 4 que são diferentes.
Eu acho que eles têm um pouco de uma posição diferente sobre
risco em aplicações móveis, onde muitos de seus problemas
são realmente como a aplicação está se comunicando com um servidor back-end
ou o que está acontecendo no servidor back-end,
não tanto aplicações que tenham comportamento de risco que são aplicações cliente apenas simples.
>> Os de vermelho aqui são as diferenças entre as duas listas.
E um pouco da minha equipe de pesquisa que realmente contribuíram para este projeto,
então vamos ver o que acontece ao longo do tempo, mas acho que o takeaway aqui é
nós realmente não sabemos o que a lista top 10 é em aplicativos móveis porque
eles realmente apenas em torno de 2 ou 3 anos,
e não houve tempo suficiente para realmente pesquisar os sistemas operacionais
eo que eles são capazes de fazer, e não houve tempo suficiente
para a comunidade maliciosa, se quiser, de ter passado tempo suficiente
tentando atacar usuários através de aplicativos móveis, por isso espero que estas listas para mudar um pouco.
Mas, por agora, estas são as 10 melhores coisas para se preocupar.
Você pode se perguntar sobre o lado móvel onde é que o código malicioso-móvel
como consegue no dispositivo?
North Carolina State tem um projeto chamado Projeto Genoma Móvel Malware
onde eles estão coletando o máximo de malware móvel que puderem e analisá-lo,
e eles têm dividido os vetores de injeção que o malware móvel usa,
e 86% usam uma técnica chamada reembalagem,
e este é apenas na plataforma Android
você pode realmente fazer isso reembalagem.
>> A razão é código do Android é construído com
um código Java byte chamado Dalvik, que é facilmente descompilável.
O que o bandido pode fazer é
ter uma aplicação Android, decompor-lo,
inserir o código malicioso, recompilá-lo,
e, em seguida, colocá-lo na loja de aplicativos que se apresente uma nova versão desse aplicativo,
ou talvez apenas mudar o nome do aplicativo.
Se fosse algum tipo de jogo, altere o nome ligeiramente,
e por isso esta reembalagem é como 86% dos malware móvel é distribuída.
Há uma outra atualização técnica chamada que é
muito semelhante a reembalagem, mas na verdade você não colocar o código malicioso dentro
O que você faz é colocar em um pequeno mecanismo de atualização.
Você descompilar, você coloca em um mecanismo de atualização, e você recompilar,
e depois, quando o aplicativo está sendo executado ele puxa para baixo o malware para o aparelho.
>> A grande maioria são as 2 técnicas.
Não há realmente muito de download drive-bys ou drive-by downloads em celulares,
o que poderia ser como um ataque de phishing.
Ei, veja este site muito legal,
ou você precisa ir a este site e preencha este formulário
para manter continua fazendo alguma coisa.
Esses são ataques de phishing.
A mesma coisa pode acontecer na plataforma móvel, onde eles
apontam para um aplicativo móvel para download, dizer "Oi, aqui é o Bank of America."
"Nós vemos que você está usando esta aplicação."
"Você deve baixar este outro aplicativo."
Teoricamente, isso poderia funcionar.
Talvez ele simplesmente não está sendo usado o suficiente para determinar se é ou não bem sucedida,
mas eles descobriram que menos de 1% do tempo que a técnica é utilizada.
A maioria das vezes é realmente um código reembalado.
>> Há uma outra categoria chamada standalone
onde alguém apenas cria um aplicativo novo.
Eles constroem um aplicativo que pretende ser algo.
Não é uma reembalagem de outra coisa, e que tem o código malicioso.
Isso é usado 14% do tempo.
Agora eu quero falar sobre o que está a fazer o código malicioso?
Um dos primeiros malware para fora lá
você poderia considerar um spyware.
Ele espia basicamente sobre o usuário.
Ele coleta e-mails, mensagens SMS.
Acontece no microfone.
Colhe o livro de contatos e envia-lo para outra pessoa.
Este tipo de spyware existente no PC,
por isso, faz todo o sentido para as pessoas a tentar fazer isso em dispositivos móveis.
>> Um dos primeiros exemplos disso foi um programa chamado Segredo SMS Replicator.
Foi no Android Marketplace um par de anos atrás,
ea idéia era se você tivesse acesso a alguém telefone Android
que você queria para espionar, então talvez seja o seu cônjuge
ou o seu outro significativo e você quer espionar suas mensagens de texto,
você pode baixar este aplicativo e instalá-lo e configurá-lo
para enviar uma mensagem de texto SMS para você uma cópia
de cada mensagem de texto SMS que eles têm.
Isto, obviamente, é em violações dos termos App Store do serviço,
e este foi removido do Android Marketplace dentro de 18 horas do mesmo estar lá,
assim que um número muito pequeno de pessoas estavam em risco por causa disso.
Agora, eu acho que se o programa foi chamado de algo talvez um pouco menos provocante
como Segredo SMS Replicator ele provavelmente teria funcionado muito melhor.
Mas era meio óbvio.
>> Uma das coisas que podemos fazer para determinar se os aplicativos têm esse comportamento que não queremos
é inspecionar o código.
Isso é realmente muito fácil de fazer em Android porque podemos decompor os apps.
No iOS, você pode usar um disassembler como IDA Pro
olhar para o que APIs do aplicativo está chamando eo que ele está fazendo.
Nós escrevemos nosso próprio analisador estático binário para o nosso código
e fazemos isso, e assim o que você poderia fazer é que você poderia dizer
se o dispositivo de fazer qualquer coisa que é, basicamente, me espionando ou me rastrear?
E eu tenho alguns exemplos aqui no iPhone.
Este primeiro exemplo é como acessar o UUID no telefone.
Isso é realmente algo que a Apple acaba banido para novas aplicações,
mas aplicativos antigos que você pode ter em execução no seu telefone ainda pode fazer isso,
e de modo que o identificador exclusivo pode ser utilizado para rastrear você
em muitas aplicações diferentes.
>> No Android, tenho um exemplo aqui de obter a localização do dispositivo.
Você pode ver que, se essa chamada API é lá que o app está seguindo,
e você pode ver se ele está ficando boa localização ou localização grosseira.
E, em seguida, na parte inferior aqui, eu tenho um exemplo de como no BlackBerry
um aplicativo pode acessar as mensagens de e-mail em sua caixa de entrada.
Estes são o tipo de coisas que você pode inspecionar para ver
se o aplicativo está fazendo essas coisas.
A segunda grande categoria de comportamento malicioso, e este é provavelmente o maior da categoria, agora,
é a marcação não autorizado, não autorizado prémio de mensagens de texto SMS
ou pagamentos não autorizados.
Outra coisa que é único sobre o telefone
se o dispositivo estiver ligado a uma conta de cobrança,
e quando as atividades acontecem no telefone
ele pode criar encargos.
Você pode comprar as coisas pelo telefone,
e quando você envia uma mensagem de texto SMS premium na verdade você está dando dinheiro
para o titular da conta do número de telefone do outro lado.
Estes foram criados para obter cotações de ações ou obter o seu horóscopo diário ou outras coisas,
mas eles podem ser configurados para encomendar um produto, enviando um SMS.
As pessoas dão dinheiro para a Cruz Vermelha através do envio de uma mensagem de texto.
Você pode dar 10 dólares dessa maneira.
>> Os agressores, o que eles fizeram é eles montaram
contas em países estrangeiros, e eles incorporar na malwares
que o telefone irá enviar uma mensagem de texto SMS premium,
dizer, algumas vezes por dia, e no final do mês você percebe que você passou
dezenas ou talvez até centenas de dólares, e que a pé com o dinheiro.
Este ficou tão ruim que esta foi a primeira coisa que o Android
Mercado ou o Google lugar-foi o mercado Android no momento,
e é agora o Google Play-a primeira coisa que o Google começou verificando.
Quando o Google começou a distribuir os apps Android em sua loja de aplicativos
eles disseram que não estavam indo para verificar se há qualquer coisa.
Vamos puxar aplicativos, uma vez que já foi notificado que quebrou nossos termos de serviço,
mas nós não estamos indo para verificar se há qualquer coisa.
Bem, há um ano ele ficou tão ruim com este malware mensagem de texto SMS premium
que esta é a primeira coisa que eles começaram a verificação de.
Se um aplicativo pode enviar mensagens de texto SMS
que examinar mais que a aplicação manualmente.
Eles olham para as APIs que chamam isso,
e agora, desde então, o Google se expandiu,
mas esta foi a primeira coisa que eles começaram a procurar.
>> Alguns outros aplicativos que faziam algumas mensagens de texto SMS,
este Qicsomos Android, acho que ele é chamado.
Havia um evento atual no celular onde esta CarrierIQ saiu
como spyware colocar no dispositivo pelas operadoras,
para que as pessoas queriam saber se seu telefone era vulnerável a isso,
e este foi um aplicativo gratuito que testou isso.
Bem, é claro, o que fez este aplicativo foi enviado mensagens de texto SMS premium,
assim, testando para ver se você está infectado com spyware
você carregou malware em seu dispositivo.
Vimos a mesma coisa acontecer no último Super Bowl.
Houve uma versão falsa do jogo de futebol Madden
que enviou mensagens de texto SMS premium.
Na verdade, tentou criar uma rede bot também no dispositivo.
Aqui eu tenho alguns exemplos.
Curiosamente, a Apple foi muito inteligente,
e eles não permitem que aplicativos para enviar mensagens de texto SMS em tudo.
Nenhum aplicativo pode fazê-lo.
Essa é uma ótima maneira de se livrar de toda uma classe de vulnerabilidade,
mas no Android você pode fazê-lo, e, claro, no BlackBerry, você pode fazê-lo também.
É interessante que no BlackBerry tudo o que você precisa é de permissões de internet
para enviar uma mensagem de texto SMS.
>> A outra coisa realmente que nós procuramos
quando estamos olhando para ver se algo está mal-intencionado é qualquer tipo de
atividade de rede não autorizado, como olhar para a atividade de rede
o app é suposto ter que ter a sua funcionalidade,
e olhar para esta outra atividade da rede.
Talvez um aplicativo, para funcionar, tem de obter dados sobre HTTP,
mas se for fazer as coisas por e-mail ou SMS ou Bluetooth ou algo parecido
agora que o app poderia ser potencialmente malicioso, por isso esta é uma outra coisa que você pode inspecionar.
E neste slide aqui eu tenho alguns exemplos disso.
Outra coisa interessante que vimos com malware aconteceu em 2009,
e aconteceu em grande forma.
Eu não sei se isso aconteceu muito desde então, mas era um app
que personificou outro aplicativo.
Houve um conjunto de aplicativos, e foi apelidado de ataque 09Droid,
e alguém decidiu que havia um monte de pequenos bancos de médio porte, regionais
que não tinha aplicações bancárias on-line,
então o que eles fizeram foi que eles construíram cerca de 50 aplicações bancárias online
que tudo o que fez foi levar o nome de usuário e senha
e redirecioná-lo para o site.
E assim, eles colocaram todos estes acima no Google Marketplace,
no mercado Android, e quando alguém procurou para ver se o seu banco
tinha uma aplicação que iria encontrar o aplicativo falso,
que coletou suas credenciais e, então, redirecionado-os para o seu site.
A maneira que isso realmente se tornou-os aplicativos foram até lá por algumas semanas,
e havia milhares e milhares de downloads.
>> A maneira como isso veio à tona era alguém estava tendo um problema
com uma das aplicações, e chamaram o seu banco,
e chamaram linha de apoio ao cliente do seu banco e disse:
"Eu estou tendo um problema com o aplicativo de mobile banking".
"Você pode me ajudar?"
E eles disseram: "Nós não temos um aplicativo bancário móvel."
Isso começou a investigação.
Esse banco chamado Google e Google olhou e disse:
"Uau, o mesmo autor tem escrito 50 aplicações de banco", e os levou a todos para baixo.
Mas, certamente, isso pode acontecer de novo.
Aí está a lista de todos os diferentes bancos aqui
que fizeram parte desta farsa.
A outra coisa que um aplicativo pode fazer é apresentar a interface do usuário de outro aplicativo.
Enquanto ele está correndo poderia aparecer o Facebook UI.
Ele diz que você tem que colocar em seu nome de usuário e senha para continuar
ou colocar qualquer nome de usuário e senha da interface do usuário para um site
que talvez o usuário utiliza apenas para tentar enganar o usuário
em colocar as suas credenciais dentro
Este é realmente um paralelo direto dos ataques de phishing e-mail
onde alguém lhe envia uma mensagem de e-mail
e dá-lhe, basicamente, uma interface de usuário para um site falso
que você tem acesso.
>> A outra coisa que procurar em um código malicioso é a modificação do sistema.
Você pode olhar para todas as chamadas de API que requerem privilégios de root
para executar corretamente.
Alterar proxy web do dispositivo seria algo que um aplicativo
não deve ser capaz de fazer.
Mas se o aplicativo tem código lá para fazer isso
você sabe que é, provavelmente, um aplicativo malicioso
ou altamente provável que seja um aplicativo malicioso,
e assim o que aconteceria é que o app teria alguma forma de escalada privilégio.
Teria algum escalonamento de privilégios explorar
na aplicação, em seguida, uma vez que ele escalou privilégios
seria fazer essas modificações no sistema.
Você pode encontrar malware que tem escalação de privilégios
nele mesmo sem saber como o escalonamento de privilégios
exploit que vai acontecer, e isso é uma maneira agradável, fácil
para procurar malware.
DroidDream foi, provavelmente, a mais famosa peça de malware Android.
Eu acho que afetou cerca de 250 mil usuários ao longo de alguns dias
antes de ter sido encontrado.
Eles reembalado 50 aplicativos falsos,
colocá-los na loja de aplicativos Android,
e, essencialmente, ela usou o código jailbreak Android para escalar privilégios
e, em seguida, instalar um comando e controle e virar todas as vítimas
em uma rede de bot, mas você poderia ter detectado esta
se você fosse a digitalização do aplicativo e apenas procurando
Chamadas de API que a permissão raiz necessários para executar corretamente.
>> E há um exemplo aqui eu tenho que está mudando o proxy,
e este, na verdade, só está disponível no Android.
Você pode ver que eu estou te dando um monte de exemplos sobre Android
porque este é o lugar onde o ecossistema malware mais ativo é
porque é muito fácil para um atacante para obter o código malicioso
no Android Marketplace.
Não é tão fácil de fazer que na App Store da Apple
porque a Apple exige que os desenvolvedores a identificar-se
e assinar o código.
Eles realmente verificar quem você é, ea Apple é realmente o exame dos pedidos.
Nós não vemos um monte de malware propriamente dito, onde o dispositivo está sendo comprometida.
Vou falar sobre alguns exemplos onde é realmente de privacidade que está ficando comprometida,
e isso é o que realmente está acontecendo no dispositivo Apple.
Outra coisa é olhar para o código malicioso, código arriscado em dispositivos
é lógica ou tempo bombas e bombas de tempo são, provavelmente,
muito mais fácil do que procurar bombas lógicas.
Mas, com bombas de tempo, o que você pode fazer é que você pode olhar para
lugares no código onde o tempo é testada ou um tempo absoluto é procurado
antes de certas funcionalidades no aplicativo acontece.
E isso poderia ser feito para esconder que a atividade do usuário,
por isso está a acontecer à noite.
DroidDream fez toda a sua actividade 11:00-08:00 hora local
para tentar fazê-lo enquanto o usuário não pode estar usando seu dispositivo.
>> Outra razão para fazer isso é se as pessoas estão usando a análise do comportamento de um aplicativo,
executar o aplicativo em uma caixa de areia para ver o que o comportamento da aplicação é,
eles podem usar a lógica baseada em tempo de fazer a atividade
quando o aplicativo não está na caixa de areia.
Por exemplo, uma loja de aplicativos como a Apple
executa o aplicativo, mas eles provavelmente não executar todas as aplicações para, digamos, 30 dias
antes de o aprovar, para que possa colocar
lógica em seu aplicativo que disse, tudo bem, só fazer o que é mau
depois de 30 dias se passou ou depois de 30 dias após a data de publicação do pedido,
e que pode ajudar a esconder o código malicioso de pessoas que inspecionam por isso.
Se as empresas de antivírus estão conduzindo as coisas em caixas de areia
ou as próprias lojas de aplicativos são isso pode ajudar
esconder que a partir dessa inspecção.
Agora, o outro lado da moeda é que é fácil de se encontrar com a análise estática,
por isso, na verdade, inspecionando o código que você pode olhar para todos os lugares
onde o aplicativo testa o tempo e inspecionar assim.
E aqui eu tenho alguns exemplos sobre essas três plataformas diferentes
como o tempo pode ser verificado pelo fabricante aplicativo
para que você saiba o que procurar se você está inspecionando o aplicativo estaticamente.
>> Eu só passei por um monte de diferentes atividades maliciosas
que temos visto na natureza, mas quais são os mais prevalentes?
Esse mesmo estudo da North Carolina State móvel Projeto Genoma
publicados alguns dados, e foram basicamente quatro áreas
que eles viram onde havia uma grande quantidade de atividade.
37% dos apps fez escalação de privilégios,
então eles tinham algum tipo de código de jailbreak lá
onde tentaram escalar privilégios para que eles pudessem
que comandos API rodando como sistema operacional.
45% dos apps lá fora fez SMS premium,
de modo que é uma enorme percentagem que está a tentar rentabilizar diretamente.
93% fizeram o controle remoto, para que eles tentaram criar uma rede de bot, uma rede bot móvel.
E 45% colhidas informações de identificação
como números de telefone, UUIDs, localização GPS, contas de usuário
e isto acrescenta-se a mais de 100, porque a maioria dos malware tenta fazer algumas dessas coisas.
>> Eu vou mudar para a segunda metade e falar sobre as vulnerabilidades de código.
Esta é a segunda metade da atividade de risco.
Este é o lugar onde essencialmente o desenvolvedor está cometendo erros.
Um desenvolvedor legítimo escrever um aplicativo legítimo
é cometer erros ou é ignorante sobre os riscos de a plataforma móvel.
Eles simplesmente não sabem como fazer um aplicativo móvel seguro,
ou, por vezes, o desenvolvedor não se preocupa em colocar o usuário em risco.
Às vezes, parte de seu modelo de negócio pode ser
colhendo informações pessoais do usuário.
Isso é uma espécie de outra categoria, e é por isso que algumas dessas malicioso
contra começa a sangrar mais legítimos porque não há diferença de opiniões
entre o que o usuário quer e aquilo que o usuário considera arriscado
eo que o desenvolvedor do aplicativo considera arriscado.
Claro, não é de dados do desenvolvedor do aplicativo, na maioria dos casos.
>> E então, finalmente, uma outra maneira isso acontece é um desenvolvedor pode vincular em
uma biblioteca compartilhada que tem vulnerabilidades ou este comportamento de risco em que
sem o conhecimento deles.
A primeira categoria é o vazamento de dados sensíveis,
e isso é quando o aplicativo coleta informações
como localização, informações de livro de endereços, informações do proprietário
e manda que desligar o dispositivo.
E uma vez que ele está fora do dispositivo, não sabemos o que está acontecendo com essa informação.
Poderia ser armazenados de forma insegura pelo desenvolvedor do aplicativo.
Temos visto os desenvolvedores de aplicativos se comprometido,
e os dados que estão armazenando é levado.
Isso aconteceu há alguns meses para um desenvolvedor na Flórida
onde um grande número de-era UUIDs iPads e nomes de dispositivos
vazaram porque alguém, eu acho que era anônimo,
alegou para fazer isso, invadiu os servidores deste desenvolvedor
e roubou milhões de iPad UUIDs
e nomes de computadores.
Não a informação mais arriscado,
mas o que se fosse esse o armazenamento de nomes de usuário e senhas
e endereços residenciais?
Há muitos aplicativos que armazenam esse tipo de informação.
O risco está lá.
>> A outra coisa que pode acontecer é se o desenvolvedor não cuidar
para proteger o canal de dados, e isso é outro grande vulnerabilidade eu vou falar,
que os dados estão sendo enviados em claro.
Se o usuário estiver em uma rede Wi-Fi pública
ou alguém está cheirando a internet em algum lugar
ao longo do percurso que os dados estão a ser expostos.
Um muito famoso caso deste vazamento de informações aconteceu com Pandora,
e isso é algo que pesquisou no Veracode.
Ouvimos que havia uma-Eu acho que foi uma Comissão Federal de Comércio
investigação acontecendo com Pandora.
Nós dissemos: "O que está acontecendo lá? Vamos começar a cavar para o aplicativo Pandora."
E o que determinou foi a aplicação Pandora coletadas
seu sexo e sua idade,
e também acessada a sua localização GPS eo aplicativo Pandora
fez isso para que eles disseram eram razões legítimas.
A música que eles estavam jogando-Pandora é um aplicativo de streaming de música
a música que eles estavam jogando só foi licenciado nos Estados Unidos,
então eles tinham que verificar para cumprir seus contratos de licença que tinham
para a música que o usuário estava nos Estados Unidos.
Eles também queriam cumprir com o parental advisory
em torno de linguagem adulta na música,
e por isso é um programa voluntário, mas eles queriam cumprir essa
e não jogar letras explícitas para crianças de 13 anos ou menos.
>> Eles tinham razões legítimas para a coleta de dados.
Seu aplicativo tinha as permissões para fazê-lo.
Usuários achava que isso era legítimo. Mas o que aconteceu?
Eles ligaram em 3 ou 4 bibliotecas de anúncios diferentes.
Agora, de repente, todas essas bibliotecas de anúncios
estão tendo acesso a esta mesma informação.
As bibliotecas de anúncios, se você olhar o código nas bibliotecas de anúncios
o que eles fazem é cada biblioteca anúncio diz
"Será que meu aplicativo tem permissão para obter a localização GPS?"
"Oh, isso? Ok, me diga a localização GPS."
Cada biblioteca anúncio só faz isso,
e se o aplicativo não tem permissão GPS
não será capaz de obtê-lo, mas, se isso acontecer, ele vai buscá-la.
Este é o lugar onde o modelo de negócio das bibliotecas de anúncios
opõe-se à privacidade do usuário.
E tem havido estudos lá fora, que vai dizer se você sabe a idade
de uma pessoa e você sabe que a sua localização
onde dormir à noite, porque você tem as suas coordenadas de GPS
enquanto eles estão dormindo, talvez, você sabe exatamente quem é essa pessoa
porque você pode determinar qual membro dessa família é essa pessoa.
Realmente esta é a identificação para os anunciantes
exatamente quem você é, e parece que era legítimo.
Eu só quero que meu streaming de música, e esta é a única maneira de obtê-lo.
>> Bem, nós expusemos isso.
Nós escrevemos isso em vários posts,
e descobriu-se que alguém da revista Rolling Stone
ler um de nossos posts e escreveu seu próprio blog na revista Rolling Stone sobre o assunto,
e no dia seguinte Pandora pensou que era uma boa idéia
para remover as bibliotecas de anúncios com a sua aplicação.
Tanto quanto eu sei que eles são a única, eles devem ser elogiados.
Eu acho que eles são o único tipo freemium de aplicativo que tenha feito isso.
Todos os outros aplicativos freemium ter esse mesmo comportamento,
então você tem que pensar sobre o tipo de dados que você está dando
esses aplicativos freemium porque tudo vai para os anunciantes.
Praetorian também fez um estudo sobre as bibliotecas compartilhadas e disse:
"Vamos ver quais bibliotecas compartilhadas são as bibliotecas compartilhadas top", e isso foi os dados.
>> Eles analisaram 53 mil apps,
ea biblioteca compartilhada número 1 foi AdMob.
Na verdade, foi em 38% das aplicações lá fora,
assim 38% dos aplicativos que você está usando
provavelmente estão colhendo suas informações pessoais
e enviá-lo para as redes de anúncios.
Apache e Android foram de 8% e 6%,
e, em seguida, estes outros, na parte inferior, o Google Ads, Flurry,
Mob City e Millennial Media,
estas são todas as empresas de publicidade, e depois, curiosamente,
4% ligados na biblioteca Facebook
provavelmente para fazer a autenticação através do Facebook
de modo que o aplicativo poderia autenticar o Facebook.
Mas isso também significa que a corporação Facebook controla código
que está sendo executado em 4% dos aplicativos móveis Android lá fora,
e eles têm acesso a todos os dados que esse aplicativo tem permissão para chegar.
Facebook essencialmente tenta vender espaço publicitário.
Esse é o seu modelo de negócio.
>> Se você olhar para todo esse ecossistema com essas permissões
e bibliotecas compartilhadas, você começa a ver que
você tem um monte de risco em um aplicativo, supostamente legítima.
A mesma coisa semelhante que aconteceu com Pandora
aconteceu com um aplicativo chamado Path,
e Caminho pensaram que estavam sendo úteis, desenvolvedores amigáveis.
Eles estavam apenas tentando dar-lhe uma grande experiência do usuário,
e descobriu-se que sem avisar o usuário ou dizer qualquer coisa que o usuário-
e isso aconteceu no iPhone e no Android,
o aplicativo Pandora foi no iPhone e Android-
que o aplicativo Path foi pegar seu livro de endereços inteiro
e enviá-lo ao caminho apenas quando você instalou e executou o aplicativo,
e não falar sobre isso.
Eles pensaram que era realmente útil para você
para ser capaz de compartilhar com todas as pessoas em sua lista de endereços
que você está usando o aplicativo Path.
>> Bem, obviamente Caminho achava que isso era ótimo para a sua empresa.
Não tão grande para o usuário.
Você tem que pensar que é uma coisa que se talvez um adolescente
está usando esse aplicativo e suas dezenas de amigos estão lá,
mas o que se é o CEO de uma empresa que instala Path
e depois, de repente, seu livro de endereços inteiro está lá em cima?
Você vai ter um monte de informações de contato potencialmente valiosa
para um monte de pessoas.
Um repórter do New York Times, que você pode ser capaz de obter o número de telefone
para ex-presidentes de seu livro de endereços,
então, obviamente, uma grande quantidade de informações sigilosas é transferido com algo parecido com isso.
Houve uma grande aba tal sobre isso que caminho se desculpou.
Eles mudaram a sua aplicação, e ainda impactado Apple.
A Apple disse, "Nós estamos indo para forçar os fornecedores de aplicativos para solicitar aos usuários
se eles estão indo para recolher todo o seu catálogo de endereços. "
>> Parece que o que está acontecendo aqui é
quando há uma grande violação de privacidade e isso faz a imprensa
vemos uma mudança lá fora.
Mas, claro, há outras coisas lá fora.
O aplicativo LinkedIn colhe suas entradas de calendário,
mas a Apple não faz o usuário será solicitado a esse respeito.
As entradas de calendário pode ter informações confidenciais neles também.
Onde é que você vai desenhar a linha?
Isso realmente é uma espécie de lugar evoluindo
onde não há realmente nenhuma boa qualidade lá fora
para os usuários a entender quando a sua informação vai estar em risco
e quando eles vão saber que está sendo tomada.
Nós escrevemos um aplicativo em Veracode chamado Adios,
e, essencialmente, que lhe permitiu apontar o aplicativo em seu diretório iTunes
e olhar para todas as aplicações que foram colhendo o seu livro de endereço completo.
E como você pode ver nesta lista aqui, Angry Birds,
AIM, AroundMe.
Por que Angry Birds precisa de seu livro de endereços?
Eu não sei, mas ele de alguma forma.
>> Isso é algo que muitos, muitos aplicativos fazem.
Você pode inspecionar o código para isso.
Há APIs bem definidas para iPhone, Android e BlackBerry
para chegar ao livro de endereços.
Você pode muito facilmente inspecionar para isso, e é isso que nós fizemos em nossa aplicação Adios.
A próxima categoria, inseguro de armazenamento de dados sensíveis,
é algo onde os desenvolvedores tomar algo como um alfinete ou um número de conta
ou uma senha e guarde-a em claro no dispositivo.
Ainda pior, eles podem armazená-lo em uma área no telefone
que é globalmente acessível, como o cartão SD.
Você vê isso com mais frequência no Android porque o Android permite a um cartão SD.
Dispositivos iPhone não.
Mas nós ainda vimos isso acontecer em um aplicativo Citigroup.
Sua aplicação bancária on-line armazenados os números de conta de forma insegura,
apenas em claro, então se você perdeu o seu dispositivo,
essencialmente você perdeu sua conta bancária.
É por isso que eu, pessoalmente, não fazer serviços bancários no meu iPhone.
Eu acho que é muito arriscado no momento de fazer esses tipos de atividades.
>> Skype fez a mesma coisa.
Skype, é claro, tem um saldo de conta, nome de usuário e senha
que acessar esse equilíbrio.
Eles estavam armazenando todas as informações em claro no dispositivo móvel.
Eu tenho alguns exemplos aqui de criar arquivos
que não têm as permissões adequadas ou gravando em um disco
e não ter qualquer criptografia acontecer para isso.
Esta próxima área, inseguro de transmissão de dados sensíveis,
Eu já aludiu a isso algumas vezes, e por causa do público Wi-Fi
isso é algo que os aplicativos absolutamente precisa fazer,
e este é, provavelmente, o que vemos errar mais.
Eu diria-na verdade, eu acho que eu tenho os dados reais,
mas é perto de metade das aplicações móveis
estragar fazendo SSL.
Eles simplesmente não usar as APIs corretamente.
Quer dizer, tudo que você tem a fazer é seguir as instruções e usar as APIs,
mas eles coisas como não verificar se existe um certificado inválido, no outro extremo,
não verificar se a outra extremidade está tentando fazer um ataque protocolo rebaixamento.
>> Os desenvolvedores, eles querem obter a sua opção, certo?
Sua exigência é a de usar isso para vender. Eles usaram isso para vender.
A exigência não é usar isso para vender com segurança,
e assim é por isso que todas as aplicações que utilizam o SSL para proteger dados
como está sendo transmitida desligar o dispositivo realmente precisam ser inspecionadas
ter certeza de que foi implementado corretamente.
E aqui eu tenho alguns exemplos onde você pode ver uma aplicação
pode estar usando HTTP em vez de HTTPS.
Em alguns casos, aplicativos vai cair de volta para HTTP
se o HTTPS não está a funcionar.
Eu tenho outra chamada aqui no Android onde eles desativado a verificação do certificado,
assim um ataque man-in-the-middle pode acontecer.
Um certificado inválido será aceito.
Estes são todos os casos em que os atacantes vão ser capazes de obter em
a mesma conexão Wi-Fi como o usuário e acesso de todos os dados
que está sendo enviada através da internet.
>> E, finalmente, a última categoria que eu tenho aqui é a senha e chaves codificado.
Nós realmente ver um monte de desenvolvedores usar o mesmo estilo de codificação
que eles fizeram quando estavam construindo aplicativos de servidor web,
assim eles estão construindo um aplicativo de servidor Java, e eles estão codificar a chave.
Bem, quando você está construindo uma aplicação de servidor, sim,
codificar a chave não é uma boa idéia.
Torna-se difícil de mudar.
Mas não é tão ruim no lado do servidor, porque quem tem acesso ao lado do servidor?
Apenas os administradores.
Mas se você tomar o mesmo código e você derramou-o para uma aplicação móvel
agora todo mundo que tem esse aplicativo móvel tem acesso a essa chave codificada,
e realmente vemos isso um monte de vezes, e eu tenho algumas estatísticas
de quantas vezes vemos isso acontecer.
Ele realmente estava no código de exemplo que a MasterCard publicado
sobre como utilizar o seu serviço.
O código de exemplo mostrou como é que você simplesmente pegar a senha
e colocá-lo em uma seqüência codificada ali mesmo,
e sabemos como os desenvolvedores gostam de copiar e colar trechos de código
quando eles estão tentando fazer alguma coisa, para que você copie e cole o trecho de código
que deu como exemplo de código, e você tiver um aplicativo inseguro.
>> E aqui temos alguns exemplos.
Este primeiro é que vemos um monte onde se codificar
o direito de dados em uma URL que é enviado.
Às vezes, vemos string password = a senha.
Isso é muito fácil de detectar, ou string password no BlackBerry e Android.
É realmente muito fácil para verificar se há porque quase sempre
os nomes de desenvolvedores a variável que está segurando a senha
alguma variação de senha.
Eu mencionei que nós fazemos a análise estática em Veracode,
por isso temos analisado várias centenas de aplicativos Android e iOS.
Nós construímos modelos cheio deles, e nós somos capazes de digitalizá-los
para diferentes vulnerabilidades, especialmente as vulnerabilidades que eu estava falando,
e eu tenho alguns dados aqui.
68,5% dos aplicativos Android que nós olhamos
tinha quebrado código criptográfico,
que, para nós, não podemos detectar se você fez a sua própria rotina de criptografia,
não que isso seja uma boa idéia, mas isso está realmente usando as APIs publicadas
que estão sobre a plataforma, mas fazendo-as de tal maneira
que a criptografia seria vulnerável, 68,5.
E isso é para as pessoas que estão enviando-nos as suas aplicações, porque na verdade
eles acham que é uma boa idéia para fazer testes de segurança.
Estes já são pessoas que provavelmente estão pensando em segurança,
por isso é provavelmente ainda pior.
>> Eu não falar sobre controle de linha de injeção de alimentação.
É que verificar se há alguma coisa, mas não é tão arriscado um problema.
Vazamento de informações, este é o local onde os dados confidenciais estão sendo enviadas fora do dispositivo.
Descobrimos que em 40% dos pedidos.
Tempo e Estado, essas são questões tipo de condição de corrida, normalmente muito difíceis de explorar,
então eu não falar sobre isso, mas olhamos para ele.
23% tiveram problemas de injeção SQL.
Muitas pessoas não sabem que um monte de aplicativos
use um pequeno banco de dados SQL pouco em seu back-end para armazenar dados.
Bem, se os dados que você está agarrando na rede
tem cordas de ataque de injeção SQL nele
alguém pode comprometer o dispositivo através disso,
e então eu acho que nós encontramos cerca de 40% das aplicações web tem esse problema,
que é um problema enorme epidemia.
Podemos encontrá-lo 23% do tempo em aplicativos móveis
e isso é provavelmente porque muitas outras aplicações web usam SQL do móvel.
>> E depois ainda vemos alguns cross-site scripting, as questões de autorização,
e gerenciamento de credenciais, que é onde você tem a sua senha codificada.
Em 5% dos pedidos que ver isso.
E então nós temos alguns dados sobre iOS.
81% tiveram problemas de tratamento de erros.
Este é mais um problema de qualidade de código,
mas 67% tiveram problemas de criptografia, por isso não é tão ruim quanto o Android.
Talvez as APIs são um pouco mais fácil, os códigos de exemplo um pouco melhor no iOS.
Mas ainda uma percentagem muito elevada.
Tivemos 54% com o vazamento de informações,
cerca de 30% com erros de gestão buffer.
É lugares onde não poderia ser um problema de corrupção de memória.
Acontece que isso não é tanto um problema para a exploração
em iOS, porque todo o código tem de ser assinado,
por isso é difícil para um invasor executar um código arbitrário no iOS.
Qualidade de código, passagem de diretório, mas depois credenciais gestão aqui em 14,6%,
tão pior do que no Android.
Temos pessoas não lidar com senhas corretamente.
E, em seguida, os erros numéricos e buffer overflow,
aqueles são mais vai haver problemas de qualidade de código no iOS.
>> Que foi para a minha apresentação. Eu não sei se nós estamos sem tempo ou não.
Eu não sei se há alguma dúvida.
[Masculino] Uma pergunta rápida em torno da fragmentação e do mercado de Android.
A Apple, pelo menos, é dono de correção.
Eles fazem um bom trabalho de começá-lo lá fora, enquanto menos assim, no espaço Android.
Você quase precisa desbloquear seu telefone para se manter atualizado
com a versão atual do Android.
Sim, isso é um problema enorme e por isso, se você pensar sobre-
[Masculino] Por que você não pode repetir?
>> Ah, certo, então a questão é o que acontece com a fragmentação
do sistema operacional na plataforma Android?
Como isso afeta o grau de risco desses dispositivos?
E isso realmente é um problema enorme, porque o que acontece é
os dispositivos mais antigos, quando alguém surge com um jailbreak para esse dispositivo,
essencialmente isso é escalação de privilégios, e até que o sistema operacional é atualizado
qualquer malware pode, então, usar essa vulnerabilidade para comprometer totalmente o dispositivo,
e o que estamos vendo no Android é a fim de obter um novo sistema operacional
Google tem de apagar o sistema operacional e, em seguida, o fabricante do hardware
tem que personalizá-lo, e, em seguida, o transportador tem a personalizá-lo e entregá-lo.
Você tem basicamente três partes móveis aqui,
e está girando para fora para que os transportadores não me importo,
e os fabricantes de hardware não se importam, e Google não está estimulando-as o suficiente
para fazer qualquer coisa, por isso, essencialmente mais da metade dos dispositivos lá fora
têm sistemas operacionais que têm essas vulnerabilidades de escalonamento de privilégios neles,
e por isso, se você tem malware no seu dispositivo Android é muito mais de um problema.
>> Ok, muito obrigado.
[Aplausos]
[CS50.TV]