[Seminario] [Defender Detrás do teléfono: Seguridade de Aplicacións Mobile]
 [Chris Wysopal] [Universidade de Harvard]
 [Isto é CS50.] [CS50.TV]
 

Boa tarde. O meu nome é Chris Wysopal.
 Eu son o CTO e cofundador da Veracode.
 Veracode é unha empresa de seguridade da aplicación.
 Probamos todo tipo de aplicacións diferentes,
 eo que eu vou falar hoxe é a seguridade de aplicacións móbiles.
 A miña experiencia é que eu veño facendo investigación de seguridade
 por un tempo moi longo, probablemente case tan longo como calquera.
 I comezou a mediados dos anos 90,
 e foi un tempo que foi moi interesante porque
 tivemos un cambio de paradigma a mediados dos anos 90.
 Todas ordenador súpeto de todo estaba ligado á internet,
 e logo, tivemos o inicio de aplicacións web,
 e iso é o que me concentrei en moito, entón.
 É interesante.
 Agora temos unha outro cambio de paradigma a ocorrer coa computación,
 que é o cambio para aplicacións móbiles.
 

Eu sinto que é unha especie de tempo similar, a continuación, foi a finais dos anos 90
 cando estabamos investigando aplicacións web e atopar defectos como
 erros de xestión sesión e inxección de SQL
 que realmente non existía antes, e de súpeto eles estaban por todas partes
 en aplicacións web, e agora unha gran parte do tempo eu paso
 está mirando para aplicacións móbiles e ollando para o que está pasando aí fóra na selva.
 As aplicacións móbiles son realmente vai ser a plataforma de computación dominante,
 entón nós realmente necesita gastar unha morea de tempo, se está no sector de seguridade
 con foco en aplicacións web.
 Había 29 millóns de aplicacións móbiles descargados en 2011.
 Está previsto en 76 mil millóns de aplicacións en 2014.
 Hai 686 millóns de dispositivos que van ser compras este ano,
 de xeito que este é o lugar onde as persoas van estar facendo
  a maioría dos seus computación cliente de aquí para fronte.
 

Eu estaba a charlar con un vicepresidente da Fidelity Investments
 un par de meses, e el dixo que só vin máis tráfico
 facendo transaccións financeiras a partir da súa base de clientes
 sobre a súa aplicación móbil que na súa páxina web,
 así un uso común para a web no pasado foi
 comprobando as súas presupostos de accións, a xestión da súa carteira,
 e nós estamos realmente a ver que en 2012 máis de chave
 para ser máis dominante na plataforma móbil.
 Certamente, se non vai ser calquera actividade criminal,
 calquera actividade maliciosa, que vai comezar a ser focado na plataforma móbil
 ao longo do tempo como a xente pasar a iso.
 Se ollar para a plataforma móbil,
 ollar os riscos da plataforma é útil división la en diferentes capas,
 así como faría nun ordenador de escritorio,
 e pensa sobre as diferentes capas, software, sistema operativo,
 capa de rede, capa de hardware, e, por suposto, hai vulnerabilidades en todas as capas.
 

O mesmo acontece no móbil.
 Pero móbil, parece que algunhas destas capas están en situación peor.
 Por unha banda, a capa de rede é máis problemático no móbil
 porque unha morea de persoas teñen na súa oficina ou na casa
 conexións con fío ou teñen conexións WiFi seguras,
 e con unha morea de dispositivos móbiles que está, obviamente, fóra de casa
 ou fóra da oficina moito, e se está a usar Wi-Fi alí
 pode estar a usar unha conexión Wi-Fi insegura,
 algo que é unha conexión Wi-Fi público,
 por iso, cando pensamos sobre aplicacións móbiles que debemos ter en conta
 que o ambiente de rede é máis arriscado para as aplicacións
 cando o WiFi está a ser usado.
 E cando eu entrar en máis do risco de aplicacións móbiles
 vai ver por que isto é máis importante.
 Hai riscos a nivel de hardware en dispositivos móbiles.
 Esta é unha área de investigación en curso.
 As persoas chaman eses ataques de banda ancha ou de banda base de ataques
 onde está atacando o firmware que está escoitando na radio.
 

Estes son realmente asustado ataques por
 o usuario non ten que facer nada.
 Podes bater distintos dispositivos dentro do rango de RF
 dunha vez, e parece que sempre que esta investigación burbulla
 el rapidamente se clasifican onde
 persoas rusga arredor e dicir: "Aquí, conte-nos sobre iso, e por favor, deixe de falar sobre iso."
 Hai algunha investigación en curso na área de banda ancha,
 pero parece ser moi silencio silencio.
 Creo que é máis de un tipo de Estado-nación de investigación que está a suceder.
 Unha área de investigación activa, con todo, é a capa de sistema operativo,
 e, de novo, iso é diferente do que no mundo da computación de escritorio
 porque no espazo móbil ten eses equipos de persoas chamadas Jailbreakers,
 e Jailbreakers son diferentes do que os investigadores de vulnerabilidades comúns.
 Están intentando atopar vulnerabilidades no sistema operativo,
 pero a razón pola que eles están intentando atopar as vulnerabilidades non é
 invadir máquina de outra persoa e compromete-lo.
 É de romper no seu propio ordenador.
 

Eles queren invadir o seu propio teléfono móbil, modificar o sistema operativo do seu propio teléfono móbil
 para que se poidan executar as aplicacións da súa elección
 e cambiar as cousas con permisos administrativos totais,
 e eles non queren dicir o vendedor sobre iso. Eles non son como un investigador de seguridade, que é un investigador de seguridade sombreiro branco
 que vai facer a divulgación responsable e dicir ao vendedor sobre iso.
 Queren facer esa investigación, e queren realmente public-lo
 nun ataque ou un rootkit ou un código de jailbreak,
 e queren facelo estratexicamente, como logo
 os buques de provedores do novo sistema operativo.
 Ten esa relación conflitiva
 con vulnerabilidades de nivel de sistema operativo no móbil,
 que eu creo que é moi interesante, e un lugar que velo
 iso é o que o fai tan bo que non hai código publicado explotar por aí
 de vulnerabilidades no nivel do núcleo,
 e vimos aqueles realmente ser usado por escritores de malware.
 É un pouco diferente do que o mundo do PC.
 E, a continuación, a capa final é a capa superior, a capa de aplicación.
 Iso é o que eu vou falar hoxe.
 

