Android Log Forensics

El uso del sistema operativo Android está creciendo a una velocidad que asusta. Los últimos datos dicen que cada día se activan 1,3 millones de dispositivos Android y que, si sigue este ritmo, en 4 años habrá más sistemas de Google en funcionamiento que sistemas Windows. Dedicar esfuerzo de investigación hacia este sistema se hace totalmente necesario, y en seguridad, un área importante e interesante es el estudio forense.

Un analista forense debe ser capaz de extraer el máximo de información disponible del dispositivo. Dependiendo del propósito de la investigación, se centrará en extraer unos determinados datos u otros. Por ejemplo, un investigador que analiza un posible smartphone infectado con malware necesitará los procesos en memoria, las conexiones activas, el tráfico entrante y saliente, mientras que en el análisis de un móvil cuyo dueño es sospechoso de un delito, buscará datos que pueda ayudar a la investigación a aportar evidencias, como las llamadas realizadas, emails, posición GPS, fotos, historial de chat, etc.

Tenemos varios métodos para extraer información en un dispositivo android: volcado de memoria RAM, imagen de memoria NAND, de la memoria externa SD-card y extracción de datos en caliente. El post de hoy se va a centrar en recuperar datos mediante comandos propios del sistema de Android, y concretamente, en los logs generados por el sistema.

Sin embargo, hay que tener en cuenta un concepto claro: el análisis de los logs generados en una máquina en vivo tiene dos principales riesgos:

• Los datos generados por comandos de una máquina no se pueden tomar por 100% fiables, puesto que el dispositivo puede estar deliberadamente comprometido, y generar datos falsos. Solo se puede estar seguro de los datos extraídos si los comandos ejecutados provienen de una fuente confiable.
• El hecho de ejecutar comandos propios de un sistema para extraer información altera el estado original del dispositivo, por lo que se podría romper la cadena de custodia.

No obstante, el análisis forense de un dispositivo móvil es más complicado que el de un equipo clásico. No se puede sacar fácilmente la memoria de almacenamiento interno del sistema, es decir, extraer el disco duro, y hacerle una imagen. En este caso hay que extraer la memoria mediante técnicas de chip-off y suele ser bastante complicado y costoso. Además, apagando el dispositivo se corre el riesgo de no volver a acceder al sistema, por tener la partición de sistema cifrada o dispositivos de bloqueo por contraseña. Hay que valorar por tanto si merece la pena afrontar los dos riesgos anteriores para extraer información del dispositivo en caliente, que con los otros métodos no sería posible recuperar.

Como apunte, en un futuro probablemente estos problemas estarán solucionados gracias a poder recuperar toda la información mediante el análisis del volcado de la memoria RAM. Por ahora se puede conseguir bastante información, volcando la RAM con LiME y analizándola con volatility. La siguiente versión de éste último promete mayor soporte para Android. En una próxima entrada se explicará con más detalle este método.

Dicho esto, vamos a mostrar algunos ejemplos útiles. El primero es logcat. Esta aplicación vuelca eventos generados por el sistema. Actualmente Android tiene cuatro buffers que recogen eventos: main, system, events, y radio. Estos se encuentran en /dev/log. Pueden mostrarse cada uno de ellos con el parámetro -b:

$ logcat -b radio
D/GSM     (  641): [GsmDCT] onReceive: action=android.net.wifi.WIFI_STATE_CHANGED
D/GSM     (  641): [GsmDCT] onReceive: action=android.intent.action.SCREEN_OFF
D/GSM     (  641): [GsmDCT] stopNetStatPoll
D/GSM     (  641): [GsmDCT] overall state is IDLE
D/GSM     (  641): [GsmDCT] onReceive: action=android.intent.action.SCREEN_ON
[..]

Por defecto no inserta los timestamps, pero se pueden incluir con el parámetro -v time:

$ logcat -b events -v time
10-30 12:24:31.476 I/am_kill (  351): [2908,com.google.android.calendar,15,too many background]
10-30 12:24:31.486 I/am_proc_died(  351): [2908,com.google.android.calendar]
10-30 12:24:31.486 I/am_proc_bound(  351): [10397,com.google.android.apps.docs]
10-30 12:24:31.946 I/am_kill (  351): [573,com.google.android.gm,15,too many background]
[...]

Normalmente estos logs suelen ser muy “verbosos” y nos puede interesar que muestre entradas a partir de nivel warning:

$ logcat -b system -v time *:W
10-30 06:35:42.286 W/ThrottleService(  351): unable to find stats for iface rmnet0
10-30 06:39:42.676 W/AlarmManager(  351): setInexactRepeating ignored because interval 0 is invalid
10-30 06:39:43.376 E/NetdConnector(  351): NDC Command {737 resolver flushif wlan0} took too long 
   (60002ms)
10-30 06:45:43.316 W/ThrottleService(  351): unable to find stats for iface rmnet0
[...]

El resto de parámetros se puede encontrar en la web de ayuda de desarrollo Android.

Otras dos herramientas vuelcan muchísima información sobre el estado del dispositivo: dumpsys y dumpstate. Dumpsys muestra un montón de información sobre los servicios del sistema, mientras que dumpstate recopila información a través de /proc (además de volcarte un dumpsys también). Como el tamaño del log mostrado suele ser de varios MB, con dumpsys se puede mostrar información de un servicio concreto:

$ dumpsys cpuinfo
Load: 0.0 / 0.03 / 0.27
CPU usage from 17672ms to 958ms ago:
  24% 351/system_server: 22% user + 2.5% kernel / faults: 4232 minor
  0% 30188/com.levelup.touiteur: 0% user + 0% kernel / faults: 662 minor
  1% 142/adbd: 0.2% user + 0.7% kernel
  0.5% 692/com.google.process.gapps: 0.5% user + 0% kernel / faults: 250 minor
[....]

Se pueden enumerar los servicios disponibles para mostrar con el siguiente comando:

$ dumpsys | grep DUMP
DUMP OF SERVICE SurfaceFlinger:
DUMP OF SERVICE accessibility:
DUMP OF SERVICE account:
DUMP OF SERVICE activity:
DUMP OF SERVICE alarm:
[...]

Por último, el comando bugreport es la madre de todos los comandos de logging, puesto que vuelca la salida de dmesg, logcat, dumpsys, y dumpstate.

Para hacerlo más cómodo para el investigador, hay una aplicación llamada chkbugreport que procesa la salida de bugreport y la muestra más amigable al usuario, en forma de informe en html.