Tor Forensics Advanced. Part 2

Publicado el Por Manuel Guerra

Aquí estoy de nuevo, después de un pequeño parón para poder dedicarme a otros quehaceres, vuelvo a retomar GLIDER.es justo dónde lo dejé, hablando de lo que más me gusta, de análisis forense informático, en este caso, hablando de análisis forense en TOR. En la primera parte de este artículo: “TOR Forensics I”, os contaba todos los artefactos forenses que podemos extraer del navegador Tor Browser, ya que este no es otra cosa que un Mozilla Firefox modificado. Sin embargo en esta segunda parte, un poco más avanzada y técnica, os voy a hablar en primer lugar del resto de artefactos forenses que nos podemos encontrar cuando se ejecuta el navegador Tor Browser, ya sea en un sistema Linux o Windows, artefactos como por ejemplo los ficheros de configuración de Tor, así como los vestigios que Tor puede dejar en la memoria RAM.


Fig. 1 Tor Forensics II

 

Como ya comenté muchas veces, Tor no es solo un cliente, es decir, un sistema para conectarnos a un lugar. Ese lugar al que nos conectamos también formará parte de la red TOR y de ello también os voy a hablar en este nuevo artículo, comentando toda la información forense que se puede extraer de un servidor que se ha utilizado para ofrecer un servicio a través de la red Tor.

Comenzaremos hablando por un fichero bastante importante en lo que a forense en Tor Browser se refiere, este es el fichero: “state”, el cual nos permitirá determinar los distintos bridges que el navegador Tor Browser ha usado, así como sus direcciones IP (¡OJO! Estas no son las direcciones IP públicas del usuario), de forma indirecta podremos averiguar cuando fue la última vez que se escribió este archivo, o lo que es lo mismo, la última vez que se inició Tor Browser en ese equipo, ya que para que Tor Browser puede conectarse a la red, tiene que tener actualizado este fichero.

 


Fig. 2 Actualización del fichero “state”

 

Otro dato importante del fichero “state” es la versión de Tor con la que se está operando (No confundir con la versión del navegador Web). Normalmente, podremos encontrar este fichero en la ruta de instalación de Tor Browser: “/Browser/TorBrowser/Data/Tor/state” (Linux o Windows)

 


Fig. 3 Versión Tor

 

Es importante distinguir a la hora de realizar un análisis forense sobre Tor: Tor Browser (el Mozilla Firefox modificado) de lo que es la red Tor en sí (sistema de servidores y enrutadores que nos permite acceder a los distintos nodos y servicios que nos ofrece esta red). Lógicamente, una cosa necesita de la otra, pero son independientes al a hora de realizar el análisis.

 


Fig. 4 Versión Tor Browser

 

Que en la primera parte de este artículo, hubiera nombrado una serie de bases de datos y ficheros, no significa que solo sean estos los ficheros que pueden ser interesantes a nivel forense. He reseñado los que desde mi punto de vista pudieran ser interesantes, pero para poder realizar un análisis en profundidad de este navegador es necesario realizar un trabajo pormenorizado con cada uno de los ficheros que nos podamos encontrar durante el análisis, ya que en caso de que se actualice el navegador o el sistema Tor, estos artefactos pueden modificarse y dejar de proporcionar la información que ahora nos dan, o también que simplemente pase a almacenarse en un lugar distinto al ahora explicado.

 


Fig. 5 Aviso de actualización de Tor Browser

 

Pero… – ¿Que es lo que no nos podemos olvidar de analizar en un artículo de este tipo?, eso es, – ¡La memoria RAM!. Como ya dije al principio de este artículo, TOR Browser, está pensado para enrrutar tráfico a través de la red Tor, pero no está pensado para ofrecernos anonimato mas allá de lo que es la propia red, por lo que a nivel forense, podremos aplicar técnicas usables en cualquier otro navegador, como por ejemplo el análisis de RAM. No os voy a contar como capturar la RAM de un equipo, ya que lo he explicado en otros artículos anteriores. Tampoco hablaremos de Volatility, la navaja suiza del análisis de memoria RAM, hoy vamos a ser un poco mas artesanales, tan solo utilizaremos dos herramientas para realizar este análisis de RAM, un “grep” y un “uniq” (comandos de Unix) . ¡Vamos a ello!. Seguir leyendo