Existir As outras capas, e as outras capas de xogar nel,
 pero eu estou indo todo para falar sobre o que está a ocorrer na capa de aplicación
 onde o código está en execución no cadro de area.
 Non ten privilexios administrativos.
 Ten que usar as APIs do dispositivo,
 pero aínda así, unha gran cantidade de actividades maliciosas e unha morea de risco pode ocorrer a esa capa
 porque esa é a capa onde toda a información é.
 Aplicacións poden acceder toda a información sobre o dispositivo
 se eles teñen os permisos axeitadas,
 e poden acceder aos distintos sensores do teléfono,
 Sensor GPS, micrófono, cámara, o que ten.
 Aínda que nós só estamos a falar na capa de aplicación
 temos unha morea de risco alí.
 A outra cousa que é diferente sobre o ambiente móbil
 é todos os xogadores do sistema operativo, sexa BlackBerry ou Android
 ou iOS ou Windows Mobile, todos eles teñen un modelo de permiso de gran fino,
 e esta é unha das formas que eles incorporados ao sistema operativo
 a idea de que non é tan arriscado como pensa.
 Aínda que teña todos os seus contactos sobre alí, toda a súa información persoal,
 ten as súas fotos, ten a súa localización no alí,
 está almacenando o seu contrasinal da base para auto login alí, é seguro porque
 aplicacións ten que ter certas permisos para chegar a certas partes
 de información sobre o dispositivo, e que o usuario ten que ser presentado con
 os permisos e dicir ben.
 

O problema con isto é que o usuario sempre di todo ben.
 Como unha persoa de seguridade, sei que pode solicitar que o usuario,
 dicir algo moi malo vai pasar, que quere que ocorre?
 E se eles están nunha carreira ou hai algo realmente atractivo do outro lado de que,
 como un xogo será instalado que estaba esperando,
 están indo a facer clic ben.
 É por iso que digo no meu diapositivas aquí, déixeme tirar paxaros en porcos xa,
 e pode ver na foto aquí hai exemplos dunha caixa de permiso BlackBerry.
 El di: "Por favor, configure os permisos de aplicacións BlackBerry Viaxe
 tras o botón premendo de abaixo ", e, basicamente, o usuario está indo só para dicir
 establecer os permisos e gardar.
 Aquí está unha liña de Android, onde mostra as cousas,
 e realmente pon algo que case se parece un aviso.
 Ten unha especie de sinal de rendemento alí dicindo comunicación de rede, chamada de teléfono,
 pero o usuario vai facer clic instalar, non?
 E entón o que Apple é completamente inocuo.
 Non dá ningún tipo de aviso.
 É só Apple quere usar a súa localización actual.
 Claro que vai facer clic todo ben.
 

Existe ese modelo de permiso de gran fino,
 e as aplicacións ten que ter un ficheiro de manifesto onde declaran
 os permisos que precisan, e que será exhibida para o usuario,
 e que o usuario terá que dicir que eu conceder os permisos.
 Pero imos ser honestos.
 Os usuarios están indo só para dicir sempre todo ben.
 Imos dar unha rápida ollo nas permisos que estas aplicacións están pedindo
 e algunhas dos permisos que están alí.
 Esta empresa pretoriana fixo unha investigación o ano pasado
 de 53.000 aplicacións analizadas nos mercados de mercado e 3rd party para Android,
 entón iso é todo o Android.
 E o app media solicitado 3 permisos.
 Algunhas aplicacións solicitado 117 permisos,
 entón, obviamente, estes son moi gran fino e demasiado complexo para un usuario para entender
 se son presentados con esta aplicación que necesita deses 117 permisos.
 É coma se o acordo de licenza do usuario final que é 45 páxinas.
 Quizais en breve terá unha opción onde é como
 imprimir os permisos e enviar-me un e-mail.
 

Pero se ollar para algunhas das principais permisos interesantes
 24% das aplicacións que baixaron de 53.000 a
 información de GPS solicitada desde o dispositivo.
 8% ler os contactos.
 4% enviaron SMS, e 3% recibiron SMS.
 2% rexistrados audio.
 1% procesadas chamadas de saída.
 Eu non sei.
 Eu non creo que o 4% das aplicacións na App Store realmente necesita para enviar mensaxes de texto SMS,
 entón eu creo que iso é un indicio de que algo desagradable está pasando.
 8% das aplicacións que ler a súa lista de contactos. Probablemente non é necesario.
 Unha das cousas interesantes sobre permisos e
 se conectar en bibliotecas compartidas na súa aplicación
 quen herdar os permisos da aplicación,
 polo que, se a súa aplicación precisa da lista de contactos ou precisa da localización GPS a funcionar
 e conectar nunha biblioteca de publicidade, por exemplo,
 esta biblioteca anuncio tamén poderá acceder aos contactos
 e tamén ser capaz de acceder o lugar de GPS,
 eo creador do app non sabe nada sobre o código que está a ser executado na biblioteca anuncio.
 Eles están só conectando en que, porque eles queren rendibilizar a súa aplicación.
 

Este é o lugar onde, e eu vou falar sobre algúns exemplos deste con
 unha aplicación chamado Pandora, onde un programador de aplicacións
 pode inadvertidamente estar vazando información
 dos seus usuarios por mor de bibliotecas eles conectados dentro
 Examinando a paisaxe aí fóra, mirando para as diferentes aplicacións
 que foron relativos na noticia como algo que os usuarios mal intencións ou facendo non quería
 e despois de inspeccionar unha morea de aplicacións de que facemos unha morea de análises binaria estática en aplicacións móbiles,
 polo que temos inspeccionado los e mirou para o propio código-
 que xurdiu co que chamamos a nosa lista top 10 dos comportamentos de risco nas aplicacións.
 E está dividido en dúas seccións, código malicioso,
 así que estas son cousas malas que as aplicacións poden estar a facer iso
 tenden a ser algo que un individuo malicioso
 ten especificamente poñer na aplicación, pero é un pouco confuso.
 Podería ser algo que un desenvolvedor pensa é bo,
 mais acaba sendo visto como mal intencionado polo usuario.
 

