"Idle Scanning" y algunos juegos relacionados al IPID

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.