El sábado 30 de mayo realice una pequeña charla con los chicos de GR2Dest
en la que hablé sobre anonimato con TOR y pentesting contra servicios
ocultos. En dicha charla me centre especialmente en actividades de
pentesting contra servicios ocultos en la red de TOR y si bien es cierto
que no es algo complicado, creo que muchas personas no saben o no
entienden como hacerlo. Por ese motivo me he animado a escribir un par
de artículos explicando la forma en la que puedes utilizar algunas de
las herramientas de pentesting más habituales para atacar los servicios
ocultos que se encuentran en la red de TOR. Este es el primero de ellos,
espero que sea de tu agrado y te resulte informativo.
Antes de comenzar, intentaré aclarar algunas cuestiones que son importantes sobre TOR. Tal como mencionaba en el artículo ataca un servicio oculto si te atreves
los servicios ocultos en TOR se registran en las autoridades de
directorio, donde cada registro se incluye en una tabla hash que se
compone por la clave pública del servicio y su dirección onion, la cual
estará compuesta por letras entre la a y la zeta en minúsculas y los
números entre 2 y 7. Este valor se genera al aplicar el algoritmo Base32
sobre el hash SHA de la clave privada del servicio oculto. Suena
complejo, pero en realidad es algo de lo que no tenemos que preocuparnos
ya que el cliente de TOR se encarga de la generación de la dirección
onion de forma automática. No obstante, conocer esa dirección “onion” es
otra historia y ahí es donde reside la verdadera dificultad de atacar
servicios ocultos en TOR: Su disponibilidad y que en algunos casos,
solamente unos pocos usuarios tienen conocimiento de las direcciones que
utilizan para transmitir información. Por poner un ejemplo, imaginaros
por un segundo a un grupo de islamistas radicales que necesitan
transferir documentos e información entre ellos y que se encuentran
ubicados en distintos países. Evidentemente, su dios les exige que
luchen contra el infiel y se oculten adecuadamente si quieren disfrutar
de las 40 mujeres (o cabras) que están reservadas para ellos en el
paraíso, por ese motivo el anonimato es una de sus prioridades
principales. En este sentido, solamente un grupo reducido de usuarios
conocen la dirección del servicio que utilizarán para intercambiar
información y adicionalmente, dicho servicio puede estar disponible en
una franja horaria determinada y el resto del tiempo puede encontrarse
inactivo, con lo cual las probabilidades de que el servicio sea
encontrado por cualquier usuario en la red de TOR son realmente bajas.
En Tortazo, existe
el modo “onion repository” que intenta descubrir direcciones de forma
aleatoria o incremental y aunque funciona de un modo similar a otras
aplicaciones como Shallot (https://github.com/katmagic/Shallot) el problema del descubrimiento sigue estando latente.
No obstante, si conoces la dirección ONION del servicio que quieres
atacar, las cosas cambian muchísimo, ya que puedes utilizar las
herramientas de pentesting que utilizas para auditar cualquier servicio
en Internet. Puedes usar Metasploit Framework, W3AF, OpenVAS, NeXpose,
Nikto, Nmap, etc, etc. Lo único que necesitas es conocer la dirección
ONION del servicio que quieres atacar y arrancar una instancia de TOR
levantando un proxy SOCKS. El mecanismo es muy sencillo, basta con crear
un túnel que permita conectar el servicio oculto con un puerto
arbitrario en la máquina local utilizando el proxy SOCKS levantado por
la instancia de TOR. A partir de aquí, basta con ejecutar las
herramientas anteriormente mencionadas o cualquier otra contra un puerto
en la máquina local. Es tan fácil como suena y no requiere de
configuraciones especiales. Eso si, todo debe funcionar con protocolo
TCP, ya que UDP o ICMP no se encuentran soportados por TOR. En este
artículo, explicaré cómo atacar un servicio HTTP utilizando herramientas
de pentesting comunes.
Atacando un servicio oculto en TOR del tipo HTTP
Crear un servicio oculto en TOR no tiene ninguna dificultad, basta
con especificar las directivas “HiddenServiceDir” y “HiddenServicePort”
en el fichero de configuración utilizado para arrancar la instancia de
TOR y poco más. Evidentemente, tienes que tener un servidor ejecutándose
en el puerto indicado, de lo contrario solamente tendrás una dirección
ONION pero nada que responda a las peticiones de los clientes.
Al utilizar las propiedades anteriores, la instancia de TOR se encargará
de crear el directorio del servicio oculto y en él incluirá la clave
privada del servicio (private_key) y el fichero en el que se incluye la
dirección onion del servicio (hostname). En el caso de que el directorio
indicado en la propiedad “HiddenServiceDir” ya exista, la instancia de
TOR entiende que el servicio ha sido creado previamente y no intenta
machacar el directorio, por el contrario, intenta utilizar los ficheros
que en él se encuentran incluidos (hostname y private_key). Las
siguientes directivas pueden ser utilizadas el fichero de configuración
“torrc” que se utilizará para levantar la instancia de TOR.
| HiddenServiceDir /home/adastra/Escritorio/hidden_service_django/HiddenServicePort 80 127.0.0.1:8080 |
Como se puede apreciar, es realmente simple. No requiere ninguna otra
opción de configuración adicional, aunque evidentemente en el fichero
“torrc” se incluirán muchas más opciones de configuración para
personalizar el comportamiento de la instancia, pero esa es otra
historia.
En el directorio “/home/adastra/Escritorio/hidden_service_django/ ”
se crearán dos ficheros (hostname y private_key) que contienen la
dirección ONION del servicio y su clave privada. Por otro lado, cuando
un usuario de TOR ingrese a la dirección ONION del servicio por el
puerto “80”, la instancia de TOR que recibe dicha petición se encargará
de redirigirla al endpoint correspondiente, que en este caso será la
máquina local en el puerto “8080”. Evidentemente, es necesario arrancar
un servicio en dicho puerto y dicho servicio puede ser de cualquier tipo
(SSH, HTTP, SMB, FTP, etc.) Lo que realmente importa es que funcione
sobre TCP.
En este caso, para demostrar el uso de algunas herramientas de
pentesting contra un servicio oculto vulnerable en la web profunda de
TOR, vamos a arrancar una aplicación web con múltiples vulnerabilidades
que utiliza el equipo de W3AF para realizar pruebas, dicha aplicación
web vulnerable es Django-moth (https://github.com/andresriancho/django-moth)
| >python manage runserver 8080 |
Después de arrancar la aplicación, se podrá acceder al servicio
oculto utilizando cualquier otra instancia de TOR que permita el acceso a
la web profunda de TOR, como por ejemplo “TOR Browser”.
Django-moth como servicio oculto en la red de TOR
Ahora que el servicio vulnerable se encuentra levantado y es
accesible en la web profunda de TOR, lo siguiente es intentar atacar
dicho servicio de la misma forma que atacamos cualquier aplicación o
servidor web en Internet por medio de herramientas de pentesting
comunes. Utilizar herramientas de reconocimiento para aplicaciones web
puede ser un buen inicio, como por ejemplo Nikto o algún script NSE de
Nmap. No obstante, antes de hacerlo es necesario aplicar algún mecanismo
para acceder a cualquier servicio oculto en la web profunda de TOR
utilizando dichas herramientas. Para hacer esto, pueden aplicarse 2
enfoques, o bien la herramienta que se va a utilizar soporta el
enrutamiento de peticiones por medio de un proxy SOCKS (algo que no
todas soportan) o crear un túnel transparente que permita enrutar todas
las peticiones al servicio oculto utilizando el proxy SOCKS levantado
por una instancia de TOR (siempre y cuando dicha instancia tenga activa
la propiedad SOCKSPort). La segunda alternativa resulta ser la más
fiable, ya que no hay que aplicar ningún tipo de configuración adicional
para que las herramientas funcionen correctamente, todo se hace de
forma transparente por medio del proxy SOCKS de la instancia de TOR.
Para montar un túnel de estas características hay varias alternativas,
una de ellas es creando un túnel SSH y habilitando el soporte para
servidores proxy (algo bastante común en OpenSSH), utilizando un proxy
transparente con librerías como Twisted o utilizando directamente SOCAT.
Dado que utilizar SOCAT es lo más cómodo, fácil y conveniente, es una
de las mejores alternativas.
| >socat TCP4-LISTEN:7000,reuseaddr,fork SOCKS4A:127.0.0.1:fieqd7c2ljyyo54f.onion:80,socksport=9150 |
El comando anterior abrirá el puerto “7000” en la máquina local y
utilizará el puerto 9150 (Proxy SOCKS de TOR) para enrutar todas las
peticiones entrantes por el puerto “7000” al servicio oculto en el
puerto 80. Esto se traduce a que se puede utilizar cualquier herramienta
de pentesting web tirando directamente contra la máquina local en el
puerto “7000” y SOCAT se encargará de redirigir todas peticiones
realizadas desde dicho puerto al servicio oculto definido. Además de
enrutar las peticiones desde el cliente hacia el endpoint (servicio
oculto) otra de las características que tiene SOCAT es que los túneles
creados con esta herramienta son bidireccionales, es decir, que no
solamente es capaz de enrutar las peticiones a su correspondiente
destino, sino que también es capaz de transmitir las respuestas que
emite el servidor. A partir de aquí, realizar un proceso de pentesting
contra el servicio oculto es mucho más fácil.
Utilizando Nikto contra un servicio oculto en la red de TOR.
Dado que en este caso concreto el servicio oculto se
encuentra soportado por la aplicación web vulnerable Django-moth, qué
mejor forma de atacarlo que utilizando W3AF.
Como se puede apreciar, se ha encontrado una
vulnerabilidad y se ha registrado en la “Knowledge Base” de W3AF. A
continuación, se puede intentar explotar dicha vulnerabilidad utilizando
el plugin “os_commanding”
Generando una consola contra el servicio oculto vulnerable utilizando W3AF
Como se puede apreciar, se ha generado una consola
contra el servicio oculto utilizando W3AF. A partir de aquí, el atacante
podrá ejecutar comandos directamente contra el servicio oculto
vulnerable y de esta forma, romper su anonimato.
Ejecutando comandos directamente contra el servicio oculto.
En este caso se está atacando a un servicio oculto del
tipo HTTP, pero en la web profunda de TOR existen toda clase de
servicios vulnerables, los cuales evidentemente también se pueden
comprometer. Algunos de ellos los explicaré en el próximo post.
Autor:
adastra