E entón a segunda parte é o que chamamos de codificación vulnerabilidades,
 e estas son as cousas en que o creador, basicamente, é cometer erros
 ou simplemente non entende como escribir a aplicación con seguridade,
  e que está poñendo o usuario de aplicación en perigo.
 Vou pasar por iso en detalles e dar algúns exemplos.
 Para referencia, eu quería poñer a lista móbil top 10 da OWASP.
 Estas son as 10 preguntas que un grupo de OWASP,
 o Proxecto Open Web Application Security, eles teñen un grupo de traballo
 traballando nun móbil lista top 10.
 Teñen unha lista moi famoso web top 10, que é o top 10
 cousas máis arriscadas que pode ter nunha aplicación web.
 Están facendo o mesmo para móbil,
 e súa lista é un pouco diferente da nosa.
 6 dos 10 son o mesmo.
 Teñen 4 que son diferentes.
 Eu creo que teñen un pouco de unha posición diferente sobre
 risco en aplicacións móbiles, onde moitos dos seus problemas
 son realmente como a aplicación está comunicando con un servidor back-end
 ou o que está pasando no servidor back-end,
 non tanto aplicacións que teñan comportamento de risco que son aplicacións cliente só simple.
 

Os de vermello aquí son as diferenzas entre as dúas listas.
 E un pouco da miña equipo de investigación que realmente contribuíron a este proxecto,
 entón imos ver o que acontece ao longo do tempo, pero creo que o takeaway aquí é
 nós realmente non sabemos o que a lista top 10 é en aplicacións móbiles porque
 realmente só en torno de 2 ou 3 anos,
 e non houbo tempo suficiente para realmente buscar os sistemas operativos
 eo que son capaces de facer, e non houbo tempo suficiente
 á comunidade maliciosa, se quere, de pasar tempo suficiente
 tentando atacar usuarios a través de aplicacións móbiles, polo que espera que estas listas para cambiar un pouco.
 Pero, por agora, estas son as 10 mellores cousas para se preocupar.
 Podes preguntar sobre o lado móbil onde é que o código malicioso-móbil
 como consegue o dispositivo?
 New York State ten un proxecto chamado Proxecto Xenoma Móbil Malware
 onde están traídos o máximo de malware móbil que puideren e analiza-lo,
 e eles teñen dividido os vectores de inxección que o malware móbil usa,
 e 86% utilizan unha técnica chamada reembalagem,
 e este é só na plataforma Android
 pode realmente facer iso reembalagem.
 

A razón é código de Android está construído con
 un código Java byte chamado Dalvik, que é facilmente descompilável.
 Que o bandido pode facer é
 ter unha aplicación Android, decompor-lo,
 introducir o código malicioso, recopila-lo,
 e, a continuación, colocar-lo na tenda de aplicacións que se presente unha nova versión deste programa,
 ou que só cambiar o nome da aplicación.
 Se fose algún tipo de xogo, cambie o nome lixeiramente,
 e por iso esta reembalagem é como 86% dos malware móbil é distribuída.
 Hai outra actualización técnica chamada que se
 moi semellante a reembalagem, pero en realidade non poñer o código malicioso dentro
 O que fai é poñer nun pequeno mecanismo de actualización.
 Vostede descompilar, se pon nun mecanismo de actualización, e recompilar,
 e despois, cando a aplicación está en execución el tira abaixo o malware para o aparello.
 

A gran maioría son as 2 técnicas.
 Non hai realmente moito de descarga drive-bys ou drive-by descargas en teléfonos móbiles,
 o que podería ser como un ataque de phishing.
 Ei, mira esta web moi legal,
 ou ten que ir a este sitio web e enche este formulario
 para manter continúa facendo algo. Estes son ataques de phishing.
 O mesmo pode ocorrer na plataforma móbil, onde
 apuntan a unha aplicación móbil para descargar, dicir "Ola, aquí é o Bank of America."
 "Vemos que está a usar esta aplicación."
 "Debe descargar esta outra aplicación."
 Teoricamente, isto podería funcionar.
 Quizais el simplemente non está a ser usado como para determinar se é ou non un éxito,
 pero descubriron que menos do 1% do tempo que a técnica é utilizada.
 A maioría das veces é realmente un código reembalado.
 

Hai outra categoría chamada standalone
 onde alguén só crea unha aplicación nova.
 Eles constrúen unha aplicación que pretende ser algo.
 Non é unha reembalagem doutra cousa, e que ten o código malicioso.
 Isto é usado 14% do tempo.
 Agora quero falar sobre o que está a facer o código malicioso?
 Un dos primeiros malware para fora alí
 podería considerar un spyware.
 El espia basicamente sobre o usuario.
 El recolle correos electrónicos, mensaxes SMS.
 Acontece o micrófono.
 Colle o libro de contactos e envia-lo a outra persoa.
 Este tipo de spyware existente no ordenador,
 por iso, fai todo o sentido para as persoas intentando facelo en dispositivos móbiles.
 

Un dos primeiros exemplos diso foi un programa chamado Segredo SMS Replicator.
 Foi en Android Marketplace un par de anos,
 ea idea era se tivese acceso a alguén teléfono Android
 que quería para espiar, entón quizais sexa o seu cónxuxe
 ou o seu outro significativo e quere espiar as mensaxes de texto,
 podes descargar esta aplicación e instala-lo e configure-lo
 para enviar unha mensaxe de texto SMS para ti unha copia
 de cada mensaxe de texto SMS que eles teñen.
 Isto, obviamente, é en violacións dos termos App Store do servizo,
 e este foi eliminado do Android Marketplace dentro de 18 horas do mesmo estar alí,
 así que un número moi pequeno de persoas estaban en risco por causa diso.
 Agora, eu creo que se o programa foi chamado de algo quizais algo menos provocante
 como Segredo SMS Replicator probablemente funcionaría moito mellor.
 Pero era medio evidente.
 

Unha das cousas que podemos facer para determinar se as aplicacións teñen ese comportamento que non queremos
 é inspeccionar o código.
 Isto é realmente moi fácil de facer en Android porque podemos descompoñer os apps.
 En iOS, pode utilizar un disassembler como IDA Pro
 ollar para o que APIs da aplicación está chamando eo que está facendo.
 Nós escribir o noso propio analizador estático binario para o noso código
 e facemos isto, e así o que podería facer é que podería dicir
 O dispositivo de facer calquera cousa que é, basicamente, me espionando ou me visite?
 E eu teño algúns exemplos aquí no iPhone.
 Este primeiro exemplo é como acceder o UUID no teléfono.
 Isto é realmente algo que Apple acaba proscrito a novas aplicacións,
 pero aplicacións antigos que pode ter en execución no seu teléfono aínda pode facelo,
 e de xeito que o identificador único pode ser usado para rastrexar vostede
 en moitas aplicacións diferentes.
 

