Fingerprinting

OS Fingerprinting

Jaime P´erez Crespo <jperez@blackspiral.org>

10 de Junio del 2006

Resumen

Uno  de  los  factores  m´as  importantes  a  la  hora  de realizar un ataque inform´atico consiste en conocer la mayor cantidad de detalles posible sobre el sistema objetivo. Para el administrador de sistemas, evitar dar a conocer detalles sobre el servicio puede servir de ayuda para mantenerlo seguro. En el presente art´ıculo veremos las t´ecnicas desarrolladas hasta el d´ıa de hoy para averiguar el sistema operativo que se ejecuta en una  m´aquina  remota  sin  necesidad  de  tener  acceso a la misma. Se tratar´an adema´s diversos m´etodos de los que dispone el adminsitrador para evitar este tipo de problemas y modificar la apariencia de su sistema hacia el exterior.

1. Introduccio´n

La t´ecnica del fingerprinting  de sistema operativo consiste  en  la  suposicio´n  del  sistema  operativo  y  su versi´on en base al ana´lisis de la pila de comunicacio- nes de una m´aquina. Se basa, como su nombre indica, en la obtencio´n de una serie de patrones de compor- tamiento observados en los paquetes que genera para formar una “huella dactilar” que lo identifique un´ıvo- camente.  Como  es  l´ogico,  este  tipo  de  informaci´on facilita sobremanera cualquier tipo de ataque sobre una  m´aquina remota, e incluso  en  ocasiones se  hace imprescindible.

Antiguamente la informaci´on relativa al sistema se obten´ıa de forma muy ingenua consultando los ban- ners  o anuncios de los servicios ejecuta´ndose en una m´aquina. Un  banner  es  una  cadena  informativa  que se muestra al conectarse a un servicio remoto, que puede llegar a dar todo tipo de detalles. Incluso algu-

nos servicios como FTP proporcionan comandos co- mo  “SYST ”  para  obtener  este  tipo  de  informaci´on. A modo de ejemplo, comprobemos qu´e tipo de infor- maci´on podemos obtener de un servidor simplemente conectando a su servicio de correo y su servicio web:

[pic 1]  telnet dac.escet.urjc.es 25

Trying 212.128.1.79...

Connected to dac.escet.urjc.es. Escape character is ’^]’.

220 dac.escet.urjc.es ESMTP Sendmail 8.13.4/8.13.4/Debian-3 ; Sat, 10 Jun 2006 17:35:52 +0200; (No UCE/UBE)

[pic 2]  echo ’GET / HTTP/1.0\n’ | nc dac.escet.urjc.es 80 | egrep ’^Server:’

Server: Apache/2.0.54 (Ubuntu) PHP/5.0.5-2 ubuntu1.2 mod ssl/2.0.54 OpenSSL/0.9.7g[pic 3]

[pic 4]  echo ’GET / HTTP/1.0\n’ | nc kybele.escet.urjc.es 80 | egrep ’^Server:’

Server: Microsoft-IIS/5.0

No   hace   falta   demasiada   imaginaci´on  para   saber qu´e  sistema  operativo  ejecutan  los  dos  servidores mostrados en el ejemplo, incluso precisando la ver- sio´n del mismo y de sus servicios. Este tipo de datos son vitales a la hora de buscar vulnerabilidades que aprovechar para atacar una maquina, por lo que si bien, la seguridad por obscuridad no es una buena pol´ıtica, el hecho de que sea posible averiguar esta informaci´on  por  otras  v´ıas  no  significa  que  el  admi- nistrador facilite  de ningu´n modo su obtencio´n.

A d´ıa de hoy esto deja de ser la t´onica general. La mayor´ıa de administradores de sistemas configuran

sus servicios para que no notifiquen este tipo de in- formaci´on en los anuncios, o bien muestren una falsa. Es  por  ello  que  se  deben  utilizar  t´ecnicas  mas  sofis- ticadas como las descritas en este art´ıculo y que se engloban bajo el nombre de “fingerprinting”. Dicha t´ecnica consiste, a grandes rasgos, en obtener paque- tes provenientes de la m´aquina objetivo, analizar sus caracter´ısticas y compararlos con una base de datos de “peculiaridades” para poder identificar el sistema operativo que los genero´. Dado que los esta´ndares de- finidos en las RFC’s de TCP y otros protocolos dejan partes concretas abiertas a la implementaci´on, es po- sible distinguir distintos sistemas operativos en base a la interpretaci´on que hacen de la norma. De hecho, algunos tales como Microsoft Windows, las contradi- cen de forma expl´ıcita.

