Retransmisión de trafico con TCPReplay

julio 2, 2015 Deja un comentario

Tcpreplay es una suite de herramientas para el análisis y manipulación de paquetes de datos, muy utilizada principalmente por administradores de sistemas y redes. Las herramientas incluidas en Tcpreplay funcionan principalmente sobre ficheros PCAP que han sido generados previamente por herramientas como tcpdump, wireshark, ethereal, etc. Permiten modificar las cabeceras de los paquetes en varias de sus capas para posteriormente reinyectarlos en la red o también para clasificar y tipificar los paquetes de datos incluidos en los ficheros PCAP. Dicho esto, el principal objetivo de TCPReplay es permitir la modificación de paquetes de datos para probar el funcionamiento de routers, firewalls, IDS/IPS y similares, no obstante es importante tener en cuenta que no funciona adecuadamente contra servidores concretos de cualquier tipo, ya que es un “stateless dispacher”, lo que quiere decir que se encarga de gestionar la posible comunicación que puede existir entre un cliente y un servidor. TCPReplay no soporta flujos de comunicación o el modelo clásico de múltiples peticiones y respuestas, solamente se encarga de replicar los paquetes de datos contenidos en un PCAP. En este articulo os hablaré de esta herramienta, pero seguramente para muchos de vosotros sea más interesante una herramienta que permita hacer labores de fuzzing contra servicios concretos simplemente alterando y reinyectado los paquetes contenidos en un PCAP, para esto también hay varias utilidades y librerías de las que hablaré en el próximo post.
Para empezar, hay que tener en cuenta que hay una versión bastante antigua de la herramienta y que fue inicialmente desarrollada por Aaron Turner (http://tcpreplay.synfin.net/) pero desde hace un tiempo, el equipo de Appneta a tomado el control y ahora todas las mejoras se suben directamente a su repositorio Git. La herramienta se puede instalar directamente desde el código, el cual se encuentra ubicado en el siguiente repositorio: https://github.com/appneta/tcpreplay o en sistemas basados en Debian con APT-GET (instala una versión antigua).

>./configure –prefix=/opt/tcpreplay
>make
>sudo make install

>cd bin

>ls -l

total 2916

-rwxr-xr-x 1 adastra adastra 516147 jun 11 00:33 tcpbridge

-rwxr-xr-x 1 adastra adastra 120661 jun 11 00:33 tcpcapinfo

-rwxr-xr-x 1 adastra adastra 404802 jun 11 00:33 tcpliveplay

-rwxr-xr-x 1 adastra adastra 433456 jun 11 00:33 tcpprep

-rwxr-xr-x 1 adastra adastra 444838 jun 11 00:33 tcpreplay

-rwxr-xr-x 1 adastra adastra 553339 jun 11 00:33 tcpreplay-edit

-rwxr-xr-x 1 adastra adastra 496851 jun 11 00:33 tcprewrite

Una vez instalado, se puede ver la versión del programa y las características soportadas.

>./tcpreplay -V

Ahora es el momento de utilizar la herramienta y jugar un poco con los interruptores que soporta. Antes de continuar, es necesario contar con un fichero PCAP que será utilizado por la herramienta para replicar los paquetes de datos que se encuentran almacenados en dicho fichero. Para realizar pruebas simples, se pueden capturar paquetes con TCPDump, Wireshark o Scapy y guardarlos en un PCAP o también es posible descargar alguno de los ficheros de ejemplo que se encuentran subidos en el proyecto. http://tcpreplay.appneta.com/wiki/captures.html

Para efectos prácticos, se utilizarán los ficheros PCAP del proyecto, los cuales se pueden abrir con una herramienta como wireshark

tcpreplay

PCAP de “BigFlows”

Partiendo de este fichero, se puede utilizar la herramienta e indicar la interfaz de red que será utilizada para el envío de los paquetes.

>sudo ./tcpreplay -i eth0 -t /home/adastra/Escritorio/smallFlows.pcap

File Cache is enabled

Actual: 14261 packets (9216531 bytes) sent in 0.087737 seconds.

Rated: 105047254.8 Bps, 840.37 Mbps, 162542.59 pps

Flows: 1209 flows, 13779.81 fps, 14243 flow packets, 18 non-flow

Statistics for network device: eth0

Attempted packets: 14261

Successful packets: 14261

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

El ejemplo anterior utiliza el interruptor “-i” para especificar el dispositivo primario de salida, por medio del cual se enviarán los paquetes del fichero PCAP y con “-t” se especifica que los paquetes deben enviarse tan pronto como sea posible.
Existen otras opciones que permiten limitar la velocidad, el número de paquetes máximo a enviar o incluso, especificar otro dispositivo de salida por el que también se replicará el trafico.

>sudo ./tcpreplay -i eth0 -p 100 -L 100 /home/adastra/Escritorio/smallFlows.pcap

Actual: 101 packets (61705 bytes) sent in 1.00 seconds.

Rated: 61653.7 Bps, 0.493 Mbps, 100.91 pps

Flows: 11 flows, 10.99 fps, 101 flow packets, 0 non-flow

Statistics for network device: eth0

Attempted packets: 101

Successful packets: 101

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

El interruptor “-p” permite indicar el número de paquetes que se enviarán por segundo y “-L” indica el número total de paquetes que se deben leer y enviar desde el PCAP. Como se puede apreciar, en este caso concreto ambos interruptores tienen el valor “100” por este motivo los paquetes se han enviado en exactamente 1 segundo.

Por otro lado, anteriormente se ha utilizado el interruptor “-t” que indica que los paquetes deben enviarse a su destino lo más rápido posible, sin embargo existe otra opción que permite controlar la velocidad de trasferencia de los paquetes, dicho interruptor es –mbps.

>sudo ./tcpreplay -i eth0 -L 100 –mbps 9500 /home/adastra/Escritorio/smallFlows.pcap

Actual: 101 packets (61705 bytes) sent in 0.000525 seconds.

Rated: 117533333.3 Bps, 9490.26 Mbps, 192380.95 pps

Flows: 11 flows, 20952.38 fps, 101 flow packets, 0 non-flow

Statistics for network device: eth0

Attempted packets: 101

Successful packets: 101

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

En este caso, se envían los paquetes a un máximo de 9500 MB por segundo y tal como se puede ver en las estadísticas que arroja “tcprelay”, el promedio ha sido de 9490 MBPS. Evidentemente, entre más bajo sea este valor, más tiempo tardará la herramienta en replicar los paquetes de datos.

Otra característica interesante de TCPReplay es la posibilidad de controlar los flujos de trafico, los cuales son simplemente una secuencia de paquetes que se intercambian entre un emisor y un receptor. Por ejemplo, el clásico TCP Hanshake, es un “traffic flow” que se compone por una serie de paquetes que de forma independiente puede que no tengan mayor sentido, pero cuando se relacionan con otros paquetes tienen significado bien definido. TCPReplay cuenta con varios interruptores para controlar los flujos contenidos en un fichero PCAP. Uno de ellos es “–unique-ip”, el cual se encarga de modificar la dirección IP de destino tras cada repetición de un bucle (con el interruptor –loop). Con “–flow-expiry”, se le indica a la herramienta que debe ignorar aquellos flujos que se consideran “expirados”, es decir, aquellos que tardan más tiempo del especificado en completarse. El valor de este interruptor debe indicarse en segundos y evidentemente, entre más pequeño sea, mayor será el número de paquetes descargados ya que se consideran que hacen parte de un flujo expirado.

 

>sudo ./tcpreplay -i eth0 -t –flow-expiry 30 /home/adastra/Escritorio/bigFlows.pcap

Actual: 791615 packets (355417784 bytes) sent in 8.01 seconds.

Rated: 43556960.3 Bps, 348.45 Mbps, 97013.55 pps

Flows: 58505 flows, 40686 unique, 17819 expired, 7169.87 fps, 791179 flow packets, 436 non-flow

Statistics for network device: eth0

Attempted packets: 791615

Successful packets: 791615

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

El fichero “bigFlows.pcap” contiene una buena muestra de datos con paquetes de todo tipo, con lo cual es una buena forma de ver el funcionamiento de estos interruptores. En este caso concreto se puede ver que el número de flujos que tardan 30 o más segundos en completarse son marcados como expirados.

>sudo ./tcpreplay -i eth0 -t –flow-expiry 90 /home/adastra/Escritorio/bigFlows.pcap

Actual: 791615 packets (355417784 bytes) sent in 7.08 seconds.

Rated: 45216137.2 Bps, 361.72 Mbps, 100709.00 pps

Flows: 41818 flows, 40686 unique, 1132 expired, 5320.07 fps, 791179 flow packets, 436 non-flow

Statistics for network device: eth0

Attempted packets: 791615

Successful packets: 791615

Failed packets: 0

Truncated packets: 0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN): 0

