este artículo - Ramiro Encinas

Idlescan: Escaneo invisible
de puertos
Ataque
Ramiro Encinas
Grado de dificultad
Idlescan es una técnica con la que podemos escanear los
puertos de un host sin que éste pueda saber quien es el host que
recibe los resultados de dicho escaneo. La clave de este tipo de
escaneo reside en la observación e interpretación de los números
de identificación de datagramas IP (IPID) de un tercer host zombie
que hace el trabajo sucio.
E
l objetivo de este artículo es educacional. La técnica desarrollada(Idlescan
o Escaneo de puertos mediante IPID)
fué creada por Antirez (Salvatore Sanfilippo) en
1998 y todavía hoy es posible utilizarla debido a
que, actualmente muchas máquinas reúnen las
condiciones adecuadas para implementar esta
técnica. Para entenderla correctamente se deben poseer conocimientos sobre los protocolos
TCP/IP, y el programa de generación de paquetes hping (también creado por Antirez).
La función del IPID
Cuando un datagrama IP se fragmenta en varios datagramas más pequeños para respetar el
MTU (tamaño máximo de datagrama) en algunas redes (bit No fragmentar desactivado de la
cabecera IP), éstos datagramas independientes
que integran el datagrama original completo
tienen la siguiente información común en su cabecera: la dirección IP de origen, la dirección IP
de destino, información del protocolo, el campo
de identificación de datagrama o IPID (Figura
1) y el bit No fragmentar desactivado. Todos
los datagramas con esta información común
que lleguen al protocolo IP del host receptor
se unirán, dando como resultado el datagrama
2
original. El número del campo IPID de estos
datagramas es el mismo, esto es: un IPID para
cada datagrama IP original completo. El IPID es
fundamental para el desensamblado y ensamblado de datagramas IP. Es importante saber
que, si el datagrama no se fragmenta, también
tiene su correspondiente IPID.
¿De qué forma el protocolo IP de un host
emisor genera un IPID y cómo lo asigna a la
cabecera de un datagrama IP para enviarlo?.
El IPID (según el RFC-791) es un número de
16 bits, pero no especifica qué pautas se deben
tener en cuenta para asignar los distintos IPID’s
para sus correspondientes datagramas IP, por
lo que esto dependerá del criterio del fabricante
que implemente el protocolo IP.
En este articulo aprenderás
•
•
La función del IPID
El funcionamento de Idlescan
Lo que deberias saber
•
•
www.hakin9.org
Nociones sobre TCP/IP
Nociones sobre shell/linea de comandos
Escaneo invisible de puertos
•
Figura 1. Campo IPID de la cabecera de un datagrama IP( fuente: RFC791-ES )
Observando al IPID
Lo anterior nos da paso a analizar
la secuencia IPID de distintos hosts.
Para esto es necesario utilizar el
programa de generación de paquetes TCP/IP hping contra un host y ver
las respuestas. Las figuras 2, 3 y 4
muestran los IPID’s obtenidos de paquetes TCP/IP de distintos sistemas
operativos mediante el comando
hping nombre _ host:
Debemos tener en cuenta que
estos resultados se han obtenido
de hosts ociosos (sólo comunicaban
con nosotros en ese momento) y estaban en la misma red, por tanto el
MTU no obliga a que los datagramas
IP se fragmenten. Como podemos
observar en la Figura 2 (Windows XP
SP2), este host ha respondido con 9
paquetes donde el IPID de cada uno
se incrementa de una forma particular: cada dos paquetes con IPID
consecutivo e incrementado positivamente da un salto hacia adelante de
21 en el IPID, donde vuelve a emitir
dos paquetes con IPID’s consecutivos e incrementados positivamente.
La Lexmark Optra (Figura 3) responde con 7 paquetes donde el IPID es
una secuencia de uno más uno. Por
último, el Linux con kernel 2.4 (figura
4) siempre devuelve 0 en sus IPID’s
(cuando el bit No fragmentar está activado en sus datagramas IP).
Como podemos observar, cada
fabricante de sistema operativo trata al protocolo IP y, en concreto, la
generación de IPID’s de una forma
arbitraria ¿porqué será?
el host que quiere comunicar con el
segundo le envía a éste un primer
paquete TCP/IP con la particularidad
de contener en la cabecera TCP el
campo SYN activado (petición de conexión), el puerto destino al cual queremos conectar y el puerto de origen
(Figura 5). Este datagrama TCP está
incluido en su correspondiente datagrama IP. La cabecera del correspondiente datagrama IP contiene el
campo de la dirección IP del host destino (con quien queremos conectar),
y también contiene el campo de la
dirección IP de origen (normalmente
la IP del host origen). La cabecera IP
también contiene el campo IPID con
su número correspondiente. Si el host
destino recibe este paquete TCP/IP
con el campo SYN activado, pueden
ocurrir una de estas dos cosas:
•
Que el puerto especificado esté
abierto en el host destino y éste
opte por aceptar la conexión. En
este caso, el host destino prepara
un primer paquete de respuesta
TCP/IP cuya cabecera TCP tiene
activados los campos de reconocimiento (SYN|ACK) como respuesta afirmativa al SYN recibido
del paquete anterior. Este paquete
TCP/IP elaborado será enviado al
host cuya IP figuraba en el campo
IP de origen en la cabecera del
datagrama IP recibido anteriormente (junto con el SYN del TCP).
Este paquete TCP/IP tendrá como
puerto destino el puerto de origen
especificado en la cabecera TCP
del paquete anterior.
Que el puerto especificado esté cerrado en el host destino y
por tanto no opte por aceptar la
petición de conexión. En este
caso, el host destino prepara un
paquete de respuesta cuya cabecera TCP tiene activados los
campos de rechazo de petición
de conexión (RST|ACK) como
respuesta negativa al SYN recibido del paquete anterior. Igual que
antes, este datagrama se dirige
al host cuya IP figuraba como origen en la cabecera IP recibida en
la petición de conexión y al puer-
Figura 2. IPID’s de Windows XP SP2
Un poco de TCP/IP
Según el RFC-793, para establecer
una conexión TCP/IP entre dos hosts,
Figura 3. IPID’s de una impresora Lexmark Optra
www.hakin9.org
3
Ataque
�������
�����
��������
���
������
�������
���������������
��������
����
�������
����
�����
������
����������
����
Figura 4. IPID’s de Linux con kernel 2.4
to correspondiente de origen.
La cabecera IP de este paquete
tendra su correspondiente IPID.
Por último, es conveniente saber
que, si un host recibe un paquete
TCP/IP con un RST|ACK , éste host no
continúa con esa comunicación.
Mezclando ingredientes
Con todo lo anterior, podemos iniciar
el escaneo de puertos al host destino
deseado sin que nos vea. Primero,
con hping seguiremos observando
los IPID’s de nuestro host zombie.
La mejor elección del host zombie
entre los casos que hemos visto
antes es la de la impresora Lexmark
Optra, ¿Por qué?, porque sus IPID’s
(Figura 3) van de uno en uno (en la
observación de resultados veremos
lo importante que es eso).
Después abriremos otra sesión
shell y utilizaremos de nuevo hping
para enviar un paquete TCP/IP
(especial) con petición de conexión
(SYN) al puerto que queremos saber
si está abierto o cerrado del host
destino que queremos escanear.
Evidentemente, y en condiciones
normales, cuando un programa de
un host de origen quiere ponerse en
comunicación con un puerto de un
host remoto, el programa indica la IP
Figura 7. Flujo de un Idlescan
detectando un puerto abierto
de su propio host en la cabecera del
datagrama IP para que el host remoto
envíe la respuesta a esa IP: respuesta
afirmativa (SYN|ACK) o respuesta negativa (SYN|RST). Esto no nos conviene porque el host remoto descubriría nuestra
IP (y nuestro propósito no es ese).
Con hping podemos enviar ese
paquete TCP/IP (SYN) a un puerto
de un host remoto especificando en
la cabecera del datagrama IP una
IP de origen que NO es la nuestra,
será la IP del host zombie, esto es,
la IP de la Lexmark Optra. Esto se
consigue utilizando hping con los
siguientes parámetros:
hping ip_host_destino –a ip_host_
zombie –S –p núm_puerto_a_escanear
Figura 5. ACK, SYN y RST en cabecera de datagrama TCP ( fuente: RFC793-ES )
Este comando enviará paquetes
TCP/IP (SYN) (parámetro –S) al puerto a escanear especificado (-p núm _
puerto _ a _ escanear) del host con la
IP destino (ip _ host _ destino), y especifica la IP del host zombie (-a ip _
host _ zombie) como IP de origen en la
cabecera IP de los paquetes TCP/IP
que enviará este comando. Ejecutado
este comando con sus parámetros,
no vamos a obtener respuesta, es un
envío ciego sin vuelta, sólo estamos
enviando paquetes TCP/IP (SYN) al
host destino que estamos escaneando. Con esto podemos pensar que al
no obtener respuesta no podremos
saber nada, porque la respuesta, sea
afirmativa o negativa, llegará a la impresora y no a nosotros.
Observando resultados
Figura 6. Incremento del IPID de un host zombie que dialoga con nosotros y
con otro host
4
www.hakin9.org
Al observar los resultados obtenemos lo siguiente: tenemos una
ventana con un hping a la impresora
Escaneo invisible de puertos
�����
��������
�������
���
������
��������
����
�������
����
�����
������
����������
����
Figura 8. Flujo de un Idlescan
detectando un puerto cerrado
zombie que nos está devolviendo
paquetes con un IPID consecutivo
(uno más uno). También tenemos
otra ventana con otro hping al puerto del host destino que estamos
escaneando. Éste host devuelve la
respuesta a la impresora. En este
punto, pueden ocurrir dos cosas:
•
•
Que el puerto del host que estamos escaneando esté cerrado,
por tanto envía un SYN|RST a la
impresora y ésta no hace nada.
Que el puerto del host que estamos escaneando esté abierto,
por tanto envía un SYN|ACK a la
impresora. La impresora recibe
una respuesta afirmativa a una
solicitud SYN que no ha enviado.
La impresora asumirá que esa
petición de sesión es falsa o que
el paquete es erróneo, por tanto,
contestará al host destino con
un SYN|RST, y por tanto, y lo más
importante, debido a este envío,
incrementa su IPID en uno.
Referencias
•
•
•
•
•
•
•
http://www.kyuzz.org/antirez/
papers/ipid.html
ht tp: / /w w w.kyuzz.org /antirez/
papers/dumbscan.html
http://insecure.org/nmap/idlescanes.html
http://www.radarhack.com /dir/
papers/hping2_v1.5.pdf
http://www.icir.org/vern/papers/
norm - usenix- sec - 01- html /
node8.html
http://www.rfc-es.org/rfc/rfc0791es.txt
http://www.rfc-es.org/rfc/rfc0793es.txt
Este incremento podemos verlo reflejado en la ventana donde hping
está consultando contínuamente a
la impresora. La impresora devuelve un IPID al host escaneado y el
siguiente IPID a nosotros. La figura
6 ilustra el resultado.
Como vemos en la figura 6, la
impresora nos envía en el primer
paquete de respuesta el IPID 21898
y después, el IPID 21899 (que no
vemos) lo ha enviado al host que
estamos escaneando. A continuación
recibimos el siguiente paquete con el
IPID 21900, y así sucesivamente. El
puerto escaneado está abierto porque
la impresora está enviando paquetes
TCP/IP (SYN|RST) a ese puerto con los
IPID’s que no vemos. También podemos deducir que en las condiciones
expuestas, si el incremento es de uno
en uno, es porque la impresora recibe
paquetes TCP/IP del host escaneado
con el rechazo de conexión ( SYN|RST).
Estos paquetes los ignora, y sigue dialogando sólo con nosotros. El puerto
escaneado está cerrado. En ambos
casos, el host escaneado sólo sabe la
IP del host “zombie”, no sabe la IP del
host que recibe la información de si sus
puertos están abiertos o cerrados.
•
alguna IP de algún host de la red
interna.
En el sistema operativo Linux
con kernel 2.4 y Solaris cada conexión tiene su propia secuencia
IPID y es distinta de la secuencia
IPID de otra conexión. Por lo
tanto es imposible realizar un
Idlescan utilizando como zombie
a este tipo de host. También, y
como hemos visto con Linux con
kernel 2.4, en el caso de que el
bit No fragmentar esté activado,
el IPID generado siempre es 0.
Conclusión
Con un escaneo Idlescan suplantamos a un host, en su nombre enviamos una petición de conexión a un
puerto del host deseando saber si está abierto o cerrado, el host suplantado recibe la respuesta y nuestro host
la interpreta a partir de él. Todo esto
gracias a la predicción del IPID.
Flujos
La Figura 7 muestra el flujo del
Idlescan cuando el puerto del host
destino o escaneado está abierto, y
la Figura 8 representa el flujo cuando
el puerto escaneado está cerrado.
Protegiéndonos del
Idlescan
Es complicado defenderse del Idlescan porque siempre habrá hosts zombies óptimos para utilizarlos (IPID’s
predecibles con hosts ociosos), pero
sí hay que tener en cuenta algunas
consideraciones para protegernos
de él:
•
•
Generación de secuencias IPID
aleatorias, pero es complicado
no seguir un patrón detectable y
predecible.
Los firewalls perimetrales no deberían aceptar conexiones IP de
entrada de hosts que contengan
IP’s de origen que coincidan con
www.hakin9.org
5