"Idle Scanning" y algunos juegos relacionados al IPID

Original English version of this paper

Hace casi cuatro años, Antirez (investigador de seguridad) posteó; una nueva innovadora técnica de escaneo de puertos de TCP. Un "Idlescan", como llegó a conocerse, permite un escaneo de puertos completamente invisible. ¡Los atacantes pueden realmente escanear una máquina sin necesidad de enviar ni un sólo paquete al host destino desde su propia dirección! En lugar de ello, un ataque paralelo permite que el escaneo sea una especie de rebote en una máquina inactiva ("zombie") . Los reportes de sistemas de detección de intrusión (IDS) indicarán a la máquina "zombie" como la atacante. Además de ser extraordinariamente invisible, este tipo de escaneo permite mapear la relaciones de confianza basadas en IP entre máquinas.

Asumí que un problema de esta magnitud generaría una respuesta inmediata y parches de parte de los desarrolladores de sistemas operativos. Desafortunadamente, muchos escogieron ignorar el problema por años. Aparentemente, creen que éste es un problema "teórico que no es práctico para ser explotado en el mundo real. Para refutar esa postura, e incrementar la presión sobre los desarrolladores y obligar a que solucionen el problema, he publicado una implementación robusta de un idlescan en versiones recientes de Nmap. Este paper describe la técnica en detalle y ofrece defensas que los administradores de redes, ISPs, y desarrolladores de sistemas operativos pueden utilizar para mitigar esta vulnerabilidad.

Tengan en cuenta que un "idle scanning" es sólo uno de los riesgos de seguridad causados por números de secuencia de IPID predecibles. Este paper describe varios otros ataques de recolección de información posibles gracias a esta característica.

Técnica

