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