El pasado viernes la conocida empresa Skype confirmaba en su blog los rumores sobre la posibilidad de tener acceso a los datos de carácter privado almacenados por la aplicación en dispositivos Android.
El problema aún se agrava más si tenemos en cuenta que estos datos no están cifrados, por lo que cualquier podría utilizarlos sin mayor problema para fines delictivos.
Nuevamente volvemos a encontrarnos ante el problema de infectar aplicaciones de terceros en las que incluir el código malicioso para robar los datos.
Introducción
El objetivo de esta entrada es analizar cómo está desarrollado el exploit para vulnerar la privacidad de los usuarios y hacer un pequeño repaso al tema de análisis forenses a dispositivos android para dejar entrever algunas de sus deficiencias.
Como requisitos previos será necesario disponer de acceso root al teléfono, para ello podemos guiarnos de la aplicación SuperOneClick y tener instalado el SDK para hacer uso del Android Debug Bridge (ADB).
Skypwned
Cuando instalamos Skype y establecemos conexión por primera vez con nuestra cuenta, en la jerarquía de carpetas de la instalación se crea una nueva con nuestro nombre de usuario, y se almacenan ahí todos los ficheros como contactos, perfil, logs de las conversaciones mantenidas y bases de datos sqlite3
El problema viene con la forma de otorgar los permisos, donde hacen posible la lectura y escritura de todos los ficheros para cualquier usuario. De esta forma es relativamente sencillo conseguir acceso remoto a través de cualquier aplicación a las carpetas deseadas, hacer una copia y enviarlas a otro lugar donde tratar la información más detenidamente.
# ls -l /data/data/com.skype.raider/files/arriba_laesteban -rw-rw-rw- app_62 app_62 331776 2011-04-16 00:08 main.db -rw-rw-rw- app_62 app_62 119528 2011-04-16 00:08 main.db-journal -rw-rw-rw- app_62 app_62 40960 2011-04-14 14:05 keyval.db -rw-rw-rw- app_62 app_62 3522 2011-04-15 23:39 config.xml drwxrwxrwx app_62 app_62 2011-04-14 14:05 voicemail -rw-rw-rw- app_62 app_62 0 2011-04-14 14:05 config.lck -rw-rw-rw- app_62 app_62 61440 2011-04-15 00:08 bistats.db drwxrwxrwx app_62 app_62 2011-04-14 21:49 chatsync -rw-rw-rw- app_62 app_62 12824 2011-04-14 14:05 keyval.db-journal -rw-rw-rw- app_62 app_62 33344 2011-04-14 00:08 bistats.db-journal
Para demostrar el impacto, AndroidPolice desarrolló un pequeño POC llamado Skypwned. El APK (e788c146fbeaf4152d57c12711c4bdbd ) presenta la siguiente estructura una vez desempacado y pasado dex2jar y JAD:
sebas@Helios:~/Android/research/Source_Code_JAD$ tree . . |-- a.jad |-- b.jad |-- c.jad |-- d.jad |-- e.jad |-- f.jad `-- Main.jad 0 directories, 7 files
El trozo de código qué aprovecha este fallo podéis verlo aquí. Básicamente busca ficheros específicos y reserva memoria para varios strings donde se forman las consultas para lanzarlas a la base de datos y sacar así los datos que nos interesan : información de los contactos, perfiles, logs, y demás. El fallo, está presente en varias compilaciones de la aplicación también, aquí si las cosas se hacen mal, que sean desde el principio...
El problema viene ante la posibilidad de un vector de ataque en el que se utilicen aplicaciones de terceros para inyectar ese trozo de código, empacar el APK de nuevo y lanzarlo al market. Provocando así una infección masiva que revele los datos privados de cientos de usuarios. Incluido el número de la tarjeta de crédito en caso de que se tenga asociada a la cuenta de Skype así como los logs de las conversaciones.
Supongamos que por un casual fuese Google el que tiene este fallo, y es su aplicación de Google Talk la que tiene este problema y deja expuestos los de sus usuarios, números de teléfono y agenda de contactos. Sería un desastre ¿verdad?.
El POC en funcionamiento podéis verlo en este vídeo realizado por AndroidPolice:
¿Dónde está el problema?
Analizando más detenidamente el núcleo del error, nos damos cuenta de que se han producido tres fallos esenciales de cierto calibre:
- No se han aplicado correctamente las políticas de los permisos, dejando datos de importancia a la vista de los más curiosos. La solución a esto es bastante clara, otorgar las restricciones pertinentes.
- Los datos son almacenados sin aplicarse ningún esquema de cifrado, de forma que el usuario que tenga acceso a ellos se lleva el premio gordo. Esto sigue siendo uno de los principales problemas desde mi punto de vista, se hace necesaria una capa de protección que cifre el contenido importante del teléfono.
- Toda aplicación antes de ser lanzada, ha de pasar por unos mínimos de calidad. Estos problemas se hubieran evitado si se hubiera realizado un análisis exhaustivo de la misma antes de hacerla pública. Un mal ejemplo que deja en evidencia una empresa importante como Skype.
Evidentemente todo esto podría haberse evitado, ¿pero es un error que sólo comete Skype?
A mí las cosas me gustan claras
Podríamos pensar que esto es un hecho aislado y que está todo bajo control, pero si nos aventuramos a realizar un forense al teléfono podemos llevarnos más de una sorpresa. ¿Están nuestros datos protegidos?.
Para llevar a cabo nuestro análisis vamos a utilizar el SDK de Android que trae consigo la herramienta ADB. Otra opción es también montar un servidor SSH en el teléfono con la aplicación QuickSSHd y conectarnos en remoto desde un equipo, pero las transferencias al realizar movimientos de ficheros son más lentas.
Para ver los dispositivos conectados utilizamos:
sebas@Helios:~/Android/sdk/platform-tools$ ./adb devices List of devices attached emulator-5554 device HT07DP800223 device
En este caso estoy corriendo un Nexus One con id HT07DP800223 y un emulador para las pruebas. Vamos a centrarnos en el primero.
Estructura interna
Cuando levantamos una shell a nuestro teléfono y solicitamos un listado del directorio raíz observamos:
sebas@Helios:~/Android/sdk/platform-tools$ ./adb -s HT07DP800223 shell $ ls config cache sdcard acct mnt d etc system sys sbin proc init.rc init.mahimahi.rc init.goldfish.rc init default.prop data root dev
Si echamos un vistazo a cómo está montado el sistema de ficheros:
$ mount rootfs / rootfs ro,relatime 0 0 tmpfs /dev tmpfs rw,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /acct cgroup rw,relatime,cpuacct 0 0 tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0 none /dev/cpuctl cgroup rw,relatime,cpu 0 0 /dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0 /dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0 /dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0 /sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0 /dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 /dev/block/vold/179:1 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
Podemos observar que existen varios puntos de montaje en distintos mtdblocks para cada directorio importante en nuestro teléfono. Así tenemos:
- /system en /dev/block/mtdblock3
- /cache en /dev/block/mtdblock4
- /data en /dev/block/mtdblock5
En caso de tener una tarjeta SD externa vemos como esta es montada en /sdcard.
Este subsistema de ficheros es conocido como Memory Technology Devices (MTD) y se caracteriza por embeber y dividir el sistema en un medio flash a diferencia de dispositivos de bloque tradicionales como podemos encontrar en cualquier equipo corriente. Llegados a este punto observamos que la nomenclatura utilizada es muy tradicional a los discos IDE o SATA, siendo en este caso utilizada /dev/mtd*
Si queremos obtener más información podemos consultar el /dev y obtenemos:
$ ls /dev/mtd* mtd5ro mtd5 mtd4ro mtd4 mtd3ro mtd3 mtd2ro mtd2 mtd1ro mtd1 mtd0ro mtd0
Podemos distinguir para cada dispositivo que tiene asociado un ro (Read Only) Por lo que si deseamos hacer una correlación y traernos al equipo el punto de montaje a analizar tendrá que ser aquel que no sea de lectura sólo, para ello utilizaremos el comando dd:
# dd if=/dev/mtd/mtd5 of=/sdcard/data/mtd5.img bs=2048 100480+0 records in 100480+0 records out 205783040 bytes transferred in 108.504 secs (1896547 bytes/sec)
Nos traemos el fichero a nuestro entorno de trabajo con el comando pull:
sebas@Helios:~/Android/sdk/platform-tools$ sudo ./adb pull /sdcard/data/mtd5.img /home/sebas/Android/research/mtd5.img 1799 KB/s (205783040 bytes in 111.650s)
Ahora podemos comenzar la investigación buscando strings que nos revelen información como claves, base de datos o nombres de usuarios:
sebas@Helios:~/Android/research$ strings -a ./mtd5.img | grep databases | more ... /data/data/com.android.providers.contacts/databases/contacts2.db-journal /data/data/com.google.android.gsf/databases/talk.db-journal /data/data/com.google.android.gsf/databases/talk.db-mj157DA2E7 ...
Sabemos que en el directorio /data/data vamos a tener todas aplicaciones instaladas con sus respectivas bases de datos. Será más fácil para trabajar traernos todo el directorio al completo a local.
Facebook, Tuenti, Youtube, Google Apps, MMS, contactos, Tweetdeck. Toda la información de acceso se encuentra en sus respectivas bases de datos, aunque algunas están vacías porque nunca he acabado usando la aplicación. ¿Qué pasaría si perdiésemos nuestro teléfono?
Por ejemplo Tuenti:
A pesar de que nuestro password está cifrado utilizando MD5, sería relativamente cuestión de tiempo y GPU realizar un ataque de fuerza bruta o combinado con diccionarios para romper la clave.
Más ejemplos así podemos encontrarlos en Facebook:
Otras veces no es ni necesario consultar a la base de datos, podemos encontrar en shared_prefs un fichero XML en el que se incluye información interesante.
Por ejemplo este caso de la aplicación Delicious:
Si piensas que únicamente sucede con las aplicaciones, miremos los SMS a ver cómo se muestran:
Conclusiones
Cada vez es más habitual que los usuarios de smartphones lleven su vida digital sincronizada a su teléfono con el considerable volumen de información que ello conlleva.
Emails, redes sociales, agendas, contactos, calendarios, son expuestos automáticamente en caso de perder el dispositivo. Alguien con bajos conocimientos puede perfectamente extraer todos los datos que le interesen y utilizarlos como mejor le convenga.
El problema no viene evidentemente del usuario, sino de los propios desarrolladores que permiten utilizar sus aplicaciones sin forzar el uso de cifrado y contraseñas.
Diversos motivos son los que mantienen enfrentados a detractores y defensores, ¿Es necesario realmente proteger nuestros datos?, ¿A qué coste?, ¿Cifrado completo o parcial de los datos?, ¿Compensa tener más cercana nuestra vida digital sabiendo el peligro que corremos?
De soluciones se ha hablado mucho, utilizar sqlitecrypt, cifrar los datos que se almacenan en la BD y utilizar una clave maestra para descifrarlos cuando se sirvan a terceros, lvm-crypt. Pero nunca se llega a un acuerdo entre eficiencia y rendimiento.
En lo personal, creo que a día de hoy, nuestros teléfonos son los sustitutivos de nuestros equipos personales cuando no nos encontramos en casa, el trabajo o dónde sea. Y cada vez el flujo de datos e información que es manejado es mayor, aumentando así la responsabilidad en la protección y cuidado de los mismos. Un claro ejemplo podemos citarlo con Blackberry cuyas comunicaciones van cifradas. ¿Cuánto tiempo pasará hasta que se sucedan los típicos leaks?
---------
Contribución por Sebastián Guerrero
9 comments :
Magnifico, genial, me quito el sombrero. Gran post. Sin duda que uno pierde el movil y sobre la marcha que cancela la cuenta corriente de skype.
Salu2 desde Wasesores.com
Gran post. Sublime en contenido e innovación.
Donde quedaron los Nokia 3330...
P.D: arriba_laesteban
Cada día me gustan más los SmartPhones esos O:)
Es posible acceder al telefono por adb aunque este bloqueado? Fabricantes como HTC ofrecen un servicio de bloqueo del movil pero con este articulo ya dudo de su utilidad..
Muy buen post.
Muchas gracias por la información
Creo que tienes que activar el debug primero, y nadie lo lleva puesto de normal...
Como bien comenta pho, para poder tener acceso al teléfono por USB es necesario tener previamente conectado el dispositivo y activado el modo debug. Porque sino no aparece el teléfono para levantar una shell con ADB.
Pero si tienes un servicio SSH ejecutándose como puede ser Dropbear o QuickSSHd, tienes acceso remoto desde cualquier equipo que esté conectado a la misma red wifi.
Acceso como root, completo, para tocar memoria interna y contenido de la tarjeta sd :).
He probado con mi HTC y he podido acceder a la configuración de correo y a los passwords para autenticar en IMAP y SMTP de mi cuenta de correo.
Saludos y buen trabajo!
Gracias Hector, básicamente toda la información que almacene tu teléfono puede ser accesible y obtenida en texto claro.
Un saludo.
Publicar un comentario