GBWhatsApp para Android ¿Es seguro?

Hoy os traigo mi primer post a C43S4RS hablando de una App alternativa a WhatsApp. 

Todos sabemos que WhatsApp tiene muy pocas opciones de personalización y privacidad, así que mucha gente busca Apps alternativas para poder sentirse a gusto cuando chatea con sus amigos. Si buscamos por Google, encontramos una App llamada GBWhatsApp (sustituta de WhatsApp Plus).

La gente que usa esta App, normalmente busca más personalización en su apariencia, ya que puedes modificar absolutamente todo, desde colores y formas de las fotos a tamaños de los archivos que se pueden enviar.

También tienen más opciones de privacidad como vemos en la siguiente imagen:

 

Read More

Hackeando el 2FA en Android

Muchos de nosotros hacemos uso del doble factor de autenticación (2FA: two step verification) y recomendamos su uso, ya que es una capa de seguridad más añadida a nuestras contraseñas en cuentas de correo, blogs y otros servicios en Internet. Si es complicado hacerse con nuestras credenciales, más aún poder obtener el código de verificación 2FA. Pero ¿qué pasaría si pudiésemos obtener ambas cosas al mismo tiempo?

En el siguiendo artículo vamos a ver como podemos obtener las credenciales de cuentas de correo electrónico así como los códigos de verificación almacenadas en un terminal Android. Antes de comenzar es muy importante recordar uno de los principios de la Seguridad en Android (vistos en el artículo Metodología de Seguridad en Android) donde para cada aplicación instalada en Android se crea un usuario, de tal forma que una aplicación no puede acceder a la carpeta de otra aplicación. Además dentro de la memoria del terminal tenemos una parte de memoria interna (sólo accede el sistema) y otra de memoria externa o de usuario (sin contar con el almacenamiento SD).

Todo esto está muy bien, pero esta seguridad se rompe en el momento en que rooteamos el teléfono o una aplicación maliciosa ejecuta un exploit el cual utiliza una vulnerabilidad del sistema para hacer una elevación de privilegios y hacerse root, de tal forma que una aplicación con permisos root tendrá permiso para campar a sus anchas y acceder a los ficheros que quiera en la memoria interna. 

Nosotros nos vamos a centrar en dos aplicaciones que podemos encontrar en muchos terminales Android, un gestor de correo y el gestor de 2FA. Las aplicaciones en concreto son:

• Correo (com.android.email)
• Google Authenticator (com.google.android.apss.authenticator2)

Una de las grandes vulnerabilidades de las aplicaciones Android que podemos encontrar dentro del TOP 10 Owasp Mobile Risks es el almacenamiento inseguro de datos, este tipo de vulnerabilidad es la segunda más encontrada como podemos ver en el esquema de OWASP.

Como hemos hablado anteriormente, dentro del sistema operativo Android existe una memoria interna en la cual se instalan las aplicaciones, concretamente la ruta es /data/data/ y ahí vamos a encontrar las aplicaciones de la cual queremos obtener información, tal cual como lo haría una aplicación maliciosa que consigue acceso root.

Insecure Data Storage en com.android.email

Esta aplicación de correo electrónico desarrollada por Google la podemos encontrar en muchas distribuciones de Android como parte del sistema operativo, tanto en ROMs de marcas comerciales como también en ROMs cocinadas.

Si nos traemos las todo el directorio /data/data/com.android.email/ podemos encontrarnos con que hay una base de datos SQLite muy interesante dentro del directorio databases: EmailProvider.db

Concretamente dentro de la tabla HostAuth podemos encontrar los correos configurados en el terminal junto con la contraseña en plano, algo increible pero cierto. Si abrimos este fichero con algún programa para visualizar SQLites encontramos lo siguiente:

Aquí no acaba la cosa, el sistema también almacena en texto plano las contraseñas de los correos en texto plano en el siguiente fichero /data/system/users/0/accounts.db 

Bueno ya tenemos los correos electrónicos y las contraseñas, si ahora intentamos acceder a alguno de estos correos nos solicita el 2FA. ¿Cómo hacemos para conseguir el código de verificación teniendo acceso al terminal como root?

Insecure Data Storage en com.google.android.apss.authenticator2

Vamos a ver ahora un caso parecido con la aplicación de Google Authenticator ¿Alguna vez os habéis planteado restaurar vuestro Android de fábrica con su correspondiente Wipe-Data pero no os habéis atrevido porque podéis perder el 2FA? 

Además de eso podemos preguntarnos (por aquello del pensamiento lateral de los hackers) qué ocurriría si copio el directorio completo /data/data/com.google.android.apps.authenticator2 y lo monto en otro terminal, ¿debería dejarme acceder a los códigos de verificación? ¿la instalación del Google Authenticator y los códigos que se generan debería ser única? es decir,si tendría algún tipo de protección por seguridad. Pues bien, la respuesta a estas preguntas es que no tiene protección, podemos hacer lo que queramos

Paso a paso, haremos lo siguiente:

 1. Copiamos la carpeta completa del terminal con la instrucción: 

adb pull /data/data/com.google.android.apps.authenticator2  

 2. Vemos que tenemos dentro tres carpetas: app_sslcache, databases y shared_prefs.

 3. Dentro de la carpeta databases nos centramos en el fichero databases.db y en la tabla accounts obtenemos lo que buscamos, las cuentas asociadas con su código secreto.