O Android, teño un exemplo aquí de obter a localización do dispositivo.
 Podes ver que, se esa chamada API é alí que o app está seguindo,
 e pode ver se está quedando boa situación ou localización groseira.
 E, a continuación, na parte inferior aquí, eu teño un exemplo de como o BlackBerry
 unha aplicación pode acceder as mensaxes de correo electrónico na súa caixa de entrada.
 Estes son o tipo de cousas que pode inspeccionar a ver
 se a aplicación está a facer estas cousas.
 A segunda gran categoría de comportamento malicioso, e este é probablemente o máis grande de categoría, agora,
 é a cita non autorizado, non autorizado premio de mensaxes de texto SMS
 ou pagos non autorizados.
 Outra cousa que é único sobre o teléfono
 Se o seu dispositivo está conectado a unha conta de cobro,
 e cando as actividades se celebran no teléfono
 pode crear encargos.
 Podes mercar as cousas polo teléfono,
 e cando envía unha mensaxe de texto SMS Premium en realidade está dando cartos
 ao titular da conta do número de teléfono do outro lado.
 Estes foron creados para obter presupostos de accións ou conseguir o seu horóscopo diario ou outras cousas,
 pero poden ser configurados para solicitar un produto, enviando un SMS.
 A xente dan diñeiro para a Cruz Vermella a través do envío dunha mensaxe de texto.
 Pode dar 10 dólares dese xeito.
 

Os agresores, o que fixeron é eles montaron
 contas en países estranxeiros, e incorporar na malware
 que o teléfono pode enviar unha mensaxe de texto SMS Premium,
 dicir, algunhas veces ao día, e ao final do mes entender que pasou
 decenas ou quizais ata centos de dólares, e que a pé co diñeiro.
 Este quedou tan mal que esta foi a primeira cousa que Android
 Mercado ou Google lugar-se o mercado Android no momento,
 e agora é Google Play-o primeiro que Google comezou comprobando.
 Cando Google empezou a distribuír os apps Android na súa tenda de aplicacións
 eles dixeron que non estaban indo para comprobar a calquera cousa.
 Imos tirar aplicacións, xa que xa foi notificado que rompe nosos termos de servizo,
 pero nós non estamos indo para comprobar a calquera cousa. Así, hai un ano quedou tan mal con este malware mensaxe de texto SMS Premium
 que esta é a primeira cousa que eles comezaron a verificación de.
 Se unha aplicación pode enviar mensaxes de texto SMS
 que examinar máis que a aplicación manual.
 Eles miran para as APIs que chaman iso,
 e agora, desde entón, Google se expandir,
 pero esta foi a primeira cousa que eles comezaron a buscar.
 

Outros aplicacións que facían algunhas mensaxes de texto SMS,
 este Qicsomos Android, creo que se chama.
 Había un evento actual no móbil onde esta CarrierIQ saíu
 como spyware poñer no dispositivo polas operadoras,
 para que as persoas querían saber se o seu teléfono era vulnerable a iso,
 e este foi unha aplicación gratuita que probou iso.
 Ben, por suposto, o que fixo esta aplicación foi enviado mensaxes de texto SMS Premium,
 así, probando a ver se está infectado con spyware
 Cargou malware no seu dispositivo.
 Vimos o mesmo acontecer no último Super Bowl.
 Houbo unha versión falsa do partido de fútbol Madden
 que enviou mensaxes de texto SMS Premium.
 De feito, intentou crear unha rede bot tamén no teléfono.
 Aquí eu teño algúns exemplos.
 Curiosamente, a Apple foi moi intelixente,
 e eles non permiten que aplicacións para enviar mensaxes de texto SMS en todo.
 Ningunha aplicación pode facelo.
 Esta é unha gran forma de se librar de toda unha clase de vulnerabilidade,
 pero en Android podes facelo, e, por suposto, o BlackBerry, pode facelo tamén.
 É interesante que o BlackBerry todo o que precisa é de permisos de internet
 para enviar unha mensaxe de texto SMS.
 

A outra cousa realmente que nós buscamos
 cando estamos mirando a ver se algo está mal intencionado é calquera tipo de
 actividade de rede non autorizado, como ollar para a actividade de rede
 o app se quere ter que ter a súa función,
 e mirar para esta outra actividade da rede.
 Quizais unha aplicación, para funcionar, ten que obter datos sobre HTTP,
 pero se é facer as cousas por correo electrónico ou SMS ou Bluetooth ou algo así
 agora que o app podería ser potencialmente malicioso, polo que esta é outra cousa que pode inspeccionar.
 E neste foto aquí eu teño algúns exemplos diso.
 Outra cousa interesante que vimos con malware aconteceu en 2009,
 e pasou en gran forma.
 Eu non sei se isto aconteceu moito desde entón, pero era un app
 que personificou outra aplicación.
 Houbo unha serie de aplicacións, e foi alcumado ataque 09Droid,
 e alguén decidiu que había unha morea de pequenos bancos de medio porte, rexionais
 que non tiña aplicacións bancarias en liña,
 entón o que fixeron foi que eles construíron uns 50 aplicacións bancarias online
 que todo o que fixo foi levar o nome de usuario e contrasinal
 e redireccionándoos para o sitio.
 E así, eles puxeron todos estes por enriba en Google Marketplace,
 no mercado Android, e cando alguén buscou a ver se a súa base
 tiña unha aplicación que ía atopar a aplicación falso,
 que recadou súas credenciais e, entón, redirixido-os para o seu sitio.
 O xeito que iso realmente tornouse as aplicacións foron ata alí por algunhas semanas,
 e había miles e miles de descargas.
 

O xeito como isto veu á tona era alguén estaba tendo un problema
 cunha das aplicacións, e chamaron a súa base,
 e chamaron liña de atención ao cliente do banco e dixo:
 "Eu estou tendo un problema coa aplicación de mobile Banking".
 "Vostede me pode axudar?"
 E eles dixeron: "Nós non temos unha aplicación bancario móbil."
 Isto comezou a investigación.
 Este banco chamado Google e Google mirou e dixo:
 "Guau, o mesmo autor ten escrito 50 aplicacións de base", e os levou a todos para abaixo.
 Pero, certamente, isto pode ocorrer de novo.
 Aí está a lista de todos os distintos bancos aquí
 que formaron parte desta farsa.
 A outra cousa que unha aplicación pode facer é presentar a interface de usuario de outra aplicación.
 Mentres el está executando podería aparecer Facebook UI.
 Di que tes que poñer no seu nome de usuario e contrasinal para continuar
 ou poñer o nome de usuario e contrasinal da interface de usuario a un sitio web
 que quizais o usuario utiliza só para tratar de enganar o usuario
 en poñer as súas credenciais no
 Este é realmente un paralelo directo dos ataques de phishing correo-e
 onde alguén lle envía unha mensaxe de correo electrónico
 e dálle basicamente unha interface de usuario a un sitio falso
 que ten acceso.
 

