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!.

Se nos pueden ocurrir muchas y muy complejas técnicas para tratar un volcado de RAM, pero nunca debemos olvidarnos que normalmente la solución más sencilla, suele ser las más eficiente. Así que nada tan sencillo como un buen “strings” (comando de Unix). El proceso es sencillo, primero ejecutamos un “strings” contra el volcado de RAM para extraer todas las cadenas de texto que esta pueda contener. Luego a ese fichero de “strings”, a través de la expresión regular: egrep “[a-z 2-7]{16}\.onion” Fichero_Strings, «parseamos» (¿interpretamos?) todas las direcciones .onion que Tor Browser pudiera haber almacenado en la memoria RAM. Es importante recordar que las direcciones web de Tor v2, son direcciones de 16 caracteres, por eso lo de la opción: {16}, formadas por letras de la A la la Z y números del 2 al 7, ([a-z 2-7]) en la expresión regular, terminadas siempre en .onion. De este modo podemos extraer todas las direcciones .onion que la memoria RAM almacenaba cuando la hubiéramos capturado, finalmente con el comando “uniq”, le indicamos que solamente nos muestra direcciones únicas, es decir, que si una direcciones se repite dos veces, solamente la muestre una sola vez. De este modo obtendremos un indicio de navegación a un sitio concreto de la red Tor.

 

Fig. 6 Expresión para extraer las direcciones .onion

 

Si copiamos cualquiera de estas direcciones .onion, y la pegamos en nuestro navegador Tor Browser, podremos visitar la misma página web de Tor (siempre que se encuentre disponible) que el usuario visitó y cuya URL quedó almacenada temporalmente en la memoria RAM del equipo. En este caso el usuario buscó a través del buscador de Tor: DuckDuckGo – 3g2upl4pq6kufc4m.onion (subrayado en color rojo) la página web “Cual es mi IP” (subrayado en color verde), como así se puede determinar a través de la siguiente imagen.

 

Fig. 7 Página web en Tor extraída a través de la la RAM

 

Terminada la parte de “cliente”, nos vamos a por la del “servidor”, hasta ahora estábamos analizando un equipo desde el que alguien se conectó a la red Tor para hacer lo que fuera, y si lo estamos analizado es que no fue nada bueno. Ahora nos vamos con nuestro kit de análisis a la parte del servidor, el cual ofrece el contenido para que sea accesible desde la red Tor, puede ser un servicio: web, ssh, telnet, ftp… o lo que sea. Para averiguarlo tan solo tenemos que acceder a la ruta (por defecto) etc/tor/ y abrir el fichero “torrc”, en él tendremos toda la configuración con la que estaba operando Tor en el momento de la adquisición o análisis. En el caso que nos ocupa, podemos comprobar que hay dos servicios ocultos configurados, uno en el puerto TCP 80 (Posiblemente un servidor web) y otro en el puerto TCP 22 (Posiblemente un servidor SSH), como vemos, en este caso, estos puertos vienen redireccionados del 2580 y del 2522. Además podemos observar que el fichero dónde se encuentra la “private_key” (la “llave” que adjudica la propiedad a un dominio en Tor) y el “hostname” (el dominio de Tor “.onion” en sí), está almacenado en la ruta: /home/toruser/tor_directory/hidden_Service/ (detalle de seguridad el haber creado un nuevo usuario para la ejecución del servicio de Tor). Por otra parte en este fichero podemos configurar variables como los países de los nodos de entrada, tanto en lista blanca, como lista negra, el tiempo que permanecen activos los circuitos o si queremos ser nodo intermedio o de salida, etc…

 

Fig. 8 Configuración Tor a través de torrc

 

Fig. 9 Configuración de los nodos de Tor a través de torrc

 