Como se puede ver en las estadísticas generadas por la herramienta, el número de flujos expirados es muchísimo menor, ya que el limite que se ha especificado es de 1 minuto y medio, un valor lo suficientemente alto como para considerar que se trata de una conexión extremadamente lenta o simplemente que el destinatario no era capaz de procesar los paquetes enviados por el emisor debido a que se encontraba ocupado o no disponible.

Existen algunas otras características interesantes en TCPReplay, tales como la posibilidad de integrar Netmap para mejorar las operaciones I/O por medio de buffers RX/TX preasignados y buffers en memoria con accesos asíncronos.

Un saludo y Happy Hack!
Adastra.

Tahoe-LAFS Sistema de almacenamiento en la nube privado y seguro – Parte 1

junio 30, 2015 Deja un comentario

El “cloud storage” o almacenamiento en la nube, se ha vuelto muy popular debido a la flexibilidad y beneficios que aporta a los usuarios. La habilidad de subir documentos a un servicio en Internet y poder acceder a ellos desde cualquier lugar y en cualquier momento, es algo muy atractivo para cualquiera, sin embargo en muchas ocasiones, al utilizar algunos de estos servicios en Internet, los usuarios se exponen a varias amenazas que pueden afectar directamente la confidencialidad e integridad de su información. Es cierto que muchos de los proveedores de los servicios de almacenamiento en la nube intentan asegurar los recursos de sus usuarios de la forma más rigurosa posible, pero en algunos casos, con la excusa de mantener la información de sus usuarios “segura” y confidencial, acceden directamente a dicha información, vulnerando de esta forma su privacidad.
Una buena forma de utilizar estos servicios es por medio del cifrado de los documentos desde el origen y de esta forma, evitar que un tercero tenga acceso directo a la información de los documentos almacenados en la nube, pero aun así, es necesario un registro y posterior entrega de datos personales al proveedor. Para los usuarios de redes anónimas tales como I2P, existe una solución que puede resultar mucho más interesante y que no exige el registro de datos personales ni de ningún tipo, permitiendo de esta forma almacenar documentos de forma distribuida y privada. Dicha solución es Tahoe-LAFS.

Tahoe-LAFS (The Last Authority File Store) es un sistema descentralizado y abierto que se encarga de distribuir los documentos de un usuario por múltiples servidores Tahoe. De esta forma, es posible seguir accediendo a la información de forma transparente aunque uno o varios de los servidores se encuentren caídos o comprometidos por un atacante. Solamente el propietario de los documentos o con los permisos adecuados puede ver sus contenidos, esto en Tahoe es lo que se conoce como “Provider Independent Security”, que es justo lo contrario a lo que suele verse en los principales proveedores de almacenamiento en la nube, ya que en este caso, el proveedor del servicio nunca tendrá acceso ni podrá leer y/o modificar la información de ninguno de sus usuarios. Justo lo opuesto a los proveedores de almacenamiento convencionales.

Funcionamiento básico de Tahoe-LAFS

