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