TOR Forensics. Part 1

Publicado el Por Manuel Guerra

En este nuevo artículo de GLIDER.es os quiero mostrar otro punto de vista sobre TOR. Hasta ahora había hablado de TOR desde el punto de vista de la red, es decir, del enrutamiento de comunicaciones a través de la red onion. Pero hoy voy hablar sobre Tor Browser, es decir, uno de los navegadores web mas usados a la hora de acceder a la red TOR. En primer lugar es importante reseñar que no es lo mismo la red TOR, que el navegador TOR. Algunas veces escuchamos que alguien es usuario de la red TOR por usar el navegador Tor Browser, esto realmente no es así, el navegador es simplemente un medio para poder conectarnos a esta red. En realidad el navegador Tor Browser es un navegador Mozilla Firefox, modificado para que se puede conectar a la red TOR, pero por detrás prácticamente la forma de operar de un Tor Browser y un Mozilla Firefox es muy similar. De esto precisamente es de lo que voy hablar en este artículo: de un análisis forense del navegador Tor Browser para mostrar toda la información que se puede extraer de este. No hay que olvidar que la red TOR está pensada para ofrecer anonimato a sus usuarios, pero este anonimato se queda en el enrutamiento de los distintos paquetes a través de la red. A nivel local, es decir, a nivel del ordenador del usuario que se conecta a esta red, TOR no ofrece ninguna medida de anonimato, ya que realmente no está diseñado para ello, por lo que lo que voy a contar a continuación no se puede considerar una vulnerabilidad en la red TOR, ni mucho menos en el navegador Tor Browser, simplemente está diseñado así, y de eso, sea mucho o poco, nos tendremos que aprovechar para poder realizar nuestro análisis forense.

 

Fig. Tor Forensics

 

En primer lugar vamos a comenzar por el estudio del navegador Tor Browser, y toda la información que este va almacenado en sus distintas bases de datos y ficheros de configuración. Como ya dije anteriormente, si alguna vez habéis realizado un análisis forense del navegador Mozilla Firefox, os daréis cuenta que muchos de los pasos que a continuación voy a describir serán muy similares a los que ya conocéis de este otro navegador web.

Este análisis forense lo voy a realizar sobre una maquina Linux, mas concretamente sobre un Ubuntu v16 de 64bits. Aunque podréis comprobar que Tor Browser en sistemas Windows opera exactamente igual. En el caso de Windows podréis encontrar todos los ficheros “interesantes” en la ruta: “Tor Browser/Tor/TorBrowser/Data/Browser/profile.default/”, como así se puede observar en la siguiente imagen.

 


Fig. TOR Browser en Windows

 

Por el contrario, si necesitáis realizar un análisis forense de navegador Tor de un sistema Linux, tendréis que buscar estos ficheros en la ruta: “/home/user/.tor-browser_es-ES/Browser/TorBrowser/Data/Browser/profile.default”, que será el caso del análisis que ahora nos ocupa:

 


Fig.TOR Browser en Linux

 

Tor Browser, al igual que Mozilla Firefox, puede operar con un grado de “secretesimo” mayor o menor en función de la configuración que hubiera seleccionado el usuario. A continuación os muestro como sería la configuración de privacidad por defecto de un navegador Tor Browser recien instalado.

 


Fig. Configuración por defecto TOR Browser

 

Ahora nos metemos en materia y comenzamos con el análisis de las distintas bases de datos y ficheros de Tor Browser, comenzaremos, desde mi punto de vista con uno de los ficheros mas importantes que Tor Browser nos puede ofrecer a niver forense, la base de datos “places.sqlite”. Como su propio nombre indica, es una base de datos tipo SQLite, por lo que la podremos abrir si ningún problema con un visor de bases datos de este tipo.

 

Seguir leyendo

C0Nferencias

Publicado el Por Manuel Guerra