Con estos secret keys podemos generar los códigos de verificación asociados a cada una de las cuentas de correo cuyas contraseñas ya teníamos. Pero vamos a probar a montar toda la estructura de directorios en un emulador a ver si funciona el Google Authenticator, para ello primero instalamos la aplicación y acto seguido copiamos todo el directorio completo con las tres carpetas.

Instalamos con adb install <aplicación.,apk> y copiamos todo el directorio al emulador para ver si nos permite así cambiar los códigos de un terminal a otro simplemente con Copy/Paste. En la siguiente imagen vemos como lo permite perfectamente.

Conclusión

Hemos visto como por culpa de fallos a nivel de programación donde se lleva a cabo un almacenamiento inseguro de información sensible, se ven expuestas nuestras contraseñas y los códigos secretos de verificación. Cualquiera de nuestros terminales puede ser víctima de cierta aplicación maliciosa, de una vulnerabilidad de 0day o de una vulnerabilidad no parcheada por nuestro fabricante.

Recomendaciones

• Actualizar el sistema lo máximo posible, ya que los fabricantes no suelen sacar muy a menudo actualizaciones para forzarnos así a comprar nuevos terminales. Recomiendo en este caso el uso de ROMs cocinadas que parchean los fallos de seguridad a diario. 
• Hacer uso de herramientas de control de permisos para impedir a las aplicaciones tener más permisos de los necesarios, de tal forma que podemos así controlar quien accede a que recuersos. Podéis ver herramientas de control de recursos en mi artículo  Privacidad en Android del blog de Hacking Ético (http://hacking-etico.com/2014/08/12/privacidad-en-android/)
• Hacer uso de herramientas de seguridad como antivirus, antimalware y otras herramientas que te chequean los fallos de seguridad más reciente. Os recomiendo que uséis la herramienta Android Vulnerability Test Suite (https://github.com/nowsecure/android-vts) que os permite testear si tenéis las últimas vulnerabilidades parcheadas.
• Otras capas de seguridad recomendables serían deshabilitar el ADB (Android Debug Bridge), usar bloqueo de sesión bien con pin numérico de más de 5 dígitos o patrón y sobre todo cifra tu dispositivo por si cae en manos equivocadas. 

Formación en Seguridad Android

Si te interesa la seguridad en Android, los próximos cursos y talleres que impartiré serán los siguientes:

• Curso Forense en Android ( 29 Enero y 5 Febrero - Modalidad Online): curso totalmente práctico donde llevaremos a cabo el proceso forense de un terminal Android para obtener el máximo número de pruebas. Tocando directorios claves del sistema operativo como de las aplicaciones más utilizadas que nos brindan gran cantidad de información. Más información aquí.

• Taller Pentesting de Aplicaciones Android (12 Febrero Cuenca - MorterueloCon): taller de 4 horas sobre auditoría de aplicaciones móviles siguiendo la metodología OWASP. Más información aquí.

• Curso Pentesting en Android (27 Febrero Valencia): un curso presencial muy completo de 8 horas de duración, donde veremos los diferentes puntos del Pentesting en Android para poder auditar aplicaciones, analizar malware e incluso llevar a cabo un análisis forense de un terminal. Más información aquí.

Espero que os haya gustado el artículo y que tengáis presente que la seguridad 100% no existe, sólo podemos añadir cuantas más capas de seguridad mejor.

Un handshake

@eduSatoe

"Comienza haciendo lo que es necesario, después lo que es posible y de repente estarás haciendo lo imposible"

S.F.d.A.

Read More

Haciendo un DUMP de la memoria RAM

En un análisis forense es de vital importancia conseguir una copia exacta del sistema que se vaya analizar incluyendo la memoria RAM, teniendo ésta mucha importancia debido a la volatilidad que implica el poder llegar a perder los datos si la alimentación fallase porque como ya sabemos, la memoria RAM sólo almacenará datos cuando el sistema esté encendido. Es por esto que una de las primeras acciones para la recogida de evidencias será capturar todo lo que hay en la memoria física para poder analizarlo posteriormente sin alterar ningún dato.

Para poder hacer un dump de la memoria (volcado de memoria) existen varias herramientas que nos ayudarán a conseguir el objetivo. Yo os traigo las dos herramientas que mas me han gustado a mi después de haber estado probando unas pocas. Y por supuesto, de Microsoft Windows.

• Win32dd.exe - Win64dd.exe: Dependiendo del sistema operativo que utilices tendrás que usar una versión u otra. Esta sencilla herramienta nos hará una copia de la RAM tal cual esté en el momento. Según tengamos más o menos memoria física tardará mucho o poco, no tardará lo mismo para una RAM de 2GB que para una de 8GB. Esta herramienta funciona a través de la línea de comandos, por lo que tendremos que abrir un cmd y desde la ruta de donde tengamos el .exe escribiremos el siguiente comando: win64dd.exe /r /a /f dump.img. Vamos ahora a analizar para que sirve cada opción;
• /r -> Crea el archivo de volcado de memoria
• /a -> Contesta si a todas las preguntas que se hagan durante el proceso
• /f -> Fichero destinado (Nombre del fichero)

Como podemos ver en la imagen, sale información sobre el SO que usamos, la capacidad de la memoria, la cantidad que tenemos disponible etc.. 

Ejecutando el comando de win64dd.exe

Una vez se haya realizado el dump nos saldrá un mensaje como el de la siguiente imagen en el cual nos indica el tiempo que tarda en hacerse, el tamaño del fichero o el total de paginas escritas.

DUMP hecho exitosamente

Esta es una de las dos sencillas herramientas que traigo para hacer el volcado de la memoria física que va por línea de comandos y que puedes descargar desde aquí, la siguiente herramienta es en un entorno gráfico muy fácil de utilizar también.

• FTK Imager: La segunda herramienta también sirve para hacer una copia exacta de la memoria física del momento. Una de las ventajas que tiene esta herramienta al ser en un entorno gráfico, es que cuando conseguimos hacer la copia, podemos examinar el valor de la misma y así ver por ejemplo alguna password que haya quedado almacenada en la RAM al loguearnos en algún portal, los procesos que estaban abiertos y las conexiones activas, versión del sistema operativo y muchas más cosas. Para conseguir un volcado se haría de la siguiente manera: Al ejecutar el programa haremos click en el icono de la memoria que pone "Capture memory". 

Crear el volcado de memoria

          En la siguiente ventana que se nos abre, en destination path daremos click en browse para seleccionar el lugar de almacenamiento de dicha captura. Para finalizar haremos click en capture memory y empezará a realizar el volcado. Igual que en la anterior herramienta, dependiendo de la capacidad de nuestra memoria tardará más o menos. Una vez que tenemos la memoria capturada y quisiéramos verificar que está bien hecha la captura, deberíamos podemos verificarlo mediante el md5 o sha1 que nos da haciendo click con el botón derecho en su icono y más tarde en "Verify drive/image". Mientras tanto, vemos en la pestaña de abajo como el principio de nuestra memoria está lleno de 0, es algo normal pero si vamos bajando, vemos información que tenía almacenada la RAM cuando hicimos el dump. Os pongo dos ejemplo de una contraseña que se quedó guardada o de un simple proceso que estaba en ejecución en el momento de la captura.

Contraseña almacenada en la RAM de un campo hidden

Proceso en ejecución a la hora de realizar el dump

Esta herramienta como podemos ver nos podría servir de gran ayuda a la hora de realizar un análisis forense en la captura de evidencias, podemos ver que procesos había en ejecución incluso con las conexiones que realizarían estos mismos. FTK Imager podemos descargarla desde aquí.

Otras herramientas que también podrían servir son; NotMyFault de SysInternals, SystemDump o LiveKD



Viendo estas dos herramientas y la gran utilidad que tienen en un análisis forense para recoger evidencias he llegado a replantearme que la memoria RAM tiene mucha más información valiosa de la que yo pensaba, al ser volátil no la tenemos muy en cuenta pero nos puede servir para conseguir información muy valiosa sobre un sistema. Bueno y.. una vez conseguido el dump de la RAM ¿Qué? ¿Cómo vemos toda la información de una forma estructurada?
Para eso os traigo una gran herramienta  que incluye en su repositorio la distribución de seguridad informática Kali Linux llamada volatility que nos servirá de gran ayuda para ver que contiene nuestro volcado de memoria de una forma estructurada y con muchas opciones.



-Volatility: Para empezar, arrancaremos nuestro Kali y en un USB por ejemplo tendremos la copia del volcado que tendremos que haber hecho previamente. Empezaremos con el siguiente comando para que analice el volcado y nos dará información del SO que lleva instalado.

vol imageinfo -f /ruta/volcado.img

El siguiente comando nos ayudará para conseguir las direcciones de memoria donde están los registros del sistema. El comando que ejecutaremos eserá el siguiente. (Seleccionaremos el perfil que nos dio el resultado anterior)

vol hivelist -f /ruta/volcado.img --profile=perfil

Como ya dije anteriormente, la memoria RAM almacena cantidad de información, y una que nos puede ser muy útil es la de saber los procesos que había activos en el momento del dump para poder ver si había algun software malicioso ejecutandose.

vol pslist -f /ruta/volcado.img --profile=perfil

Y también podemos ver que procesos son hijos de que procesos pero esta vez añadiremos la opción pstree para ver en forma de árbol estos procesos.

vol pstree -f /ruta/volcado.img --profile=perfil

No nos vamos a olvidar de saber que servicios se estaban ejecutando en el momento del dump por supuesto, y para ello usaremos la opción svcscan.

vol svcscan -f /ruta/volcado.img --profile=perfil

Y por último he querido añadir también el comando ldrmodules que puede servir para buscar una dll oculta que haya en el sistema.

vol ldrmodules -f /ruta/volcado.img --profile=perfil

Esto es todo lo que os he querido mostrar en esta entrada de hoy, nos vamos sabiendo que en un análisis forense será de vital importancia hacer un volcado de la RAM siendo una de las primeras tareas que tengamos hacer debido a que es volátil. Este volcado podrá aportar a la hora de crear el informe final muchas evidencias y así conseguir el objetivo.

Un saludo!

@Joseliyo_Jstnk

Read More

Android Forensics: Descubriendo Cuentas de Usuario

Resulta que, como ya comenté en post anteriores, el principio de Locard sigue estando presente en la informática forense, el cual viene a decir que cuando dos objetos entran en contacto siempre se queda residuos (dicho bástamente ;) )

El caso es que si lo aplicamos a la informática forense y, partiendo de esa base, hay mucha probabilidad de encontrar evidencias cuando analicemos un dispositivo.

En este post vengo a mostraros CÓMO es posible identificar las cuentas de usuarios que han existido en un terminal (al menos en el mio) tras hacer una restauración de fábrica.

En ocasiones, y en los terminales Android, es muy común el hacer el típio "Resturar de fábrica" que básicamente lo que estamos haciendo es un Wipe al sistema, borrando todos los datos de usuario, cache de programas, aplicaciones, etc...

Dicho esto, recientemente lo hice en mi terminal, algo antiguo si, pero funcional, hablo de una Samsung Galaxy S GT i9000 el cual está rooteado y con una rom modificadad, CynanogenMod para ser más exacto.

Casi todos la información relativa al usuario y aplicaciones se almacenan en la partición de "Datos". Cuando hacemos un "Retore Default" o "Retaurar de fábrica" el proceso es bastante rápido, lo que me llevo a pensar que en algún lado tendría que hacer una "ligera" copia de los datos de usuario.

Al final, Android es un Unix y como bien sabéis el almacenamiento físico está unido al sistema a través de unos ficheros especiales (controladores) llamados nodos (device nodes). 

Estos nodos nos proporcionan acceso al dispositivo en bruto y a sus particiones, por lo tanto si un nodo de dispositivo es direccionado (cargado o montado por el sistema) nos lleva a pensar que todo el contenido del mismo es accesible por software (en este caso ADB), eso si como root, de ahí la importancia de tener el dispositivo "rooteado".

Podría estar hablando largo y tendido del tema de nodos, pero no es el caso, así que no me andaré más por las ramas.

El escenario es: Dispositivo Android recien restaurado de fábrica. Terminal rooteado y con acceso al mismo por adb.

El primer paso, al conectar el terminal al equipo es comprobar su conectividad, para ello:

$adb devices
List of devices attached
393320C3387D00EC    device

Observamos que el terminal está montado y es accesible por adb.
Lo siguiente que debemos hacer, y como he comentado antes, es acceder al mismo como usuario "root"

$adb root
$adb shell >> abrimos una sesión de terminal en el dispositivo

Ya tenemos nuestra consola abierta.
Vamos a ver qué particiones tenemos montado en el terminal, aqui he de decir que dependerá si nuestro dispositivo está basado en MTD (Memory Technology Device) o en EMMC (Embedded Multimedia Card), las particiones están montadas en /proc/mtd o /proc/emmc/ dependiendo de lo anterior:

root@GT-I9000:/dev/block # cat /proc/mtd                                    
dev:    size   erasesize  name
mtd0: 00780000 00040000 "boot"
mtd1: 00780000 00040000 "recovery"
mtd2: 1a600000 00040000 "datadata"
mtd3: 01180000 00040000 "cache"
mtd4: 00c80000 00040000 "efs"
mtd5: 01000000 00040000 "radio"
mtd6: 00b00000 00040000 "reservoir"

Mi Terminal está basado en MTD, así que me queda comprobar qué tipo de particiones corresponde a qué:

root@GT-I9000:/dev/block # cat /proc/partitions                             
major minor  #blocks  name

  31        0       7680 mtdblock0
  31        1       7680 mtdblock1
  31        2     432128 mtdblock2
  31        3      17920 mtdblock3
  31        4      12800 mtdblock4
  31        5      16384 mtdblock5
  31        6      11264 mtdblock6
 253        0      72804 zram0
 179        0    8028160 mmcblk0
 179        1    6062048 mmcblk0p1
 179        2    1966080 mmcblk0p2
 179        8   15622144 mmcblk1
 179        9   15618048 mmcblk1p1
 254        0     614400 dm-0
 254        1    1347584 dm-1

Llegados a este punto seguro que estáis diciendo, "UFFFFF no me entero de ná ;)", es fácil, lo que hemos hecho es preguntar qué particiones está montando el sistema al arrancar (/proc/mtd/) y luego le pregunto qué nodo es el que ha montado (/proc/partitions), mejor así no?? :D

Aqui es donde entra un poco la picaresca del analista, por decirlo de alguna forma, si somos observadores vemos que mtd1 > monta la partición de recovery y este a su vez monta el mtdblock1 pero... ¡¡¡ El terminal tiene una tarjeta SD !!!!!
Sin pegas, también está montada como mmcblk0p1

Menudo rollo no? La de vueltas que estoy dando, y ahora cuál analizo???

Todo va a depender un poco de cómo esté funcionando el almacenamiento y salvaguarda de los datos en el terminal, pero si que tenemos en claro que el recovery ha podido usar mtdblock1 como mmcblk0p1

Ya tenemos "lo gordo" localizado, ahora nos queda buscar información del usuario/s que han existido. Todos sabemos que cualquier terminal con SO Android ha de tener una cuenta de gmail

Así que vamos a buscarla ;)