El funcionamiento de Tahoe-LAFS se basa en el concepto de “Storage Grid”, que no es más que un conjunto de servidores de almacenamiento que se encargan de mantener los documentos de los usuarios del sistema. Un servidor de almacenamiento es simplemente un repositorio de datos, el cual no tiene la habilidad de actuar directamente sobre ellos, solamente se encarga de almacenarlos y brindar acceso a uno o varios “gateway”. Un gateway es un sistema independiente que se encarga de comunicarse con los servidores de almacenamiento y proveer acceso a la información que se encuentra almacenada en ellos por medio de protocolos de comunicación comunes tales como HTTP/S, SFTP o FTP. De esta forma un cliente, se comunicará con un gateway y éste a su vez, se comunicará con los servidores de almacenamiento para permitir el acceso a sus documentos. Un cliente en este caso puede ser un navegador web, un programa que se ejecuta por línea de comandos un cliente SFTP, etc. Tal como se mencionaba anteriormente, los servidores de almacenamiento tienen acceso a la información de sus usuarios y la información que se transfiere entre dichos servidores, el gateway y el cliente, se encuentra cifrada, impidiendo que cualquier “entidad” intermedia pueda manipular directamente los datos transferidos.
El procedimiento de instalación de Tahoe-LAFS se detalla a continuación.

Instalación de Tahoe-LAFS

Para instalar una instancia de Tahoe, es necesario tener Python instalado en el ordenador, preferiblemente la versión 2.7 ya que la última versión de Tahoe no funciona correctamente sobre la versión 3.x de Python. Una vez descargada la última versión estable del proyecto desde el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs se procede a instalar ejecutando el siguiente comando:

>python setup.py build

El comando anterior se encargará de instalar todas dependencias necesarias para poder arrancar correctamente Tahoe en uno de los modos descritos anteriormente (server o gateway) y además, se encargará también de generar un fichero ejecutable en el directorio <TAHOE_INSTALL>/bin.
En el caso de que exista algún problema ejecutando el script anterior, es posible que falte alguna dependencia necesaria en el sistema y no se ha podido obtener de manera automática por algún motivo. En tal caso, es necesario instalar manualmente la dependencia en cuestión, aunque son programas que suelen venir instalados por defecto en las en las últimas versiones de sistemas basados en Debian.

Por otro lado, para verificar la disponibilidad de todas las funciones que incluye Tahoe, se puede ejecutar el script setup.py con el argumento “trail”

>python setup.py trial

En tal caso, se podrán ver por pantalla, cada una de las funciones de Tahoe y si se ha podido comprobar que se encuentran correctamente instaladas y configuradas.

Uso de Tahoe-LAFS

Después de instalar el programa, es el momento de comenzar a utilizarlo y ver cuales son las opciones que se encuentran disponibles a los usuarios. En primer lugar, es posible crear clientes o un storage grid completo, todo esto ejecutando la utilidad “tahoe” que se ha generado automáticamente en el directorio “<TAHOE_INSTALL>/bin” tras ejecutar el proceso de instalación.

El primer paso para comenzar a utilizar el programa, consiste en crear un cliente simple, para ello se ejecuta el siguiente comando:

>./tahoe create-client Node created in ‘/home/adastra/.tahoe’

Please set [client]introducer.furl= in tahoe.cfg!

The node cannot connect to a grid without it.

Please set [node]nickname= in tahoe.cfg

Como se puede apreciar, con el comando anterior se ha creado un cliente simple y se ha creado también el directorio “~/.tahoe”. Tal como se enseña en la salida del comando, se debe establecer la propiedad “introducer.furl” en el fichero de configuración del nodo recién creado (tahoe.cfg) para que de esta forma, sea posible conectar al cliente con un storage grid de servidores.
Para probar las funcionalidades del sistema, existe un storage grid público que se encuentra activo para que los usuarios puedan interactuar con el sistema y opcionalmente con otros usuarios, para encontrar más detalles sobre dicho storage grid, se recomienda ver el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid
Tal como se explicaba anteriormente, es necesario establecer las propiedades “introducer.furl” y “nickname” en el fichero de configuración del cliente creado anteriormente, para ello se debe editar el fichero de configuración “<TAHOE_INSTALL/.tahoe/tahoe.cfg” y definir los valores adecuados en la sección “[client]”. Ahora bien, los valores de estas propiedades dependerán de si el usuario utiliza el storage grid de pruebas o uno propio. En el caso de utilizar uno propio, se debe indicar el valor del introducer de dicho storage grid en la propiedad “introducer.furl”, en el caso de utilizar el de pruebas, dicho valor se encuentra en el siguiente enlace: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid#HowToConnectToThePublicTestGrid

Después de establecer las dos propiedades de configuración anteriores, se puede arrancar el cliente con el siguiente comando.

>./tahoe run ~/.tahoe STARTING ‘/home/adastra/.tahoe’

running node in ‘/home/adastra/.tahoe’

2015-06-21 18:29:16+0200 [-] Log opened.

2015-06-21 18:29:16+0200 [-] twistd 13.2.0 (/usr/bin/python 2.7.6) starting up.

2015-06-21 18:29:16+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor.

2015-06-21 18:29:16+0200 [-] Listener starting on 37384

2015-06-21 18:29:16+0200 [-] NevowSite starting on 3456

2015-06-21 18:29:16+0200 [-] Starting factory <nevow.appserver.NevowSite instance at 0x7f36175311b8>

2015-06-21 18:29:16+0200 [-] My pid: 13852

2015-06-21 18:29:16+0200 [-] DatagramProtocol starting on 57219

2015-06-21 18:29:16+0200 [-] Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88>

2015-06-21 18:29:16+0200 [-] (UDP Port 57219 Closed)

2015-06-21 18:29:16+0200 [-] Stopping protocol <twisted.internet.protocol.DatagramProtocol instance at 0x7f3617547d88>

Ahora que el cliente se ha ejecutado sin errores, lo primero que hará será conectarse con el “introducer” y obtener un listado de storage servers. Es importante tener en cuenta que con lo anterior, solamente se crea un cliente plano, sin ninguna capacidad de almacenar y compartir archivos de otros usuarios, algo que desde luego, es una de las principales potencialidades del sistema y como se verá en un próximo artículo, no es demasiado difícil de instalar y configurar.

