>> [Seminario] [Defendiendo Detrás del dispositivo: Application Security Mobile]
[Chris Wysopal] [Universidad de Harvard]
[Este es CS50.] [CS50.TV]
>> Buenas tardes. Mi nombre es Chris Wysopal.
Soy el director de tecnología y cofundador de Veracode.
Veracode es una empresa de seguridad de la aplicación.
Probamos todo tipo de aplicaciones diferentes,
y lo que voy a hablar hoy es la seguridad de aplicaciones móviles.
Mi experiencia es que he estado haciendo la investigación sobre seguridad
durante mucho tiempo, probablemente casi tan largo como el que más.
Empecé a mediados de los años 90,
y fue un tiempo en que era bastante interesante porque
tuvimos un cambio de paradigma en los mediados de los años 90.
Todo el equipo de un todo repentino estaba conectado a Internet,
y luego tuvimos el inicio de las aplicaciones web,
y eso es lo que me he centrado en mucho entonces.
Es interesante.
Ahora tenemos un nuevo cambio de paradigma pasando con la informática,
que es el cambio a las aplicaciones móviles.
>> Siento que es una especie de tiempo similar y luego fue a finales de los años 90
cuando estábamos investigando las aplicaciones web y la búsqueda de defectos como
errores de administración de sesiones y de inyección SQL
que en realidad no existía antes, y, de repente, estaban por todas partes
en las aplicaciones web, y ahora una gran parte del tiempo que paso
está mirando a las aplicaciones móviles y mirando a lo que está pasando ahí fuera en el salvaje.
Las aplicaciones móviles son realmente va a ser la plataforma informática dominante,
por lo que realmente tenemos que gastar un montón de tiempo si usted está en la industria de la seguridad
centrándose en las aplicaciones web.
Hubo 29 mil millones de aplicaciones móviles descargados en 2011.
Se prevé que ser de 76 mil millones de aplicaciones para el año 2014.
Hay 686 millones de dispositivos que se van a comprar este año,
por lo que este es el lugar donde la gente va a estar haciendo
la mayor parte de su informática de cliente en el futuro.
>> Yo estaba hablando con un vicepresidente de Fidelity Investments
Hace un par de meses, y me dijo que acaban de ver más tráfico
hacer transacciones financieras desde su base de clientes
en su aplicación móvil que en su página web,
por lo que un uso común de la Web en el pasado ha sido
la comprobación de sus cotizaciones de acciones, la gestión de su cartera,
y que en realidad estamos viendo que en 2012 más de interruptor
a ser más dominante en la plataforma móvil.
Ciertamente, si no va a haber ninguna actividad criminal,
cualquier actividad maliciosa, que va a empezar a centrarse en la plataforma móvil
con el tiempo como la gente cambia a eso.
Si nos fijamos en la plataforma móvil,
mirar a los riesgos de la plataforma es útil para desglosarlo en las diferentes capas,
al igual que lo haría en una computadora de escritorio,
y se piensa en las diferentes capas, software, sistema operativo,
capa de red, capa de hardware, y por supuesto, hay vulnerabilidades en todas esas capas.
>> Lo mismo sucede en el móvil.
Pero el móvil, parece que algunas de esas capas están en peor situación.
Por un lado, la capa de red es más problemática en el móvil
porque mucha gente tiene en su oficina o en casa
cableado o las conexiones que tienen conexiones seguras Wi-Fi,
y con una gran cantidad de dispositivos móviles que está, obviamente fuera de la casa
o fuera de la oficina mucho y si estás usando Wi-Fi no
se podría estar usando una conexión Wi-Fi insegura,
algo que es un público de conexión Wi-Fi gratuita,
así que cuando pensamos en aplicaciones móviles que tenemos que tener en cuenta
que el entorno de red es más riesgoso para las aplicaciones
cuando se está utilizando Wi-Fi.
Y cuando me meto en varios de los riesgos de aplicaciones móviles
verás por qué eso es más importante.
Existen riesgos a nivel de hardware en los dispositivos móviles.
Esta es un área de investigación en curso.
La gente llama a estos ataques de banda ancha o ataques de banda base
donde se está atacando el firmware que está escuchando en la radio.
>> Estos son realmente ataques de miedo porque
el usuario no tiene que hacer nada.
Usted puede golpear un montón de dispositivos dentro de la gama de RF
a la vez, y parece que cada vez que esta investigación se propaga hacia arriba
rápidamente se clasifica en el
gente sola vez en la vuelta y decir: "Aquí, nos dicen acerca de eso, y por favor dejen de hablar de ello."
Hay un poco de investigación en curso en el área de la banda ancha,
pero parece ser hush hush muy.
Creo que es más de un tipo de Estado-nación de la investigación que está pasando.
Un área de investigación activa, sin embargo, es la capa del sistema operativo,
y de nuevo, esto es diferente que en el mundo de la computación de escritorio
porque en el espacio móvil tiene estos equipos de personas llamados jailbreakers,
y jailbreakers son diferentes que los investigadores de vulnerabilidades regulares.
Están tratando de encontrar vulnerabilidades en el sistema operativo,
pero la razón por la que están tratando de encontrar las vulnerabilidades no es
entrar en la máquina de otra persona y comprometerlo.
Es entrar en su propio ordenador.
>> Quieren entrar en su propio móvil, modificar el sistema operativo de su propio móvil
para que puedan ejecutar las aplicaciones de su elección
y cambiar las cosas con los permisos administrativos,
y ellos no quieren decirle al vendedor acerca de esto.
No son como un investigador de seguridad que es un investigador de seguridad sombrero blanco
que se va a hacer de una fuente responsable y decirle al vendedor al respecto.
Ellos quieren hacer esta investigación, y que quieren publicar en realidad
en una explotación o un rootkit o un código de fuga de la cárcel,
y quieren hacerlo estratégicamente como justo después del
las naves de proveedores del nuevo sistema operativo.
Usted tiene esta relación de confrontación
con vulnerabilidades a nivel de sistema operativo en el móvil,
que creo que es bastante interesante, y un lugar al que veo
se lo hace para que haya un buen código publicado explotar por ahí
en busca de vulnerabilidades a nivel de kernel,
y hemos visto los realmente ser utilizado por los creadores de malware.
Es un poco diferente que el mundo del PC.
Y a continuación, la capa final es la capa superior, la capa de aplicación.
Eso es lo que voy a hablar hoy.
>> Existen las otras capas, y las otras capas desempeñan en él,
pero yo estoy en su mayoría va a hablar acerca de lo que está pasando en la capa de aplicación
donde el código se ejecuta en el entorno limitado.
No tiene privilegios administrativos.
Se tiene que utilizar las API del dispositivo,
pero aún así, una gran cantidad de actividades maliciosas y una gran cantidad de riesgo pueden ocurrir en esa capa
porque esa es la capa donde toda la información está.
Las aplicaciones pueden acceder a toda la información en el dispositivo
si tienen los permisos adecuados,
y pueden acceder a los diferentes sensores en el dispositivo,
Sensor GPS, micrófono, cámara, lo que usted tiene.
A pesar de que sólo estamos hablando de la capa de aplicación
tenemos una gran cantidad de riesgo allí.
La otra cosa que es diferente en el entorno móvil
es que todos los jugadores del sistema operativo, ya sea BlackBerry o Android
o iOS o Windows Mobile, todos ellos tienen un modelo de permisos de grano fino,
y esta es una de las formas en que construyen en el sistema operativo
la idea de que no es tan arriesgado como parece.
A pesar de que tiene todos sus contactos en allí, toda su información personal,
usted tiene sus fotos, usted tiene su ubicación en allí,
usted está almacenando su pin bancaria para inicio de sesión automático de la existencia, es seguro porque
aplicaciones tienen que tener ciertos permisos para llegar a ciertas partes
de la información en el dispositivo, y el usuario tiene que ser presentada con
estos permisos y dicen bien.
>> El problema con esto es que el usuario siempre dice bien.
Como una persona de seguridad, sé que usted puede solicitar al usuario,
decir algo muy malo va a pasar, es lo que quieres que suceda?
Y si están en un apuro o hay algo realmente atractivo en el otro lado de eso,
como un juego se va a instalar que han estado esperando,
que van a hacer clic bien.
Es por eso que digo en mi diapositiva aquí sólo quiero lanzar pájaros a los cerdos ya,
y se puede ver en la diapositiva aquí hay ejemplos de una caja permiso BlackBerry.
Dice: "Por favor, establece los permisos de la aplicación BlackBerry Travel
después de hacer clic en el botón de abajo ", y, básicamente, el usuario es sólo va a decir
establecer los permisos y ahorrar.
He aquí un símbolo del Android en el que muestra las cosas,
y que en realidad pone algo que casi parece una advertencia.
Tiene una especie de señal de ceder allí diciendo comunicación de red, llamada de teléfono,
pero el usuario se va a instalar, haga clic en, ¿verdad?
Y entonces el de Apple es completamente inocuo.
No da ningún tipo de advertencia.
Es sólo de Apple le gustaría utilizar su ubicación actual.
Por supuesto que vas a hacer clic bien.
>> No es este modelo de permisos de grano fino,
y las aplicaciones tienen que tener un archivo de manifiesto en el que declaran
los permisos que necesitan, y que conseguirán que se muestra al usuario,
y el usuario tendrá que decir que me concedo estos permisos.
Pero seamos honestos.
Los usuarios son sólo va a decir siempre bien.
Echemos un rápido vistazo a los permisos que estas aplicaciones están pidiendo
y algunos de los permisos que están allí.
Esta empresa pretoriana hizo una encuesta del año pasado
de 53.000 aplicaciones analizadas en los mercados del mercado y de 3 ª parte para Android,
así que esto es todo Android.
Y la aplicación promedio pidió 3 permisos.
Algunas aplicaciones solicitaron 117 permisos,
por lo que, obviamente, estos son de grano muy fino y demasiado complejo para un usuario a entender
si se les presentan con esta aplicación que necesita estos 117 permisos.
Es como el acuerdo de licencia de usuario final que es 45 páginas de largo.
Tal vez pronto tendrán una opción donde se siente
imprimir los permisos y enviarme un correo electrónico.
>> Pero si nos fijamos en algunos de los mejores permisos interesantes
24% de las aplicaciones que se descargan de la 53000
la información del GPS solicitado desde el dispositivo.
8% lee los contactos.
4% envió de SMS, y 3% de SMS recibido.
2% el audio grabado.
1% procesa las llamadas salientes.
No se.
No creo que el 4% de las aplicaciones disponibles en la tienda de aplicaciones realmente necesita para enviar mensajes de texto SMS,
así que creo que eso es un indicio de que algo malo está pasando.
8% de las aplicaciones necesita leer su lista de contactos.
Probablemente no sea necesario.
Otra de las cosas interesantes acerca de los permisos es
si enlaza en las bibliotecas compartidas en su aplicación
los heredan los permisos de la aplicación,
así que si su aplicación necesita la lista de contactos o necesita la ubicación GPS para funcionar
y vincular en una biblioteca de la publicidad, por ejemplo,
que biblioteca anuncio también será capaz de acceder a los contactos
y también ser capaz de acceder a la ubicación del GPS,
y el desarrollador de la aplicación no sabe nada sobre el código que se está ejecutando en la biblioteca anuncio.
Sólo están vinculación que porque quieren obtener beneficios económicos de su aplicación.
>> Aquí es donde-y voy a hablar de algunos ejemplos de esto con
una aplicación llamada Pandora, donde un desarrollador de aplicaciones
podría ser, sin saberlo, la filtración de información
de sus usuarios debido a las bibliotecas que han vinculadas pulg
Topografía del paisaje por ahí, mirando todas las diferentes aplicaciones
que se han reportado en las noticias como algo que los usuarios malintencionados o hacer que no querían
y después de inspeccionar una gran cantidad de aplicaciones-que hacemos un montón de análisis binario estático en aplicaciones móviles,
por lo que los hemos inspeccionado y miramos el código en sí mismo-
se nos ocurrió lo que llamamos nuestra lista de los 10 comportamientos de riesgo en las aplicaciones.
Y se divide en 2 secciones, el código malicioso,
así que estas son las cosas malas que las aplicaciones podrían estar haciendo que
es probable que sea algo que un individuo malintencionado
ha puesto específicamente en la aplicación, pero es un poco difusa.
Podría ser algo que un desarrollador piensa está bien,
pero termina siendo considerado como malicioso por el usuario.
>> Y luego la segunda sección es lo que llamamos las vulnerabilidades de codificación,
y estas son las cosas que el desarrollador básicamente está cometiendo errores
o simplemente no entiende cómo escribir de forma segura la aplicación,
y eso es poner el usuario de la aplicación en riesgo.
Voy a ir a través de estos puntos en detalle y dar algunos ejemplos.
Como referencia, yo quería poner la lista móvil top 10 de OWASP.
Estos son los 10 temas que un grupo de la OWASP,
Proyecto Abrir Web Application Security, que tiene un grupo de trabajo
trabajando en una lista de los 10 móvil.
Tienen una muy famosa lista superior de la tela 10, que son los 10 primeros
las cosas más arriesgadas que pueden tener en una aplicación web.
Están haciendo lo mismo para móviles,
y su lista es un poco diferente a la nuestra.
6 de la 10 son el mismo.
Tienen 4 que son diferentes.
Creo que tienen un poco de una opinión diferente sobre
riesgo en aplicaciones móviles donde muchos de sus temas
son realmente la forma en la aplicación se comunica con un servidor back-end
o lo que está pasando en el servidor back-end,
no tanto las aplicaciones que tienen conductas de riesgo que son aplicaciones cliente simplemente sencillo.
>> Los que están en rojo aquí son las diferencias entre las 2 listas.
Y parte de mi equipo de investigación ha contribuido realmente a este proyecto,
así que ya veremos qué pasa con el tiempo, pero creo que la comida para llevar aquí es
nosotros no sabemos realmente lo que la lista de los 10 está en las aplicaciones móviles, ya
realmente han estado solamente alrededor de 2 a 3 años,
y no ha habido tiempo suficiente para investigar realmente los sistemas operativos
y lo que son capaces de, y no ha habido tiempo suficiente
para la comunidad malicioso, si se quiere, que ha pasado suficiente tiempo
tratar de atacar a los usuarios a través de aplicaciones móviles, por lo que espero que estas listas cambian un poco.
Pero por ahora, estos son los 10 mejores cosas de qué preocuparse.
Usted podría preguntarse por el lado móvil, donde hace el código móvil malicioso
cómo llega al dispositivo?
North Carolina State tiene un proyecto llamado Proyecto Genoma Mobile malware
donde se están recogiendo la mayor cantidad de malware móvil como pueden y su análisis,
y han derribado los vectores de inyección que utiliza el malware para móviles,
y el 86% utiliza una técnica llamada reenvasado,
y esto es sólo en la plataforma Android
Puede usted realmente hacer esto reenvasado.
>> La razón es el código de Android está construido con
un código de bytes de Java llamada Dalvik que es fácilmente decompilable.
Lo que el malo de la película puede hacer es
tener una aplicación para Android, descompilarlo,
insertar su código malicioso, recompilar,
y luego lo puso en la App Store que pretende ser una nueva versión de dicha aplicación,
o sólo tal vez cambiar el nombre de la aplicación.
Si se trataba de una especie de juego, cambiar el nombre un poco,
por lo que este reenvasado es como el 86% del malware móvil se distribuye.
Hay otra actualización técnica llamada que está
muy similar al reenvasado, pero en realidad no pone el código malicioso pulg
Lo que hace es poner en un pequeño mecanismo de actualización.
Usted descompilar, usted pone en un mecanismo de actualización, y vuelva a compilar ella,
y luego, cuando la aplicación se está ejecutando, se baja el software malicioso en el dispositivo.
>> La gran mayoría son esas 2 técnicas.
En realidad no hay mucho de descarga drive-bys o descargas drive-by en los móviles,
lo que podría ser como un ataque de phishing.
Oye, echa un vistazo a este sitio realmente genial,
o tienes que ir a este sitio web y rellenar este formulario
para mantener constante haciendo algo.
Esos son los ataques de phishing.
Lo mismo puede suceder en la plataforma móvil donde
apuntar a una aplicación móvil para descargar, decir "Hola, esto es Bank of America."
"Vemos que está utilizando esta aplicación."
"Usted debe descargar esta otra aplicación."
En teoría, eso podría funcionar.
Es posible que simplemente no se utiliza lo suficiente como para determinar si es correcta o no,
pero se encontraron con que se utiliza menos de 1% del tiempo que la técnica.
La mayoría de las veces es realmente un código de reenvasado.
>> Hay otra categoría llamada independiente
donde alguien construye una aplicación nueva.
Construyen una aplicación que pretende ser algo.
No es un nuevo envoltorio de otra cosa, y que tiene el código malicioso.
Que se utiliza el 14% del tiempo.
Ahora quiero hablar de lo que está haciendo el código malicioso?
Uno de los primeros malware que hay
usted podría considerar un spyware.
Básicamente espía al usuario.
Recoge correos electrónicos, mensajes SMS.
Se enciende el micrófono.
Recopila la libreta de contactos, y lo envía a otra persona.
Este tipo de software espía existente en el PC,
así que tiene sentido perfecto para las personas que tratan de hacer esto en los dispositivos móviles.
>> Uno de los primeros ejemplos de esto fue un programa llamado Secret SMS replicador.
Fue en el mercado Android hace un par de años,
y la idea era si tenía acceso a teléfono Android de alguien
que quería espiar a, por lo que tal vez es su cónyuge
o su pareja y quiere espiar a sus mensajes de texto,
usted puede descargar esta aplicación e instalarla y configurarla
para enviar un mensaje de texto SMS a usted con una copia
de cada mensaje de texto SMS que consiguieron.
Esto, obviamente, está en violaciónes de los términos tienda de aplicaciones de servicio,
y esto fue retirado de la del mercado androide plazo de 18 horas de que esté allí,
por lo que un número muy pequeño de personas que estaban en situación de riesgo a causa de esto.
Ahora, creo que si el programa se llamaba algo tal vez un poco menos provocativa
como Secret SMS replicador probablemente habría funcionado mucho mejor.
Pero era un poco obvio.
>> Una de las cosas que podemos hacer para determinar si las aplicaciones tienen este comportamiento que no queremos
es inspeccionar el código.
Esto es realmente muy fácil de hacer en Android, ya que podemos descomponer las aplicaciones.
En iOS puede usar un desensamblador, como IDA Pro
mirar lo que las API de la aplicación está llamando y lo que está haciendo.
Escribimos nuestro propio analizador estático binario para nuestro código
y lo hacemos, y así lo que podría hacer es que se puede decir
¿el dispositivo de hacer todo lo que está básicamente espiando a mí o me seguimiento?
Y tengo algunos ejemplos aquí en el iPhone.
Este primer ejemplo es cómo acceder a la UUID en el teléfono.
Esto es realmente algo que Apple acaba de prohibir para nuevas aplicaciones,
pero las aplicaciones antiguas que usted puede ser que se estén ejecutando en el teléfono aún se puede hacer esto,
y de manera que el identificador único puede ser usado para rastrear usted
en muchas aplicaciones diferentes.
>> En el Android, tengo aquí un ejemplo de obtener la ubicación del dispositivo.
Se puede ver que si esa llamada a la API es allí donde la aplicación es el seguimiento,
y se puede ver si se trata de obtener la ubicación para bien o ubicación gruesa.
Y luego en la parte inferior aquí, tengo un ejemplo de cómo en el BlackBerry
una aplicación puede acceder a los mensajes de correo electrónico en su bandeja de entrada.
Estos son el tipo de cosas que usted puede inspeccionar para ver
si la aplicación está haciendo esas cosas.
La segunda gran categoría de comportamiento malicioso, y esto es probablemente la categoría más grande ahora,
es la marcación no autorizada, los mensajes de texto SMS premium no autorizada
o pagos no autorizados.
Otra cosa que es único sobre el teléfono
está el dispositivo está conectado a una cuenta de facturación,
y cuando las actividades ocurren en el teléfono
puede crear cargos.
Usted puede comprar las cosas a través del teléfono,
y cuando se envía un mensaje de texto SMS premium en realidad estás dando dinero
al titular de la cuenta del número de teléfono en el otro lado.
Estos fueron creados para obtener cotizaciones de bolsa o de obtener su horóscopo diario o de otras cosas,
pero pueden ser configurados para pedir un producto mediante el envío de un SMS de texto.
La gente da dinero a la Cruz Roja mediante el envío de un mensaje de texto.
Usted puede dar $ 10 de esa manera.
>> Los agresores, lo que han hecho es que crearon
cuentas en el extranjero, y se incrustan en el malware
que el teléfono enviará un mensaje de texto SMS premium,
por ejemplo, un par de veces al día, y al final del mes te das cuenta de que has gastado
decenas o tal vez incluso cientos de dólares, y se alejan con el dinero.
Esto llegó a tal punto que ésta era la primera cosa que el Android
Del mercado o del lugar-que Google fue el mercado de Android en el momento,
y ahora es Google Play-lo primero que Google comenzó comprobando.
Cuando Google comenzó a distribuir las apps Android en su tienda de aplicaciones
me dijeron que no iban a revisar cualquier cosa.
Sacaremos las aplicaciones una vez que hemos sido notificados que han roto nuestros términos de servicio,
pero nosotros no vamos a revisar cualquier cosa.
Bueno, hace aproximadamente un año se puso tan mal con este SMS premium mensaje de texto de malware
que esta es la primera cosa que empezaron comprobando.
Si una aplicación puede enviar mensajes de texto SMS
vigilaron más manualmente la aplicación.
Buscan las API que llaman a esto,
y ahora desde entonces Google se ha expandido,
pero esta era la primera cosa que ellos comenzaron a buscar.
>> Algunas otras aplicaciones que hicieron algunos de los mensajes de texto SMS,
este Qicsomos Android, creo que se llama.
Había un evento en curso en el móvil donde esta CarrierIQ salió
como software espía ponen en el dispositivo por los transportistas,
por lo que la gente quería saber si su teléfono estaba vulnerable a esto,
y esto era una aplicación gratuita que probó eso.
Bueno, por supuesto, lo que esta aplicación hizo fue que envió mensajes de texto SMS premium,
así probando para ver si usted está infectado con spyware
que ha cargado de malware en su dispositivo.
Vimos lo mismo sucede en el último Super Bowl.
No hubo una versión falsa del partido de fútbol Madden
que envían mensajes de texto SMS premium.
En realidad, trató de crear una red bot también en el dispositivo.
Aquí tengo algunos ejemplos.
Curiosamente, Apple era bastante inteligente,
y que no permiten a las aplicaciones enviar mensajes de texto SMS en absoluto.
No aplicación puede hacerlo.
Eso es una gran manera de deshacerse de toda una clase de vulnerabilidad,
pero en Android que puedes hacerlo, y por supuesto, en el BlackBerry puede hacerlo también.
Es interesante que en el BlackBerry sólo necesitas permisos de Internet
para enviar un mensaje de texto SMS.
>> La otra cosa realmente que buscamos
cuando estamos mirando para ver si algo es malicioso es cualquier tipo de
actividad de red no autorizado, como mira el actividad de la red
la aplicación se supone que tiene que tener su funcionalidad,
y mirar a esta otra actividad de la red.
Tal vez una aplicación, a trabajar, tiene que obtener los datos a través de HTTP,
pero si se trata de hacer las cosas por correo electrónico o SMS o Bluetooth, o algo así
ahora que la aplicación podría deberse malicioso, por lo que esta es otra cosa que usted puede inspeccionar.
Y en esta diapositiva aquí tengo algunos ejemplos de ello.
Otra cosa interesante que vimos con malware que sucedió en el 2009,
y sucedió de una manera grande.
No sé si ha pasado mucho desde entonces, pero era una aplicación
que personificaron a otra aplicación.
Había un conjunto de aplicaciones, y fue apodado el ataque 09Droid,
y alguien decidió que había una gran cantidad de pequeños bancos, regional, de tamaño mediano
que no tienen las aplicaciones de banca en línea,
así que lo que hicieron fue que construyeron cerca de 50 aplicaciones de banca en línea
que lo único que hicieron fue tomar el nombre de usuario y contraseña
y le redirigirá a la página web.
Y por lo que poner todos éstos en el mercado de Google,
en el mercado Android, y cuando alguien buscado para ver si su banco
tenido una aplicación que encontrarían la aplicación falsa,
que recogió sus credenciales y luego les redirige a su página web.
La forma en que este hecho se convirtió en-las aplicaciones estaban allí por un par de semanas,
y había miles y miles de descargas.
>> La forma en que salió a la luz fue que alguien está sufriendo un problema
con una de las aplicaciones, y ellos llamaron a su banco,
y llamaron a la línea de atención al cliente de su banco y le dijeron:
"Estoy teniendo un problema con su aplicación de banca móvil".
"¿Me puedes ayudar?"
Y ellos dijeron: "No tenemos una aplicación de banca móvil".
Eso comenzó la investigación.
Ese banco llama Google, y luego Google miró y dijo:
"Wow, el mismo autor ha escrito 50 aplicaciones bancarias", y se los llevó hacia abajo.
Pero, ciertamente, esto podría suceder de nuevo.
Ahí está la lista de todos los diferentes bancos aquí
que formaban parte de esta estafa.
La otra cosa que una aplicación puede hacer es presentar la interfaz de usuario de otra aplicación.
Mientras se está ejecutando podría aparecer el Facebook UI.
Se dice que usted tiene que poner su nombre de usuario y contraseña para continuar
o poner cualquier nombre de usuario y la contraseña de la interfaz de usuario para un sitio web
que tal vez el usuario utiliza sólo para tratar de engañar al usuario
en poner sus credenciales pulg
Esto es realmente un paralelo directo de los ataques de phishing de correo electrónico
donde alguien le envía un mensaje de correo electrónico
y le da básicamente una interfaz de usuario para un sitio web falso
que usted tiene acceso.
>> La otra cosa que buscamos en el código malicioso es la modificación del sistema.
Usted puede buscar todas las llamadas a la API que requieren privilegios de root
para ejecutar correctamente.
Cambio de proxy web del dispositivo sería algo que una aplicación
no debería ser capaz de hacer.
Pero si la aplicación tiene código en allí para hacer que
usted sabe que es probable que sea una aplicación maliciosa
o muy altamente probable que sea una aplicación maliciosa,
y así lo que sucedería es que la aplicación tendría alguna forma de una escalada de privilegios.
Tendría alguna escalada de privilegios explotar
en la aplicación y, a continuación, una vez que se intensificó privilegios
sería hacer estas modificaciones en el sistema.
Usted puede encontrar malware que tiene una escalada de privilegios
en él, incluso sin saber cómo la escalada de privilegios
explotar va a suceder, y eso es una buena manera, fácil
buscar malware.
DroidDream fue probablemente la más famosa pieza de malware Android.
Creo que afectó a cerca de 250.000 usuarios en pocos días
antes de que fuera encontrado.
Ellos reenvasado 50 aplicaciones falsas,
ponerlos en la tienda de aplicaciones Android,
y, esencialmente, se utiliza el código jailbreak Android para escalar privilegios
y luego instalar un comando y control y gire todas las víctimas
en una red bot, pero se podría haber detectado esta
Si estaba escaneando la aplicación y sólo en busca de
API pide permiso a esa raíz necesario para ejecutar correctamente.
>> Y hay un ejemplo aquí tengo que cambia el proxy,
y esto en realidad sólo está disponible en el Android.
Se puede ver que te estoy dando una gran cantidad de ejemplos sobre Android
porque aquí es donde el ecosistema de malware más activo es
porque es muy fácil para un atacante para obtener el código malicioso
en el mercado Android.
No es tan fácil de hacer que en el App Store de Apple
porque Apple obliga a los desarrolladores a identificarse
y firmar el código.
Ellos realmente comprobar que es usted, y Apple es en realidad escudriñando las aplicaciones.
No vemos una gran cantidad de malware de verdad en el que el dispositivo se está comprometido.
Voy a hablar de algunos ejemplos en los que es realmente la vida privada que está siendo comprometida,
y eso es lo que realmente está sucediendo en el dispositivo de Apple.
Otra cosa a buscar código malicioso, el código de riesgo en los dispositivos
es lógicas o de bombas y bombas de tiempo son probablemente
mucho más fácil de buscar que las bombas lógicas.
Pero con bombas de tiempo, lo que puede hacer es que se puede buscar
lugares en el código donde se pone a prueba el tiempo o un tiempo absoluto que se busca
antes de cierta funcionalidad en la aplicación pasa.
Y esto se podría hacer para ocultar que la actividad del usuario,
por lo que está sucediendo a altas horas de la noche.
DroidDream hizo toda su actividad 11 p.m.-08 a.m. hora local
al tratar de hacerlo, mientras que el usuario no esté utilizando su dispositivo.
>> Otra razón para hacer esto es que si la gente está utilizando el análisis del comportamiento de una aplicación,
ejecutar la aplicación en un entorno limitado a ver lo que el comportamiento de la aplicación es,
pueden utilizar la lógica basada en el tiempo de hacer la actividad
cuando la aplicación no se encuentra en la caja de arena.
Por ejemplo, una tienda de aplicaciones como Apple
ejecuta la aplicación, pero probablemente no se ejecutan todas las aplicaciones para, por ejemplo, 30 días
antes de aprobarla, lo que puede poner
la lógica de la aplicación que, dijo, está bien, sólo hacer lo malo
después de 30 días ha pasado, o al cabo de 30 días después de la fecha de publicación de la solicitud,
y que puede ayudar a ocultar el código malicioso de la gente inspeccionando para ello.
Si las compañías de antivirus están funcionando las cosas en cajas de arena
o las propias tiendas de aplicaciones son que esto puede ayudar
ocultar que a partir de dicha inspección.
Ahora, la otra cara de esto es que es fácil de encontrar con el análisis estático,
lo que en realidad inspeccionar el código que puede buscar todos los lugares
donde la aplicación comprueba el tiempo y inspeccionar de esa manera.
Y aquí tengo algunos ejemplos de estas 3 plataformas diferentes
cómo el tiempo se puede comprobar por el fabricante de la aplicación
así que usted sabe qué buscar si está inspeccionando la aplicación de forma estática.
>> Acabo de ir a través de un montón de diferentes actividades maliciosas
que hemos visto en la naturaleza, pero que son los más frecuentes?
Ese mismo estudio realizado en Carolina del Norte State Project Mobile Genoma
publicado algunos datos, y existen principalmente 4 áreas
que vieron a donde no había mucha actividad.
37% de las aplicaciones hizo una escalada de privilegios,
por lo que tuvieron algún tipo de código de jailbreak allí
donde trataron de escalar privilegios para que pudieran
Qué comandos de la API se ejecuta como sistema operativo.
45% de las aplicaciones por ahí hizo SMS premium,
así que es un gran porcentaje que está tratando de obtener beneficios económicos de forma directa.
93% lo hizo de control remoto, por lo que trató de establecer una red bot, una red bot móvil.
Y el 45% cosechado información de identificación
como números de teléfono, UUID, localización GPS, cuentas de usuario
y esto se suma a más de 100, porque la mayoría del malware trata de hacer algunas de estas cosas.
>> Voy a cambiar a la segunda mitad y hablar acerca de las vulnerabilidades de código.
Esta es la segunda parte de la actividad de riesgo.
Aquí es donde esencialmente el desarrollador está haciendo errores.
Un desarrollador legítimo escribir una aplicación legítima
está cometiendo errores o es ignorante de los riesgos de la plataforma móvil.
Ellos simplemente no saben cómo hacer que una aplicación móvil segura,
o, a veces el desarrollador no se preocupa por poner al usuario en riesgo.
A veces parte de su modelo de negocios podría ser
cosechar la información personal del usuario.
Eso es una especie de la otra categoría, y es por eso que algunos de este malicioso
contra arranques legítimos a sangrar otra vez porque hay diferencia de opiniones
entre lo que el usuario quiere y lo que el usuario considere riesgosa
y lo que el desarrollador de la aplicación considera arriesgado.
Por supuesto, no es de datos de los desarrolladores de aplicaciones en la mayoría de los casos.
>> Y, finalmente, otra forma esto ocurre es un desarrollador podría vincular en
una biblioteca compartida que tiene vulnerabilidades o esta conducta de riesgo en ella
a espaldas de ellos.
La primera categoría es la fuga de datos sensibles,
y esto es cuando la aplicación recoge información
como la ubicación, la información de la libreta de direcciones, información del propietario
y envía que apagar el dispositivo.
Y una vez que está fuera del dispositivo, no sabemos lo que está pasando con esa información.
Podría ser almacenado de forma insegura por el desarrollador de la aplicación.
Hemos visto los desarrolladores de aplicaciones quedan comprometidas,
y los datos que se están almacenando es llevado.
Esto sucedió hace unos meses a un desarrollador en Florida
donde un gran número de-era iPad UUID y nombres de dispositivos
se filtraron porque alguien, creo que fue en el anonimato,
reclamado para hacer esto, irrumpieron en los servidores de este desarrollador
y robaron millones de iPad UUID
y los nombres de equipo.
¿No es la información más arriesgado,
pero lo que si que era el almacenamiento de nombres de usuario y contraseñas
y direcciones de domicilio?
Hay un montón de aplicaciones que almacenan ese tipo de información.
El riesgo está ahí.
>> La otra cosa que puede suceder es si el desarrollador no se ocupa
para asegurar el canal de datos, y eso es otro gran vulnerabilidad que voy a hablar,
que los datos se envían en el claro.
Si el usuario está en una red Wi-Fi pública
o alguien que está oliendo el Internet en alguna parte
a lo largo de la ruta de acceso está siendo expuesto a esos datos.
Un caso muy famoso de esta fuga de información ocurrió con Pandora,
y esto es algo que investigamos en Veracode.
Nos enteramos de que había una-Creo que fue una Comisión Federal de Comercio
investigación pasando con Pandora.
Dijimos: "¿Qué está pasando ahí? Vamos a empezar a cavar en la aplicación de Pandora."
Y lo que se determinó fue la aplicación Pandora recogido
su sexo y su edad,
y también acceder a su ubicación GPS y la aplicación de Pandora
Hice esto por lo que dijeron eran razones legítimas.
La música que tocaban-Pandora es una aplicación de streaming de música
la música estaban jugando sólo fue autorizada en los Estados Unidos,
así que tuvieron que comprobar que cumple con sus acuerdos de licencia que tenían
para la música que el usuario estaba en los Estados Unidos.
También querían cumplir con el asesoramiento de los padres
alrededor de lenguaje de adultos en la música,
y lo que es un programa voluntario, pero quería cumplir con ese
y no jugar letras explícitas de niños de 13 años o menores.
>> No tenían motivos legítimos para recopilar estos datos.
Su aplicación tiene los permisos para hacerlo.
Los usuarios pensaron que esto era legítimo. Pero, ¿qué pasó?
Se unieron en 3 o 4 bibliotecas de anuncios diferentes.
Ahora, de repente, todas estas bibliotecas de anuncios
son cada vez más el acceso a la misma información.
Las bibliotecas de anuncios, si nos fijamos en el código en las bibliotecas de anuncios
lo que hacen es cada biblioteca anuncio dice
"¿Mi aplicación tiene permiso para obtener la ubicación GPS?"
"Oh, sí? Bueno, dime la ubicación GPS."
Cada biblioteca anuncio hace eso,
y si la aplicación no tiene permiso GPS
no va a ser capaz de hacerlo, pero si lo hace, lo obtendrá.
Aquí es donde el modelo de negocio de las bibliotecas de anuncios
se opone a la privacidad del usuario.
Y no ha habido estudios por ahí que va a decir si usted sabe la edad
de una persona y usted sabe su ubicación
donde dormir por la noche, porque tiene sus coordenadas GPS
mientras que tal vez estén durmiendo, usted sabe exactamente quién es esa persona
porque se puede determinar qué miembro de ese hogar es esa persona.
Realmente esto es identificar a los anunciantes
exactamente quién es usted, y se ve como si fuera legítimo.
Sólo quiero que mi música streaming, y esta es la única manera de conseguirlo.
>> Bueno, expusimos esto.
Escribimos esto en varias publicaciones en el blog,
y resultó que alguien de la revista Rolling Stone
leer uno de nuestros mensajes de blog y escribió su propio blog en la revista Rolling Stone en ello,
y al día siguiente Pandora pensó que era una buena idea
para eliminar las bibliotecas de anuncios de su aplicación.
Por lo que yo sé que son el único-que deberían ser elogiados.
Creo que son el único tipo freemium de aplicación que se ha hecho esto.
Todas las otras aplicaciones freemium tienen este mismo comportamiento,
por lo que tiene que pensar en qué tipo de datos que se están dando
estas aplicaciones freemium porque todo va a anunciantes.
Pretoriana también hizo un estudio acerca de las bibliotecas compartidas y dijo:
"Vamos a ver lo que comparten las bibliotecas son las bibliotecas compartidas superiores", y esto fue los datos.
>> Analizaron 53,000 aplicaciones,
y la biblioteca compartida número 1 era AdMob.
En realidad, fue en el 38% de las aplicaciones que hay,
por lo que el 38% de las aplicaciones que está utilizando
probablemente estén capturando su información personal
y enviarlo a las redes de anuncios.
Apache y Android fueron del 8% y 6%,
y entonces estos otros hacia abajo en la parte inferior, los anuncios de Google, Flurry,
Mob City y Millennial Media,
estas son todas las empresas de publicidad, y luego, curiosamente,
4% relacionado en la biblioteca de Facebook
probablemente para realizar la autenticación a través de Facebook
por lo que la aplicación puede autenticar el Facebook.
Pero eso también significa que la corporación Facebook controla código
que se está ejecutando en el 4% de las aplicaciones móviles para Android por ahí,
y tienen acceso a todos los datos de que esa aplicación tiene permiso para llegar.
Facebook esencialmente trata de vender espacios publicitarios.
Ese es su modelo de negocio.
>> Si nos fijamos en todo este ecosistema con estos permisos
y las bibliotecas compartidas de empezar a ver que
usted tiene una gran cantidad de riesgo en una aplicación supuestamente legítimo.
La misma cosa similar que ocurrió con Pandora
ocurrido con una aplicación llamada Path,
y ruta pensó que estaban siendo útiles, los desarrolladores de amistad.
Ellos estaban tratando de darle una gran experiencia de usuario,
y resultó que sin preguntar al usuario o indicando al usuario nada-
y esto sucedió en el iPhone y en Android,
Pandora aplicación estaba en iPhone y Android-
que la aplicación Sendero estaba agarrando toda su libreta de direcciones
y subirlo a la ruta sólo cuando instaló y ejecutó la aplicación,
y no le dijeron nada acerca de esto.
Ellos pensaron que era muy útil para usted
para poder compartir con todas las personas de su libreta de direcciones
que está utilizando la aplicación Path.
>> Bueno, obviamente Sendero pensó que era grande para su empresa.
No es tan bueno para el usuario.
Hay que pensar que se trata de una cosa si tal vez un adolescente
es el uso de esta aplicación y sus decenas de amigos están ahí,
pero lo que si que es el CEO de una empresa que instala Sendero
y luego, de su libreta de direcciones entera súbita es ahí arriba?
Usted va a obtener una gran cantidad de información de contacto que puede ser valiosa
para un montón de gente.
Un periodista del New York Times, que podría ser capaz de ver el teléfono
para los ex presidentes de su libreta de direcciones,
por lo que, obviamente, una gran cantidad de información sensible se transfiere con algo como esto.
Hubo un gran colgajo tales acerca de esto que Sendero se disculpó.
Cambiaron su aplicación, y que incluso afectaron Apple.
Apple dijo: "Vamos a obligar a los proveedores de aplicaciones para solicitar a los usuarios
si van a cobrar la totalidad de su libreta de direcciones ".
>> Parece que lo que está sucediendo aquí es
cuando hay una gran violación de la privacidad y hace la prensa
vemos un cambio que hay.
Pero, por supuesto, hay otras cosas por ahí.
La aplicación LinkedIn cosecha las entradas de calendario,
pero Apple no lo hace se solicita al usuario acerca de eso.
Las entradas de calendario puede tener información confidencial en ellos también.
¿A dónde va a trazar la línea?
Esto es realmente una especie de lugar en evolución
donde no hay realmente ninguna buena calidad por ahí
para los usuarios a entender cuando la información va a estar en riesgo
y cuando lo van a saber que está siendo tomada.
Escribimos una aplicación en Veracode llamado Adios,
y, esencialmente, que permitió que usted señale la aplicación en el directorio de iTunes
y mirar todas las aplicaciones que estaban cosechando su libreta de direcciones completa.
Y como se puede ver en esta lista aquí, Angry Birds,
AIM, AroundMe.
¿Por qué Angry Birds necesitan tu libreta de direcciones?
No sé, pero lo hace de alguna manera.
>> Esto es algo que muchas, muchas aplicaciones hacen.
Usted puede inspeccionar el código para esto.
Hay APIs bien definidas para iPhone, Android y BlackBerry
para llegar a la libreta de direcciones.
Usted puede inspeccionar con gran facilidad para esto, y esto es lo que hicimos en nuestra aplicación Adios.
La siguiente categoría, no seguro de almacenamiento de datos sensibles,
es algo que los desarrolladores tienen algo así como un alfiler o un número de cuenta
o una contraseña y guárdela en el claro en el dispositivo.
Peor aún, podrían almacenar en un área en el teléfono
que es accesible a nivel mundial, al igual que la tarjeta SD.
Usted ve esto más a menudo en Android Android porque permite una tarjeta SD.
Dispositivos iPhone no.
Pero incluso vimos que esto suceda en una aplicación de Citigroup.
Su aplicación de banca en línea almacena los números de cuenta de forma insegura,
sólo en el claro, así que si usted perdió su dispositivo,
en esencia lo que perdiste tu cuenta bancaria.
Es por esto que yo personalmente no hago las actividades bancarias en mi iPhone.
Creo que es demasiado arriesgado en este momento para hacer este tipo de actividades.
>> Skype hizo lo mismo.
Skype, por supuesto, tiene un saldo de cuenta, nombre de usuario y contraseña
que acceder a ese equilibrio.
Ellos estaban almacenando toda esa información en el claro en el dispositivo móvil.
Tengo algunos ejemplos aquí de la creación de archivos
que no tienen los permisos adecuados o escribiendo a disco
y no tener ningún tipo de cifrado suceda para eso.
Esta área siguiente, inseguro Sensible de transmisión de datos,
Me he referido a esto unas cuantas veces, y porque de público Wi-Fi
esto es algo que las aplicaciones tienen una necesidad imperiosa de hacer,
y esto es probablemente lo que vemos salir mal la mayoría.
Yo diría que-en realidad, creo que tengo los datos reales,
pero está cerca de la mitad de las aplicaciones móviles
meter la pata haciendo SSL.
Ellos simplemente no se utilizan las APIs correctamente.
Quiero decir, todo lo que tienes que hacer es seguir las instrucciones y usar las API,
pero sí cosas como no comprobar si existe un certificado no válido en el otro extremo,
No comprobar si el otro extremo está tratando de hacer un ataque rebaja protocolo.
>> Los desarrolladores, que quieren conseguir su casilla, ¿no?
Su requisito es usar esto para vender. Han utilizado este para vender.
El requisito es no usar esto para vender con seguridad,
por lo que esta es la razón por todas las aplicaciones que utilizan SSL para proteger los datos
ya que está siendo transmitida apagar el dispositivo necesita realmente para ser inspeccionado
para asegurarse de que se ha implementado correctamente.
Y aquí tengo algunos ejemplos donde se puede ver una aplicación
podría ser a través de HTTP en lugar de HTTPS.
En algunos casos, las aplicaciones se caerán de nuevo a HTTP
si el HTTPS no está funcionando.
Tengo otra llamada aquí en Android donde han desactivaron el cheque certificado,
por lo que un ataque man-in-the-middle puede suceder.
Se aceptará un certificado no válido.
Estos son todos los casos en que los atacantes van a ser capaz de obtener en
la misma conexión Wi-Fi como el usuario y acceder a todos los datos
que está siendo enviado a través de Internet.
>> Y finalmente, la última categoría que tengo aquí es la contraseña y las teclas codificado.
En realidad, vemos una gran cantidad de desarrolladores utilizan el mismo estilo de codificación
que lo hicieron cuando estaban construyendo aplicaciones de servidor web,
por lo que están construyendo una aplicación de servidor Java, y se están codificando la llave.
Bueno, cuando usted está construyendo una aplicación de servidor, sí,
codificar la clave no es una buena idea.
Esto hace que sea difícil cambiar.
Pero no es tan malo en el lado del servidor, ya que tiene acceso a la parte del servidor?
Sólo los administradores.
Pero si se toma el mismo código y se vierte por encima de una aplicación móvil
ahora todo el mundo que tiene esa aplicación móvil tiene acceso a esa clave codificada,
y que en realidad ver esto muchas veces, y tengo algunas estadísticas
la frecuencia con la que vemos que esto suceda.
En realidad fue en el ejemplo de código que publicó MasterCard
sobre el uso de su servicio.
El código de ejemplo mostró cómo usted acaba de tomar la contraseña
y lo puso en una cadena codificada allí,
y sabemos cómo los desarrolladores les encanta copiar y pegar fragmentos de código
cuando están tratando de hacer algo, por lo que copiar y pegar el fragmento de código
que ha puesto como ejemplo de código, y usted tiene una aplicación insegura.
>> Y aquí tenemos algunos ejemplos.
Esta primera es que vemos un montón donde retocan
el derecho de los datos en una URL que se envía.
A veces vemos string password = contraseña.
Eso es muy fácil de detectar, o contraseña de serie en el BlackBerry y Android.
En realidad es bastante fácil de detectar debido a que casi siempre
los nombres de los desarrolladores de la variable que se sostiene la contraseña
alguna variación de la contraseña.
Mencioné que hacemos análisis estático en Veracode,
por lo que hemos analizado varios cientos de aplicaciones de Android y iOS.
Hemos construido modelos completos de ellos, y somos capaces de escanear
para diferentes vulnerabilidades, especialmente las vulnerabilidades de las que hablaba,
y tengo algunos datos aquí.
68,5% de las aplicaciones de Android que vimos
había roto el código de cifrado,
que, para nosotros, no podemos detectar si ha realizado su propia rutina de cifrado,
no es que eso sea una buena idea, pero esto en realidad está utilizando las API publicadas
que están en la plataforma, pero haciendo ellos de tal manera
que la criptografía sería vulnerable, 68.5.
Y esto es para las personas que nos están enviando sus solicitudes en realidad porque
ellos piensan que es una buena idea para hacer las pruebas de seguridad.
Estos ya son personas que probablemente están pensando de forma segura,
por lo que es probablemente aún peor.
>> No hablé acerca de la inyección de alimentación de la línea de control.
Es algo que vamos a comprobar, pero no es tan arriesgado un problema.
Filtración de información, es aquí donde se están enviando datos sensibles fuera del dispositivo.
Se encontró que en el 40% de las solicitudes.
El tiempo y el estado, los que son cuestiones de tipo condición de carrera, por lo general muy difíciles de explotar,
así que no me refiero a eso, sino que lo miré.
23% tenía problemas de inyección SQL.
Mucha gente no sabe que una gran cantidad de aplicaciones
utilizar un poco pequeña base de datos SQL en su parte trasera para almacenar datos.
Bueno, si los datos que usted está agarrando por la red
tiene cadenas de ataque de inyección SQL en ella
alguien puede poner en peligro el dispositivo a través de eso,
y así que creo que encontrará cerca del 40% de las aplicaciones web tienen este problema,
que es un problema enorme epidemia.
Lo encontramos 23% de las veces en las aplicaciones móviles
y eso es probablemente debido a que muchas más aplicaciones web utilizan SQL de móvil.
>> Y luego todavía vemos algunas secuencias de comandos entre sitios, las cuestiones de autorización,
y luego la administración de credenciales, que es donde usted tiene la contraseña codificada.
En el 5% de las aplicaciones que vemos eso.
Y luego tenemos algunos datos sobre iOS.
81% tenía problemas de manejo de errores.
Esto es más de un problema de la calidad del código,
pero el 67% tenía problemas de cifrado, por lo que no es tan malo como Android.
Tal vez las API son un poco más fácil, los códigos de ejemplo un poco mejor en iOS.
Pero sigue siendo un porcentaje muy alto.
Tuvimos un 54% con la fuga de información,
aproximadamente el 30% con errores de gestión de memoria intermedia.
Eso es los lugares donde podría ser potencialmente un problema de corrupción de memoria.
Resulta que eso no es como mucho de un problema para la explotación
en iOS, porque todo el código tiene que ser firmado,
así que es difícil para un atacante para ejecutar código arbitrario en iOS.
La calidad del código, recorrido de directorio, pero la gestión de credenciales de aquí en un 14,6%,
por lo peor que en el Android.
Tenemos gente no manejar contraseñas correctamente.
Y a continuación, los errores numéricos y de desbordamiento de búfer,
quienes están más va a haber problemas de calidad de código en iOS.
>> Eso fue todo para mi presentación. No sé si estamos fuera de tiempo o no.
No sé si hay alguna pregunta.
[Hombre] Una pregunta rápida alrededor de la fragmentación y el mercado Android.
De Apple, al menos, es propietaria de parches.
Ellos hacen un buen trabajo de hacer las cosas por ahí mientras que en menor medida en el espacio de Android.
Casi se necesita para hacer jailbreak a su teléfono para estar al día
con la versión actual de Android.
Sí, eso es un gran problema y lo que si se piensa en-
[Hombre] ¿Por qué no te lo repita?
>> Ah, claro, así que la pregunta era ¿qué pasa con la fragmentación
del sistema operativo en la plataforma Android?
¿Cómo afecta el grado de riesgo de estos dispositivos?
Y lo que realmente es un gran problema porque lo que ocurre es
los dispositivos más antiguos, cuando alguien se le ocurre una fuga de la cárcel para ese dispositivo,
en esencia, que es una escalada de privilegios, y hasta que se actualice el sistema operativo
cualquier tipo de malware puede entonces utilizar esa vulnerabilidad para comprometer totalmente el dispositivo,
y lo que estamos viendo en el Android es el fin de obtener un nuevo sistema operativo
Google tiene que apagar el sistema operativo, y luego el fabricante de hardware
tiene para personalizarlo, y luego el transportista tiene que personalizar y entregarlo.
Usted tiene básicamente 3 piezas en movimiento aquí,
y se está convirtiendo en que los transportistas no les importa,
y los fabricantes de hardware no les importa, y Google no se aguijoneándolos suficiente
para hacer cualquier cosa, lo que en esencia más de la mitad de los dispositivos por ahí
tener sistemas operativos que tienen estas vulnerabilidades de escalada de privilegios en ellos,
y así que si tienes el malware en su dispositivo Android es mucho más de un problema.
>> Bien, muchas gracias.
[Aplausos]
[CS50.TV]