$cd /dev/block

$strings mtdblock1 | egrep -o 'account="?.{1,25}@gmail.com"?'

 

Pues no me ha devuelto nada, vamos a probar con la MMC

 

root@GT-I9000:/dev/block # strings mmcblk0p1 | egrep -o 'account="?.{1,25}@gmail.com"?'>
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com
account=*********@gmail.com

Voila!!!! 

YA SABEMOS QUÉ USUARIO HA USADO SU CUENTA DE GMAIL EN ESTE TERMINAL

Pero me surge una pregunta, y si cambio la búsqueda y en vez de account busco password?

Os lo dejo para vosotros :)

Read More

SnaptChat: análisis forense

Mucho se ha hablado en este blog sobre las aplicaciones de mensajería para los smartphones y de los fallos de seguridad de las mismas.

No hace mucho tiempo leí este artículo sobre la aplicación de la que os voy a hablar a continuación, esta aplicación y cuyo nombre está en el título del Post es SNAPCHAT.

Podría deciros que SNAPCHAT no es más que otra aplicación de mensajería instantánea, pero no es así, el gancho que tiene dicha aplicación es que permite a los usuarios enviar imágenes, videos cortos o mensajes a través de sus smartphones. El remitente elige el tiempo que desea que su mensaje sea visible para la otra persona, con un mínimo de 10 segundos. Y después es eliminada del mensaje, vamos que desaparece. Pero...¿Desaparece totalmente?