El tiempo pasa, y pasa para todo el mundo, ya hace más de media década que di mi primera conferencia de ciberseguridad, eran 20 chavales de un grado de Formación Profesional relacionado con la informática, sentí que podía compartir con ellos la mucha o poca experiencia que por aquellas tenía en el campo de la Ciberseguridad y el Análisis Forense. Hoy, siete años después, sigue ocurriendo exactamente lo mismo, me gusta compartir de forma desinteresada con quien esté interesado en aprender lo poco que le pueda enseñar, con esa filosofía nació GLIDER.es, un lugar dónde compartir mis aventuras y “researches” en Informática Forense y Hacking.

En estos siete años, ya son muchas las charlas que llevo a mis espaldas, muchas de ellas grabadas en vídeo y publicadas en plataformas como YouTube por parte de los organizadores, otras, en forma de curso gratuito subidas a plataformas de formación online, algunas otras no han podido ser grabadas, pero si dispongo de las diapositivas que utilice para impartirlas. De ahí la idea de este apartado “CONferencias” de Glider, dónde poder compartir con vosotros todo el material que estos años he ido generando para poder realizar estas conferencias. Fueron varios los que me comentaron que les costaba encontrar las presentaciones o los vídeos de las distintas charlas que había dado, ya que al estar desperdigadas por distintos sitios de Internet, no lograban localizarlas, ahora las iré centralizando todas aquí.

 

Fig. Stickers de distintas CONs

 

Lógicamente, este apartado no sería nada sin mis queridas CONs, (Conferencias de Ciberseguridad) en las que tan buenos ratos he pasado y pasaré: Hack&Beers por todo el territorio nacional, HoneyCON en Guadalajara, QurtubaCON en Córdoba; ShellCON en Santander, MorterueloCON en Cuenca, RootedCON en Madrid, AlbahacaCON en Huesca, MoscowCON en Moscú, PaellaCON en Valencia, CONPilar en Zaragoza, Hackron en Canarias CONAnd en Andorra, ForoCiber en Badajoz East Mad Hack en Arganda, X1RedmasSegura en Madrid, Jornadas CCN-CERT en Madrid y CyberCamp itinerante por España, y por supuesto programas como el de Palabra de Hacker y Mundo Hacker TV.

En este apartado CONferencias iré publicado las distintas conferencias que vaya impartiendo a lo largo del año, pero no puedo prometer publicarlas todas, muchas de ellas no son públicas y en otras, la organización no se puede hacer cargo de la grabación de la conferencia. El resto de conferencias, las podréis encontrar aquí:

 

 

Título: Mitos, debilidades y delitos imperfectos en Tor.

Evento: X1 JORNADAS STIC CCN-CERT Centro Criptológico Nacional.
Fecha: Diciembre 2017


Fig. Fotograma de la conferencia.

Ponentes: Francisco Rodríguez (INCIBE) y Manuel Guerra.
Editor video: CCN-CERT
Descripción: En esta ponencia realizamos un análisis de la red Tor desde un punto de vista realista, dejando sensacionalismos a un lado. En la primera parte de la charla, Francisco nos habla de los delitos cometidos a través de la red Tor así como de la surface web, realizado una comparativa de ambas redes. A continuación, Manuel Guerra, realiza una práctica en directo en la que se demuestra una serie de vulnerabilidades que pueden existir en la red Tor, las cuales pueden permitir identificar plenamente a un usuario de esta red.
Difusión: Pública.
Materiales: Enlace al Video.

 

Título: Investigación en Informática Forense y Ciberderecho.

Evento: CyberMOOC – Universidad de Extremadura.
Fecha: Octubre 2018


Fig. Inicio del MOOC

Ponentes: Andrés Caro (Profesor de la Universidad de Extremadura), Enrique Avila (Director del Centro Nacional de Excelencia en Ciberseguridad), José Aurelio (Auditor Informático en Evidencias), Silvia Barrera (Experta en Ciberseguridad), Manuel Guerra, Pablo Gonzalez (Technical Manager & Security Telefónica Digital España), Ruth Sala (Directora del despacho de abogados Legalconsultor.es), Susana Gonzalez (Socio gerente en Ecixgroup) y  Tote Sancho (Personal Científico e Investigador de la Universidad de Extremadura).
Editor video: Miriadax
Descripción: Este MOOC gratuito está indicado para todos aquellos que deseen iniciarse y profundizar en Informática Forense y Derecho Tecnológico. El MOOC está especialmente orientado a una audiencia muy heterogénea: Profesionales del mundo de la informática que deseen formarse en aspectos técnicos de informática forense, hacking ético y ciberseguridad, a la vez que aprender la legislación que acompaña todo ese tratamiento técnico. En él os hablaré desde un punto de vista básico, qué es, y para que sirve la informática forense.
Difusión: Pública, previo registro.
Materiales: Enlace al Curso Gratuito.

 

