El hecho de que hoy día seamos casi tantas personas en el mundo - 7,100 millones - como dispositivos móviles - 6,800 millones - hace que nos debamos preocupar por la seguridad de los mismos. Actualmente la previsión que existe de crecimiento en los terminales Android en 2014 es de un 23,1% más que en 2013, en detrimento de IOS con un 14,8% menos que 2013 (ver noticia). Es por ello que nos interesemos por cuáles son los puntos débiles que podemos encontrar en las aplicaciones androides.
LOS PERMISOS DE LAS APLICACIONES
LOS PERMISOS DE LAS APLICACIONES
A la hora de utilizar permisos en las aplicaciones Android, los desarrolladores incurren en dos situaciones:
- Undergranting o proceso por el cual un desarrollador no asigna los permisos necesarios a una aplicación. Este hecho provocará que una aplicación no testeada de fallos en tiempo de ejecución, provocando una SecurityException, lo cual hace que caiga la reputación de una aplicación.
- Overgranting o proceso por el cual un desarrollador asigna más permisos de la cuenta a una aplicación. Este hecho es más grave aún que el anterior, ya que podría darse el caso de explotación de dicho permisos por una aplicación maliciosa, pudiendo incluso escalar privilegios en el sistema.
Ya hemos visto en entradas anteriores donde podemos encontrar todos los permisos que utiliza una aplicación, en el fichero AndroidManifest.xml y herramientas que nos detectan posibles inseguridades en este fichero, como Manitree (ver Auditoria de Aplicaciones Android). Más adelante veremos como obtener con Androguard el lugar donde se utilizan cada uno de los permisos, de manera que podamos examinar el código fuente y determinar si un permiso está bien otorgado o no.
TRANSMISIÓN INSEGURA DE DATOS SENSIBLES
Otro tema a tener en cuenta es la transmisión de los datos de la aplicación por medio de SSL o TLS, pero la mayoría de desarrolladores no le dan importancia a esto y dejan la seguridad a la transmisión "segura" del operador de telefonía. Es por ello que nos encontramos con los siguientes casos:
- Falta de cifrado o cifrado débil.
- Cifrado fuerte, pero por falta de atención en las advertencias de seguridad o errores del certificado hacen que los usuarios no sean capaces de resolver el problema.
- Uso de texto plano tras fracasar en el cifrado de los datos.
- Confiar ciegamente en la "seguridad" que nos otorga según qué tipo de red (Wi-fi o celdas del operador)
La mayoría de estas situaciones provocan que se puedan dar ataques del tipo Man In The Middle (MITM), de manera que un atacante se sitúe en mitad de la comunicación y pueda captar toda la información transmitida. Exiten en el mercado muchas herramientas para llevar a cabo un ataque MITM (Cain&Abel, Ettercap, arpspoof...) y después escuchar todo lo que se habla en ella con un sniffer de paquetes como Wireshark.
Un ejemplo de transmisión insegura fue la implementación del protocolo de autenticación de Google ClientLogin en las versiones de Android 2.1 a la 2.3.4. El protocolo lo que hacía era pedir un token de autenticación para la cuenta de usuario de Google, de manera que este sirviera para autenticarse en servicios determinados de Google. Pues bien, investigadores de la Universidad de Ulm descubrieron que dicho token se enviaba a través de HTTP en texto plano en las aplicaciones de Calendario y Contactos de Android 2.1 a la 2.3 y en el servicio de sincronización de Picasa de Android 2.3.4, lo cual permitiría a un atacante que capturase el token, llevar a cabo una suplantación de identidad (ver más sobre la captura del token de Google).
ALMACENAMIENTO INSEGURO DE LOS DATOS
Dentro del sistema operativo Android existen muchas posibilidades a la hora de almacenar la información: fichero de preferencias shared_preferences, bases de datos SQLite o ficheros de texto plano. Las maneras de acceso a estos almacenes de información pueden ser varias: desde el propio código fuente de la aplicación, desde código nativo del propio sistema operativo, desde un Content Provider que de servicio a otra aplicación para acceder a los datos...
Los errores que se suelen cometer son los siguientes:
- Almacenar datos sensibles en ficheros de texto plano.
- Desproteger los Content Provider, de tal forma que se permita el acceso desde cualquier aplicación.
- Otorgar permisos inseguros a los archivos, de tal forma que puedan acceder otros usuarios que no sean la propia aplicación.
Un ejemplo de este almacenamiento inseguro se descubrió en Abril de 2011 en la aplicación Skype, la cual hacía uso de código nativo de Android para la creación de sus ficheros de preferecias, bases de datos y texto plano, con el problema de que el sistema le estaba asignando permisos 666 (lectura y escritura) para todos estos ficheros, lo cual exponía toda nuestra información de Skype: nombres, números de teléfono, llamadas, etc. (ver más sobre el caso de Skype)
FUGA DE INFORMACIÓN ALMACENADA EN LOGS
A través de los depuradores de código podemos obtener gran cantidad de información, desde credenciales de acceso hasta otros datos sensibles. Aquellas aplicaciones que tengan activado el READ_LOGS nos permite leer a bajo nivel los logs de dicha aplicación, o lo que es lo mismo, los registros de la misma. Es por ello que podemos hacer uso de la herramienta logcat que incorpora Android Debug Bridge (ADB) y obtener información sensible de la aplicación. Aquí os dejo un vídeo de como hacer uso de la misma (ver vídeo), así como información de los parámetros que utiliza desde línea de comandos (ver docs).
El permiso READ_LOGS ya no está disponible a partir de Android 4.1, sin embargo en versiones anteriores si. Un ejemplo de fuga de información por medio de registros fue el descubierto en la aplicación Firefox para Android en Diciembre de 2012, la cual registraba toda la actividad de navegación: URL visitadas e incluso identificadores de sesión, con lo que eso significa, pudiendo un atacante hacer un secuestro de sesión con esos datos.
COMUNICACIÓN ENTRE PROCESOS DE MANERA INSEGURA
Existe gran cantidad de comunicación entre procesos de equipos (conocida como IPC Endpoints): Servicios, Actividades, BroadcastReceivers o Content Providers. La protección en la comunicación en estos casos se lleva a cabo por medio de permisos que se establecen de un punto a otro de la comunicación, pero puede que nos encontremos con estos problemas:
- A través de un Content Provider se pueden dar ataques de inyección de código o directorio trasversal, de tal forma que accedamos a lugares no permitidos.
- Las actividades pueden verse comprometidas por código o apps maliciosas y poder acceder a la comunicación IPC.
- Los BroadCastReceiver se encargan de escuchar intenciones implícitas, estos pueden ser vulnerables si contienen el atributo intent-filter igual a "not unique just to Broadcast Receivers" o lo que es lo mismo, que si por ejemplo llega un SMS (intención implícita) otra app puede leer dicha info aunque ese mensaje fuera para mi, ya que con ese atributo y su valor, cualquier otro Broadcast Reveivers puede leer la información.
Un ejemplo de explotación de un IPC fue el descubierto por sh4ka en la app Samsung Kies en el Galaxy S3, la cual tiene privilegios elevados. Dicha aplicación tenía un Broadcast Receivers que se utilizaba para restaurar las APKs desde la carpeta /sdcard/restore/, pues bien, aprovechando esto, sh4ka consiguió poder instalar cualquier aplicación sin permisos (puedes encontrar más información al respecto en su Web).
Pues bien, hasta aquí ya hemos visto los puntos a tener en cuenta a la hora de analizar una aplicación en Android, los cuales pueden hacer que se comprometa la seguridad de nuestro sistema y exponer nuestros datos.
Espero que les haya resultado interesante y les sirva !!
Un handshake
"Es una locura seguir haciendo lo mismo y esperar resultados diferentes"
Albert Einstein
0 comentarios:
Publicar un comentario