Adaptado por LOBOestepaRIO
y .:BioHazard:.
Detección remota de sistema operativo vía reconocimiento de stack
TCP/IP
Ultima Modificación: Abril 10, 1999
[French Translation by Arhuman
]
[Portuguese Translation by Frank Ned
]
[Italian Translation by Rige
]
[Russian Translation by Alex Volkov
]
[Spanish Translation by Marco Barbosa
]
RESUMEN
Este documento discute como obtener información
valiosa sobre una maquina consultando su stack TCP/IP. Primero presentaré
algunos de los métodos "clásicos" para determinar el sistema
operativo de una máquina, que no requieren identificación de su stack.
Después describiré las herramientas actuales más novedosas para
identificación del stack. Después viene una descripción de muchas técnicas
para hacer que la maquina remota nos provea de un poco de información
sobre sí misma. Finalmente, detallaré mi implementación de esto
(Nmap), seguido de una imagen obtenida de Nmap que nos dice que sistema
operativo están corriendo en muchos sitios populares de Internet.
RAZONES
Pienso que la utilidad de determinar que sistema operativo esta
corriendo en un host es bastante obvia, así que haré esta sección
corta. Una de los ejemplos más frecuentes de esta utilidad es que
muchos agujeros de seguridad son dependientes de la versión del sistema
operativo. Digamos que en una prueba de penetración resulta que
un host tiene el puerto 53 abierto. Si esta es una versión vulnerable
del Bind, solo hay una oportunidad de explotarlo ya que un intento
fallido detendrá el demonio. Con un buen identificador de TCP/IP, rápidamente
sabrás que esta maquina esta corriendo "Solaris 2.51" o
"Linux 2.0.35" y entonces ajustar tu código shell de acuerdo
a esto.
Una posibilidad aun peor, es alguien que desee
escanear 500,000 maquinas con anticipación para ver que sistemas
operativos están corriendo y que puertos tienen abiertos. Después,
cuando se publicara (digamos) un agujero para obtener root en el demonio
comsat de Sun, se podria hacer un grep a su lista para obtener
"UDP/512" y "Solaris 2.6" e inmediatamente tener
paginas y paginas de maquinas vulnerables. Debe notarse que esto es un
comportamiento de script kiddie, porque no es necesaria ninguna
habilidad en especial y nadie se impresionará por que alguien encuentre
algún server .edu vulnerable que no haya parcheado el agujero a tiempo.
Además, en base a eso tampoco resultaría difícil (pero si bastante
tonto) utilizar el agujero para ridiculizar el sitio-web con un
monumento anunciando lo estúpidos que deben ser los administradores del
sistema.
Otro uso posible es para ingeniería social.
Digamos que estas escaneando tu compañía objetivo y Nmap reporta un
'Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06'. En este caso se
puede llamar como 'Soporte de Datavoice' y discutir algunos asuntos
sobre su PRISM 3000. "Vamos a anunciar un agujero de seguridad
pronto, pero primero queremos que todos nuestros clientes actuales
instalen el parche -- se lo acabo de enviar por correo..." Algunos
administradores ingenuos podrían asumir que solo un ingeniero
autorizado de Datavoice podría saber tanto de su CSU/DSU.
Otro uso potencial para esta capacidad es evaluación
de compañías con las cuales hacer negocios. Después de seleccionar un
ISP, escanealos para ver que equipo usan. Esos tratos de "$99/año"
no suenan tan buenos cuando se entera que tienen routers baratos y
ofrecen PPP basado en servidores Windows.
TECNICAS CLASICAS
La identificación de stack resuelve el problema
de identificar un sistema operativo de manera única. Yo pienso que esta
técnica tiene el mayor futuro, pero hay en la actualidad muchas otras
soluciones. Tristemente, esta es aun una las técnicas mas efectivas:
#shell> telnet hpux.u-aizu.ac.jp
Trying 163.143.103.12 ...
Connected to hpux.u-aizu.ac.jp.
Escape character is '^]'.
HP-UX hpux B.10.01 A 9000/715 (ttyp2)
login:
No vale la pena pasar por todo el procedimiento de identificación si
la maquina anunciara despreocupadamente al mundo exactamente que
es lo que esta corriendo! Tristemente, muchos vendedores envían
sistemas actuales con este tipo de letreros y muchos administradores no
los quitan. Solo porque hay otras maneras de averiguar que sistema
operativo se esta corriendo, no quiere decir que vamos a anunciar
nuestro sistema operativo y arquitectura a todo aquel que trate de
conectarse.
El problema con depender de esta técnica es que
un numero creciente de gente esta quitando los letreros, muchos sistemas
no dan mucha información, y es trivial que alguien "mienta"
en sus letreros.
Sin embargo, lectura de letreros es todo lo que se
obtiene gastando $miles en el escaner ISS comercial. Nmap son mucho
mejores y completamente gratis :-).
Aun si sacas los letreros, muchas aplicaciones
felizmente regalaran este tipo de información cuando se les pregunte.
Por ejemplo veamos a un servidor FTP:
#shell> telnet ftp.netscape.com 21
Trying 207.200.74.26 ...
Connected to ftp.netscape.com.
Escape character is '^]'.
220 ftp29 FTP server (UNIX(r) System V Release
4.0) ready.
SYST
215 UNIX Type: L8 Version: SUNOS
Primero que nada, nos da detalles del sistema en
su letrero por defecto. Después si le damos el comando 'SYST', nos
regresa aun más información.
Si soporta FTP anónimo, muchas veces podemos
bajar /bin/ls u otros ejecutables y determinar para que arquitectura
fueron construidos.
Muchas otras aplicaciones también dan información
gratis. Toma los servidores web por ejemplo:
#shell> echo 'GET / HTTP/1.0 ' | nc hotbot.com
80 | egrep '^Server:'
Server: Microsoft-IIS/4.0
Hmmm ... me pregunto que sistema operativo están
corriendo estas personas, jeje.
Otras técnicas clásicas incluyen registros de
información del DNS (raramente efectivos) e ingeniería social. Si la
maquina esta escuchando 161/udp (snmp), casi se te garantiza muchísima
información detallada usando 'snmpwalk' de la distribución de
herramientas de CMU SNMP y el nombre comunitario 'public'.
PROGRAMAS DE IDENTIFICACION ACTUALES
Nmap no es el primer programa de reconocimiento de
sistema operativo que usa identificación de stack TCP/IP. El spoofer
para IRC sirc de Johan ha incluido técnicas de identificación muy
primitivas desde la versión 3 (o anteriores). Intenta colocar un
anfitrión en las clases "Linux", "4.4BSD",
"Win95", o "Desconocido" usando una cuantas pruebas
simples de los flags del segmento TCP.
Otro programa así es checkos, hecho publico en
Enero de este año por Shok en el numero 7 de Confidence Remains High.
Las técnicas de identificación son exactamente
las mismas que las de SIRC, y aun el código es idéntico en muchos
lugares. Checkos ya era disponible privadamente por mucho tiempo antes
de su puesta al publico, así que no tengo idea quien le copio código a
quien. Pero ninguno parece darle crédito al otro. Algo que checkos
agrega, es el chequeo de letrero de telnet, que es útil, pero tiene los
problemas descritos con anterioridad. [Actualización: Shok escribio
para decir que no se tenia la intencion de hacer checkos publico y por
esto no se molesto en darle credito a SIRC por algunas partes del
codigo.]
Su1d también escribió un programa para chequear
sistema operativos. El suyo se llama SS y a partir de la versión 3.11
puede identificar 12 diferentes tipos de sistemas operativos. Yo soy un
tanto parcial hacia este ya que le da crédito a mi Nmap por unas partes
del código interconexión :).
Después, esta queso. Este programa es el más
nuevo y es un gran salto en comparación con los otros de los otros
programas. No solo introducen un par de pruebas novedosas, sino que
fueron los primeros (que yo he visto) en mover el fingerprinting fuera
del código fuente. Los otros escaners incluyeron código como:
/* from ss */
if ((flagsfour & TH_RST) && (flagsfour
& TH_ACK) && (winfour == 0) &&
(flagsthree & TH_ACK))
reportos(argv[2],argv[3],"Livingston
Portmaster ComOS");
En su lugar, queso pone esto en un archivo de
configuración, que obviamente es mejor para incrementar y hace que
poner otro sistema operativo sea tan fácil como agregar unas cuantas líneas
a un archivo de fingerprints.
Queso fue escrito por Savage.
Un problema con todos los programas descritos
arriba es que están muy limitados en el numero de pruebas de
identificación que limita la granularidad de las respuestas. Yo quiero
saber más que solo 'esta maquina es OpenBSD, FreeBSD, NetBSD, yo deseo
saber exactamente cual de esas es así como una idea de el numero de
versión del sistema.
De la misma manera, preferiría ver 'Solaris 2.6'
que simplemente 'Solaris'.
Para obtener esta granularidad en las respuestas,
yo trabajé en un numero de técnicas de identificación que se
describen en la siguiente sección.
METODOLOGIA DE IDENTIFICACION
Hay muchas técnicas que pueden ser usadas para
identificar las diferencias entre los stack TCP/IP. Básicamente, solo
alcanza con buscar cosas que difieran entre los sistemas operativos y
escribir una prueba para la diferencia. Combinando suficientes de estas,
se puede aislar el sistema operativo con gran exactitud. Por ejemplo
Nmap puede distinguir confiablemente Solaris 2.4 vs. Solaris 2.5-2.51 vs
Solaris 2.6. También puede identificar el kernel de Linux 2.0.30 del
2.0.31-34 o 2.0.35.
Aquí hay algunas técnicas:
La prueba FIN
-- Aquí mandamos un paquete FIN (o cualquier
paquete sin una bandera ACK o SYN) a un puerto abierto y esperamos una
respuesta.
El comportamiento correcto del RFC793 es no
responder, pero muchas implantaciones quebradas como MS Windows, BSDI,
CISCO, HP/UX, MVS, e IRIX envían un RESET (flag RSET) de regreso.
Muchas de las herramientas actuales utilizan esta técnica.
La prueba de flag BOGUS
-- Queso es el primer escaner que he visto
utilizar esta prueba inteligente. La idea es poner un "flag"
TCP indefinido (64 o 128) en el encabezado TCP de un paquete SYN.
Los kernels Linux antes de 2.0.35 mantienen la
bandera puesta en su respuesta. No he encontrado ningún otro sistema
operativo que tenga este defecto.
Sin embargo, algunos sistemas operativos parecen
cancelar la conexión cuando reciben un paquete SYN+BOGUS. Este
comportamiento podría ser útil para identificarlos.
La prueba TCP ISN (número de secuencia TCP)
-- La idea aquí es encontrar patrones en los números
de secuencia inicial seleccionados por las implantaciones de TCP al
responder a solicitudes de conexión. Esto puede ser categorizado en
muchos grupos como el tradicional 64K (presente en muchos UNIX viejos),
incrementos aleatorios (nuevas versiones de Solaris, IRIX, FreeBSD,
Digital UNIX, Cray, y muchas otras), "Aleatoriedad" verdadera
(Linux 2.0.*, OpenVMS, AIX mas nuevos, etc). Los Windows (y unas cuantas
más) usan un modelo "dependiente del tiempo" donde el ISN se
incrementa por una pequeña cantidad estática cada periodo de tiempo.
Sin necesidad de decirlo, esto se vence tan fácilmente como el viejo
comportamiento de 64K. Claro que mi técnica favorita es la
"constante". Las maquinas SIEMPRE usan exactamente el mismo
ISN. :). He visto esto en algunos hubs 3com (usan 0x803) y en impresoras
Apple LaserWriter (usan 0xC7001).
También se puede subdividir grupos tales como
incremento aleatorio por varianzas computacionales, máximos comunes
divisores, y otras funciones en el conjunto números de secuencia y las
diferencias entre los números.
Debe notarse que la generación de ISN tiene
implicaciones de seguridad importantes. Nmap es el primer programa que
he visto que usa esto para identificación del sistema operativo.
BIT de No-fragmentación
-- Muchos sistemas operativos están empezando a
poner el bit "no-fragmentación" de IP en algunos paquetes que
mandan. Esto da varios beneficios de desempeño (aunque también puede
ser molesto, y por esto las exploraciones de fragmentación de Nmap no
funcionan en Solaris). En cualquier caso, no todos los sistemas
operativos hacen esto y algunos lo hacen en diferentes casos, así que
poniendo atención a este bit podemos obtener aún mas información
sobre nuestro objetivo. Tampoco he visto esto antes en ningún otro
programa.
Ventana Inicial TCP
-- Esto solo requiere chequear el tamaño de la ventana de los
paquetes regresados. Escaners mas viejos simplemente utilizan en una
ventana inicial distinta de cero en un paquete RST para querer decir
"derivado de BSD 4.4". Escaners mas nuevos como queso y
Nmap dan seguimiento a la ventana exacta, ya que es en realidad bastante
constante según el tipo de sistema operativo. De hecho esta prueba nos
da mucha información, ya que algunos sistemas operativos pueden ser
identificados de manera única por la ventana en si (por ejemplo, AIX es
el único sistema operativo que he visto usa 0x3F25). En su stack TCP
"completamente re-escrita" para NT5, Microsoft usa 0x402E. De
“casualidad”, ese es exactamente el numero usado por OpenBSD y
FreeBSD.
Valor ACK
-- A pesar de que podría pensarse que esto seria completamente estándar,
en algunos casos las implementaciones difieren en el valor que usan para
el campo ACK. Por ejemplo, digamos que mandas un paquete con flags FIN |
PSH | URG a un puerto TCP cerrado. La mayor parte de las
implementaciones pondrán el ACK igual que tu numero de secuencia
inicial, pero Windows y algunas impresoras estúpidas te mandaran tu
secuencia + 1. Si mandas un SYN | FIN | URG | PSH a un puerto abierto,
Windows es muy inconsistente. Algunas veces regresa tu secuencia, otras
veces manda el número de secuencia + 1, aun otras veces regresa un
valor aparentemente aleatorio. No es necesario preguntarse que tipo de código
esta escribiendo MS que cambia su parecer de esta manera.
Control de Error de Mensaje ICMP
-- Algunos sistemas operativos (inteligentes)
siguen la sugerencia RFC 1812 de limitar la cantidad en que diferentes
mensajes de error son mandados. Por Ejemplo, el kernel de Linux (en
net/ipv4/icmp.h) limita la generación de mensajes de destino
inalcanzable a 80 en 4 segundos, con 1/4 de segundo de castigo si se
sobrepasa ese limite. Una manera de probar esto es mandar muchos
paquetes a algún puerto UDP alto seleccionado al azar y contar el
numero de inalcanzables recibidos. No he visto que esto se use antes, de
hecho no he agregado esto a Nmap (excepto para usarlo con escaneo de
puertos UDP). Esta prueba haría la detección de sistema operativo un
poco más lenta ya que se necesita mandar un montón de paquetes y
esperar a que regresen. Hay que tomar en cuenta la posibilidad de que
los paquetes sean descartados por la red, lo que alteraría el resultado
de la prueba.
Devolución de mensajes ICMP
-- Los RFCs especifican que los mensajes de error
ICMP devuelven una pequeña cantidad de un mensaje ICMP que
provocó errores variados. Para un mensaje de puerto inalcanzable, casi
todas las implementaciones mandan solo el encabezado IP requerido + 8
bytes de regreso. Sin embargo, Solaris regresa un poco mas y
Linux regresa aun mas que eso. La belleza de esto es que permite a Nmap
identificar a maquinas Linux y Solaris aun cuando no tengan ningún
puerto escuchando.
Eco de Integridad de Mensajes de Error ICMP
-- Obtuve esta idea de algo que Theo de Raadt (desarrollador
principal de OpenBSD) publicó en comp.security.unix. Como se ha
mencionado antes, las maquinas tienen que regresar parte del mensaje
original junto con un error de puerto inalcanzable. Y aun otras maquinas
tienden a usar tus encabezados como "scratch space" durante su
procesamiento inicial, así que están un tanto alterados cuando los
regresan. Por ejemplo, AIX y BSDI nos regresan un datagrama IP con el
campo "longitud total" que es 20 bytes mas grande. Algunos
BSDI, FreeBSD, OpenBSD, ULTRIX, y VAXen alteran el ID del datagrama IP
que les mandaste. Mientras el checksum va a cambiar debido que se
cambia el TTL de todas formas, hay algunas maquinas (AIX, FreeBSD, etc.)
que regresan un checksum inconsistente o de 0.
Lo mismo sucede con el checksum UDP. En resumen,
Nmap hace nueve diferentes pruebas de errores ICMP para detectar
diferencias sutiles como estas.
Tipo de Servicio
-- Para los mensajes ICMP de puerto inalcanzable
se toma el valor del tipo de servicio (TOS) en el paquete que regresan.
Casi todas las implantaciones usan 0 para este error ICMP, aunque Linux
usa 0xC0. Esto no indica uno de los valores TOS estándar, pero en vez
de eso, es parte del campo de precedencia que no es usado (esto es una
suposición de la cual no estoy muy seguro). No se por qué sucede esto,
pero si cambian a 0 podremos seguir identificando las versiones
anteriores y podremos identificar entre anteriores y recientes.
Manejo de fragmentación
-- Esta es una técnica favorita de Thomas H.
Ptacek de Secure Networks, Inc. Esto se aprovecha del hecho de que
diferentes implementaciones manejan los fragmentos IP de manera
diferente. Algunos sobrescribirán las viejas porciones con las nuevas,
y en otros casos las porciones viejas tienen precedencia. Hay muchas
pruebas diferentes que se pueden usar para determinar como el paquete
fue reensamblado. No agregue esta característica ya que no conozco
ninguna manera portable para mandar fragmentos de IP (esto está
particularmente mal implementado en Solaris).
Opciones TCP
-- Estos son una verdadera mina de oro en términos
de fugas de información. La belleza de estas opciones es que:
1) Son generalmente opcionales (uh!) :) así que
no todas las maquinas las implementan.
2) Se puede saber si una maquina las implementa
mandando una solicitud con una opción definida. El objetivo
generalmente muestra que soporta la opción poniéndola también en la
respuesta.
3) Se pueden mandar todas las opciones en un mismo
en un paquete para probar todo al mismo tiempo.
Nmap manda estas opciones en casi todos los
paquetes de prueba:
Window Scale=10; NOP; Max Segment Size = 265;
Timestamp; End of Ops;
Cuando se obtiene una respuesta, se puede mirar
que opciones regresaron y por lo tanto son soportadas. Algunos sistemas
operativos como los FreeBSD recientes soportan todas las anteriores,
mientras otras, como las Linux 2.0.X soportan muy pocas. Los kernels
Linux 2.1.x mas recientes soportan todas la anteriores. Por otro lado,
son mas vulnerables a predicción de secuencia TCP. Imagínense.
Aun si varios sistemas operativos soportan las
mismas opciones, se pueden distinguir algunas veces por los valores de
las opciones. Por ejemplo, mandando un valor MSS pequeño a un Linux,
generalmente te hará un eco con ese MSS de regreso. Otros sistemas
operativos darán un valor diferente.
Y aun obteniendo el mismo conjunto de opciones
soportadas Y los mismos valores, aun se puede diferenciar por el orden
en que las opciones son dadas, y donde se pone relleno en el paquete.
Por ejemplo: Solaris regresa 'NNTNWME' que significa:
Mientras que Linux 2.1.122 regresa MENNTNW. Mismas
opciones, mismos valores, pero diferente orden!
No he visto ninguna otra herramienta para detección
de sistema operativo que utilice opciones TCP, pero es muy útil.
Hay otras cuantas opciones útiles para las que
podría probar en algún momento, como aquellas que soportan T/TCP y
reconocimientos selectivos.
Cronología de Explotación
-- Aun con todas la pruebas anteriores, Nmap es
incapaz de distinguir entre el stack TCP de Win95, WinNT, o Win98. Esto
es algo sorprendente, especialmente ya que Win98 salió casi 4 años
después que Win95. Es de suponer que el stack fue mejorado de alguna
manera (como soportar mas opciones TCP) y de esta manera podríamos
detectar el cambio y distinguir entre los sistemas operativos.
Desafortunadamente este no es el caso. El stack NT es aparentemente el
mismo que pusieron en el '95. Y no se molestaron en actualizarlo para el
'98.
Pero a no desesperar, ya que
hay una solución. Se puede simplemente empezar con antiguos ataques
para Windows DoS (Ping of Death, WinNuke, etc) y después cambiar un
poco mas arriba a ataques como Teardrop y Land. Después de cada ataque,
hacer un ping para ver si cayeron. Cuando finalmente el host caiga, se
puede deducir la versión que están corriendo, e incluso hasta de
paquete o parche.
No he agregado esta función a Nmap, aunque debo
admitir que es muy tentador :).
Resistencia a SYN-flood
-- Algunos sistemas operativos dejan de aceptar
nuevas conexiones cuando reciben demasiados paquetes SYN spoofeados
(spoofear el ip de origen de los paquetes impide que tu kernel corte las
conexiones). Muchos sistemas operativos pueden solo manejar 8 paquetes.
Kernels recientes de Linux (entre otros sistemas operativos) permiten
varios metodos, como cookies SYN para prevenir que esto se convierta en
un problema serio. Asi se puede aprender algo de un sistema operativo
objetivo, al mandarle 8 paquetes de una fuentes falsificadas a un puerto
abierto y después probando si se puede establecer una conexión
verdadera a ese puerto. Esto no fue implantado en Nmap ya que el
SYN-flooding no es algo que muchos admins soporten sin enojarse. Aun
explicando que solo tratabas de determinar que tipo de sistema operativo
están corriendo no ayudara a calmarlos.
IMPLANTACION DE Nmap Y RESULTADOS
He creado una implantación de referencia para las
técnicas de detección de sistema operativo mencionadas arriba (excepto
esas que dije estaban excluidas). He agregado esto a mi escaner Nmap que
tiene la ventaja de que ya sabe que puertos están abiertos y cerrados
para identificación así que no es necesario especificárselo. También
es portable entre Linux, *BSD, y Solaris 2.51 y 2.6, y algunos otros
sistemas operativos.
La nueva versión de Nmap lee un archivo de
fingerprints que siguen una gramática simple. Aquí hay un ejemplo:
FingerPrint IRIX 6.2 - 6.4 # Thanks to Lamont Granquist
TSeq(Class=i800)
T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT)
T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Miremos la primera línea (Estoy agregando
marcadores '>'):
> Fingerprint IRIX 6.2 - 6.3 # Gracias a Lamont Granquist
Esto dice simplemente que la huella cubre las
versiones 6.2 y 6.3 de IRIX y el comentario dice que Lamont Grandquist
amablemente me mando la direccion IP o el fingerprint de las maquinas
IRIX probadas.
> TSeq(Class=i800)
Esto significa que un muestreo ISN lo puso en la
clase "i800". Esto significa que cada nueva secuencia de números
es un múltiplo de 800 mayor que el último.
>
T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
La prueba se llama T1 (por test1 en Ingles, listo
eh?). En esta prueba mandamos un paquete SYN con muchas opciones TCP a
un puerto abierto. DF=N significa que el bit "no fragmentación"
de la respuesta debe estar puesto. W=C000|EF2A quiere decir que el
anuncio de ventana que recibimos deber ser 0xC000 o EF2A. ACK=S++ quiere
decir que el reconocimiento que recibimos debe ser nuestra secuencia
inicial mas 1. Flags = AS quiere decir que los flags ACK y SYN fueron
mandadas en la respuesta. Ops=MNWNNT quiere decir que las opciones en la
respuesta deben ser (en este orden):
> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
La prueba 2 involucra a un NULL con las mismas
opciones a un puerto abierto. Resp=Y significa que debemos obtener una
respuesta. Ops= significa que no debe haber ningunas opciones incluidas
en el paquete respuesta. Si quitáramos '%Ops=' completamente, entonces
cualesquier opciones mandadas
corresponderian.
> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)
La prueba 3 es un SYN|FIN|URG|PSH con opciones a
un puerto abierto.
> T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
Esta es un ACK a un puerto abierto. Notar que no
tenemos un Resp= aquí. Esto significa que la falta de respuesta (como
el paquete que haya sido descartado por la red o por un firewall) no
descalificara correspondencia mientras todas las otras pruebas
correspondan. Hacemos esto porque virtualmente cualquier sistema
operativo mandara una respuesta, así que la falta de esta es
generalmente un atributo de las condiciones de la red y no de el sistema
operativo en si. Ponemos la etiqueta de Resp en las pruebas 2 y 3 porque
algunos sistemas operativos si descartan esos sin responder.
> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
> T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
Estas pruebas son SYN, ACK, y FIN|PSH|URG,
respectivamente, a un puerto cerrado. Las mismas opciones están
puestas, como siempre. Claro que esto es probablemente obvio dado los
nombres descriptivos 'T5', 'T6' y 'T7' :).
>
PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Esta es la prueba de mensaje de 'puerto inalcanzable'. Ya deberías
reconocer el DF=N a estas alturas. TOS=0 significa que el campo de tipo
de servicio IP era 0. Los siguientes dos campos dan los valores
(hex) del campo de longitud total de IP del encabezado IP del mensaje y
la longitud total dada en el encabezado IP que nos regresan por eco a
nosotros. RID=E significa que el valor RID que obtuvimos en la copia de
nuestro paquete UDP original se esperaba (por ejemplo el mismo que
mandamos). RIPCK=F significa que no fregaron la suma de control (si lo
hicieron, diria RIPCK=F). UCK=E significa que la suma de control UDP
también esta correcta. Después viene la longitud UDP que era 0x134 y
DAT=E significa que hicieron un eco de nuestro UDP correctamente.
Ya que la mayoría de las implantaciones
(incluyendo esta) no envían ninguno de nuestros datos UDP de regreso,
obtienen DAT=E por omisión.
La versión de Nmap con esta funcionalidad esta
actualmente en el 6to ciclo beta privado. Puede haber salido cuando lean
esto en Phrack.
Pero a lo mejor, tal vez no. Vean insecure.org/nmap/
para la versión mas reciente.
VISTAS DE SITIOS POPULARES
Aquí están los divertidos resultados de nuestro
esfuerzo. Ahora podemos tomar sitios de internet de manera aleatoria y
determinar que tipo de sistema operativo están usando. Mucha de esta
gente ha eliminado los letreros telnet, etc. para tratar de mantener
esta información privada.
Pero esto no sirve de nada con nuestro nuevo
identificador!
El comando usado en este ejemplo fue: nmap -sS -p
80 -O -v
También noten que muchas de estas exploraciones
fueron hechas el 18/10/98. Algunos de estos hosts pueden haber
actualizado/cambiado sus sistemas operativos desde entonces.
Noten que algunos sitios no me gustan.
# sitios "Hacker" o (en un par de casos)
sitios que piensan que son
www.l0pht.com => OpenBSD
2.2 - 2.4
www.insecure.org => Linux 2.0.31-34
www.rhino9.ml.org => Windows 95/NT
# sin comentario :)
www.technotronic.com => Linux 2.0.31-34
www.nmrc.org =>
FreeBSD 2.2.6 - 3.0
www.cultdeadcow.com => OpenBSD 2.2 - 2.4
www.kevinmitnick.com => Linux 2.0.31-34 # liberen a Kevin!
www.2600.com =>
FreeBSD 2.2.6 - 3.0 Beta
www.antionline.com => FreeBSD 2.2.6 - 3.0 Beta
www.rootshell.com => Linux 2.0.35 #
Cambiaron a OpenBSD después de que fueron hackeados varias veces
# Proveedores, consultores de seguridad, etc.
www.repsec.com => Linux 2.0.35
www.iss.net
=> Linux 2.0.31-34
www.checkpoint.com => Solaris 2.5 - 2.51
www.infowar.com => Win95/NT
# Lealtad de proveedores a su sistema operativo
www.li.org
=> Linux 2.0.35 # Linux International
www.redhat.com => Linux
2.0.31-34 # Me pregunto que distribución:)
www.debian.org => Linux 2.0.35
www.linux.org => Linux
2.1.122 - 2.1.126
www.sgi.com
=> IRIX 6.2 - 6.4
www.netbsd.org => NetBSD 1.3X
www.openbsd.org => Solaris 2.6
# Ajem :)
www.freebsd.org => FreeBSD 2.2.6-3.0
Beta
# Grandes universidades
www.harvard.edu => Solaris 2.6
www.yale.edu =>
Solaris 2.5 - 2.51
www.caltech.edu => SunOS 4.1.2-4.1.4
# Hola!! son los 90's :)
www.stanford.edu => Solaris 2.6
www.mit.edu
=> Solaris 2.5 - 2.51 # Coincidencia que tantas buenas escuelas
parecen gustar de Sun?. Tal vez sea el 40 % de descuento a .edu :)
www.berkeley.edu => UNIX OSF1 V
4.0,4.0B,4.0D
www.oxford.edu => Linux
2.0.33-34 # Rock on!
# Sitios mas graciosos
www.aol.com
=> IRIX 6.2 - 6.4 # Ahora sabemos por que son tan inseguros :)
www.happyhacker.org => OpenBSD 2.2-2.4 # Te cansaste de que
te hackearan Carolyn? hasta el sistema operativo mas seguro es inútil
en las manos de un admin incompetente.
# Sitios varios
www.lwn.net
=> Linux 2.0.31-34 # Este sitio de noticias Linux es impresionante!
www.slashdot.org => Linux 2.1.122
www.whitehouse.gov => IRIX 5.3
sunsite.unc.edu => Solaris 2.6
Notas: En su articulo de seguridad, Microsoft dijo
sobre su seguridad relajada: "esta suposición ha cambiado con el
paso de los años mientras Windows NT gana popularidad vastamente por
sus características de seguridad.". Hmm, desde donde yo estoy no
parece que Windows sea muy popular con la comunidad de seguridad :).
Solo veo dos cajas Windows de todo el grupo, y Windows es fácil para
Nmap de distinguir ya que esta bien quebrado (en lo referente a estándares).
Y desde luego, hay un sitio mas que debemos ver.
Este es el sitio web de la corporación ultra-secreta Transmeta. De
manera interesante la compañía fue fundada en gran parte por Paul
Allen de Microsoft, pero emplea a Linus Trovalds. Así que se quedan con
Paul y corren NT o se unen con los rebeldes y se hacen parte de la
revolución Linux? Veamos:
Usamos el comando:
nmap -sS -F -o transmeta.log -v -O
www.transmeta.com//24
Esto dice se revise con SYN los puertos conocidos
(de /etc/services), se guarden los resultados en 'transmeta.log',
mostrando todo el texto posible al respecto, hacer un chequeo de sistema
operativo, y revisar la subred clase 'C' donde www.transmeta.com reside.
Aquí están los resultados:
neon-best.transmeta.com (206.184.214.10) =>
Linux 2.0.33-34
www.transmeta.com (206.184.214.11) => Linux
2.0.30
neosilicon.transmeta.com (206.184.214.14) =>
Linux 2.0.33-34
ssl.transmeta.com (206.184.214.15) => Linux
unknown version
linux.kernel.org (206.184.214.34) => Linux
2.0.35
www.linuxbase.org (206.184.214.35) => Linux
2.0.35 (posiblemente la misma maquina de arriba)
Bueno, creo que esto contesta a nuestra pregunta
de manera clara :).
AGRADECIMIENTOS
La única razón por la que Nmap puede detectar tantos sistemas
operativos actualmente es que mucha gente del equipo beta privado puso
mucho esfuerzo para buscar nuevas y excitantes implementaciones
para identificar! En particular, Jan Koum, van Hauser, Dmess0r, David
O'Brien, James W. Abendschan, Solar Designer, Chris Wilson, Stuart
Stock, Mea Culpa, Lamont Granquist, Dr. Who, Jordan Ritter, Brett
Eldridge, y Pluvius mandaron toneladas de direcciones IP de maquinas
raras y/o fingerprints de maquinas no alcanzables desde Internet.
Gracias a Richard Stallman por escribir GNU Emacs.
Este articulo no estaría tan bien acomodado si estuviera usando vi o
cat y ^D.
Preguntas o comentarios pueden ser mandados a
fyodor@insecure.org (en ingles!)
Nmap puede ser obtenido de www.insecure.org/nmap/nmap_download.html
GLOSARIO
fingerprint: la "huella" del sistema
operativo en si. Se obtiene con el conocimiento previo que se tiene de
un sistema operativo en sí, y se lo contrasta con las pruebas
realizadas.
fingerprinting: Se traduce como identificación por medio de las
huellas digitales de los dedos. Se utiliza análogamente al caso de la
identificación de un host, utilizando el fingerprint.
host: maquina, anfitrion, computadora que a la
que se puede hacer una conexión. Toda maquina conectada a la red es
llamada host en el significado mas amplio del término.
scratch space: generalmente un espacio temporal
para escribir y borrar cosas que no tienen importancia o mientras se
genera una idea.
script kiddie: persona que se dedica a explotar
fallas de seguridad en gran escala con herramientas y conocimientos de
otros.
checksum: suma de control, para verificar la
integridad del paquete. No se si alguien lo maneje así o si la mayoría
de la gente en computación lo use como checksum.
grep: comando unix que busca una cadena de
caracteres especificada en un archivo de texto.
flags: opciones del segmento tcp.
RFC: Request For Comments. Documentos
de en los cuales se especifican y se proponen los protocolos y estándares
en Internet.
SYN-flood: se traduce como inundación de SYN,
consiste en enviar a un host gran cantidad de paquetes TCP con el flag
SYN puesto, "inundándolo".
Stack: pila (TCP/IP).
|