Continuando un poco con la senda de la información que vamos descubriendo, ahora nos toca ir a la ruta: /home/toruser/tor_directory/hidden_Service/, dónde como ya dije tendremos el fichero “private_key” y “hostname”, tal como se ve en la siguiente imagen, hemos averiguado que este servidor en concreto era desde dónde estaba publicado en servicio correspondiente al dominio de Tor: manunjzzbatsnnsd.onion. Hay que recordar que normalmente cada servicio oculto, dispone de su propio hostname.

 

Fig. 10 Hostamente .onion descubierto

 

Como no podía ser de otro modo, Tor también nos deja muchos logs de todas sus operaciones, un ejemplo de ello lo podemos encontrar en la ruta: /var/log/tor (por defecto). Los logs que encontramos en este directorio nos pueden servir para saber durante que franjas de tiempo estuvo operativo el servicio de Tor (este tipo de servicios es habitual que solamente estén operativos durante unas horas al día o unos días en concreto), así como poder ver la configuración con la que estaba operando. De nuevo, podemos ver como una misma información la tenemos repartida en varios lugares distintos del sistema a analizar.

 

Fig. 11 Log de Tor

 

Una vez que ya sabemos que lo que estaba “sirviendo” esta instancia de Tor a través del puerto 80 TCP era un servidor web Apache, tan solo tenemos que ir a la ruta por defecto: /var/www/html/ y ver qué es lo que estaba publicado en este sitio en concreto de Tor, en la siguiente imagen se observa el index.html (raíz del sitio).

 

Fig. 12 Código web de una página web en Tor

 

Y dónde hay un Apache, hay logs de Apache, así que solo nos tenemos que mover un par de directorios, para llegar a la ruta /var/log/apache2 y poder exprimir todos los logs de este servidor web. Al estar estos directamente relacionados con la instancia de Tor, nos podrá aportar información para entender globalmente que estaba haciendo este servidor en Tor. Lógicamente, no vamos a tener las direcciones IP de los usuarios que se conectaron a este servidor a través de Tor, ya que todas las direcciones quedaran registradas como “localhost” por aquello del TCP 80 al 2580, pero sí que vamos a disponer de un «fingerprint» muy básico, de los visitantes de este sitio: navegador web, sistema operativo, etc…

 

Fig. 13 Logs de Apache

 

Finalmente en los ficheros: “cached-microdescs” y “state” guardados en la ruta /var/lib/tor tendremos información sobre las fechas de inicio del servicio de Tor, las versiones, configuraciones, etc… Si recordáis en el apartado de Tor Browser también os hablé del fichero “state”, en este caso es eximente lo mismo, pero desde el lado del servidor.

 

Fig. 14 Fichero de micro descriptores

 

Fig. 15 Uso de la red Tor a través del fichero state

 

Si os gusta el mundo de Tor y queréis profundizar un poco más en el funcionamiento de esta red, desde un punto de vista más técnico a nivel de enrutamiento de tráfico, os dejó el video del taller titulado: “Cambiando el CuenTOR”, que Francisco Rodríguez @0fjrm0 y yo, impartimos hace dos años en el evento de ciberseguridad CyberCamp de INCIBE celebrado en la ciudad de León.

 

Fig. 16. Video taller: «Cambiando el CuentTOR»

 

En este taller se aborda desde el punto de vista del trafico de red a través de TOR, no tanto a nivel forense, por lo que de este modo podréis ver las dos caras de la moneda, por una lado cómo se comporta el navegador Tor Browser a nivel forense en un equipo con Windows o Linux, y por otro lado, como opera la red tor a través de sus distintos relays y bridges.

 

Fig. 17 Logo congreso de ciberseguridad C1b3rWall

 

¿Os ha gustado el taller que impartí con Francisco Rodríguez en Cybercamp 2016 sobre TOR y os habéis quedado con ganas de mas?. Pues estad atentos a la web de C1b3rWall @C1b3rWall, el primer congreso de Seguridad Digital y Ciberinteligencia que se celebrará del 17 al 20 de junio de este año, en la Escuela Nacional de Policía Nacional en Ávila: c1b3rwall.es

¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.

 

Pulsa Aquí para invitarme a un café con hielo.

  Salu2.