A outra cousa que buscar en un código malicioso é a modificación do sistema.
 Podes ollar para todas as chamadas de API que requiren privilexios de root
 para realizar correctamente.
 Cambiar proxy web do dispositivo sería algo que unha aplicación
 non debe ser capaz de facer.
 Pero se a aplicación ten código alí para facelo
 vostede sabe que é, probablemente, unha aplicación malicioso
 ou altamente probable que sexa unha aplicación malicioso,
 e así o que sucedería é que a app tería algún tipo de escalada privilexio.
 Tería algún intercambio de privilexios explotar
 na aplicación, a continuación, unha vez que el escalou privilexios
 sería facer estas modificacións no sistema. Podes atopar malware que ten escalação de privilexios
 nel aínda sen saber como o intercambio de privilexios
 exploit que vai pasar, e iso é un xeito agradable, fácil
 para buscar malware.
 DroidDream foi, probablemente, a máis famosa peza de malware Android.
 Eu creo que afectou preto de 250 mil usuarios ao longo de varios días
 antes de ser atopado.
 Eles reembalado 50 aplicacións teitos,
 colocalos na tenda de aplicacións Android,
 e, esencialmente, ela usou o código jailbreak Android para escalar privilexios
 e, a continuación, instalar un mando e control e virar todas as vítimas
 nunha rede de bot, pero podería ter detectado este
 se fose a dixitalización da aplicación e só a buscar
 Chamadas de API que o permiso raíz necesarios para executar correctamente.
 

E hai un exemplo aquí teño que está cambiando o proxy,
 e este, en realidade, só está dispoñible en Android.
 Podes ver que eu estou te dando unha morea de exemplos sobre Android
 porque este é o lugar onde o ecosistema malware máis activo é
 porque é moi doado para un dianteiro para obter o código malicioso
 en Android Marketplace.
 Non é tan fácil de facer que na App Store de Apple
 porque Apple esixe que os desenvolvedores a identificar-se
 e asinar o código.
 Realmente comprobar quen é vostede, e Apple é realmente o exame das solicitudes.
 Non vemos unha morea de malware en si, onde o dispositivo está a ser comprometida.
 Vou falar sobre algúns exemplos onde é realmente de privacidade que está quedando comprometida,
 e iso é o que realmente está a suceder no dispositivo de Apple.
 Outra cousa é mirar para o código malicioso, código arriscado en dispositivos
 é lóxica ou tempo bombas e bombas de tempo son, probablemente,
 moito máis fácil do que buscar bombas lóxicas.
 Pero, con bombas de tempo, o que pode facer é que pode ollar
 lugares no código onde o tempo é probada ou un tempo absoluto é demandado
 antes de certas funcionalidades na aplicación pasa.
 E iso podería ser feito para ocultar que a actividade do usuario,
 polo que está a acontecer á noite.
 DroidDream fixo toda a súa actividade 11:00-08:00 hora local
 para tratar de facelo mentres o usuario non pode estar usando o seu dispositivo.
 

Outra razón para facelo é se a xente está a usar a análise do comportamento dunha aplicación,
 executar a aplicación nunha caixa de area a ver que o comportamento da aplicación,
 poden usar a lóxica baseada en tempo de facer a actividade
 cando a aplicación non está no cadro de area.
 Por exemplo, unha tenda de aplicacións como Apple
 executa a aplicación, pero eles probablemente non realizar todas as aplicacións para, digamos, 30 días
 antes de que o aproba, para que poida poñer
 lóxica na súa aplicación que dixo, todo ben, só facer o que é malo
 despois de 30 días se pasou ou despois de 30 días a partir da data de publicación da solicitude,
 e que pode axudar a ocultar o código malicioso de persoas que inspeccionan por iso.
 Se as empresas de antivirus están levando as cousas en caixas de area
 ou as propias tendas de aplicacións son isto pode axudar
 ocultar que a partir desa inspección.
 Agora, a outra cara da moeda é que é fácil de encontrar coa análise estática,
 por iso, en realidade, inspecionar o código que podes ollar para todas as partes
 onde a aplicación examina o tempo e inspeccionar así.
 E aquí eu teño algúns exemplos sobre estas tres plataformas diferentes
 como o tempo pode ser verificado polo fabricante aplicación
 para que vostede sabe o que buscar se está inspecionar a aplicación estaticamente.
 

Eu só pasei por unha morea de diferentes actividades maliciosas
 que vimos na natureza, pero cales son os máis prevalentes?
 Ese mesmo estudo da New York State móbil Proxecto Xenoma
 publicados algúns datos, e foron basicamente catro áreas
 que viron onde había unha gran cantidade de actividade.
 37% dos apps fixo escalação de privilexios,
 entón eles tiñan algún tipo de código de jailbreak alí
 onde tentaron escalar privilexios para que puidesen
 que comandos API rodando como sistema operativo.
 45% dos apps aí fixo SMS Premium,
 de xeito que é unha enorme porcentaxe que está intentando rendibilizar directamente.
 93% fixeron o mando a distancia, para que eles intentaron crear unha rede de bot, unha rede bot móbil.
 E o 45% collido información de identificación
 como números de teléfono, UUIDs, localización GPS, contas de usuario
 e isto engade-se a máis de 100, porque a maioría dos malware intenta facer algunhas destas cousas.
 

Vou pasar á segunda metade e falar sobre as vulnerabilidades de código.
 Esta é a segunda metade da actividade de risco.
 Este é o lugar onde esencialmente o creador está cometendo erros.
 Desenrolador lexítimo escribir unha aplicación lexítimo
 é cometer erros ou é ignorante sobre os riscos de que a plataforma móbil.
 Eles simplemente non saben como facer unha aplicación móbil seguro,
 ou, por veces, o creador non se preocupa en poñer o usuario en perigo.
 Ás veces, parte do seu modelo de negocio se pode
 collendo información persoal do usuario.
 Isto é unha especie de outra categoría, e é por iso que algunhas desas malicioso
 contra comeza a sangrar máis lexítimos porque non hai diferenza de opinións
 entre o que o usuario quere eo que o usuario considera arriscado
 eo que o creador da aplicación considera arriscado. Por suposto, non é de datos do creador da aplicación, na maioría dos casos.
 

