Buenas,

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:

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:

 Nuestra primera ejecución será un listado del directorio raíz:

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:

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:

 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

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.

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

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:

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

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:

De la base de datos de correo también es fácil obtener las claves:

En otras ocasiones encontraremos bajo los directorios shared_prefs
distintos ficheros XML en claro que también incluyen información
interesante:

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.

Un saludo,
Autor: Sergio Hernando
Fuente: Seguridad de la Información y Auditoría de Sistemas

See the rest here:
Análisis forense de teléfonos basados en sistemas Android |