Título: Taller: Autopsia a Whatsapp.

Evento: Congreso de Ciberseguridad CyberCamp 2017 – Santander.
Fecha: Diciembre 2017


Fig. Autopsia a Whatsapp

Ponentes: Manuel Guerra.
Editor video: INCIBE
Descripción: La idea de este taller, eminentemente práctico, es demostrar y mostrar toda la información que se puede extraer desde el punto de vista forense, de la aplicación de mensajería instantánea más utilizada en España y en el resto de Europa: WhatsApp.
Difusión: Pública.
Materiales: Enlace al Video.

 

Título: Taller: Cambiando el CuenTOR.

Evento: Congreso de Ciberseguridad CyberCamp 2016 – León
Fecha: Diciembre 2016


Fig. Cambiando el CuenTOR

Ponentes: Francisco Rodríguez (INCIBE) y Manuel Guerra.
Editor video: INCIBE
Descripción: El objetivo del taller es desmitificar mucha de la información proporcionada por los medios de comunicación sobre red TOR, proporcionando al público información realista obtenida de primera mano tanto por INCIBE, UIT y TOR Project. Se proporcionaran el conocimiento práctico para el uso de Tor desde un punto de vista técnico.
Difusión: Pública.
Materiales: Enlace al Video.

Seguir leyendo

Forense en Babia. Parte 3

Publicado el Por Manuel Guerra

Llegados a este punto, significa que ya habéis leído la Primera y Segunda parte de esta serie de artículos sobre Análisis Forense en la Nube. En los “episodios” anteriores os contaba la parte teórica del funcionamiento de los sistemas de computación en la nube, para a continuación, explicar como realizar un análisis de la información y artefactos forenses que pudiera albergar un sistema en la nube, en este caso, una instancia de Ubuntu 16, alojada en la nube de Amazon WS.

En este último apartado (III), os contaré como realizar un análisis forense en e vivo de estas máquinas o instancias en la nube, más concretamente como realizar un análisis de la memoria RAM de una instancia de AWS. Quizás en otra ocasión os cuente como realizar un análisis de tráfico de red de una máquina en la nube, pero de momento, nos vamos a centrar en el análisis de la memoria RAM.

 

Fig. Ejecución de htop en una máquina Ubuntu

 

Que la máquina a analizar sea un Ubuntu 16.04 no es fruto de la casualidad, en la parte anterior de este artículo ya os contaba que seleccioné un sistema operativo tipo Linux a propósito. Analizar la memoria RAM de un sistema Windows, no tiene mucha complicación, poco importa que la máquina se encuentre en la nube o delante de nuestros ojos, el procedimiento es prácticamente el mismo. Sin embargo, con Linux la cosa cambia bastante, no es que sea imposible realizar un análisis de la RAM de un sistema Linux, pero no hay un protocolo tan simple o intuitivo como puede ser con un Windows. Si utilizamos la herramienta Volatility nos daremos cuenta que prácticamente, por defecto, ya viene con todos los perfiles de los distintos sistemas Windows que tenemos en el mercado (XP, Vista, 7, 10… así como con sus distintos “Servipacks”), cosa distinta ocurre con los sistemas operativos Linux, en los cuales tendremos que compilar nosotros manualmente cada uno de los perfiles del sistema, para que Volatility “entienda” como funciona cada uno de los kernel de Linux. El problema es que la versiones de Windows prácticamente se cuentan con los dedos de la mano, si embargo el número de kernels de Linux existentes hoy en día, son prácticamente infinitos, ya que cada cual puede “engendrar” el suyo propio, lo que imposibilita que Volatility pueda incluir todos los perfiles de todos los kernel de Linux existentes.