Bien, pues ya os hacéis una idea de lo que hace la aplicación, no obstante en el artículo que menciono en los párrafos superiores, su uso entre adolescentes es para casos de sexting, así que como disponía de algo de tiempo libre me dispuse a instalarla en mi smartphone y ver si realmente cumplía su objetivo, pero eso sí, iba a ir un poco más allá en mi investigación.

Tras una primera prueba he de decir que realmente la aplicación cumple su objetivo, recibes una foto (es la prueba que hice) y al tiempo estipulado por el remitente de la misma ésta se borra.

Pues bien, aquí es donde entra mi curiosidad, y me acordé del principio de transferencia de Locard, que viene a decir en resumen "cada contacto deja un rastro", así que me puse manos a la obra.

He decir que la "mini" investigación está realizada sobre un terminal Android rooteado.

En primer lugar fué localizar la aplicación en el terminal, por regla general las aplicaciones que se instalan en terminales Android se almacenan en el directorio data o datadata (según versión).

Ya tenía localizada el directorio de la aplicación, así que para ver los datos que contenía de forma más cómoda me la descargué a un directorio de mi equipo:

Como podéis observar, he desplegado todo el contenido de los directorios para que os hagáis una idea de lo que contiene.

Mi primera intención, y en la consola antes de descargarla a mi equipo, fué dirigirme al directorio Files a ver si hay se almacenaba una copia de la imagen recibida, pero...Mi gozo en un pozo.