A partir de aquí, el usuario puede interactuar con el grid de varias formas, una de ellas es por medio de una interfaz web muy simple que se levanta automáticamente en el puerto 3456. La siguiente imagen enseña dicha interfaz.

tahoe1Interfaz web del cliente Tahoe.

Como se puede ver, aparece la dirección del “Introducer”, los servidores de almacenamiento conectados y a la izquierda, un panel muy simple para subir directorios o descargar ficheros al sistema de almacenamiento. Cuando se sube un fichero o directorio, automáticamente se generará una URI única del fichero, la cual seguirá el siguiente formato

URI:SSK:xxx:xxxx

Dicha URI debe ser utilizada para acceder al documento y se debe ingresar en el campo de texto de la interfaz web que pone “OPEN TAHOE-URI”.

La interfaz web es solamente uno de los mecanismos disponibles en Tahoe para interactuar con los servidores de almacenamiento, pero no es el único, ya que también es posible interactuar con el grid por medio de los comandos disponibles en la utilidad “tahoe” o incluso también es posible utilizar una API Rest para interactuar con el sistema por medio de peticiones HTTP(S).

El objetivo de esta primera entrada era el de introducir al lector en los conceptos básicos de Tahoe-LAFS y en las próximas dos publicaciones, se hablará sobre configuración avanzada del sistema, creación de un grid, uso de la web api y cómo desplegar Tahoe-LAFS en I2P.

Un saludo y Happy Hack!
Adastra.

Nueva convocatoria del curso de Python para Pentesters el próximo 29 de Junio.

junio 18, 2015 Deja un comentario

Ya os podéis inscribir a la próxima convocatoria del curso de Python para Pentesters que comienza el próximo 29 de Junio. Se trata de un curso que ha tenido muy buena aceptación en su primera convocatoria y que debido a la demanda que ha tenido, hemos decidido abrir una nueva convocatoria para que se apunten las personas que no han podido hacerlo en la primera. Como ya os comentaba en la entrada en la que hablaba del curso comienza con los conceptos básicos de programación y en la medida que avanza, el enfoque se especializa en temas relacionados con el pentesting y el hacking. Es recomendado para personas que tienen escasos conocimientos en programación y que quieren aprender a desarrollar sus propias herramientas con Python enfocadas a la seguridad informática. Los estudiantes también podrán entrar en un espacio privado en el que se encuentran todos los contenidos del curso y en el que además, se puede hablar por chat conmigo y con otros estudiantes. Por mi parte, os guiaré en vuestro proceso de aprendizaje y me encuentro disponible para responder a vuestras dudas y apoyaros en el desarrollo de las practicas. Intento que sea lo más personalizado posible, por ese motivo el número de alumnos en cada convocatoria es reducido. Tienes más información sobre los contenidos del curso en el siguiente enlace: http://www.thesecuritysentinel.es/1/curso_de_python_para_pentester_676511.html
Por otro lado, también hay una nueva convocatoria de Certificación Profesional de Hacking Ético (CPHE), impartida por Francisco Sanz y que comienza el día 22 de Junio. Las plazas de ambos cursos son limitadas, por lo que os recomiendo que reservéis plaza cuanto antes enviando un correo electrónico a info@thesecuritysentinel.es

Un saludo y Happy Hack!

Adastra.

Generación personalizada de direcciones ONION de TOR con Shallot

junio 16, 2015 2 comentarios

Las direcciones ONION en TOR son cadenas con una longitud exacta de 16 caracteres, compuestas por los dígitos entre 2-7 y las letras en minúsculas de a-z. Dichas direcciones generalmente se crean de forma automática por cualquier cliente de TOR, pero en ocasiones, se pueden encontrar sitios en la web profunda de TOR con direcciones ONION que no parecen ser tan aleatorias como la mayoría, en ocasiones tienen patrones fijos que determinan el contenido y/o temática del servicio oculto. Un ejemplo es Facebook, que cuenta con un servicio oculto en la web profunda de TOR para aquellos que quieran acceder a esta popular red social y ya de paso, perder su privacidad y probablemente el anonimato que brinda TOR. La dirección ONION de facebook en la web profunda de TOR es esta: facebookcorewwwi.onion y como se puede apreciar, existe un patrón bastante claro que además, resulta fácil de memorizar. Ahora bien, lo cierto es que personalizar la dirección completa (16 caracteres) con la capacidad de computo que tenemos actualmente resulta imposible, tal como comentaba en un articulo que he escrito hace algún tiempo, calcular y en consecuencia, descubrir un servicio oculto en TOR, puede llevar millones de años, una escala de tiempo que evidentemente no es tolerable. No obstante, si que se puede personalizar una parte de dicha dirección en poco tiempo, todo depende del número de caracteres que se quiera aplicar al patrón. Para hacer esto, existe una herramienta muy fácil de instalar y utilizar, dicha utilidad es Shallot.

INSTALACIÓN Y USO DE SHALLOT

Shallot es una herramienta que permite aplicar un patrón para personalizar una parte de la dirección ONION de un servicio oculto. Los patrones que se pueden aplicar típicamente son expresiones regulares que permiten indicar la forma en la que se debe generar la clave privada del servicio oculto y en consecuencia, la dirección ONION del mismo. Es un programa que se encuentra escrito en lenguaje C y solamente tiene dos dependencias: libssl y libcrypto, librerías que son bastante comunes en sistemas Linux. El proyecto se puede descargar desde GitHub y el proceso de instalación es tan simple como ejecutar “configure” y “make”

>git clone https://github.com/katmagic/Shallot.git

>./configure
>make

Las opciones que admite Shallot se pueden ver a continuación

>./shallot

Usage: shallot [-dmopv] [-f <file>] [-t count] [-x time] [-e limit] pattern

-d : Daemonize (requires -f)

-m : Monitor mode (incompatible with -f)

-o : Optimize RSA key size to improve SHA-1 hashing speed

-p : Print ‘pattern’ help and exit