Aunque un `idle scanning' es bastante sofisticado en materia de métodos de escaneo de puertos, uno no tiene que ser un experto en TCP/IP para comprenderlo. Sólo se necesita comprender algunas cuestiones básicas:

  • La mayoría de los servidores esuchan en puertos de TCP, de la manera en la que los servidores de web escuchan en el puerto 80 y los servidores de correo en el puerto 25. Un puerto es considerado "abierto" si alguna aplicación está escuchando en ese puerto, si no, está cerrado.
  • Una manera de determinar si un puerto esta abierto es envia un paqueter con "SYN" (establecimiento de sesión) al puerto. La máquina destino enviará de vuelta un paquete con "SYN|ACK" (reconocimiento de pedido de sesión) si el puerto está abierto, y un paquete con "RST" si el puerto está cerrado.
  • Una máquina que recibe un paquete con "SYN|ACK" no solicitado previamente responderá con una "RST". Pero un "RST" no solicitado previamente es ignorado.
  • Cada paquete de IP en Internet tiene un número de "identificación de fragmento". Varios sistemas operativos simplemente incrementan este número por cada paquete que envían. Por lo tanto la observación de este número puede decirle al atacante cuántos paquente han sido enviados desde la última observación.

Al combinar estas características, es posible escanear una red falsificando nuestra identidad para que parezca que una máquina "zombie" inocente realizó el escaneo. Es más fácil describir esta técnica por medio de un diagrama. En la imagen, debajo, un atacante, A, está escaneando una máquina destino, y a la vez culpando del escaneo a algún zombie, Z. Los cuadrados representan máquinas y las líneas representan paquetes. Breves descripciones en castellano de los paquetes están impresas por encima de las líneas, mientras que las "flags" reales de TCP e información distintiva de los paquetes están impresas debajo de ellas:

Como muestra el diagrama, el host destino responde de manera diferente al Zombie dependiendo del estado del puerto. Si el puerto probado está abierto, el destino envía un SYN|ACK al Zombie. El Zombie no esperaba este SYN|ACK, por lo tanto, envía de vuelta un RST. Al enviar este RST, el Zombie hace que se incremente su número de secuencia de IPID. El verdadero atacante detecta esto en el paso 3. Si el puerto está cerrado, el destino envía un RST al Zombie. Los Zombies ignoran este paquete RST no solicitado y no incrementan su número de secuencia de IPID.

Ventajas del Idlescan

Las técnicas de Idlescan ofrecen al atacante muchas ventajas por sobre otros tipos de escaneo populares como los "SYN scans" o los "FIN scans". Es por esto, que recomendamos defensas importantes para ayudar a proteger la red de este ataque. Estas son algunas de las razones, por las cuales los atacantes podrían usar este método de escaneo:

  • Porque es el más sigiloso -- Hay muchas técnicas que la gente puede utilizar para camuflar su identidad. Entre ellas, el uso de señuelos (Nmap -D) of escaneos medio-abiertos ("half-open scans", nmap -sS). Pero incluso estas técnicas requieren que el atacante envíe algunos paquetes al destino desde su dirección de IP real. Por otra parte, un Idlescan es completamente invisible -- ningún paquete es enviado al destino desde la verdadera dirección de origen --.

    Como conclusión, se tiene que los sistemas de detección de intrusión (IDS), generalmente, ¡indicarán y enviarán alertas diciendo que la máquina Zombie ha lanzado un escaneo hacia ellos!.

  • Vencer routers/firewalls que filtran paquetes -- El filtrado por dirección de IP de origen es un mecanismo de seguridad muy común que sirve para limitar las máquinas que pueden conectarse a un host delicado. Por ejemplo, el servidor de base de datos de una compañía quizás admita conexiones sólo desde el servidor público de web que accede a ella. Un usuario desde su casa quizás sólo permita conexiones de `ssh' (login interactivo) desde sus máquinas del trabajo.

    Un escenario más perturbador ocurre cuando alguien de peso en alguna compañía demanda que los adminstradores de red abran un agujero en el firewall para que él puede acceder a los recursos de la red interna desde la dirección de IP de su casa. Esto puede pasar cuando los ejecutivos no pueden o no tienen ganas de contemplar una alternativa de VPN (red privada virtual) segura.

    El "idle scanning" puede ser utilizado con frecuencia para mapear esas relaciones de confianza. El factor clave es que los resultados de un Idlescan listan los puertos abiertos desde la perspectiva del host zombie. Por lo tanto un escaneo normal sobre el servidor de base de datos mencionado anteriormente podría mostrar que no hay puertos abiertos. Pero al realizar un Idlescan utilizando al servidor de web como zombie podría exponerse la relación de confianza al mostrar abiertos los puertos de servicios relacionados a la base de datos.

    Mapear estas relaciones de confianza puede ser muy útil para que los atacantes le den prioridad a algunos destinos. El servidor de web distutido anteriormente puede parece algo normal al atacante hasta que nota su acceso especial a la base de datos.

Ejemplos de uso de Nmap

El primer paso es encontrar un host zombie apropiado. El host no debería tener mucho tráfico, (de ahí el nombre Idle, inerte, inactivo ) y debería ofrecer valores de IPID predecibles. Impresoras, máquinas con Windows, hosts con versiones de Linux viejas, FreeBSD, y Mac OS son generalmente útiles. Las últimas versiones de Linux, SOlaris Y OpenBSD son inmunes a ser tratadas como zombies, pero cualquier host puede ser objeto de el escaneo. Una manera de determinar la vulnerabilidad de un host es simplemente probar un Idlescan de Nmap. Nmap comprobará el zombie y reportará si es confiable.

Efectuar estos escaneos es bastante fácil. Simplemente hay que proveer de el nombre del host zombie a la opción -SI y Nmap hace el resto. Este es un ejemplo rápido: 