Mi siguiente paso fué abrir una de las bases de datos, las de google anaytics no me interesaban, así que abrítcspahn.db. Tras indagar en la base de datos, la cual como podréis ver en la siguiente imagen, tiene unas cuantas tablas, personalmente me llamaron la atención las tablas "StoryImageFiles" y "StoryImageThumbnailFiles", pues dicho y hecho a por ellas :)

La primera tabla "StoryImageFiles" no contiene datos, al menos en mis pruebas, ya que son eliminados de la misma, pero la siguiente "StoryImageThumbnailsFiles" si como podéis ver:

No hay que ser un hacha, nos está diciendo en qué directorio hay almacenada una miniatura de la imagen, pues ya tenemos la evidencia :) (Volved a mirar la captura de los directorios), y he aquí la imagen que me remití en mis pruebas, las zapatillas de mi niña :) :

Comentar, que la miniatura se guarda con la extensión jpg.no-media así que hay que eliminar el no-media para que sea legible su visualización.

Mi investigación no quedo ahí, me propuse indagar algo más, el resto de tablas que componen la BBDD podemos encontrar información de números de teléfonos añadidos a la aplicación, quién te ha mandado un mensaje, a quién se lo has mandado, campos TIMESTAMP etc... y además, podríamos obtener información EXIF de la imagen recuperada. Además, en los ficheros XML, se puede ver la información de la cuenta de correo que se ha utilizado para crear la cuenta, aunque el resto de datos esté cifrada.

No he realizado pruebas con los videos ni ninguna otra, así que animo a otros investigadores a realizar sus propias pruebas, y quien sabe, quizás algun investigador con más conocimientos es capaz de obtener más datos.

Nota: el post me lo publicaron en Security by Default

Read More

Análisis Forense en Android (Parte III)

Cómo comenté en la entrada anterior sobre análisis forense en Android y la obtención de evidencias sin tener rooteado el terminal, en esta nueva entrada voy a explicar cómo podemos obtener algunas evidencias básicas utilizando herramientas externas, eso si, open source.

Para este cometido disponemos de una pequeña aplicación desarrollada por la empresa ViaForensics. La aplicación en cuestión se llama AFLogical, la cual la podéis descargar desde aqui

Esta aplicación, una vez instalada sin ser root, nos permitirá obtener:

• Información sobre las llamadas
• Contactos del teléfono
• Mensajes MMS y adjuntos
• Mensajes SMS