E entón, finalmente, outra forma isto ocorre é un creador pode vincular en
 unha biblioteca compartida que ten vulnerabilidades ou este comportamento de risco en que
 sen o coñecemento deles.
 A primeira categoría é a filtración de datos sensibles,
 e iso é cando a aplicación recolle información
 como localización, información de libro de enderezos, información do propietario
 e manda que apagalo.
 E xa que está fóra do dispositivo, non sabemos o que está a suceder con esta información.
 Podería ser gardados de forma insegura polo creador da aplicación.
 Vimos os desenvolvedores de aplicacións comprometido,
 e os datos que están almacenando é levado.
 Iso aconteceu hai uns meses a un creador en Florida
 onde un gran número de-era UUIDs iPads e nomes de dispositivos
 baleiraron porque alguén, eu creo que era anónimo,
 presuntamente para facelo, invadiu os servidores deste creador
 e roubou millóns de iPad UUIDs
 e nomes de computadores.
 Non a información máis arriscado,
 pero o que se fose ese o almacenamento de nomes de usuario e contrasinais
 Enderezos residenciais?
 Hai moitas aplicacións que almacenan este tipo de información.
 O risco está aí.
 

A outra cousa que pode ocorrer é que o creador non coidar
 para protexer a canle de datos, e iso é outro gran vulnerabilidade vou falar,
 que os datos están sendo enviados en claro.
 Se o usuario está nunha rede Wi-Fi pública
 ou alguén está cheirando a internet nalgún lugar
 ao longo do percorrido que os datos están sendo expostos.
 Un moi famoso caso deste baleirado de información pasou con Pandora,
 e iso é algo que investigou no Veracode.
 Escoitamos que había unha-Eu creo que foi unha Comisión Federal de Comercio
 investigación a suceder con Pandora.
 Nós dixemos: "O que está a suceder alí? Imos comezar a cavar para a aplicación Pandora".
 E o que determinou foi a aplicación Pandora recollidas
 seu sexo ea súa idade,
 e tamén acceder á súa localización GPS ea aplicación Pandora
 fixo isto para que eles dixeron eran razóns lexítimas.
 A música que eles estaban xogándose Pandora é unha aplicación de streaming de música
 a música que eles estaban xogando só foi licenciado en Estados Unidos,
 entón eles tiñan que comprobar a cumprir os seus contratos de licenza que tiñan
 para a música que o usuario estaba nos Estados Unidos.
 Eles querían cumprir co parental Advisory
 en torno a linguaxe adulta na música,
 e por iso é un programa voluntario, pero eles querían cumprir esa
 e non xogar letras explícitas para nenos de 13 anos ou menos.
 

Tiñan razóns lexítimas para a obtención de datos.
 Seu programa tiña os permisos para facelo.
 Usuarios pensaba que iso era lexítimo. Pero o que pasou?
 Eles ligaron en 3 ou 4 bibliotecas de anuncios diferentes.
 Agora, de súpeto, todas estas bibliotecas de anuncios
 están tendo acceso a esta mesma información.
 As bibliotecas de anuncios, se ollar o código nas bibliotecas de anuncios
 o que fan é cada biblioteca anuncio di
 "Será que o meu programa ten permiso para obter a localización GPS?"
 "Oh, iso? Ben, me diga a localización GPS."
 Cada biblioteca anuncio só fai iso,
 e se a aplicación non ten permiso GPS
 non poderá obtelo, pero se isto acontecer, que vai busca-la.
 Este é o lugar onde o modelo de negocio das bibliotecas de anuncios
 oponse á privacidade do usuario.
 E houbo estudos alí fóra, que vai dicir se sabe a idade
 dunha persoa e sabe que a súa situación
 onde durmir á noite, porque ten as coordenadas GPS
 mentres eles están durmindo, quizais, vostede sabe exactamente quen é esa persoa
 porque pode determinar membro desta familia é esa persoa.
 Realmente esta é a identificación para anunciantes
 exactamente quen é vostede, e parece que era lexítimo.
 Eu só quero que o meu streaming de música, e esta é a única forma de obtelo.
 

Ben, nós expuxemos iso.
 Nós escribir isto en varios artigos,
 e descubriuse que alguén da revista Rolling Stone
 ler un dos nosos artigos e escribiu o seu propio blog na revista Rolling Stone sobre o tema,
 e ao día seguinte Pandora pensou que era unha boa idea
 para eliminar as bibliotecas de anuncios coa súa aplicación.
 Polo que eu sei que son o único, eles deben ser eloxiados.
 Eu creo que son o único tipo freemium de aplicación que teña feito isto.
 Todos os outros programas freemium ter ese mesmo comportamento,
 así que ten que pensar sobre o tipo de datos que está dando
 estas aplicacións freemium porque todo vai para os anunciantes.
 Praetorian tamén fixo un estudo sobre as bibliotecas compartidas e dixo:
 "Imos ver cales bibliotecas compartidas son as bibliotecas compartidas top", e iso foi os datos.
 

Eles analizaron 53 mil apps,
 ea biblioteca compartida número 1 foi AdMob.
 De feito, foi en 38% das aplicacións aí fóra,
 así 38% das aplicacións que está a usar
 probablemente están collendo a súa información persoal
 e enviá-lo para as redes de anuncios. Apache e Android foron de 8% e 6%,
 e logo, estes outros, na parte inferior, Google Ads, Flurry,
 Mob City e Millennial Media,
 estas son as empresas de publicidade, e despois, curiosamente,
 4% ligados na biblioteca Facebook
 probabelmente para facer a identificación a través de Facebook
 de xeito que a aplicación podería rexistrarse Facebook.
 Pero iso tamén significa que a corporación Facebook controla código
 que está a ser executado en un 4% das aplicacións móbiles Android aí,
 e eles teñen acceso a todos os datos que este programa ten permiso para chegar.
 Facebook esencialmente intenta vender espazo publicitario.
 Ese é o seu modelo de negocio.
 