-f <file> : Write output to <file>

-t count : Forces exactly count threads to be spawned

-x secs : Sets a limit on the maximum execution time. Has no effect without -m

-e limit : Manually define the limit for e

Version: 0.0.3-alpha

 

El interruptor “-p” puede ser útil para conocer algunos de los patrones (expresiones regulares) que se pueden aplicar con Shallot.

./shallot -p

base32 alphabet allows letters [a-z] and digits [2-7]

pattern can be a POSIX-style regular expression, e.g.

xxx must contain ‘xxx’

bar$ must end with ‘bar’

^foo must begin with ‘foo’

b[a4]r may contain leetspeech ;)

^ab|^cd must begin with ‘ab’ or ‘cd’

[a-z]{16} must contain letters only, no digits

^dusk.*dawn$ must begin with ‘dusk’ and end with ‘dawn’

 

Como se puede apreciar, algunas de las expresiones de ejemplo permiten aplicar patrones muy variados, como por ejemplo que la dirección ONION debe comenzar y/o terminar con una cadena determinada, que contenga solamente números o letras o que contenga en cualquier posición de la dirección una cadena determinada.
También existen otras opciones que permiten controlar el tiempo máximo en el que se debe ejecutar la herramienta, si se debe ejecutar como un proceso en “background” y si el resultado (clave privada para el servicio oculto) se debe almacenar en un fichero. Algunos ejemplos del uso de estos interruptores se enseña a continuación

>./shallot -f /home/adastra/private_key ^hack

>./shallot -m -o ^hacker

>./shallot -m -t 15 ^hacker

En todos los casos, después de procesar y descubrir una clave privada cuya dirección ONION generada contenga el patrón, se pinta por pantalla o se crea un fichero con dicha clave privada para que sea utilizada por un servicio oculto.
Como comentaba antes, el número de caracteres especificados en el patrón es importante y determina si es posible obtener una clave privada que encaje con el patrón y cuánto tiempo puede tardar el calculo de dicha clave. En el proyecto de GitHub de Shallot se enseña la siguiente tabla que nos da una idea del número de caracteres que podemos personalizar en la dirección ONION.

characters time to generate (approx.)
1 less than 1 second
2 less than 1 second
3 less than 1 second
4 2 seconds
5 1 minute
6 30 minute
7 1 day
8 25 days
9 2.5 years
10 40 years
11 640 years
12 10 millenia
13 160 millenia
14 2.6 million years

Las pruebas anteriores las ha realizado el autor con un ordenador de 1.5Gh de procesador. Si bien es cierto que se puede utilizar ordenadores mucho más potentes, las estimaciones anteriores no sufren cambios considerables con una mayor capacidad de computo, además, solamente se ha llegado a calcular hasta 14 caracteres, la cifra con 15 y 16 caracteres puede llegar a billones de años. Muchísimo más de lo que estamos dispuestos a esperar, por mucho que estemos acostumbrados a utilizar sistemas Windows.
Suponiendo que se utiliza un patrón con pocos caracteres, se puede generar una clave privada en muy poco tiempo, de hecho, las dificultades comienzan a partir de 7 o 8 caracteres, pero cualquier patrón que esté por debajo de dicho valor, puede ser procesado por Shallot en un tiempo bastante razonable.
Uno de los resultados que da la herramienta tras aplicar el patrón “^hack” es el siguiente

—————————————————————-

Found matching domain after 998147 tries: hacktkeocgipcjvv.onion

—————————————————————-

—–BEGIN RSA PRIVATE KEY—–

MIICWwIBAAKBgQCmZx9BMoG55KOoyAa0T43rNRW4z8m9vjgdXRxX2ZOaFMbrMITC

U6zm5CaauB0RYvu0m99/J9YhfXJQor69/YUIWMWGOXdn3CfVPML5kJWdCF68jhyE

qmPJAaTuodv7rwlB0KyTzOYUGNLDN/yZey9aG2CKWLfTX/w3Aq7c/6Y20QIDBKSB

AoGABFqfSWmx3CIHU40PJCv2ecf61m7LZcAQErvXddYZDCodEYKXDypWJZatQjKm

Whl9DGCZIMR3jpfVrKlIVjwT8+ERk35DXdRGzWi0n/y8be5XokYMnTreEbkcsprR

H8TeN6cJPwrjgXnd4g9Z2q9luKkDegdGLbsKY9nnh8lf5oUCQQDZi+lDL7S/jEoX

k5Xs805cTLPnqdGT0RelivchoGm03U2ggIUycCLv0SM6VaRcKNsBrGBtWg5jznu9

Xm9865xvAkEAw9DuwqkXK+WixHVY+uoT+LUHmBRJiVV+ZHKUzCOvF4yTxqGNCMAM

LcuCZtiamFbA4YQnBHAMRpMJt12/OSuAvwJAQjs2GYeqUmYE0MFt99KYhA2HHDny

DpSzwriBqAKC/lzk/SnEyYw5nBb/+zLYS3+zNUEAEZ8ktwIF1eFVriczdQJAE6qG

q9J5kLbmVuyhkBB0zO5hcCE5EFVren5/XUGrzOz1hJbv4Q+9TkqDO3xaQ/v+iIqt

hmu8XPNRhi50Q4vXhwJAQywFaZosVqFLUPJB4AmMeKQ2nPHpSLVVWFVPNNTypDZC

LDJgX849UGd0Nu9bCTWFtJaFROGUOa8U2cIsa8N6iQ==

—–END RSA PRIVATE KEY—–

A continuación, solamente es necesario incluir el contenido anterior en un fichero con nombre “private_key” que se deberá ubicar en el directorio que se declara en la propiedad “HiddenServiceDir” del fichero de configuración de TOR (torrc).

HidenServiceDir /home/adastra/servicioOculto

HiddenServicePort 80 127.0.0.1:80