Ya explicamos anteriormente el uso de adb y sus posibilidades, así que manos a la obra. Conectamos el terminal al equipo, nos abrimos una consola con nuestro adb instalado (voy a obviar los comandos previos ya que doy por echo de que los conoces. AH!!!! se me olvidaba, previamente hemos tenido que descargar la aplicación AFLogical.apk anteriomente mecionada.

$adb install e:\aflogical.apk
1251 KB/s (28794 bytes in 0.022s)
        pkg: /data/local/tmp/aflogical.apk
Success

Pues ya tenemos la aplicación instalada, ahora bien, como no quiero tocar el terminal, vamos a ejecutarlo (eso si, mi terminal no tiene bloqueo, si el vuestro lo tuviera deberíais leer este post) mediante abd.
Como toda aplicación que instalamos en android hemos de llamar al ejecutable, todos los ejecutables en android suelen estar en el directorio data/app

$adb shell am start -n  com.viaforensics.android.aflogical_ose/com.viaforensics.android.ExtractAllData
Starting: Intent { cmp=com.viaforensics.android.aflogical_ose/com.viaforensics.android.ExtractAllData }

Con ese comando lo que hemos echo ha sido ejecutar la aplicación con todas las opciones marcadas. Eso si, he de comentar que esta aplicación dispone de unas veriones de pago que nos permite obtener más información.
Si vieramos la pantalla del terminal tendríamos un cartel que nos diría que la extracción de datos se ha completado, tal cual la siguiente:

Ahora sólo nos queda recuperar los datos que la aplicación ha obtenido. Estos datos se almacenan, por regla general, en la sdcard externa y crea el directorio (en mi caso):
forensics/20130409.1234
Si lo analizamos un poco podemos deducir que 20130409 es la fecha actual 2013/04/09 y 1234 es la hora 12:34
Así que si nos conectamos por shell al terminal y ejecutamos la orden ls nos devolverá algo parecido a lo siguiente (dependiendo de la versión de aflogical.apk):

• CallLog Calls.csv
• Contacts Phones.csv
• DSC00295.jpg
• MMS.csv
• MMSParts.csv
• SMS.csv
• info.xml

Como podéis ver nos lo presenta en csv un formato más que legible para analizar los datos, así que sólo nos queda traernos esos datos a nuestra máquina para su posterior análisis:

$adb pull sdcard/forensics e:\aflogical
pull: building file list...
pull: sdcard/forensics/20130228.1158/Contacts Phones.csv -> e:\aflogical/20130228.1158/Contacts Phones.csv
pull: sdcard/forensics/20130228.1158/MMSParts.csv -> e:\aflogical/20130228.1158/MMSParts.csv
pull: sdcard/forensics/20130228.1158/MMS.csv -> e:\aflogical/20130228.1158/MMS.csv
pull: sdcard/forensics/20130228.1158/SMS.csv -> e:\aflogical/20130228.1158/SMS.csv
pull: sdcard/forensics/20130228.1158/CallLog Calls.csv -> e:\aflogical/20130228.1158/CallLog Calls.csv
pull: sdcard/forensics/20130228.1158/info.xml -> e:\aflogical/20130228.1158/info.xml
pull: sdcard/forensics/20130409.1234/Contacts Phones.csv -> e:\aflogical/20130409.1234/Contacts Phones.csv
pull: sdcard/forensics/20130409.1234/DSC00295.jpg -> e:\aflogical/20130409.1234/DSC00295.jpg
pull: sdcard/forensics/20130409.1234/SMS.csv -> e:\aflogical/20130409.1234/SMS.csv
pull: sdcard/forensics/20130409.1234/CallLog Calls.csv -> e:\aflogical/20130409.1234/CallLog Calls.csv
pull: sdcard/forensics/20130409.1234/MMS.csv -> e:\aflogical/20130409.1234/MMS.csv
pull: sdcard/forensics/20130409.1234/MMSParts.csv -> e:\aflogical/20130409.1234/MMSParts.csv
pull: sdcard/forensics/20130409.1234/info.xml -> e:\aflogical/20130409.1234/info.xml
13 files pulled. 0 files skipped.
705 KB/s (359236 bytes in 0.497s)

IMPORTANTE

No olvidéis desinstalar la aplicación:

$adb uninstall com.viaforensics.android.aflogical_ose
Success

Nos vemos en la siguiente entrada.

Things up!

Read More

Android Simular pulsaciones por ADB (Input KeyCodes)

Después de unos días desconectado de todo volvemos a la carga, esta vez os voy a hablar de cómo podemos simular que pulsamos una tecla o realizamos una acción en un terminal Android.

Este método lo podremos aplicar para, por ejemplo, activar el modo avión en un terminal que no tiene bloqueo de seguridad.

De todos es bien sabido que el ADB de Android nos permite, entre otras cosas, instalar y desinstalar aplicaciones, recuperar/subir ficheros, etc. 

Todo esto está muy bien, pero además el ADB nos proporciona una serie de acciones con las que podemos simular que presionamos físicamente la pantalla. Para ello disponemos de la siguiente tabla de acciones:

Ahora bien, supongamos que nos llega a nuestras manos un terminal Android al que hemos de realizar un análisis forense, ya hablábamos en un post anterior que es recomendable tener activado el modo avión para realizar el análisis, así que vamos a ponernos manos a la obra.

Ya sabemos que lo primero es que el terminal tenga el modo depuración activado, de lo contrario poca cosa podremos hacer, bien, lo conectamos a nuestro equipo y ... "Ha habido suerte" tenemos el adb activo, así que vamos a "cacharrear", bueno ya sabéis cómo comprobar que tenemos acceso al terminal, no? de no ser así te recomiendo leer este post.

A lo que vamos, vamos a hacer uso de lo mencionado anteriormente, activar el modo avión sin tocar la pantalla, para ello:

#adb shell am start -a android.settings.AIRPLANE_MODE_SETTINGS

Veremos como se abre la ventana de configuración del modo avión :)