# nmap -P0 -p- -sI kiosk.adobe.com www.riaa.com
Starting nmap V. 3.10ALPHA3 ( insecure.org/nmap/ )
Idlescan using zombie kiosk.adobe.com (192.150.13.111:80); Class: Incremental
Interesting ports on 208.225.90.120:
(The 65522 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp
25/tcp     open        smtp
80/tcp     open        http
111/tcp    open        sunrpc
135/tcp    open        loc-srv
443/tcp    open        https
1027/tcp   open        IIS
1030/tcp   open        iad1
2306/tcp   open        unknown
5631/tcp   open        pcanywheredata
7937/tcp   open        unknown
7938/tcp   open        unknown
36890/tcp  open        unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 2594.472 seconds

De este escaneo, aprendemos que la RiAA no es muy consciente de la seguridad (se pueden notar abiertos los puertos de "PC Anywhere", "portmapper, Y "Legato nsrexec"). Ya que aparentemente no tienen un firewall, es poco probable que sí tengan un IDS. Pero si lo tienen, mostrará a 'kiosk.adobe.com' como el culpable del escaneo. La opción -P0 previente que Nmap envíe un ping incial a la Máquina de RIAA. Esto disminuye la velocidad del escaneo (hay menos información disponible sobre los tiempos), pero asegura que ningún paquete sea enviado al destino desde nuestra verdadera dirección de IP. El escaneo tardó un largo tiempo porque se escanearon los 65535 puertos -- hay que saltear la opción "-p-" si sólo se quieren escanear los puertos bastante conocidos ("well know ports") además de los puertos 1-1024 --. Uno tiene que asegurarse de encontrar zombies propios -- Kiosk no es muy confiable y es probable que desaparezca o sea monitoreado de cerca --.

Defensas

Afortunadamente, hay varias defensas que pueden ser implementadas para prevenir la mayoría de los ataques relacionados a IPID:

Administradores de Redes:

  • Los firewalls y "border routers" deberían estar configurados para denegar paquetes entrantes con direcciones de origen extrañas. (por ej. que parezcan venir desde máquinas internas a nuestra red, direcciones reservadas como 10.X.X.X o 192.168.X.X, direcciones localhost 127.X.X.X, etc. Cualquier buena guía de firewalls debería proveer de una orientación más detallada acerca de estas reglas esenciales).
  • Las reglas de los firewalls que mantienen registro del estado de las conexiones ("Stateful firewalls") pueden ayudar también a este tipo de ataques -- hay que asegurarse de que el firewall ofrezca esta característica y de que esté habilitada --.
  • Tratar de utilizar sistemas operativos con secuencias de IPID menos predecibles, como versiones recientes de OpenBSD, SOlaris o Linux. Mientras que esos sistemas operativos son inmunes a convertirse en zombies con la versión actual de Nmap, quizás no frenen todos los ataques relacionados a IPID. Se necesita más investigación.
  • Implementar filtrado de salida para prevenir que paquetes forjados con direcciones falsas abandonen nuestra red. Esto previene que nuestros empleados/estudiantes lancen alguno de estos ataques.

Proveedores de Servicio de Internet (ISPs):

La protección más importante que los ISPs pueden ofrece es utilizar filtrado de salida para prevenir que paquetes forjados con direcciones falsas abandonen nuestra red. Esto previene que los usuarios ejecuten muchos ataques horribles e inclusive, detiene un Idlescan. Además de ayudar al desempeño de Internet, el filtrado de salida puede ahorrartnos costos sustanciales al tener que investigar ataques de "IP spoofing" (engaño de IP).

Desarrolladores de sistemas operativos:

Un buen enfoque es utilizar secuencias de IPID específicas a cada conexión o a cada "peer" (peer: el otro host involucrado en el intercambio de paquetes). Solaris hace esto y limita severamente la información que los atacantes puedan obtener acerca de otras conexiones. Linux 2.4 también utiliza Valores de IPID específicos por cada peer (ver net/ipv4/inetpeer.c). Adicionalmente, Linux 2.4 resetea a cero el campo IPID en paquetes en los que el bit DF ("No fragmentar") está activado. Después de todo, la defragmentación de IP es el único uso crítico del campo ID. Otro enfoque (utilizado por OpenBSD) es generar la secuencia IPID aleatoriamente. Esto es difícil de lograr correctamente -- hay que asegurarse de que la secuencia no se repite y de que cada número no sea utilizado dos veces en un período corto de tiempo --.

Desafíos de Idlescan

Iba a discutir competiciones de implementación para escribir escáners rápidos y precisos. Pero muy pocos de ustedes están haciéndolo, y aquellos que lo hacen, pueden leer la fuente de Nmap y otros escáners. Por lo tanto, sólo remarcaré un cuantos puntos importantes. Esta sección también incluye algunos desafíos encontrados por usuarios de las herramientas.

  • Desempeño -- Escanear un puerto a la vez (como muestra el diagrama antes visto) puede ser horrendamente lento en el caso de miles de puertos. Nmap maneja esto mandando hasta 100 pruebas. Si Nmap encuentra que la IPID sí se incrementó, limitará la búsqueda de puertos abiertos usando un enfoque de búsqueda binaria.
  • Hosts no inertes -- Un Idlescan funciona contando el número de paquetes enviados por un zombie y asumiendo que esos paquetes son respuestas a paquetes originados por el destino. Entonces, paquetes extraños enviados por un zombie no inerte pueden causar una confusión importante. Nmap trata de contrarrestar este problema, con retransmisión de las pruebas y otras técnicas para detectar resultados falsos. Por ejemplo, Nmap sabe que algo está mal si prueba 6 puertos y la IPID se incrementa en 10 o 20. Nmap ajusta sus tiempos y paralelismo para compensar hosts que estén ligeramente activos o que descarten (drop) paquetes cuando detecta esto. Sin embargo, Nmap no será confiable con los zombies muy cargados de actividad. Una técnica para manejar zombies muy activos es enviar un gran número (docenas o cientos) de pruebas a cada puerto. Esta técnica de "fuerza bruta" puede ocultar una pequeña cantidad de tráfico de "ruido blanco". Desafortunadamente, el costo es un ancho de banda significativo, escaneos lentos, y la posibilidad de rebalsar con SYNs ("SYN flood") al destino. Thomas Olofsson demostró una herramienta para lograr esto en su presentación en la "2001 Black Hat Briefings". Su presentación (Powerpoint) está disponible aquí.
  • Filtrado de salida -- Si no podemos forjar paquetes con direcciones de origen falsas debido al filtrado de salida por parte de tu ISP, intenta con otro ISP o (para usuaros avanzados) se puede probar haciendo un "IP tunneling". También se puede tratar de hacer "rebotar" el ataque desde otra máquina dentro de tu misma red (ya que es poco probable que sea filtrada).
  • Zombies inmunes -- Algunos hosts no funcionarán como zombies debido a un sistema operativo astuto o tráfico sustancial. En muchos casos, simplemente se puede utilizar un zombie diferente.

Más diversión con predicción de IPID

Aunque este paper se enfoca en utilizar secuencias de IPID predecibles para escanear puertos, hay muchas otras maneras retorcias de explotar esta información. Esta es una breve lista:

  • Análisis de tráfico -- Los números de IPID secuenciales exponen el número de paquetes enviados por un host sobre un cierto período. Esto puede ser usado para estimar el tráfico de un sitio web, determinar cuando se loggea la gente, etc.
  • Detección de alias de hosts -- Muchas veces un host tendrá múltiples direcciones de IP o varias interfaces ethernet. Casi siempre se puede determinar cuáles direcciones pertenecen a un cierto host buscando números de secuencia de IPID similares.
  • Demultiplexación de equilibrio de Carga ("load balancing") -- ésta es casi la técnica inversa a la previa. Grandes sitios suelen utilizar equipo de equilibrio de carga para que una sóla dirección mapee a una pequeña granja de servidores. Teniendo en cuenta los valores de IPID, se puede, usualmente, determinar cuántas máquinas están detrás del equipo y a cuál estamos conectados. Por ejemplo, los campos "id' en la siguiente ejecución de hping2 ponen en obvia evidencia que beta.search.microsoft.com es manejada por dos máquinas detrás del equipo de equilibrio de carga (207.46.197.115). 
    # hing2 -c 10 -i 1 -p 80 -S beta.search.microsoft.com.
HPING beta.search.microsoft.com. (eth0 207.46.197.115): S set, 40 headers + 0 data bytes
46 bytes from 207.46.197.115: flags=SA seq=0 ttl=56 id=57645 win=16616 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=1 ttl=56 id=57650 win=16616 rtt=21.4 ms
46 bytes from 207.46.197.115: flags=RA seq=2 ttl=56 id=18574 win=0 rtt=21.3 ms
46 bytes from 207.46.197.115: flags=RA seq=3 ttl=56 id=18587 win=0 rtt=21.1 ms
46 bytes from 207.46.197.115: flags=RA seq=4 ttl=56 id=18588 win=0 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=5 ttl=56 id=57741 win=16616 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=RA seq=6 ttl=56 id=18589 win=0 rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=7 ttl=56 id=57742 win=16616 rtt=21.7 ms
46 bytes from 207.46.197.115: flags=SA seq=8 ttl=56 id=57743 win=16616 rtt=21.6 ms
46 bytes from 207.46.197.115: flags=SA seq=9 ttl=56 id=57744 win=16616 rtt=21.3 ms
--- beta.search.microsoft.com. hping statistic ---
10 packets tramitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 21.1/21.3/21.7 ms
  • Detección de sistemas operativos -- Como se discutió anteriormente, los sistemas operativos difieren salvajamente en la manera en la que generan los números de IPID. Nmap utiliza esta información para ayudar a determinar qué versión de sistema operativo se está usando. Más detalles de esta técnica aquí.
  • Detección de reglas de firewall -- El valor de IPID puede ayudar a mapear las reglas de firewall. Este es un ejemplo simple:
    1. Observamos la IPID de la máquina destino detrás del firewall.
    2. Enviamos un paquete de ping "desde" un host detrás del firewall hacia el mismo destino.
    3. Observamos la IPID nuevamente. Si se incrementó en 2 (uno por la respuesta al ping y otro por la segunda observación de la IPID), nuestro ping engañoso logró pasar. Algo de Tráfico extraño puede interferir, pero volver a probar puede asegurará precisión. Esta técnica puede ser expandida de varias maneras. Podría (y quizás lo haga) escribir un paper completo describiéndolas. Hay que tener en cuenta que todos los pasos anteriores pueden ser realizados con Hping.

Links relacionados

  • Nmap, que ahora incluye un Idlescan, está disponible en http://nmap.org/
  • La técnica básica de escaneo por IPID fue inventada por Antirez (Salvatore Sanfilippo). Su home page está en http://www.kyuzz.org/antirez/.
  • Antirez también desarrolló la excelente herramienta Hping, que es tremendamente útil para pruebas de IPID de bajo nivel.
  • LiquidK posteó un escáner de IPID como prueba de concepto y le puso el nombre "idlescan" en 1999. Las URLs no funcionan más, pero quizás se puede encontrar su implementación por medio Google o Packetstorm.
  • Thomas Olofsson escribió y demostró una herramienta de escaneo de IPID en la conferencia "2001 Black Hat Briefings". Su presentación (Powerpoint) está disponible en aquí y le da una buena mirada a la técnica básica. Como mencioné anteriormente en este paper, esta heramienta podría ser preferible a Nmap en casos en los que el host zombie inerte, no es realmente inerte. Desafortunadamante, no tengo una URL que funcione para esta herramienta.