Con las dos directivas anteriores se define un servicio oculto que va a procesar peticiones de los clientes por el puerto 80 en la dirección ONION generada. En este caso, el fichero “private_key” con la clave RSA generada por Shallot debe ubicarse en el directorio “/home/adastra/servicioOculto”. Una vez hecho esto, basta con arrancar la instancia de TOR utilizando el fichero torrc con las directivas anteriores y se podrá ver que en el directorio “/home/adastra/servicioOculto” existe un nuevo fichero llamado “hostname”, con la dirección ONION generada a partir de la clave privada definida en el fichero “private_key”.
Con estos sencillos pasos se puede personalizar una parte de la dirección ONION de un servicio oculto en TOR, algo que en algunos casos viene bien para tener direcciones que sean un poco más fáciles de recordar y compartir.

Saludos y Happy Hack!
Adastra.

Análisis de trafico con Netsniff-ng

junio 11, 2015 1 comentario

Netsniff-ng es una de esas herramientas que aunque tiene unas características muy interesantes y es muy potente, es más bien poco conocida. También es una de las tantas herramientas que llevo tiempo con ganas de mencionar aquí, pero por cuestiones de tiempo (y también porque se me olvida) no lo había hecho antes, hoy le ha llegado su turno. Se trata de un sniffer diseñado especialmente para sistemas Linux, muy similar a herramientas como TCPDump o TShark, pero con algunas ventajas adicionales. Una de ellas es su rendimiento, el cual es mucho más óptimo que otros sniffers existentes, ya que los paquetes manejados por Netsniff-ng no son copiados entre el espacio del kernel y el espacio del usuario, algo que es tan común en librerías como libpcap (De hecho, netsniff-ng no requiere de libpcap para su correcto funcionamiento).

Algunos sniffers realizan una serie de invocaciones a las system calls desde el espacio del usuario para realizar el proceso de captura de paquetes, los cuales son procesados en primera instancia por el kernel y almacenados en el kernel space. Este proceso es muy ineficiente, ya que se debe invocar a una (en algunos casos varias) system calls de la API de sockets del sistema operativo. Debido a esto, en las últimas versiones de la rama 2.4 y en prácticamente todas de la rama 2.6 del kernel de Linux se ha introducido PACKET_MMAP, un mecanismo que se encarga de crear un buffer compartido entre el kernel space y el user space para la captura y procesamiento de paquetes de red. Se trata de una característica antigua y que se encuentra integrada en prácticamente todos los sistemas Linux modernos por medio de la opción CONFIG_PACKET_MMAP. No obstante, para el correcto funcionamiento de netsniff-ng también se recomienda utilizar versiones recientes del kernel de Linux (>= 2.6.31) ya que implementan el concepto de “rings” del tipo RX y TX, los cuales permiten un control mucho más eficiente de los buffers utilizados para la recepción y transmisión de paquetes de datos. El tamaño de cada uno de estos rings puede variar dependiendo de las limitaciones físicas de la interfaz de red y típicamente se calcula en base al ancho de banda soportado por la interfaz de red.

INSTALACIÓN

