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,
Me ha parecido muy interesante el artículo.
Aunque por desgracia no puedo probar nada de esto al no disponer de un maquinon como ese, apoyo totalmente tu petición de cifrado nativo en todos este tipo de teléfonos, tanto en SO Android como en el resto.
NaCl u2
¡Excelente artículo Sergio!
Te refieres a las BBDD de cada aplicación. Entonces…cifrar de forma nativa android o hacer lo mismo con SQLLite. ¿Podría hacerse lo segundo no? Quiero decir, ¿no es problema del propio desarrollador no implemetar cifrado en su aplicación? ¿O te refieres a quitar esta carga al desarrollador haciendolo de forma nativa en el SO?. ¿Esto último no trae una carga al sistema y tiene repercusión en su rendimiento?
¿Pasa lo mismo con las bases de datos por ejemplo de contactos del telefono?
eifersucht,
Yo apostaría por el cifrado completo de los medios. Si dejas que cada desarrollador haga sus pinitos, acabarás con 50 cifrados distintos por teléfono. Además la idea del cifrado es proteger todo el teléfono, y no sólo aquello que el desarrollador estime oportuno.
BlackBerry o Symbian S60 son ejemplos de sistemas que soportan el cifrado completo de los medios (flash y tarjetas) sin que el rendimiento se vea afectado.
Un saludo,
El rendimiento _siempre_ se verá afectado al utilizar cifrado, es inevitable, aún con soporte hardware.
asd,
Tienes toda la razón del mundo. Permíteme reformular la frase a «sin que el usuario perciba una disminución del rendimiento» (es decir, sin que el rendimiento, a ojos del usuario, se vea afectado)
La idea es que al final el rendimiento no penalice la usabilidad. Pero el rendimiento, obviamente, siempre se verá afectado como bien dices. Aún así, lo verdaderamente relevante es que esa disminución no provoque una falta de rendimiento que sea notoria y visible para el usuario.
Un saludo,
Muy interesante el artículo.
Parece increíble que Android, teniendo a mano todo el desarrollo libre de Linux, no implemente una solución de cifrado y otras soluciones hasta ahora (o hasta hace poco) cerradas, como Symbian, sí lo hagan.
Me parece raro, ya que con Google se puede estar mas o menos de acuerdo, pero suele hacer muy bien su trabajo.
Sergio Hernando
Gracias por la respuesta. De todos modos. En el momento que se detecte alguna vulnerabilidad en ese cifrado nativo esto pondría en serios problemas cualquier aplicación y es aquí donde un desarrollador puedo estimar oportuno usar su propio cifrado. Por tanto el rendimiento se vería dos veces penalizado porque supongo que ya hay aplicaciones que ya implementan sus propias herramientas de cifrado. Lo se, es un poco rebuscado, pero ¿qué no lo es? De todos modos es un gran articulo.
Como es necesario ser root para acceder a ese nivel del sistema, si no lo eres, no tendrías estos problemas de privacidad, ¿no?
Preocupante sin duda si te roban o pierdes un teléfono con Android. Sería bueno tratar si actualmente hay soluciones para asegurar o borrar esos datos en casos de emergencia.
si que hay distintas aplicaciones para hacer un wipe del telefono una vez que lo hayas perdido
Mosquis,
La única diferencia de ser root es que obviamente tienes acceso a parte del sistema que el usuario regular no puede acceder, y por tanto, en un análisis como el mostrado, la diferencia es pasar de tener acceso parcial a total. Como no he ejecutado el análisis antes de ser root, no puedo darte las diferencias exactas, pero el análisis lógico es factible con y sin root (siendo el segundo más limitado)
Es absolutamente cierto que en muchos escenarios ganar root para tener acceso a todo puede implicar la pérdida de datos en el teléfono, y que por tanto ante un forense no entrañaría riesgos siempre y cuando exista la pérdida de datos.
No menos cierto es que sin cifrado un teléfono con root (el mío, sin ir más lejos) es susceptible de recuperación, y que los datos de usuario almacenados en /sdcard están igualmente expuestos esté o no esté el teléfono con root.
Sigo pensando que sería un punto a favor de Google que el teléfono soportase cifrado al vuelo, incluyendo /sdcard. Tengo un Nokia E71, y cuando abres el menú de configuración el cifrado para el medio flash y la tarjeta es cuestión de dos pulsaciones (cierto es que la tarjeta es más lenta, pero el teléfono es rapidísimo y cuando está activo ni lo notas). Idem para BlackBerry.
Un saludo,
Hola,
Antes de nada felicidades por el artículo. Al principio pensé que no podía ser tan cierto lo que estaba viendo, y que algo tan lógico tan simple no podía suceder. Bueno, me he puesto a trastear y ha probar. HE comprobado mis aplicaciones más críticas, y vale si he visto como algunas claves estaban escritas tal cual las introduje.
Aplicación WordPress, es una de ellas, aplicación facebook no he localizado mi clave, pero si la dirección de mails de todos mis amigos en FB, de la cuenta de gmail no he visto rastro, y para el resto de correos como uso k9 como cliente, tampoco he localicalizado las claves.
Podría seguir numerando pero, podría aburrir. En resumen he verificado como unas 20 aplicaciones de las que uso y solo en 3 he encontrado las claves escritas a fuego. Por que cifrar todo el data, si solo se tienen que encargar cada aplicación de aplicar un cifrado solo para las password.
Metodos como el de Astrid para sincronizar con el remember the milk mediante un token de validación que se genera en un momento dado, no parecen malos.
Sergio, gracias por el post.
Hola!
Yo quería hacerte una pregunta!!!
Tal vez sabes de alguna referencia para saber como es la estructura del manejo de memoria real del ANDROID. …bueno también estoy buscando la misma información para el SYMBIAN.
Te quedaría muy agradecido con esa ayuda!
At. Andrés
andyeryto@gmail.com
andyeryto,
Quizás en los foros de Android te aclaren un poco más el tema.
Yo buscaría información de Dalvik, ya que a fin de cuentas es la máquina virtual que utiliza Android, con lo que la gestión de memoria debería estar meridianamente documentada en la documentación de Dalvik.
Un saludo,
Un Mundo Seguro?
Yo defiendo el cifrado integral no sólo por las claves, sino por tu lista de contactos, los MMS, los SMS, tus fotos, tus twits … son muchas cosas las que hay que proteger (aunque el artículo sólo ilustra claves, fallo mío no haber documentado otros casos)
Creo que es el camino a seguir, y probablemente veremos a las plataformas móviles evolucionar en ese sentido.
Un saludo,
Muy interesante el artículo, sin duda pones el dedo en la llaga sobre algo que a muchos usuarios les pasaría desapercibido, y que puede comprometer la confidencialidad de toda la información que almacenen en su teléfono.
Saludos.
Además del cifrado de medios, algo dependiente del fabricante de turno, lo que sí está claro es que los desarrolladores también deben tener en cuenta el tema de la seguridad y sobre todo la relativa a las bases de datos.
Que el medio en sí tenga cifrado, no impide que se realice una consulta tan simple como la que nos ha mostrado Sergio para coger las claves. Esas claves deberían estar cifradas en la propia base de datos, así como otra información sensible. Esto dependería del desarrollo de la aplicación concreta en cada caso.
Todos han de contribuir.
Un saludo.
Si te quieren robar la información, te va a dar igual como esté grabada, cifrada o no… se acaba consiguiendo, es verdad que das más facilidad por no tenerla cifrada, pero, hay pocos casos de cifrado que no se puedan descifrar, y en los casos que no se puede, implica una complejidad añadida para las apk’s del sistema, ya que debería guardar la cadena cifrada en algún sitio, y aun así conociendo el algoritmo, acabarían descifrando.
VEO INÚTIL CIFRAR, pero si a tí te da una falsa seguridad…
No obstante existe la posibilidad investiga más en tu móvil;)
Excelente Articulo Sergio te felicito,
Quisiera hacerte una pregunta, tu dices que esta analisis lo hiciste en tu nexus con android y no es un movil con un sistema encriptacion y ademas dices que algunos celulares como los nokia o los blacberry tienen el sistema de encriptado. es en una versión en particular de android o en cual la hiciste???? es posible que este sistema de encriptación no lo tenga tambien el samsung galaxy? o ahora las tablets??
Gracias por tu respuesta
un buen dia para ti
Quisiera saber como reacer la asociación de archivos en mi Dispositivo que usa android. No se si me puedas dar una solución porque hasta hace unos días daba «click» sobre los documentos epub y me salían las aplicaciones disponibles para que escoja con cual abrir el documento pero hoy por defecto se me abre con el visor Html. No se que pasó que ya no sale el menú de aplicaciones disponibles. Ni siquiera me he metido a monear nada. Gracias de antemano.
Hola, me gustaria saber: cuál esl el manejo de sistemas de archivos de Android 3.0? Te agradeceria, toda información referente que pudieras facilitarme.
Jacqali,
http://developer.android.com/index.html
Es la fuente que siempre utilizo.
Un saludo,
HOla exelente articulo lo he encontrado por que anduve molestando en un sony ericsson xperia mini pro rooteado con android 2.1 update 1 y llegue aqui buscando como hacerle una imagen ya que habia podido acceder a los passwords en claro desde el rootexplorer y queria profundizar en mi caso probe las siguientes aplicaciones y ninguna de ellas tenia cifrado , meebo para android, twitdroid, en su ultima version, ebuddy, facebook, tweetdeck. Una ves pase por esto perdi toda esperanza de que alguna haga bien su tarea claro teniendo en cuenta que para acceder a la info se necesita root es un 1% de alivio… pero imaginate que tu eres un ejecutivo de una multinacional que tienes tu maquina android, y hay gestionas tus cuentas de mail, facebook, twitter, etc… en un ataque focalizado en ti y en tu telefono la cuestion cambiaria, pero esto solo son hipotesis. Mal por android en este aspecto para probar y salir de duda tambien probe lo mismo con el sdk y un android virtualizado y es igual e incluso mas facil.
Gracias por tu articulo.
Es muy necesario el cifrado, pero tedioso el cifrado nos limitaria la SD card como USB externo lo cual no es muy agradable para todos.
el windows mobile 7 funciona de esa forma por defecto y es un dolor de bolas todos se tiene que hacer con la aplicacion del telefono y como todos sabemos nunca son amigables.
y si existiera un cifrado en un producto tan famoso seria decifrado en muy poco tiempo ya que su solucion seria muy valiosa en el mercado.
en fin muy buen articulo disfrute mucho leyendolo.
Gracias por el manual, me gustaría hacer una pregunta.
Normalmente, cuando se realizan forensicas sobre dispositivos moviles es a causa de un proceso judicial en curso, el cual no permite la modificación de ningún aspecto del dispositivo auditado. Por lo tanto ¿Existe alguna posibilidad de realizar un volcado de la sd interna sin tener permisos de root?
Un saludo y gracias
Una pregunta de que manera puedo ralizar un analisis a la imagen obtenida que fostwarer usar, ya que el sistema de archivos es yaffs2 y no pude montar la imagen en linux.