Pero tampoco nos vayamos a asustar, que no venga incluido en Volatility un perfil por defecto, no quiere decir que no se pueda realizar un análisis de la memoria RAM de ese sistema, a continuación os detallaré cuales son los pasos necesarios para poder realizar este análisis, pasos que por cierto, no difieren mucho de un análisis físico a un análisis en la nube.

Explicado esto, ahora nos toca ponernos manos a la obra, en primer lugar, tendremos que saber cual es el Kernel de nuestra máquina Linux “victima”, para ello la teoría dice que ejecutando el comando ”uname -r” nos devuelve la versión del Kernel. Pero en este caso, vamos a hacer un poco de trampa. No nos interesa interactuar en exceso con nuestra máquina victima, digamos que ya sufrido lo suyo con el ciber ataque que recibió, como para seguir ejecutando comandos y procesos en ella.

 

Fig. Versión de Ubuntu 16.04 en AWS

 

Seguir leyendo

Forense en Babia. Parte 2

Publicado el Por Manuel Guerra

Si en el artículo anterior: “Forense en Babia. Parte 1” os contaba solamente la parte teórica de los sistema de computación en la nube, en esta segunda y tercera parte nos meteremos hasta la cabeza en el barro y pasaremos a la parte práctica del análisis forense en la nube. Como ya os imaginareis, cada vez son más las infraestructuras informáticas que operan en la nube, es decir, en un tercer lugar fuera del alcance físico de los administradores de sistemas y también de los analistas forenses informáticos, lo que implica que tanto para unos como para otro, su labor diaria cambie drasticamente. Los administradores de sistemas ganaran en tranquilidad al no tener que estar preocupados por fallos de hardware, ya que de estos fallos se encargan otro, los “dueños” de la nube. Pero para los analistas forenses la cosa cambia, la costumbre ancestral de todo lo que se “volcaba”, “clonaba” y “analizaba”lo podíamos ver y tocar con nuestras manos cambiará con el análisis forense en la nube, ya que la nubes no se tocan, solo se huelen 😉 .Para este cambio de paradigma tendremos que disponer de una mente abierta que nos permita adaptarnos a estas nuevas técnicas y modalidades de análisis, aunque si bien es cierto que los protocolos se basan en las técnicas tradicionales que llevamos años y años ejecutando, habrás ciertas peculiaridades como las que hoy os voy a contar, que harán que este tipo análisis sea un poco mas complejo.

Vamos al lío, en esta ocasión nos tocará analizar una instancia de un Ubuntu 16.04 de 64bits, sin interfaz gráfico, la cual está desplegada en los servidores de Irlanda de Amazon Web Services (AWS), la cual ha sufrido un ciber ataque, en el que alguien ha podido tomar el control remoto de esta instancia, para desplegar una servidor oculto en la Dark Web para vender droga a través de TOR, lógicamente, todo ello sin el permiso de los dueños de la instancia de AWS.

El primer paso, será acceder al panel de administración de la instancia afectada para de este modo poder determinar las características técnicas de la misma. En la siguiente imagen podremos ver toda esta información, como por ejemplo: Nombre de la Instancia (VPS IRLANDA); Dominio público con el que está operando (ec2-34-244-248-204.eu-west-1.compute.amazonaws.com) ; Tipo de Instancia (t2.micro); Zona de operación (eu-west-1c); Estado (Running / Stopped..); Identificador único de la instancia (i-09d357…); Grupos de Seguridad y las IP publicas y privadas de la instancia (172.31.21.174 y 34.244.248.204). Toda esta información la deberemos registrar debidamente.

 

Fig 1 Panel con las características de una Instancia AWS

 

También deberemos anotar las Keypass asociadas a la instancia (NambCORE), esto es la “key” que nos permite establecer una conexión remota segura a través de SSH con la instancia en cuestión, es decir, para poder administrar la instancia deberemos tener acceso a este fichero, si sospechamos que alguien se ha podido conectar de forma fraudulenta a nuestra instancia, significará o que han tenido acceso a nuestra “key” secreta, o que nos han generado una nueva para establecer una nueva conexión, por eso es importante listar todas las keypass generadas para una misma instancia. En esta ventana también podremos ver que tipo de instancia se trata (ubuntu-xenial-16.04-amd64-server-20170811 ); las tarjetas de red habilitadas (eth0); el tiempo que la máquina lleva encendida (51 horas) o los volúmenes de almacenamiento disponibles (/dev/sda1).

 