Bien, dependiendo de cada versión de android, la activación de la casilla correspondiente puede estar más arriba o más abajo, así que nos podremos mover con los keycodes tabla anterior hasta la opción deseada y luego:

adb shell input keyevent 23 

Ya tendremos el terminal en modo avión, curioso verdad?? :D

Espero que os sea de utilidad.

Things Up!

Read More

Análisis Forense en Android (Parte II)

En la entrada anterior comenté la posibilidad de obtener datos del terminal sin ser root, se me olvidó comentar que es aconsejable tener el terminal en modo avión (aunque en muchos casos es necesario que esté rooteado, sobre todo si tiene patrón de acceso, clave, etc.). En en siguiente ejemplo que vamos a ver voy a usar el comando anteriormente mencionado:

#adb bugreport > bugreportAndroid.txt
#wc -l bugreportAndroid.txt
61497 bugreportAndroid.txt

Salen unas cuantas líneas que revisar, no?? :D

Aqui es importante, o cuanto menos aconsejable, que el terminal esté en modo avión y/o aislado de la red como mencioné en el post anterior, de lo contrario la ejecución del comando nunca terminará, dado que el terminal constantemente está pidiendo conexiones a la red, y lo tendréis que cortar, lo que ello conllevaría que, posiblemente, el report del comando esté incompleto.

Vayamos al tema!

Ya tenemos el fichero en cuestión, vamos a ver qué nos ofrece.

Nada más abrir el fichero veremos algo similar a:

========================================================
== dumpstate: 2013-03-13 16:14:56
========================================================

Build: cm_galaxysmtd-userdebug 4.2.2 JDQ39 eng..20130303.223331 test-keys
Build fingerprint: 'samsung/GT-I9000/GT-I9000:2.3.5/GINGERBREAD/XXJVT:user/release-keys'
Network: movistar
Kernel: Linux version 3.0.66-g6c5dade (xxxxxxxxxx@cyanogenmod)
Command line: console=ttySAC2,115200 loglevel=4 androidboot.serialno=XXXXXXXXXXXXXX bootmode=0

------ UPTIME (uptime) ------
up time: 3 days, 01:19:28, idle time: 1 days, 00:31:41, sleep time: 1 days, 19:24:50
[uptime: 0.1s elapsed]

Vamos a paranos un segundo en revisar estas líneas, podemos ver que el terminal es un Samsung GT-I9000, con la versión de Android GingerBread, Kernel XXJVT, Kernel Version 3.0.66, con cynanogenmod (rom de cynanogen ), operador Movistar, número de serie del terminal y el tiempo que lleva encendido. No está mal nada más abrir el fichero, no?

Voy a saltarme unos cuantos pasos y voy a ir al grano directamente.

Sabemos que el terminal es Android, por consiguiente el propietario del mismo ha de disponer de cuenta en goggle (ya sabés [usuario]@gmail.com) para que el terminal sea operativo al 100%. Pues al grano, realizamos una búsqueda en el fichero y buscamos el patrón: DUMP OF SERVICE account

Al realizar esta búsqueda encontraremos rápidamente el volcado de las cuentas del terminal, y podremos ver algo similar a lo siguiente:


DUMP OF SERVICE account:
User UserInfo{0:Jesus D.:13}:
  Accounts: 6
    Account {name=[usuario]@gmail.com, type=com.google}
    Account {name=[telephone_number], type=com.whatsapp}
    Account {name=[usuario], type=com.twitter.android.auth.login}
    Account {name=[usuario]@gmail.com, type=com.linkedin.android}
 


Pues no está nada mal, no? Básicamente y a un sólo click obtenemos el número de teléfono (eso si, por que el usuario tenía WhatsApp, y quién no??), la cuenta de correo, su cuenta de twitter, linkedin

Ahora bien, otro de los datos interesantes que podemos obtener es la última localización conocida del terminal, realizaremos los mismos pasos anterior, pero ahora el patrón de búsqueda será: DUMP OF SERVICE location

Hemos de encontrar algo así:

Last Known Locations:

    passive: Location[network [coordenada],[coordenada] [....]

Ahora sólo nos quedará ir a google maps y en el cuadro de búsqueda introducir los numeritos obtenidos, eso si IMPORTANTE tenéis que sustituir la coma por puntos, quedaría algo así (coordenadas inventadas) plasmado en el mapa.

Se pueden sacar muchas más cosas interesantes, pero no os lo voy a decir todo no?? Así que a estudiar :D jejejejej

Nos vemos en la siguiente entrada.

Si te ha gustado comparte!

Things Up!

Read More

Análisis Forense en Android (Parte I)

Llevo un tiempo queriendo hacer una mini-guía de cómo realizar un análisis forense a un terminal Android, al menos los puntos básicos, y hoy me he decidido a empezar :D (Nunca es tarde, no).

Como publicaba, a groso modo, en una entrada anterior , donde se describía el proceso de análisis forense, esa parte me la voy a saltar. No obstante publicaré con detalle todo el proceso de análisis forense.

Lo primer que hay que tener en cuenta, cuando nos encontramos en un análisis de un terminal Android es aislarlo de la red, vamos, cortarle toda comunicación con cualquier tipo de red. Lo idea sería disponer de una Jaula de Farady, y qué es esto os preguntaréis, pues básicamente un habitáculo que aísla el terminal de campos electromagnéticos. Por qué hacemos esto? Fácil, queremos conservar la información del teléfono tal cual está en el momento que se nos hace entrega. Lo ideal sería ponerlo en "Modo Avión" pero si tiene patrón de bloqueo, pin o cualquier otro patrón de acceso nos sería, prácticamente, imposible. Eso si, desde aquí es donde tenemos que empezar a documentar nuestra intervención.

Volviendo a la Jaula de Faraday, si no podemos poner el terminal en Modo Avión y tampoco disponemos de una Jaula de Faraday (lógico ya que son caras) yo os recomiendo que envolváis el terminal con Papel Albal, si si, como suena y leéis, Papel de Aluminio, nos hará el mismo efecto que una Jaula de Farady :) (qué cosas verdad :D), con esto tendremos el terminal aislado y podemos empezar a trabajar. (Probad a llamaros, dará que el terminal está apagado). NO le conectéis el cable y luego lo envolváis, ya que el mismo cable hará de antena, así que toca esperar hasta que podamos aislarlo completamente o activar el modo avión.

Por regla general, y desde la versión 2.2 de Android, Froyo, el modo Depuración USB viene activado al conectar el terminal, si esto no fuera así o estuviera desactivado poco podremos hacer, se podría intentar otra cosilla pero vamos a dar por echo de que está activado, de esta forma podríamos empezar con el análisis.

Creo que no es necesario mencionar que necesitamos el SDK de Android, pero por si acaso lo comento, es requisito casi indispensable, por no decir que Imprescindible, así que si no lo tenéis ya podéis descargarlo desde aquí.

Hasta ahora ya tenemos el terminal aislado y con el cable conectado, nos queda conectarlo a nuestro equipo, donde tendremos el SDK de Android y ponernos manos a la obra.

Lo primero que haremos es comprobar que tenemos acceso al terminal, os recomiendo familiarizados con la herramienta ADB (Android Debug Bridge)que incluye el propio SDK.

Una vez conectado el terminal, lo primero que haremos es verificar si está disponible para conectarlo por ADB:

Pues ya sabemos que el terminal tiene el modo depuración activado, vamos a ver si está rooteado o no:

Pues parece ser que no, nos tocará rootearlo (lo veremos en el siguiente post), pero de momento hay una serie de datos que podemos obtener sin ser root.

De todos es bien sabido que Android trabaja con un Kernel de Linux, bien, sabemos que el kernel es la capa más baja del sistema operativo y la cual provee acceso al hardware del dispositivo. Así que tenemos la posibilidad de consultarlo, al igual que en Linux, mediante el comando dmseg.  

¿Qué información podemos obtener?

Básicamente lo que podemos obtener, al ejecutar el comando, es un detalle a bajo nivel de la actividad del dispositivo, sellos de tiempo (arranque, apagado, etc.), e incluso tenemos la posibilidad de volcar el resultado a nuestro equipo para realizar un análisis más detallado:

#adb dmesg >dmesg.log

Android tiene varias técnicas de depuración adicionales disponibles. Otra aplicación interesante es el comando LOGCAT  que nos devuelve una lista permanentemente actualizada de los mensajes del sistema. Un análisis rápido de log devuelto nos puede proporcionar:

-          Datos sobre Longitud y Latitud del Teléfono

-          Información Fecha/Hora

-          Detalles de Aplicaciones

El registro es muy detallado. Es interesante conocer que cada mensaje del registro comienza con un indicador, siendo estos:

-          V: verbose

-          D: debug

-          I: information

-          W: warning

-          E: error

-          F: fatal

-          S: silent

Además, con logcat podemos obtener información detallada de la “radio” del dispositivo mediante el comando:

#adb logcat –b radio

Aunque el detalle del comando es bastante detallado, la exploración de esos registros nos puede proporcionar información muy interesante en nuestro análisis (la cual deberemos documentar), tales como:

-          Hora de los eventos

-         AT commands (radio) usados por el módem interno del terminal para establecer comunicaciones

-          Receptor, tamaño, hora y codificación de los mensajes de texto SMS

-          Ip del dispositivo e información de su localización

-          Información del proveedor de la red WiFi

Podemos decir que una de las características principales de logcat es la visualización de eventos:

#adb logcat –b events

Otra de las herramientas interesantes en nuestro análisis, es dumpsys

Dumpsys  nos ofrece información de los servicios, memoria, y otros detalles del sistema que nos puede proporcionar gran información. Alguna de la información interesante que podemos encontrar es:

-          Servicios actualmente en ejecución

-          Volcados de los servicios

-          Etc.

No sólo podemos obtener los programas utilizados, sino que nos puede revelar, en muchas ocasiones, las cuentas del usuario del teléfono (gmail, Exchange, facebook, twitter, …)

Normalmente todos los códigos de tiempo que podemos obtener se encuentra en milisegundos.

El último comando, pero no menos interesante es bugreport el cual combina todos los anteriores:

#adb bugreport > bugreport.log

#wc –l bugreport.log

42575 bugreport.log

Si te ha gustado comparte, no cuesta nada :)
Nos vemos en la siguiente entrada!!

Things Up!!

Read More