Se ollar para todo este ecosistema con os permisos
 e bibliotecas compartidas, comeza a ver que
 ten unha morea de risco nunha aplicación, supostamente lexítima.
 A mesma cousa semellante que pasou con Pandora
 aconteceu con un programa chamado Path,
 e Camiño pensaron que estaban a ser útiles, desenvolvedores amigables.
 Eles estaban só tentando darlle unha gran experiencia do usuario,
 e descubriuse que sen avisar o usuario ou dicir calquera cousa que o usuario-
 e aconteceu no iPhone e en Android,
 a aplicación Pandora foi o iPhone e Android-
 que a aplicación Path foi coller o seu libro de enderezos enteiro
 e envialo ao camiño só cando instalou e executou a aplicación,
 e non falar sobre iso.
 Eles pensaron que era realmente útil para ti
 para poder compartir con todas as persoas na súa lista de enderezos
 que está a usar a aplicación Path.
 

Ben, obviamente Camiño pensaba que iso era óptimo para a súa empresa.
 Non tan grande para o usuario.
 Ten que pensar que é unha cousa que se cadra un adolescente
 está a usar esta aplicación e as súas decenas de amigos están alí,
 pero o que si é o CEO dunha empresa que instala Path
 e despois, de súpeto, o seu libro de enderezos enteiro está aí enriba?
 Vai ter un monte de información de contacto potencialmente valiosa
 para unha morea de xente.
 Un reporteiro do New York Times, que pode ser capaz de obter o seu número de teléfono
 para expresidentes do seu libro de enderezos,
 entón, obviamente, unha gran cantidade de información sigilosas é trasladado con algo parecido a isto.
 Houbo unha gran pestana tal sobre iso que camiño desculpouse.
 Cambiaron a súa aplicación, e aínda impactado Apple.
 Apple dixo, "Estamos indo para forzar os provedores de aplicacións para solicitar aos usuarios
 se eles están indo a recoller todo o seu catálogo de enderezos. "
 

Parece que o que está pasando aquí é
 cando hai unha gran violación de privacidade e iso fai a prensa
 vemos un cambio alí fora.
 Pero, claro, hai outras cousas por aí.
 A aplicación LinkedIn colle súas entradas de calendario,
 pero Apple non fai o usuario será solicitada a este respecto.
 As entradas de calendario pode ter información confidencial neles tamén.
 Onde é que vai debuxar a liña?
 Isto realmente é unha especie de lugar evolucionando
 onde non hai realmente ningunha boa calidade por aí
 para os usuarios a entender cando a súa información vai estar en perigo
 e cando eles van saber que está a ser tomada.
 Nós escribir unha aplicación Veracode chamado Adios,
 e, esencialmente, que lle permitiu apuntar a aplicación no seu directorio de iTunes
 e ollar para todas as aplicacións que foron collendo o seu libro de enderezo completo.
 E como podes ver nesta lista aquí, Angry Birds,
 AIM, AroundMe.
 Por que Angry Birds precisa do seu libro de enderezos?
 Eu non sei, pero de algunha maneira.
 

Isto é algo que moitos, moitos programas fan.
 Pode inspeccionar o código para iso.
 Hai APIs ben definidas para iPhone, Android e BlackBerry
 para chegar ao libro de enderezos.
 Pode moi facilmente inspeccionar para iso, e iso é o que nós fixemos na nosa aplicación Adios.
 A seguinte categoría, inseguro de almacenamento de datos sensibles,
 é algo que os desenvolvedores tomar algo como un alfinete ou un número de conta
 ou un contrasinal e garde-a en claro no dispositivo.
 Aínda peor, poden almacena-lo nunha área no teléfono
 que é globalmente accesible, como a tarxeta SD.
 Ve iso con máis frecuencia en Android porque Android permite a unha tarxeta SD.
 Dispositivos iPhone non.
 Pero aínda vimos isto acontecer nunha aplicación Citigroup.
 A súa aplicación bancaria en liña gardados os números de conta de forma insegura,
 só en claro, entón se perde o seu dispositivo,
 esencialmente perdeu a súa conta bancaria.
 É por iso que eu, persoalmente, non facer banca no meu iPhone.
 Creo que é moi arriscado no momento de facer estes tipos de actividades.
 

Skype fixo o mesmo.
 Skype, por suposto, ten un saldo de conta, nome de usuario e contrasinal
 que poida acceder a este equilibrio.
 Estaban almacenando toda a información en claro no teléfono móbil.
 Teño algúns exemplos aquí de crear arquivos
 que non teñen os permisos axeitadas ou gravando nun disco
 e non ter ningún cifrado ocorrer para iso.
 Esta próxima zona, inseguro de transmisión de datos sensibles,
 Eu xa aludiu a iso algunhas veces, e por mor do público WiFi
 iso é algo que as aplicacións absolutamente que facer,
 e este é, probablemente, o que vemos errar máis. Eu diría-de feito, eu creo que eu teño os datos reais,
 pero é preto de metade das aplicacións móbiles
 romper facendo SSL.
 Eles simplemente non usar as APIs correctamente.
 É dicir, todo o que tes que facer é seguir as instrucións e utilizar as APIs,
 pero cousas como non comprobar se existe un certificado válido, no outro extremo,
 non comprobar se o outro extremo está a tratar de facer un ataque protocolo descenso.
 

Os desenvolvedores, queren obter a súa opción, non?
 A súa esixencia é a de usar isto para vender. Utilizaban tanto para vender.
 A demanda non é usar isto para vender con seguridade,
 e así é por iso que todas as aplicacións que utilizan o SSL para protexer datos
 como está a ser transmitida apagalo realmente precisan ser inspeccionadas
 estar seguro de que foi aplicado correctamente.
 E aquí eu teño algúns exemplos onde se pode ver unha aplicación
 pode estar usando HTTP en vez de HTTP.
 Nalgúns casos, aplicacións vai caer de volta para HTTP
 O HTTPS non está funcionando.
 Teño outra chamada aquí en Android onde desactivado a verificación dos certificados,
 así un ataque man-in-the-middle pode ocorrer.
 Un certificado válido será aceptado.
 Estes son todos os casos en que os atacantes van ser capaces de obter en
 a mesma conexión Wi-Fi como o usuario e acceso de todos os datos
 que está a ser enviada a través de internet.
 

