On-the-fly: Sniffing & Pivoting

Ya hemos hablado en el blog sobre la herramienta on-the-fly. Hoy queríamos mostrar algunos casos de uso dónde on-the-fly ofrece posibilidades y entender bien el trabajo de los ‘jobs’ de la herramienta y cómo se pueden ir ‘apilando’ las funciones pequeñas y conseguir una función grande. Por ejemplo, si queremos hacer un DNS Spoofing con un ARP Spoofing y a la vez ir capturando el tráfico que pasa por nosotros pues podemos ir configurando tres módulos (serán tres jobs) que van trabajando de forma conjunta. 

Figura 1: On-the-fly: Sniffing & Pivoting

La herramienta será presentada por Luis Eduardo Álvarez en BlackHat Europe y esperamos que guste a la gente y vean el potencial que creemos que tiene esta forma de hacer las cosas. No hay que olvidar que el foco de la herramienta es ataques de red para el Ethical Hacking en el mundo TI, IoT e ICS.

Figura 2: Libro de Ethical Hacking 2ª Edición

En el artículo de hoy veremos algunas cosas que se pueden ir haciendo con on-the-fly. Además, invitamos a cualquier a realizar un módulo para la herramienta, aunque dejamos para más adelante el poder hacer un plugin para la herramienta, lo cual no es complejo como se verá.

Figura 3: GitHub de OnTheFly

¿Qué haremos? Lo primero es colocarnos en medio de la comunicación con el módulo arp_spoof muy común en los ataques en redes de datos IPv4 & IPv6. Hay que recordar que este módulo es ‘apilable’ a otros, es decir, este funciona como base para que otros puedan construir por encima.

Figura 4: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

Para este artículo, comenzaremos usando el módulo spoof/arp_spoof de la herramienta. Tendremos una máquina ‘target’, la cual es una máquina Windows y un ‘gateway’ que en este caso es una máquina macOS. Nos colocamos en medio de la comunicación entre ambas máquinas a través de la técnica ARP Spoofing.

Figura 5: ARP Spoofing hecho con on-the-fly

Ahora toca realizar tareas de sniffing que son necesarias en muchos ámbitos y vamos a utilizar en ataques de evaluación en el mundo IT, IoT o ICS. 

Sniffing

La herramienta on-the-fly dispone, actualmente, de cuatro módulos de sniffing. Uno orientado a sniffing en general, donde el usuario puede configurar los filtros que quiere aplicar (filtros BPF), donde almacenar la captura, si generar un PCAP o no, qué información mostrar por pantalla, etcétera. Además, la herramienta tiene módulos de sniffing ‘dedicado’, es decir, módulos que ya vienen filtrados para detectar y guardar cierto tipo de tráfico. 

Figura 6: Opciones del módulo de sniffing

Por ejemplo hay módulos de sniffing sobre el protocolo COAP, Modbus o MQTT (aquí se pueden ver ejemplos de uso en el mundo IoT o ICS). En la imagen anterior podemos ver las opciones del módulo sniffer/sniff de on-the-fly. Este módulo dispone de una serie de opciones:

- Interfaz por la que realizar el sniffing.

- El tipo de filtro o conjunto de filtros en modo BPF que se quieren usar. Es un parámetro opcional.

- Un boolean que nos dirá si queremos almacenar o no en PCAP el tráfico que capturemos en la interfaz.

- El nombre del fichero que queremos poner a la captura, si la almacenamos.

- Si queremos mostrar información sobre las conexiones y comunicaciones que puedan pasar por la interfaz.

- El parámetro ‘showPayload’ permite ver el contenido.

Configuramos el módulo para probar, tocando algunos parámetros. Aplicamos un filtro y todo lo que almacenaremos en el fichero PCAP estará filtrado a tráfico ICMP. Por otro lado, si queremos ver las conexiones y comunicaciones tenemos la opción de verlo con el parámetro verbose.

Figura 7: Configuración del módulo de sniffing

El fichero PCAP que obtenemos tiene todo el tráfico ICMP que haya pasado por nosotros. Solo tenemos que abrir el fichero PCAP, por ejemplo, con Wireshark y verlo tranquilamente.

Figura 8: Filtrando tráfico con Wireshark

Aplicar un filtro siempre es algo bueno, ya que evita que nuestra captura se llene de tráfico y protocolos que no nos interesen para el pentesting.

Pivoting con SOCKS4

Una de las intenciones de on-the-fly es ser como una navaja suiza en temas de red. Aún le queda mucho recorrido y por eso la herramienta es un proyecto colaborativo donde todos pueden aportar con sus módulos. Dentro de los módulos de pivot, podemos encontrar un par: proxy_socks4 y tcp_forwarding.

El primero lo veremos en detalle, mientras que el segundo es una forma de hacer forward de tráfico a través de un puerto TCP (un clásico). En el caso de proxy_socks4 podemos decir que el módulo presenta pocos atributos y que su configuración es sencilla. La idea es convertir la máquina donde se ejecuta on-the-fly en una máquina con un proxy SOCKS4. Se puede estudiar la implementación de un SOCKS5, ya que no es complejo teniendo la versión 4. Vamos a ver los atributos del módulo:

- local_host. Aquí indicaremos por cual interfaz queremos escuchar las peticiones que recibirá el proxy SOCKS4. Si dejamos 0.0.0.0 por cualquier interfaz de red de la máquina atenderemos a ellas.

- local_port. El puerto por defecto es 1080. Luego tiene que tener concordancia con, por ejemplo, la configuración de la herramienta proxychains.

- verbose. Si queremos ver las conexiones que pasan por nosotros, podemos activar este parámetro.

Figura 9: Opciones proxy_socks4

Bien, una vez ejecutado el módulo, si observamos los puertos a la escucha en nuestra máquina (donde se ejecuta on-the-fly) veremos el puerto 1080 activo por cualquier interfaz de red. El protocolo SOCKS4 es sencillo, es una manera de poder enviar tráfico a cualquier puerto a través de un ‘pivote’ que será nuestro proxy.

Figura 10: conexiones activas

Ahora, desde otra máquina pasaremos el tráfico por el proxy SOCKS4. Como se puede ver en la imagen, haciendo uso de proxychains (hay que tener en cuenta el fichero de configuración de proxychains para que apunte a la máquina dónde está on-the-fly).

Como se puede ver en la imagen, el tráfico se inicia en la máquina Ubuntu, pasa por la Kali Linux y llega a la Windows. La máquina Windows recibe la petición desde la máquina Kali, por lo que registra la conexión desde ella, pero realmente la conexión viene de la máquina Ubuntu.

Figura 11: Conexión proxificada

Bien, con este ejemplo finalizamos el artículo de hoy. Hay que indicar que si ejecutamos el comando ‘jobs’ veremos los trabajos en background que tenemos activos en este caso. Sin duda, la posibilidad de ir apilando funciones de manera sencilla proporciona flexibilidad y potencia a la herramienta. 

Figura 12: Trabajos apilados en on-the-fly

Para eliminar o parar un módulo, simplemente hay que ejecutar: job -k [ID Job]. Mientras que si se quieren detener todos los módulos: Jobs -K. Por último, os dejamos un video de uso de la herramienta con el ejemplo de proxySOCKS4.

Figura 13: PoC ProxySOCKS

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 14: Contactar con Pablo González