Android+Skype – All your data are belong to us

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

Etiquetas: android , forensic