Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
domingo, 22 de abril de 2007
Hoy me voy a salir un poco de la temática habitual, relacionada con el mundo del desarrollo, para comentar una técnica de escaneo de puertos que me ha llamado mucho la atención por el ingenio que derrochó su inventor, Salvatore antirez Sanfilippo, en el año 1998.

Se trata de idle scan, una ocurrente forma para detectar los puertos abiertos en una máquina remota sin poner al descubierto al atacante, es decir, al equipo que realiza el escaneo. Para ello, se vale de una máquina intermedia, llamada zombie o dumb, que ejerce como intermediario en la comunicación y hace que en ningún caso la víctima reciba paquetes directamente desde el atacante, quedando éste en el más absoluto anonimato.

Bueno, he de decir que si no tienes claro el funcionamiento del protocolo TCP y el establecimiento de conexiones, es probable que debas pegar un repaso antes de seguir leyendo el post. En todo caso será una lectura aconsejable para todo humano interesado en saber qué está ocurriendo por debajo cuando estamos utilizando servicios en una red como Internet.

Ahora vamos al lío. La cuestión es que todo intrépido pirata sabe que antes de iniciar el ataque a una ciudad costera es conveniente ver los puertos en los que se puede atracar para hacer el desembarco, ¿no? Pues en Internet ocurre lo mismo, un puerto abierto en un equipo conectado a la red es siempre una posible vía de entrada al mismo; indica que hay una aplicación escuchando en la máquina, y habitualmente puede averiguarse cuál es y explotar sus debilidades.

Por tanto, un ataque tipo debería ir precedido de un escaneo de los puertos abiertos, es decir, recorrer los 65535 puertos posibles (o al menos el subconjunto de uso más habitual) a ver cuáles están en uso. La pega es que esto suele ser demasiado ruidoso, no son pocos los sistemas de detección de intrusos y filtros que detectan peticiones sucesivas desde una misma dirección y las clasifican de inmediato como sospechosas pudiendo llegar a banear (prohibir) la conexión desde la IP que está haciendo el barrido, o incluso a registrar la dirección para más adelante poder tomar medidas legales si procede.

Esta es la razón que hacen de Idle Scan una técnica interesante, puesto que, como he comentado antes, en ningún momento el atacado es consciente de la dirección del atacante.

Para ello se aprovecha, en primer lugar, el funcionamiento del three way handshake, el protocolo estándar utilizado para el establecimiento de conexiones TCP, donde de forma habitual:
  • El procedimiento se inicia cuando el cliente envía un paquete SYN al servidor. Si es posible realizar una conexión, éste responde con un SYN + ACK, y el cliente debe confirmar enviando de nuevo un ACK al servidor. En caso contrario, es decir, si no es posible realizar la conexión porque el puerto esté cerrado, el servidor responde con un RST y se da por finalizada la secuencia.
  • Si un host, sin haberlo solicitado previamente, recibe un paquete de confirmación de conexión SYN+ACK de otro, responde con un RST con objeto de informarle de que no va a establecerse conexión alguna.
  • Si un host, sin haberlo solicitado previamente, recibe un paquete de reseteo (RST), lo ignora.
En segundo lugar, y es la parte importante, Idle Scan utiliza una característica de determinadas implementaciones de la pila TCP/IP, la numeración de paquetes salientes IP de forma consecutiva, principalmente con objeto de que, en el caso de que deban ser fragmentados, el destinatario pueda determinar a qué paquete pertenece cada fragmento. Al número identificativo de un paquete se le conoce como IPID.

Para detectar si un puerto está abierto o cerrado, es necesario primero observar el IPID del zombie, enviar paquetes a la víctima haciéndole ver que realmente se los está enviando éste y, posteriormente, observar de nuevo el IPID utilizado por el incauto intermediario. En función de los valores iniciales y finales obtenidos, se puede inferir el estado del puerto destino.

A continuación se exponen dos escenarios distintos de escaneo; en el primero de ellos se muestra lo que ocurre cuando el puerto objeto de la detección está abierto, mientras que en el segundo se supone que está cerrado.

Escenario 1: Víctima con el puerto abierto

El primer paso es enviar al zombie un paquete SYN+ACK, con objeto de que éste nos devuelva el paquete RST correspondiente, del cual tomaremos el IPID.

Acto seguido, se realiza una solicitud de conexión a la víctima, previa manipulación del paquete para que sea el zombie el que figure como origen del mismo. Al recibirlo, dado que estamos asumiendo que el puerto está abierto (escenario 1), la víctima envía de vuelta la confirmación de la conexión al que cree que es el solicitante, el zombie.

El zombie recibe la confirmación de la conexión, pero como no es él el que la ha generado, responde a la víctima con una señal de reseteo (RST), incrementando su IPID.

