[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]