Aplicación práctica sobre NetcaTor, una shell inversa a través de Tor

Uno de los puntos débiles de los atacantes a la hora de exfiltrar información comprometida es la exposición de parte de su infraestructura tecnológica durante el proceso. En este sentido, la red Tor ofrece la posibilidad de hacer accesibles servicios en una máquina como servicios ocultos o hidden services aprovechando la capa de anonimato que ofrece y así evitar que quede expuesta la localización real de la máquina.

La configuración de un hidden service es sencilla y además está bien documentada por parte de los desarrolladores del proyecto Tor dentro del propio código como en la propia web del proyecto. Virtualmente, cualquier servicio que utilice tráfico TCP puede ser creado a través de la red Tor modificando la configuración del archivo torrc.

La creación del hidden service con Tor instalado en una máquina requiere la edición del fichero de configuración de Tor torrc que se encuentra en la ruta /etc/tor/ en sistemas operativos Linux. En las líneas del fichero 63 y siguientes se detallan ejemplos de cómo configurar un hidden service. La primera de ellas establecerá la ruta en la que se almacenará la información relativa al hidden service y que será creada si no existe por el servicio que arranca Tor. En esa ruta se almacenan dos archivos importantes: hostname, que contiene el dominio que otros podrán utilizar para acceder al servicio y private_key, el fichero que almacena la clave privada del hidden service y cuya custodia queda a cargo del administrador del sitio siendo necesario que permanezca secreta.

Por ejemplo, en el caso de que hubiéramos desplegado un servidor Apache en el puerto 80, podríamos hacerlo accesible a través de un hidden service editando la configuración y descomentando la información de las líneas 72 y 73 de dicho fichero para crear los archivos hostname en la ruta /var/lib/tor/hidden_service/ y redirigir el tráfico que reciba Tor en el puerto 80 a ese hidden service al puerto 80 de la máquina local en donde está esperando el servidor Apache.

Esta aproximación podría llevarse a cabo también para exponer un servicio SSH accesible a través de Tor, modificando las líneas relativas al HiddenServicePort para que apunten al puerto 22. Para acceder a dicho servicio existen diferentes aproximaciones, pero la más sencilla es la de lanzar el comando de conexión precediéndolo del comando torify, que se encargará de redirigir el tráfico de red para enviarlo a través de la instancia de Tor que esté en ejecución en dicha máquina.

Desde el punto de vista de la arquitectura necesaria para esta prueba de concepto se asumirá qué víctima y atacante están utilizando sistemas Linux y tienen Tor instalado y corriendo como servicio. El procedimiento seguido para llevar a cabo esta prueba de concepto es el siguiente:

   1. Despliegue del servicio malicioso a la escucha en la máquina atacante. En este caso se desplegará un netcat a la espera de conexiones en el puerto 1234 de la máquina local. No es necesario exponer públicamente el servicio ya que el tráfico en ese puerto será encaminado hacia y desde Tor.

   2. Configuración de Tor en la máquina atacante para hacerlo accesible a través de un dominio .onion. Utilizando como plantilla el fichero torrc, se añaden dos líneas nuevas que especifican la ruta en la que se generarán los ficheros auxiliares del servicio y las reglas de direccionamiento.

El dominio .onion definido en el archivo hostname estará disponible apenas unos segundos después de arrancarlo. En el caso de esta prueba de concepto el dominio generado es: vks3v4ilo4tgud7h.onion.

   3. Preparación del payload torificado por parte del atacante. El payload se generará con la utilidad msfvenom de Metasploit Framework utilizando el módulo linux/x86/exec que torificará la conexión de netcat hacia el dominio .onion del atacante y que permitirá al atacante la ejecución de comandos.

   4. Ejecución del payload torificado en la máquina de la víctima. Aunque se podría realizar explotando algún tipo de vulnerabilidad, para simplificar el proceso en este caso se ha ejecutado directamente el payload generado.

En este caso, se asume que la víctima cuenta con Tor instalado y la aplicación torify disponible. En el supuesto de no ser así, se podría instalar automáticamente desde los repositorios oficiales de la distribución si el usuario dispone de los permisos adecuados y así proceder a su instalación. En cualquier caso, si el usuario no tiene permisos de administración se podría incluir también el proceso de descarga de la última instancia de Tor y compilarla desde las fuentes satisfaciendo las dependencias o accediendo a versiones precompiladas de la aplicación. El primer análisis del payload generado en esta prueba de concepto en Virustotal no ha sido clasificado como malicioso por ninguna de las 53 soluciones de antivirus.

Figura 2. Ejemplo de la ejecución de la prueba de concepto en una máquina local.

Hemos creado entonces un payload utilizando el módulo exec con msfvenom. El inconveniente que tiene es que tenemos que recordar el comando completo que tenemos que ejecutar. Una aproximación más cómoda sería crear a partir de ese módulo uno nuevo que directamente nos solicitara el dominio .onion y el puerto al que nos vamos a conectar. En el siguiente repositorio de Github podréis acceder al nuevo módulo que hemos creado.

Esta prueba de concepto pone sobre la mesa la necesidad de monitorizar si máquinas consideradas como críticas están usando Tor para comunicarse con la red y determinar si este comportamiento es esperado o si podría ser consecuencia de un potencial encubrimiento de comunicaciones maliciosas.