Aprovechando que desde hace algn tiempo tengo un Nexus One quiero compartir con vosotros los pasos bsicos para poder realizar una auditora forense de este tipo de dispositivos, con el fin de que comprendis un poco mejor cmo se organiza el sistema de ficheros en Android y cmo localizar informacin sensible dentro del mismo. Tambin quiero que este texto sirva para ilustrar que la prdida o el robo de un telfono 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 informacin sensible sera largo y costoso. Prefiero hacer una descripcin general y poner algunos ejemplos prcticos que espero sean de vuestro agrado y utilidad. Estos ejemplos estn enfocados al anlisis forense de un sistema de ficheros, con lo que otras partes del sistema como la memoria no estn cubiertas. Si te interesa esta ltima disciplina, quizs te interese este artculo.
Requisitos previos
  • Ser root en el sistema, lo cual se logra normalmente desbloqueando el bootloader para proceder a ganar root. Hay infinidad de artculos al respecto en Internet. En la enorme mayora de los artculos se utliza fastboot para desbloquear el bootloader y superboot para ganar root arrancando una imagen boot.img que permite la ejecucin con usuario root. Ganar root implica perder la garanta del telfono, as que abstente si no tienes absolutamente claro cmo hacerlo.
  • La manera natural de intractuar con el telfono 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 mquina 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 depuracin USB tiene que estar activada en el telfono.
  • De modo altrnativo, es factible tener un servidor SSH instalado en el telfono. Con paciencia y un poco de conocimiento se puede echar a andar Dropbear. Tambin se pueden emplear ROMs que tengan el demonio SSH incorporado. Por ltimo puedes comprar en el Market una aplicacin que habilite un servidor SSH sin complicaciones, como por ejemplo QuickSSHD.
Conectando con el telfono
En este artculo emplearemos el SDK de Android, que incluye la herramienta Android Debug Bridge (ADB) para conectar al telfono. En mi caso particular el rendimiento de conectar va SSH en una red WLAN es muy pequeo a causa de la seal, con lo que prefiero hacerlo con el telfono 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 ms le guste:





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 documentacin. A los que usis 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 hacis estos dos pasos no veris el dispositivo conectado. Una vez conectado el dispositivo, lanzamos la consola:



Nuestra primera ejecucin ser un listado del directorio raz:



El sistema de ficheros Android
Android est basado en un ncleo Linux. Como tal la manera de aproximarse al sistema es la que usaramos en cualquier derivado de Unix, teniendo en cuenta las particularidades de cada caso.
Un primer vistazo nos revela la composicin del sistema de ficheros:



En lo que a dispositivos se refiere se puede observar que los puntos de montaje para /system, /data y /cache estn asociados a distintos mtdblocks presentes en /dev/block/. Es tambin el caso de la tarjeta SD externa que acompaa a este modelo de telfono, 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 telfono, 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 ms informacin de los dispositivos inspeccionando /dev y /proc:





En esta ltima captura podemos ver otro distintivo caracterstico de los dispositivos MTD, y es que en vez de tener sectores como los dispositivos de disco, tienen eraseblocks cuyo tamao 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, slo 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 mdulo automticamente se crea un dispositivo de bloque para cada dispositivo MTD presente en el sistema. El acceso a esos dispositivos de bloque se hace a travs de los nodos de dispositivo /dev/mtdblock, motivo por el cual aparecen en la ejecucin de mount.

Una vez entendido esto es ms o menos sencilo realizar una correlacin. As por ejemplo, para realizar una imagen forense del dispositivo boot habr que emplear mtd2



Para trasladar el fichero al equipo del investigador existen varios mtodos. El ms cmodo 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.



Una vez tengamos los ficheros en la mquina podemos analizarlos empleando nuestro procedimiento habitual. As por ejemplo, para el dispositivo mtd5 (userdata), la ejecucin de bsqueda de cadenas empieza a ofrecer datos interesantes sobre el usuario del telfono, como por ejemplo claves wireless precompartidas o la presencia de bases de datos en la carpeta /data




Una de las ventajas del mtodo pull de ADB es que podemos procesar ficheros en lote. A tenor del posible inters que pueda tener, procesamos la carpeta de datos al completo trasladndola al equipo del investigador:



Una vez en nuestro equipo, un listado del directorio basta para comprobar que las probabilidades de encontrar informacin confidencial del usuario son elevadas:



Correo, contactos, YouTube, Facebook, Google Apps, Gmail, Seesmic, MMS ... hasta algn juego (iMobsters, os lo recomiendo, por cierto). Aunque algunas bases de datos estn vacas (por ejemplo la de Facebook, que se crea al lanzar la aplicacin pero que nunca he utilizado) algunas s contienen informacin relevante. La informacin que contienen estas bases de datos es la que te puede provocar serios problemas si pierdes un telfono de estas caractersticas, 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 informacin de las cuentas declaradas en la aplicacin:



De la base de datos de correo tambin es fcil obtener las claves:



En otras ocasiones encontraremos bajo los directorios shared_prefs distintos ficheros XML en claro que tambin incluyen informacin interesante:



De donde se puede comprobar que la clave de mi servidor FTP en el telfono 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 telfono 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 telfono que est pensado para que desarrolles toda tu vida online en l, el volumen de la prdida normalmente ser elevado.

Este problema no es slo de Android o del Nexus One. Es de muchos ms telfonos que permiten que el usuario tenga todas sus aplicaciones favoritas en l sin forzar el uso de cifrado y contraseas maestras, lo que provoca que todas las claves sean accesibles ante un evento de prdida o robo con mtodos 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 agradecera que el sistema soportase nativamente cifrado, y estoy seguro que los usuarios tambin lo terminaran agradeciendo. Hago extensivo el mensaje a los dems desarrolladores de sistemas de telfonos inteligentes, como no poda ser de otro modo, aunque s que es un mensaje que no suele despertar simpatas, 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/