Fig 2 Características técnicas de la instancia 

 

Otra comprobación rutinaria, pero no menos importante será comprobar la configuración de las reglas del firewall que han sido habilitadas, en este caso, nada relativamente sospechoso (Un 80 y un 22).

 

Fig 3 Reglas Firewall

 

Llegados a este punto deberemos tomar una decisión muy importante: mitigar el ciber ataque cortando por lo sano, apagando la máquina afectada o “desconectándola” de Internet, o dejándola lanzada para analizar todas las comunicaciones que establece. En todo caso no hay una respuesta concreta, todo ello dependerá de cada caso y de la importancia del recursos afectado, así como de la información que contenga o de la disponibilidad que necesite. No hay que olvidar que ahora mismo el principal problema que tenemos, es la falta de control absoluto sobre la totalidad de los elementos afectados, en realidad solo tenemos un acceso web y en el mejor de los casos una conexión SSH a una máquina física que se encuentra a miles de kilómetros de nosotros y en la que verdaderamente está ocurriendo el ciber ataque. No podemos desconectar cables, no podemos conectarnos a una pantalla del Hypervisor, no podemos tirar del enchufe, no podemos sacar los discos duros… – ¿Y que podemos hacer?. – Vamos a verlo.

Lo primordial será salvaguardar la evidencia, para ellos crearemos un snapshot de la instancia afectada:

 

Fig. 4 Proceso de creación del Snapshot 

 

Fig. 5 Snapshot terminado

 

Ahora con el snapshot que acabamos de crear, generamos un volumen lógico del mismo.

 

Fig. 6 Creación de un Volumen desde un Snapshot 

 

En este momento ya disponemos una “copia forense” del disco duro del servidor afectado, pero tenemos un pequeño problema, la “la copia forense” se encuentra a varios miles de kilómetros de distancia de nosotros, y lo que es peor, de nuestro laboratorio forense. Por desgracia AWS, no dispone de un sistema 100% que nos permita “descargar” o “traernos” esa copia forense de una forma sencilla. Por eso que si la montaña no va a Mahoma, tendrá que ser Mahoma quien vaya a la montaña. – ¿Y como va a ir Mahoma a esa montaña?, o lo que es lo mismo: – ¿Como vamos a llevar un laboratorio forense a los servidores de Amazon Web Service de Irlanda?. – Muy fácil, ¡llevándolo!.

Tranquilos, no tendréis que comenzar desconectar vuestras pantallas de 40 pulgadas ni vuestros equipos forenses del laboratorio para llevarlo todo a Irlanda, esta vez será un poco mas fácil. Básicamente la idea es levantar una nueva instancia de Ubuntu en la misma zona de AWS (eu-west-1a), instalar las herramientas forenses de SIFT – Sans para así convertir el Ubuntu en una máquina forense y después asignarle el volumen lógico (disco duro) que hemos creado sobre la maquina afectada, y así poder analizarlo todo ello en remoto. Para ellos seguiremos los siguientes pasos:

Generamos una nuevo usuario “administrador” a nuestro AWS.

 

Fig 7 Generación de usuario 

 

Descargamos el fichero .pem para poder establecer la conexión remota SSH a nuestra máquina forense.

 

Fig. 8 Descarga del fichero 

 

Creamos una nueva instancia, la cual se convertirá en nuestra máquina forense. Aunque en un principio podrá ser perfectamente un Windows, veremos en las próxima parte de este artículo, que si levantamos una instancia exactamente igual a la afectada, podremos matar dos pájaros de un tiro y así ser un poco mas eficientes a la hora de realizar el análisis.

 

Fig. 9 Levantamos un Ubuntu 16.04

 

Como ya dije anteriormente, nuestra nueva instancia forense, deberá estar obligatoriamente en la misma zona de AWS (eu-west-1a) que el volumen que hemos generado anteriormente (no en la misma zona que la instancia afectada), ya que si no, no podremos “conectar” ambos elementos.

Seguir leyendo