Mostrando entradas con la etiqueta forensic. Mostrar todas las entradas
Mostrando entradas con la etiqueta forensic. Mostrar todas las entradas

martes, 13 de octubre de 2015

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


"Comienza haciendo lo que es necesario, después lo que es posible y de repente estarás haciendo lo imposible"
S.F.d.A.










viernes, 20 de febrero de 2015

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

jueves, 5 de febrero de 2015

¿Sabes qué procesos corren en tu sistema?


Cada vez me adentro más en la rama del análisis forense en sistemas Microsoft Windows y es por ello que hoy os traigo una nueva entrada al blog después de llevar mucho tiempo ausente sobre los procesos que corren en tiempo real en nuestro sistema operativo Windows.

Muchas veces me he preguntado que procesos se ejecutarán al instalar un programa del cual no me fío mucho y seguro que muchos de vosotros también os los habéis preguntado. Como bien sabéis, una parte fundamental de un análisis forense es la de tener una copia de seguridad siempre de la imagen real del disco duro que vayamos analizar y trabajar a partir de dicha copia. También es de vital importancia intentar trabajar con herramientas que vayan por linea de comandos ya que son más ligeras y se modifica menos la memoria RAM por lo cual, os traigo una herramienta nativa de Windows llamada tasklist que va por linea de comandos y sirve para conocer los procesos que se encuentran corriendo en el sistema. Si la usamos sin ninguna opción nos mostrará una lista muy parecida a la pestaña de Procesos del Administrador de tareas, pero en nuestro caso la utilizaremos con la opción /SVC para así poder saber que servicios dependen de los procesos que corren en el momento y que nos muestre solamente el nombre del proceso, PID y al servicio que pertenece. Por supuesto, todos estos resultados podemos arrojarlos a un archivo de texto añadiendo > nombredelfichero.txt que se guardara en la ruta en la que nos encontremos en ese mismo instante.

Salida del comando tasklist

Salida del comando tasklist con la opción /SVC

Salida del comando tasklist con la opción /SVC
Como podemos observar en la salida del comando tasklist con la opción /SVC nos muestra solamente lo que queremos saber sobre los procesos y sus servicios a los que pertenece junto al PID por lo que de esta manera, podemos comprobar en un análisis forense si el sistema infectado tiene algún proceso en ejecución malicioso y más tarde comprobar alguna conexión que pudiese tener con el exterior con otra aplicación nativa de Windows llamada netstat. Añadir que en alguna ocasión deberemos utilizar herramientas que utilicen sus propias APIs para detectar procesos y conexiones ocultas ya que muchas veces el malware avanzado es capaz de modificar el retorno de las llamadas a las APIs de Windows y no veríamos nada extraño con las herramientas propias de Windows. Es por esto que es recomendable utilizar herramientas que implementen sus propias funciones de acceso a los datos.


Al igual que tasklist, Process Explorer también permite comprobar los procesos que corren de en un equipo en tiempo real y archivos DLL que se han abierto o cargado pero esta vez en un entorno gráfico. Uno de los beneficios de que se visualice gráficamente es que podemos ver  los procesos en su estructura jerárquica. Así, sin un proceso es el padre de otro aparecerá identado. Process Explorer nos muestra dos pantallas al abrirlo. En la parte superior nos mostrará todos los procesos activos, PID, nombre de la compañía etc.. Mientras que en la parte inferior nos mostrará diferente información dependiendo del modo en el que tengamos Process Explorer como podría ser; identificadores que ha abierto el proceso seleccionado en la parte superior, los archivos DLL y los asignados en memoria que el proceso ha cargado..

Procces Explorer

Una de las cualidades que contiene esta herramienta no nativa de Windows, es la integración de VirusTotal para poder analizar los procesos que están corriendo en el momento sobre nuestro sistema. Este análisis se realiza gracias a que Process Explorer envía hashes de los archivos y no el propio archivo para que nos muestre el resultado del scan que tienen almacenado en la BBDD de anteriores scans y muestra el resultado de los 57 antivirus que poseen.


Process Explorer mostrando una amenaza por VirusTotal en un servicio


Puede pasar que en la columna de VirusTotal aparezca "Unknown". Eso quiere decir que dicho archivo y versión nunca fueron subidos a VirusTotal pero, nosotros mismos podemos subirlo haciendo click en Options > VirusTotal.com > Submit Unknown Executables.

Enviando ejecutables desconocidos a VirusTotal.com

Para enviar un archivo a VirusTotal manualmente basta con hacer doble click sobre el proceso que queramos enviar para que analicen y hacer click en "Submit" en la pestaña que se nos abrirá.

Enviando a VirusTotal un proceso

A continuación os dejaré que significa cada color en los procesos que aparecen en Process Explorer.

Process Explorer colores


Un saludo :-)!