Análisis forense de teléfonos basados en sistemas Android
Aprovechando que desde hace algún tiempo tengo un Nexus One quiero compartir con vosotros los pasos básicos para poder realizar una auditoría forense de este tipo de dispositivos, con el fin de que comprendáis un poco mejor cómo se organiza el sistema de ficheros en Android y cómo localizar información sensible dentro del mismo. También quiero que este texto sirva para ilustrar que la pérdida o el robo de un teléfono implica que siempre es posible tratar de recuperar datos sensibles de él, y aquí vamos a poner alguos ejemplos.
Describir un procedimiento completo y detallar todas y cada una de las ubicaciones en el sistema donde puede haber información sensible sería largo y costoso. Prefiero hacer una descripción general y poner algunos ejemplos prácticos que espero sean de vuestro agrado y utilidad. Estos ejemplos están enfocados al análisis forense de un sistema de ficheros, con lo que otras partes del sistema como la memoria no están cubiertas. Si te interesa esta última disciplina, quizás te interese este artículo.
Requisitos previos
- Ser root en el sistema, lo cual se logra normalmente desbloqueando el bootloader para proceder a ganar root. Hay infinidad de artículos al respecto en Internet. En la enorme mayoría de los artículos se utliza fastboot para desbloquear el bootloader y superboot para ganar root arrancando una imagen boot.img que permite la ejecución con usuario root. Ganar root implica perder la garantía del teléfono, así que abstente si no tienes absolutamente claro cómo hacerlo.
- La manera natural de intractuar con el teléfono a nivel consola es lanzar comandos mediante Android Debug Bridge (ADB). ADB es parte del SDK de Android y nos permite conectar al dispositivo estando este conectado via USB en la máquina que queramos analizar. Ojito si vais a usar ADB en Windows, ya que tenemos que tener el driver USB instalado (consultar SDK). En cualquiera de los casos, tanto Windows como Mac o Linux, la depuración USB tiene que estar activada en el teléfono.
- De modo altrnativo, es factible tener un servidor SSH instalado en el teléfono. Con paciencia y un poco de conocimiento se puede echar a andar Dropbear. También se pueden emplear ROMs que tengan el demonio SSH incorporado. Por último puedes comprar en el Market una aplicación que habilite un servidor SSH sin complicaciones, como por ejemplo QuickSSHD.
Conectando con el teléfono
En este artículo emplearemos el SDK de Android, que incluye la herramienta Android Debug Bridge (ADB) para conectar al teléfono. En mi caso particular el rendimiento de conectar vía SSH en una red WLAN es muy pequeño a causa de la señal, con lo que prefiero hacerlo con el teléfono conectado con el cable USB, lo que me hará tener mejores cuotas de transferencia al mover ficheros. Es indiferente emplear Windows o Linux, cada cual que escoja lo que más le guste:
http://www.sahw.com/images/forensics/android/adb_start_win.png
http://www.sahw.com/images/forensics/android/adb_start_lin.png
Si al solicitar la lista de dispositivos conectados vemos claramente nuestro dispositivo podemos proceder con tranquilidad, ya que todo ha ido correctamente y estamos en condiciones de operar. Caso contrario hemos de referirnos a la documentación. A los que uséis Linux comentaros que pese a que el binario está precompilado y no hay por tanto que compilar (basta con extraer las herramientas del SDK) sí que es preciso crear un fichero de reglas y relanzar udev para que lea los cambios. Si no hacéis estos dos pasos no veréis el dispositivo conectado. Una vez conectado el dispositivo, lanzamos la consola:
http://www.sahw.com/images/forensics/android/adb_shell.png
Nuestra primera ejecución será un listado del directorio raíz:
http://www.sahw.com/images/forensics/android/adb_ls_root.png
El sistema de ficheros Android
Android está basado en un núcleo Linux. Como tal la manera de aproximarse al sistema es la que usaríamos en cualquier derivado de Unix, teniendo en cuenta las particularidades de cada caso.
Un primer vistazo nos revela la composición del sistema de ficheros:
http://www.sahw.com/images/forensics/android/adb_mount.png
En lo que a dispositivos se refiere se puede observar que los puntos de montaje para /system, /data y /cache están asociados a distintos mtdblocks presentes en /dev/block/. Es también el caso de la tarjeta SD externa que acompaña a este modelo de teléfono, montada en /sdcard.
MTD es un subsistema Linux llamado Memory Technology Devices. En aquellos sistemas Linux donde no existen dispositivos de bloque tradicionales (las unidades de disco, por ejemplo) sino que el sistema está embebido en un medio flash, como es el caso del teléfono, es normal encontrar dentro de los puntos de montaje habituales referencias a los bloques MTD (en nuestro caso, son los mtdblocks).
Para comprender esta nomenclatura basta con pensar en las convenciones que se toman para dispositivos de bloque tradicionales, como por ejemplo los discos IDE (/dev/hd* significando hd hard drive) o los discos SCSI o SATA (/dev/sd*). En este caso es exactamente igual, pero sin embargo existe una diferencia: Los MTD siguen la nomenclatura /dev/mtd*
Podemos obtener más información de los dispositivos inspeccionando /dev y /proc:
http://www.sahw.com/images/forensics/android/adb_mtd.png
http://www.sahw.com/images/forensics/android/adb_proc_mtd.png
En esta última captura podemos ver otro distintivo característico de los dispositivos MTD, y es que en vez de tener sectores como los dispositivos de disco, tienen eraseblocks cuyo tamaño viene definido por erasesize.
Igualmente, del listado de /dev/mt* se puede verificar que cada dispositivo cuenta con un dispositivo ro asociado, así para mtd0 tenemos mtd0ro, etc. En este caso ro implica read only, sólo lectura. Para poder utilizar sistemas de ficheros convencionales en dispositivos MTD es preciso emular dispositivos de bloque sobre el dispositivo MTD. Esta necesidad mana de la propia naturaleza de un MTD, y en el caso de Linux se emplea mtdblock. Cuando se carga este módulo automáticamente se crea un dispositivo de bloque para cada dispositivo MTD presente en el sistema. El acceso a esos dispositivos de bloque se hace a través de los nodos de dispositivo /dev/mtdblock, motivo por el cual aparecen en la ejecución de mount.
Una vez entendido esto es más o menos sencilo realizar una correlación. Así por ejemplo, para realizar una imagen forense del dispositivo boot habrá que emplear mtd2
http://www.sahw.com/images/forensics/android/ddboot.png
Para trasladar el fichero al equipo del investigador existen varios métodos. El más cómodo es usar la funcionalidad pull de ADB, aunque aquellos que tengan SSH o un servidor FTP pueden recuperar los ficheros empleando esos protocolos, o incluso montando la tarjeta en un lector de tarjetas.
http://www.sahw.com/images/forensics/android/adb_pull.png
Una vez tengamos los ficheros en la máquina podemos analizarlos empleando nuestro procedimiento habitual. Así por ejemplo, para el dispositivo mtd5 (userdata), la ejecución de búsqueda de cadenas empieza a ofrecer datos interesantes sobre el usuario del teléfono, como por ejemplo claves wireless precompartidas o la presencia de bases de datos en la carpeta /data
http://www.sahw.com/images/forensics/android/adb_wifi.png
http://www.sahw.com/images/forensics/android/adb_databases.png
Una de las ventajas del método pull de ADB es que podemos procesar ficheros en lote. A tenor del posible interés que pueda tener, procesamos la carpeta de datos al completo trasladándola al equipo del investigador:
http://www.sahw.com/images/forensics/android/adb_pull_data.png
Una vez en nuestro equipo, un listado del directorio basta para comprobar que las probabilidades de encontrar información confidencial del usuario son elevadas:
http://www.sahw.com/images/forensics/android/adb_data.png
Correo, contactos, YouTube, Facebook, Google Apps, Gmail, Seesmic, MMS ... hasta algún juego (iMobsters, os lo recomiendo, por cierto). Aunque algunas bases de datos están vacías (por ejemplo la de Facebook, que se crea al lanzar la aplicación pero que nunca he utilizado) algunas sí contienen información relevante. La información que contienen estas bases de datos es la que te puede provocar serios problemas si pierdes un teléfono de estas características, y ahora veremos por qué.
Por ejemplo, de la base de datos de Seesmic podemos, aprovechando que es un formato SQLite, extraer a partir del esquema la información de las cuentas declaradas en la aplicación:
http://www.sahw.com/images/forensics/android/adb_sqlite_twitter.png
De la base de datos de correo también es fácil obtener las claves:
http://www.sahw.com/images/forensics/android/adb_sqlite_email.png
En otras ocasiones encontraremos bajo los directorios shared_prefs distintos ficheros XML en claro que también incluyen información interesante:
http://www.sahw.com/images/forensics/android/adb_sqlite_swiftp.png
De donde se puede comprobar que la clave de mi servidor FTP en el teléfono es 1234. Prometo cambiarla :)
Conclusiones
Yo no voy a entrar a comentar aspectos de usabilidad de Android, porque para eso hay cientos y cientos de publicaciones que ya lo han hecho antes que yo. Lo que sí quiero hacer es un comentario a la vista de lo que hemos estado analizando.
En mi caso particular, este Android corre en un Nexus One. Es un teléfono que no incorpora cifrado, como sí puede incorporarlo, por ejemplo, una BlackBerry o un Nokia E71. Esto representa un grave problema para los usuarios: si pierdes un teléfono que está pensado para que desarrolles toda tu vida online en él, el volumen de la pérdida normalmente será elevado.
Este problema no es sólo de Android o del Nexus One. Es de muchos más teléfonos que permiten que el usuario tenga todas sus aplicaciones favoritas en él sin forzar el uso de cifrado y contraseñas maestras, lo que provoca que todas las claves sean accesibles ante un evento de pérdida o robo con métodos similares a los mostrados: Redes sociales, correo, mensajes, contactos, etc.
Ante esto, lanzo a los desarrolladores de Android el mensaje de que al menos yo agradecería que el sistema soportase nativamente cifrado, y estoy seguro que los usuarios también lo terminarían agradeciendo. Hago extensivo el mensaje a los demás desarrolladores de sistemas de teléfonos inteligentes, como no podía ser de otro modo, aunque sé que es un mensaje que no suele despertar simpatías, por las implicaciones en la usabilidad (y por ende ventas) que suele tener el cifrado.
Fuente: http://www.sahw.com/wp/archivos/2010/05/23/analisis-forense-de-telefonos-basados-en-sistemas-android/