E, finalmente, a última categoría que eu teño aquí é o contrasinal e claves codificado.
 Nós realmente ver unha chea de desarrolladores utilizar o mesmo estilo de codificación
 que fixeron cando estaban construíndo aplicacións de servidor web,
 así eles están construíndo unha aplicación de servidor Java, e están codificar a clave.
 Ben, cando está a construír unha aplicación de servidor, si,
 codificar a clave non é unha boa idea.
 Faise difícil de cambiar.
 Pero non é tan malo no lado do servidor, porque quen ten acceso ao lado do servidor?
 Só os administradores.
 Pero se tomar o mesmo código e derramou-o para unha aplicación móbil
 agora todo o mundo que ten ese aplicación móbil ten acceso a esa chave codificada,
 e realmente vemos iso unha morea de veces, e eu teño algunhas estatísticas
 de cantas veces vemos isto acontecer.
 El realmente estaba no código de exemplo que a MasterCard publicado
 sobre como usar o seu servizo.
 O código de exemplo amosa como é que coller o contrasinal
 e poñelas nunha secuencia codificada alí mesmo,
 e sabemos como os desenvolvedores quere copiar e pegar fragmentos de código
 cando eles están tentando facer algo, para que copie e pegue o fragmento de código
 que deu como exemplo de código, e ten unha aplicación inseguro.
 

E aquí temos algúns exemplos.
 Este primeiro é que podemos ver unha chea onde se codificar
 o dereito de datos en unha URL que é enviado.
 Ás veces vemos cadea password = o contrasinal.
 Iso é moi fácil de detectar, ou cadea contrasinal no BlackBerry e Android.
 É realmente moi fácil para comprobar a porque case sempre
 os nomes de desenvolvedores a variable que está sostendo o contrasinal
 algunha variación de contrasinal.
 Eu mencionar que nós facemos a análise estática en Veracode,
 polo que temos analizado varios centos de aplicacións Android e IOS.
 Nós construímos modelos cheo deles, e nós somos capaces de dixitalizar-los
 para diferentes vulnerabilidades, sobre as vulnerabilidades que eu estaba falando,
 e eu teño algúns datos aquí.
 68,5% das aplicacións Android que nós miramos
 tiña roto código criptográfico,
 que, para nós, non podemos detectar se fixo a súa propia rutina de cifrado,
 non que iso sexa unha boa idea, pero iso está realmente usando as APIs publicadas
 que están sobre a plataforma, pero facendo-as de tal xeito
 que o cifrado sería vulnerábel, 68,5.
 E iso é para as persoas que están enviando-nos as súas aplicacións, porque en realidade
 eles pensan que é unha boa idea para facer probas de seguridade.
 Estes xa son persoas que probablemente están a pensar en seguridade,
 por iso é probablemente aínda peor.
 

Eu non falar de control de liña de inxección de alimentación.
 É que comprobar se hai algo, pero non é tan arriscado un problema.
 Baleirado de información, este é o lugar onde os datos confidenciais están sendo enviadas fóra do dispositivo.
 Descubrimos que o 40% das solicitudes.
 Tempo e Estado, estas son cuestións tipo de condición de carreira, normalmente moi difíciles de explotar,
 entón eu non falar sobre iso, pero miramos para el.
 23% tiveron problemas de inxección SQL.
 Moitas persoas non saben que unha morea de aplicacións
 use un pequeno banco de datos SQL pouco no seu back-end para almacenar datos.
 Ben, se os datos que está agarrando na rede
 ten cordas de ataque de inxección SQL nel
 alguén pode comprometer o dispositivo a través diso,
 e entón eu creo que atopamos uns 40% das aplicacións web ten este problema,
 que é un problema enorme epidemia.
 Podemos atopalo 23% do tempo en aplicacións móbiles
 e iso pode ser porque moitas outras aplicacións web empregan SQL do móbil.
 

E despois aínda vemos algúns cross-site scripting, as cuestións de autorización,
 e xestión de credenciais, que é onde ten o seu contrasinal codificado.
 O 5% das solicitudes que ver iso.
 E entón temos algúns datos sobre IOS.
 81% tiveron problemas de tratamento de erros. Este é un problema de calidade de código,
 pero o 67% tiveron problemas de cifrado, polo que non é tan malo como Android.
 Quizais as APIs son un pouco máis fácil, os códigos de exemplo un pouco mellor en iOS.
 Pero aínda unha porcentaxe moi elevada.
 Tivemos 54% co baleirado de información,
 preto de 30% con erros de xestión buffer.
 É lugares onde non podería ser un problema de corrupción de memoria.
 Acontece que isto non é tanto un problema para a explotación
 en iOS, porque todo o código debe ser asinado,
 por iso é difícil para un invasor executar un código arbitrario en iOS.
 Calidade de código, paso de directorio, pero despois credenciais xestión aquí en 14,6%,
 tan peor que en Android.
 Temos xente non xestionar contrasinais correctamente.
 E, a continuación, os erros numéricos e buffer overflow,
 quen son máis vai haber problemas de calidade de código en iOS.
 

Que foi a miña presentación. Eu non sei se estamos sen tempo ou non.
 Non sei se hai algunha dúbida.
 [Feminino] Unha pregunta rápida arredor da fragmentación e do mercado de Android.
 Apple, polo menos, é propietario de corrección.
 Eles fan un bo traballo de comeza-lo alí fóra, mentres menos así, no espazo Android.
 Vostede case ten desbloquear o teléfono para manterse actualizado
 coa versión actual de Android.
 Si, iso é un problema enorme e por iso, se pensar sobre-
 [Feminino] Por que non pode repetir?
 

Ah, ben, entón a pregunta é o que pasa coa fragmentación
 do sistema operativo na plataforma Android?
 Como iso afecta o grao de risco destes dispositivos?
 E iso realmente é un problema enorme, xa que o que pasa é
 os dispositivos máis antigos, cando alguén xorde cun jailbreak para este dispositivo,
 esencialmente iso é escalação de privilexios, e ata que o sistema operativo está actualizado
 calquera malware pode, entón, usar esta vulnerabilidade para comprometer totalmente o dispositivo,
 E o que estamos a ver en Android é a fin de obter un novo sistema operativo
 Google ten que apagar o sistema operativo e, a continuación, o fabricante do hardware
 ten que personalizar-lo, e, a continuación, o transportista ten a personalizar-lo e entrega-lo.
 Ten basicamente tres partes móbiles aquí,
 e está xirando para fóra para que os transportistas non me importa,
 e os fabricantes de hardware non lles importa, e Google non está estimulando-as abondo
 para facer calquera cousa, polo que, esencialmente máis da metade dos dispositivos aí
 teñen sistemas operativos que teñen esas vulnerabilidades de escalonamento de privilexios neles,
 e por iso, se ten malware no seu teléfono Android é moito máis dun problema.
 

Vale, moitas grazas.
 [Aplausos]
 [CS50.TV]