De nuevo, pasado unos segundos, desde el atacante se vuelve a obtener el IPID del zombie de la misma forma que al comienzo, comprobando que ha sido incrementado en 2 unidades. De esta forma, se determina que el puerto destino del escaneo estaba abierto.

El siguiente diagrama muestra la secuencia forma gráfica:




Escenario 2: Víctima con el puerto cerrado

Como en el escenario anterior, el primer paso siempre es obtener el IPID del zombie, enviándole un paquete SYN+ACK, con objeto de que éste nos devuelva el paquete RST correspondiente.

De la misma forma, se envía a la víctima el paquete de solicitud de conexión, indicando en las cabeceras que el origen del mismo es el host zombie. Dado que el puerto está cerrado (escenario 2), la víctima devuelve al aparente emisor un paquete RST indicándole que no será posible establecer la conexión solicitada. El zombie recibe el paquete RST y lo ignora.

El atacante, siguiendo la misma técnica que en otras ocasiones, obtiene el IPID del zombie, y dado que es el número siguiente al recibido al iniciar el procedimiento, puede determinar que no ha realizado ningún envío entre ambos, y que, por tanto, el puerto de destino estaba cerrado.


Desde el punto de vista del atacante las ventajas son, fundamentalmente:

  • El anonimato, puesto que desde la víctima todas las conexiones provienen virtualmente del zombie, y en ningún momento se envía información directamente desde el atacante.
  • El alcance, es decir, esta técnica permite escanear puertos de máquinas a las que directamente no se tendría acceso debido a la acción de filtros (como firewalls) intermedios. Dado que las conexiones provienen del zombie, sólo habría que tener acceso a éste para realizar el escaneo.
  • La visión de red que aporta, en otras palabras, permite determinar las relaciones de confianza existentes entre el zombie y la víctima. Si, por ejemplo, un intento directo de conexión a un puerto de la víctima es rechazado y, sin embargo, es posible acceder a él desde un intermediario, es porque existe algún tipo de relación de confianza entre ambos, lo cual puede ser utilizado en ataques posteriores.

En la actualidad, el principal inconveniente es la dificultad de localizar un zombie apropiado para realizar los ataques, tanto por las condiciones software que debe cumplir (sistemas operativos, kernels, etc.), el escaso tráfico de red que debe tener en el momento del escaneo (necesarios para que los IPID no se incrementen por otras conexiones) y, sobre todo, las medidas de seguridad de que disponga, puesto que desde él sería posible detectar al atacante.

10 Comentarios:

Anónimo dijo...

Gracias, el texto es muy explicativo. Me ha gustado :-).

Una de esas ocasiones en que buscar (en google) info en castellano produce una respuesta excelente.

josé M. Aguilar dijo...

Gracias por tu comentario.

Y sí, en la red hay mucho contenido interesante en nuestro idioma, aunque todavía no podamos competir con el inglés. Todo se andará. ;-)

Anónimo dijo...

Muchas Gracias por la información la verdad pocas veces tan bien hecha y explicativa y como mencionan en español que es lo mejor jeje, saludos y suerte.

Ivan dijo...

idle scan
Hola Jose se que tu blogpost es un poco antiguo pero me ah resultado interesante tu blogger. Escribes bien. Es entretenido leerte. Podrias pensar en hacer articulos para revistas.
Referente al tema voy investigar y asi tambien poder aportar algo al tema.
Y desde luego tengo una pregunta un poco tediosa.
Como podria hacer algo parecido al idle scan preferiblemente desde c# o plataforma.net?
Realmente pienso que el tema "idle scan" tiene mucho mas que decir.
puedes contactarme en el idioma que te sea mas facil a ECDundy@rediff.com
gracias

Ivan dijo...

ecdundy@rediffmail.com

josé M. Aguilar dijo...

Hola, Iván.

Gracias por tu comentario.

No sé si existen componentes que permiten realizar idle scan u otras técnicas desde aplicaciones .NET. Probablemente podrías implementarlo usando las capacidades de la plataforma (System.Net), pero es un tema en el que no he profundizado hasta ese nivel.

Si encuentras algo, no dudes en compartirlo!

Anónimo dijo...

guacala

Anónimo dijo...

Hola estuvo buna la explicacion, solo que la mayoria de la gente que pasa por aqui anda buscando que les ayuden a escanear los puertos de una maquina para realizar sus ataques, seria mejor que leyeran un poco sobre un escaneo, un testeo y un barrido de puertos, que esos son 3 conceptos muy diferentes.

Saludos

Lsca Alfonso Mtz

quico dijo...

gracias . justo lo que necesitaba claro y en castellano

Emilio Nahuel dijo...

Hola, vale aclarar que este tipo de scan no me pertime distinguir de un puerto cerrado o filtrado.

Para mas detalladisima informacion:

http://nmap.org/idlescan-es.html

(si, ya se que este es un post del 2007)