Atendiendo a la forma en la que se obtienen paque- tes que analizar se puede distinguir entre dos m´etodos de fingerprinting, activo y pasivo.

1. Fingerprinting pasivo

Cuando  se  utiliza  la  variante  pasiva  de  la  t´ecnica del fingerprinting los paquetes a analizar se obtienen directamente de la red local, lo cual quiere decir que el  sistema atacante no  genera ningu´n  tipo  de  comu- nicaci´on  hacia  el  destino  con  el  fin  de  provocar  una respuesta. La  implicaci´on  inmediata  de  esta  t´ecnica es que no permite analizar sistemas fuera de la red local, y que obliga al atacante a configurar su dispo- sitivo de red en modo prom´ıscuo  [1]. Adicionalmente significa que el atacante esta´ a merced del tr´afico que circule  por  la  red.  Si  desea  obtener  informaci´on  de una m´aquina concreta es posible que tenga que espe- rar bastante tiempo o que incluso nunca llegue a ver un paquete proveniente de dicha m´aquina.

Por lo general se analizan dos cabeceras distintas en busca de signos diferenciadores [2]: la cabecera IP de nivel de red y la cabecera TCP de nivel de trans- porte [8]. La siguiente figura muestra un ejemplo de cabecera IP:

[pic 5]

Uno de los campos mas interesantes de la cabecera IP es el del “Tipo de Servicio” o TOS. Indica si los datos transmitidos tienen algu´n tipo de requisito. La mayor´ıa de sistemas operativos lo mantienen al valor 0x00 por defecto, mientras que otros como OpenBSD lo inicializan a 0x08 (minimizar el retardo) cuando se abren conexiones con protocolos como telnet. Las posibles opciones del campo TOS son las siguientes:

1000: minimizar el retardo.[pic 6]

0100: maximizar rendimiento.[pic 7]

0010: maximizar fiabilidad.[pic 8]

0001: minimizar el coste monetario.[pic 9]

0000: servicio convencional.[pic 10]

Por tanto, atendiendo a las opciones encontradas en dicho campo podemos identificar o descartar de for- ma  sencilla qu´e  sistema operativo  las  ha  producido. Por otra parte, la longitud total del paquete es quiza´s el campo mas importante. Referencia la longitud de la cabecera embebida, de la cabecera IP y del re- lleno.  La  variacio´n  de  este  campo  es  muy  alta  entre distintos sistemas operativos, sobretodo en paquetes SYN  de  apertura  de  conexio´n. Cada  sistema utiliza sus propias opciones de TCP, incluyendo NOP’s, lo que hace que cada uno tenga una longitud distinta de datagrama. En general, podemos estar seguros de que cualquier paquete con menos de 44 bytes ha si- do manipulado, ya que todos los sistemas operativos utilizan  al  menos  una  opcio´n  MSS  de  4  bytes  en  el paquete SYN. Linux tiene una longitud de paquete de 60 bytes. OpenBSD de 64 bytes. Solaris 7 se queda en el m´ınimo de 44 bytes, al igual que AIX 4.3, mientras que Microsoft Windows 2000 asciende el taman˜o a 48 bytes.

Podemos observar adicionalmente el campo de identificaci´on  de  IP  o  IP  ID.  Se  utiliza  fundamen- talmente en fragmentaci´on, y puede ser un gran indi- cativo a la hora de identificar el sistema subyacente. Por ejemplo, en Linux 2.4 el IP ID es totalmente alea- torio, excepto dentro de una misma sesio´n, durante la cual se incrementa en uno el valor inicial. OpenBSD lo  rellena  con  un  nu´mero  completamente  aleatorio. Solaris  utiliza  una  implementaci´on  realmente pobre, e incrementa en uno el valor de IP ID permanen- temente, al igual que AIX 4.3 y Windows 2000.

Por  u´ltimo,  el  TTL  o  “tiempo  de  vida”  juega  un papel interesante. El TTL indica el nu´mero  maximo de saltos (nodos de la red) por los que puede pasar un paquete antes de llegar a su destino. En cada salto se decrementa en uno, y cuando llega a cero el paque- te se desecha. El valor inicial de este campo puede ser muy significativo. Mientras que Linux, AIX 4.3 y OpenBSD utilizan un valor inicial de 64, Solaris 7 se desmarca con un valor incre´ıblemente alto de 255 y toda la familia de Windows se queda a medio camino con un TTL de 128.

...