Foro de elhacker.net

La mayoría de administradores de sistemas tienen una regla de oro y esta es, si funciona… no lo toques, no es lo más recomendado, pero es bastante extendida y existen muchas razones para que sea tan popular, una de las más comunes es la rotación en el mundo de IT, donde hay poco personal bien formado y los buenos profesionales son arrebatados de una empresa a otra a punta de cartera, esto genera una especie de teléfono roto donde una persona recibe el trabajo de otra, la mayoría de las veces sin mayores indicaciones y con la premisa de que funcione.

Conozco pocos profesionales que se atrevan a bloquear en su red conexiones salientes a puertos como el 80 o el 443, protocolos como el DNS o el ICMP y por eso es común que nos encontremos con escenarios idóneos para probar técnicas de bypass como la que presentaremos el día de hoy (si les llama la atención este contenido, podríamos generar otros bypass camuflando tráfico por el protocolo DNS u otros), que puede ser usada para saltarnos controles como el de portales cautivos, filtros de navegación o incluso sistemas de monitoreo.

Imagen 1: Topología de estudio.
(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-1-1024x392.png)

Como se observa en la Imagen 1, la topología por utilizar consiste en:

KL Interno: Host virtualizado con Kali Linux (versión 2018.1)
KL Externo: Host virtualizado con Kali Linux (versión 2018.1)
RA: Router Cisco (IOS Versión 15.2)
RB: Router Cisco (IOS Versión 15.2)
SWA: Sin configuraciones.
SWB: Sin configuraciones.
En los hosts “KL Interno” y “KL Externo”, se descargó (imagen 2) e instaló “Hans – IP over ICMP”. A continuación, se puede observar el proceso realizado en el host “KL Interno”.

Descarga desde https://sourceforge.net/projects/hanstunnel/

Imagen 2: Descarga de Hans desde sourceforge.
(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-2.png)

Descompresión de los archivos (imagen 3).
(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-3.png)

Compilación de archivos (imagen 4).
(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-4.png)

Configuraciones Routers
Se realiza la configuración de RA e ISP (imagen 5).
(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-5-896x1024.png)

(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-5-896x1024.png)

ICMP (Internet Control Message Protocol)

Es utilizado para realizar notificaciones y diagnostico entre otras funciones en redes IPv4, definido en la RFC 792. El formato de los mensajes ICMP se puede observar en la imagen 6:

(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-6.png)

Los valores asignados para los campos “Tipo” y “Código”, son responsabilidad de la IANA (https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml).

 

Ejemplo mensaje ICMP enviado desde KL Interno a RA:

En este ejemplo (imagen 7) se enviaron 5 mensajes de prueba (echo request) y se recibieron 5 respuestas (echo reply).

(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-7.png)

Se realizó la captura de estos mensajes en el segmento ubicado entre RA y KL Interno como se observa en la Imagen 8.

(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-8-1024x392.png)

En la Imagen 9 se puede apreciar los 5 mensajes enviados, con sus correspondientes respuestas.

(https://www.dragonjar.org/wp-content/uploads/2018/07/trafico-sobre-icmp-9.png)

Al analizar el primer mensaje enviado, se puede observar que este corresponde a un mensaje del tipo 8 (Echo Request) – Código 0. Además, se puede observar que existe un campo de relleno donde se le agrega carga al mensaje ICMP:

Más información: https://www.dragonjar.org/creando-un-tunel-ipv4-sobre-icmp-para-bypassear-controles.xhtml

Saludos.

hmm interesante!...


usualmente en empresa cuando estoy mi politica es input, output y forward drop y le doy accept a los puertos a medida que los voy necesitando

El siguiente criterio, está basado en mi experiencia personal. Dado, por los entornos, en que lo he implementado.
Centrándonos en el túnel ICMP. La primera vez que leí sobre él, fue buscando información para hacer un túnel DNS. Me pareció que era el descubrimiento de oro. Pero no.

Aspectos positivos:

Donde quiera que esté restringida la conexión (firewall, portales cautivos, etc.) y puedas hacer ping, “en teoría”, avala, para establecer un túnel TCP, sobre el ICMP (ping), y establecer tráfico.

Aspectos negativos:

-Es muy lento; tanto o igual que el túnel DNS.
-Es fácil de detectar; pues su tráfico, cualquier firewall, lo confunde con un ataque de “nukeo”.
-Fácil también de bloquear.
-Los portales cautivos modernos, no se saltan con este tipo de tráfico.

Y aquí pongo una anécdota:
La única vez que un túnel ICMP, me funcionó para saltar un portal cautivo, de tal manera estaba configurado (el portal), que con un simple Mac Spoofing y suplantación de IP, daba el brinco. Por supuesto, los AP no estaban isolados. Pero, el método del Mac Spoofing, era mejor (navegaba mejor), que con el túnel.

Tal vez sea que no haya tenido suerte, y no haya estado en las circunstancias correctas.
Honestamente, fue decepcionante.
Existen otras cosas mejores (en mi humilde opinión).
No lo recomiendo. Aunque siempre es bueno probar.  ;)