El proceso de instalación es muy simple, basta con descargar la última versión estable desde el sitio web oficial (http://pub.netsniff-ng.org/netsniff-ng/) y descomprimir en cualquier directorio del sistema. También es posible instalar la versión de desarrollo que se encuentra en su repositorio GitHub (https://github.com/netsniff-ng/netsniff-ng.git) pero pueden haber errores y problemas a la hora de instalar, así que se recomienda tirar de la última versión estable.

>./configure

>make

>sudo make install

Con las instrucciones anteriores es suficiente para tener netsniff-ng instalado en el sistema local. A continuación, se puede ejecutar el comando “netsniff-ng” especificando la interfaz de red que será utilizada para el proceso de captura.

>sudo netsniff-ng -i eth0

Para ver todas las opciones de configuración disponibles en la herramienta, basta con ejecutar el comando con la opción “-h”

>sudo netsniff-ng -h

Esta herramienta tiene varias dependencias a librerías que se tienen que encontrar instaladas en el sistema, dichas dependencias se pueden ver en el fichero INSTALL (https://github.com/netsniff-ng/netsniff-ng/blob/master/INSTALL).

Uso básico y análisis de trafico con Netsniff-ng

La herramienta permite la captura de paquetes desde un dispositivo o un fichero de capturas (típicamente formato PCAP) y dicha información también puede ser inyectada/redireccionada a un dispositivo de red o un fichero de capturas. Un ejemplo muy sencillo seria el siguiente:

>netsniff-ng –in eth0 –out /home/adastra/Escritorio/dump.pcap -s icmp

En este caso se van a capturar todos los paquetes que utilicen el protocolo ICMP y que se transfieran por medio de la interfaz de red “eth0”. Con la opción “–out” se indica el destino al que deben redirigirse dichos paquetes, los cuales en este caso concreto, serán almacenados en un fichero PCAP. En el caso de que se indicase, por ejemplo, una interfaz de red, dichos paquetes serían inyectados a dicha interfaz de red. Finalmente, con la opción “-s” la información correspondientes a los paquetes capturados ya no serán enseñados por pantalla.

Hay que tener en cuenta que además de las opciones estándar que admite la herramienta, también es posible aplicar filtros sobre los paquetes capturados, como en este caso concreto en el que se han capturado todos los paquetes que utilicen protocolo ICMP. Estos filtros deben seguir las normas definidas en el estándar BPF (Berkeley Packet Filters) algo que es tan común en este tipo de herramientas (véase por ejemplo TCPDump o Wireshark). No obstante, por línea de comandos no es la única forma de especificar este tipo de filtros, también existe la posibilidad de crear ficheros con los filtros que se desea aplicar y pasarlos a la herramienta por medio de la opción “-f”. Existen algunos de estos ficheros que vienen con la herramienta y que permiten aplicar filtros que son bastante comunes cuando se trabaja con redes.

>netsniff-ng –in eth0 -f /etc/netsniff-ng/rules/icmp.bpf

 

Además de los filtros BPF, también soporta filtros especiales sobre el tipo de trafico a capturar aplicando el interruptor “-t”. Los posibles valores que puede asumir “-t” son los siguientes:

broadcast: Permite filtrar solamente el trafico broadcast.
multicast: Permite filtrar solamente el trafico multicast.
host: Permite filtrar solamente los paquetes cuyo destino es la máquina desde donde se ejecuta la herramienta.
others: Permite filtrar los paquetes cuyo origen o destino es distinto de la máquina desde donde se ejecuta la herramienta.
outgoing: Permite filtrar solamente los paquetes cuyo origen es la máquina desde donde se ejecuta la herramienta.

>netsniff-ng –in eth0 -t others -s

Por otro lado, tal como mencionaba anteriormente, también es posible la reinyección de trafico utilizando esta herramienta, para ello se puede utilizar un fichero PCAP o una interfaz de red que contendrá/capturará los paquetes de datos que serán reinyectados en una interfaz de red determinada. Para ello, se debe utilizar también el interruptor “–mmap” tal como se enseña en el siguiente comando

>netsniff-ng –in /home/adastra/Escritorio/dump.pcap –mmap –out eth0 -k1000 –silent

De esta forma, la herramienta leerá los paquetes de datos incluidos en el fichero PCAP especificado con la opción “–in” y dichos paquetes serán inyectados a la interfaz de red especificada con el interruptor “–out”. Esto evidentemente sirve para generar trafico en el segmento de red y posiblemente, generar estímulos sobre un objetivo determinado. Todo depende de los contenidos del fichero PCAP, pero desde luego es una opción bastante interesante si se desea producir algún tipo de respuesta por parte de un objetivo determinado en el segmento de red.
Existen algunas otras opciones en el comando netsniff-ng, sin embargo no es la única herramienta que incluye el paquete Netsniff-ng, existen otras herramientas que son igualmente interesantes y que merece la pena conocer.

Ifpps

Se trata de una herramienta que permite generar estadísticas en tiempo real sobre los “rings” TX y RX del sistema operativo. Permite la visualización de datos directamente desde la consola o exportar dicha información a ficheros CVS o GNUPlot. Además, como prácticamente todas las herramientas incluidas en Netsniff-ng, permite utilizar varias CPUs para un mejor desempeño.

>ifpps -d eth0 –promisc

>ifpps -d eth0 –promisc -c

 

Astraceroute

Funciona como traceroute para tracear los sistemas por los que pasa un paquete antes de llegar a su destino, el beneficio adicional de esta herramienta es que permite resolver el AS (Sistema Autónomo) de origen y utiliza la librería GeoIP para intentar obtener las referencias geográficas de cada AS encontrado.
Antes de poder utilizar esta herramienta, es necesario actualizar la base de datos de georeferencias con el siguiente comando.

>sudo astraceroute -i eth0 –update

Después de actualizar la base de datos, se puede utilizar el comando astraceroute con las opciones de configuración admitidas.

>astraceroute -i eth0 -N -F -L -H netsniff-ng.org

En este caso, se han utilizando las opciones -N y -F para ejecutar una resolución DNS inversa y enviando paquetes con la flag FIN habilitada respectivamente, luego -L y H permiten pintar las referencias geográficas encontradas (latitud y longitud) así como especificar el objetivo del análisis.
Espero que os haya gustado y que juguéis con esta estupenda herramienta.

Saludos y Happy Hack!
Adastra.

Pentesting contra servicios ocultos en TOR – Parte 2

junio 9, 2015 Deja un comentario

Tal como mencionaba en el artículo anterior sobre pentesting contra servicios ocultos en TOR, es posible que algunos crean que atacar un servicio oculto es una tarea compleja y que requiere de muchos conocimientos para llevarla a cabo, pero lo cierto es que no difiere de un proceso de pentesting convencional. Es importante tener en cuenta que cualquier servicio en la web profunda de TOR puede contener vulnerabilidades criticas que pueden afectar a su desempeño y seguridad, sin embargo, son muchos los usuarios de TOR, I2P o Freenet que creen que por utilizar este tipo de redes ya se encuentran “protegidos” y relajan o descuidan la seguridad de los servicios ocultos que crean y administran. Esto es un error y cualquier servicio que contenga vulnerabilidades puede ser igualmente explotable, aunque se encuentre en la “cyphernet” de TOR o I2P.

En el artículo anterior se explica como utilizar SOCAT para crear un túnel entre la máquina local y el servicio oculto que se desea atacar, utilizando por medio el proxy socks que típicamente se levanta cuando se arranca una instancia de TOR. Este es el mecanismo más sencillo y eficaz que se puede utilizar para realizar pruebas de pentesting contra servicios ocultos, no obstante es necesario mapear en puertos distintos cada una de las direcciones ONION que se desea atacar, no es cómodo pero desde luego resulta sencillo y fácil de implementar. En el post anterior explicaba cómo hacer esto contra un servicio oculto del tipo HTTP, el cual era soportado por una aplicación web vulnerable con Django-moth. En dicho post se explicaba el uso de Nikto y W3AF para comprometer el servicio oculto y ya de paso su anonimato, pero también es posible hacer esto mismo con otros servicios ocultos que no son el típico servidor web, sino también con cualquier servidor que funcione utilizando protocolo TCP. En este artículo se realizarán pruebas sencillas contra servicios ocultos del tipo FTP y SSH

Atacando un servicio oculto en TOR del tipo FTP

Existen muchas implementaciones del protocolo FTP tanto desde el lado del cliente como desde el lado del servidor y también, han sido muchas las vulnerabilidades que se han encontrado y explotado en dichas implementaciones. Si un servidor FTP vulnerable se expone en la web profunda de TOR, es probable que pueda seguir siendo utilizado sin mayores problemas en el caso de que solamente un grupo reducido de usuarios conozca su dirección ONION y no pretendan vulnerarlo, pero si un atacante descubre dicha dirección ONION no tardará demasiado en hacerse con el control de dicho servicio.
Las directivas utilizadas para crear un servicio FTP no son diferentes a las de cualquier otro tipo de servicio oculto, lo único que probablemente cambiará será el puerto y obviamente el directorio.

HiddenServiceDir /home/adastra/Escritorio/hidden_service_ftp/HiddenServicePort 21 127.0.0.1:21

Las líneas anteriores se incluirán en el fichero “torrc” y en la máquina donde se levanta la instancia de TOR, deberá existir un proceso vinculado al puerto 21. La dirección ONION generada, también responderá únicamente a las peticiones entrantes por el puerto 21.
Nuevamente se puede utilizar SOCAT para crear un túnel entre el servicio oculto y la máquina del atacante, pero eso si, es necesario que en la máquina del atacante se arranque una instancia de TOR que tenga la propiedad SOCKSPort establecida (bastante frecuente) para poder utilizar dicho proxy SOCKS y conseguir llegar al servicio oculto.

>socat TCP4-LISTEN:8000,reuseaddr,fork SOCKS4A:127.0.0.1:ondsyq4v4xcr6ct6.onion:21,socksport=9150

El puerto que se abrirá en la máquina del atacante será el 8000 y cualquier petición que llegue a dicho puerto, será automáticamente enrutada al servicio oculto en el puerto 21 cuya dirección ONION es “ondsyq4v4xcr6ct6”, evidentemente para que dicho enrutamiento funcione correctamente se debe establecer el proxy SOCKS, que en este caso es el puerto 9150 (puerto por defecto que utiliza TOR Browser).

Con todos los elementos dispuestos, se puede utilizar cualquier herramienta para realizar pruebas de penetración contra el servicio oculto, no obstante antes de hacer nada, es mejor comprobar que el túnel funciona correctamente y para ello, basta con realizar una petición al servidor FTP utilizando cualquier cliente.

pentestingserviciosocultos-II-1Conexión con el servicio oculto del tipo FTP utilizando SOCAT.

Después de verificar que la conexión se puede establecer, se puede utilizar una herramienta como Metasploit Framework para realizar pruebas automatizadas utilizando los módulos auxiliares que se encuentran incluidos en el framework.

pentestingserviciosocultos-II-2Ejecutando el módulo “auxiliary/scanner/ftp/ftp_login” de MSF contra el servicio oculto FTP

pentestingserviciosocultos-II-3Ejecutando otros módulos auxiliares de MSF contra el servicio oculto FTP

Atacando un servicio oculto en TOR del tipo SSH

SSH es un protocolo bastante conocido y utilizado por prácticamente todos los administradores de sistemas y también es un protocolo muy utilizado en la web profunda de TOR. No es sencillo encontrar direcciones ONION con este tipo de servicios, pero hay bastantes y a veces no se encuentran debidamente configurados.  Como mencionaba antes, la principal dificultad a la hora de atacar los servicios ocultos en TOR es que es muy difícil encontrar la dirección ONION de un servicio a atacar y más aun cuando se trata de servicios cuyas funciones son principalmente de administración, como es el caso de cualquier servicio SSH, normalmente son direcciones ONION que solamente las conocen aquellas personas que crean el servicio oculto y que intentan administrar sus servidores de forma remota y anónima. Sin embargo, una vez se descubre la dirección del servicio oculto en cuestión, nuevamente basta con crear un túnel cuyo endpoint será el servicio oculto y a continuación realizar pruebas de pentesting con las herramientas habituales. Suponiendo que la dirección del servicio oculto SSH a atacar es “klebohg2zv4b5j5u”, la siguiente imagen enseña la forma en la que se debe crear el túnel con SOCAT y cómo utilizar el cliente SSH en sistemas Linux para realizar la conexión contra el servicio oculto.

pentestingserviciosocultos-II-4Conexión al servicio oculto del tipo SSH

Después de verificar que el servicio se encuentra activo y que el túnel enruta las peticiones adecuadamente, se puede realizar un proceso de pentesting básico utilizando MSF.

pentestingserviciosocultos-II-5Ejecutando el módulo “ssh_version” de MSF contra el servicio oculto.

pentestingserviciosocultos-II-6Ejecutando el módulo “ssh_enumusers” de MSF contra el servicio oculto.

pentestingserviciosocultos-II-7Ejecutando el módulo “ssh_login” de MSF contra el servicio oculto.

Además de utilizar MSF también se pueden utilizar otras herramientas comunes, como por ejemplo THC Hydra.

pentestingserviciosocultos-II-8Ataque de fuerza bruta contra el servicio oculto utilizando THC Hydra.

Como se puede apreciar, realizar procesos de pentesting contra servicios ocultos en TOR no es una tarea demasiado compleja, aunque si que lo es descubrir las direcciones dichos servicios ocultos. Muchas veces creemos que por utilizar TOR las vulnerabilidades o una mala configuración del sistema es menos evidente o será más difícil de explotar. La realidad es que un servicio oculto en TOR o en cualquier otra red anónima es perfectamente explotable si dicho servicio contiene alguna vulnerabilidad, los vectores de ataque no cambian, solamente cambia el medio utilizado por el atacante.
Si tienes publicado un servicio oculto en cualquier red anónima, presta atención a las vulnerabilidades o malas configuraciones que pueda tener.

Un saludo y Happy Hack!
Adastra.

Pentesting contra servicios ocultos en TOR – Parte 1

junio 2, 2015 1 comentario

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

pentestingserviciosocultos-1Django-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.

pentestingserviciosocultos-2Utilizando 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.

>./w3af_console

w3af>>> plugins audit os_commanding

w3af>>> target set target http://localhost:7000/audit/os_commanding/param_osc.py?param=-la

w3af>>> start

OS Commanding was found at: “http://localhost:7000/audit/os_commanding/param_osc.py&#8221;, using HTTP method GET. The sent data was: “param=%7C%2Fbin%2Fcat%20%2Fetc%2Fpasswd” The modified parameter was “param”. This vulnerability was found in the request with id 39.

Scan finished in 14 seconds.

Stopping the core…

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”

pentestingserviciosocultos-3Generando 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.

pentestingserviciosocultos-4Ejecutando 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.

Un saludo y Happy Hack!
Adastra.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.543 seguidores

A %d blogueros les gusta esto: