Español | English
rss facebook linkedin Twitter

WYSIWYG (What you sniff is what you get)

Cuando se quiere comprobar la seguridad de un sistema, el primer paso es recopilar la mayor cantidad de información posible hasta llegar a conocer que vulnerabilidades podrían afectarle. Hay varias técnicas y herramientas que facilitan o directamente automatizan esto. El problema viene cuando en el proceso se interactúa con el sistema de manera que efectivamente se explota una vulnerabilidad o por cualquier otro motivo el funcionamiento normal se ve afectado. Si se realiza de una manera controlada, las consecuencias pueden ser mínimas, imperceptibles para los usuarios, pero en caso de ser un sistema crítico, es inaceptable que se pueda poner en riesgo su correcto funcionamiento, aunque se haga bajo control. Cuando no se nos permite interactuar con el sistema, tan solo nos queda la técnica WYSIWYG (What you sniff is what you get) es decir, observar el tráfico de red y sacar toda la información posible de ahí. Vamos a suponer que se utiliza el tráfico es IP sobre las tecnologías conocidas como Ethernet, wifi o zigbee por ejemplo.

En primer lugar, las malas noticias. La información que se obtiene de observar el tráfico no solo es incompleta, sino que no es fiable al 100%. Al fin y al cabo hay que capturar tráfico en el momento adecuado y confiar en que el sistema no se ha modificado de manera que genera tráfico que se sale de lo que sería habitual. En este post vamos a suponer que no se ha modificado nada con la única intención de confundir o engañar.

En segundo lugar las buenas noticias. Se pueden extraer más datos de los que parece. Empecemos por lo más fácil/obvio:
  • Dirección IP y de enlace (MAC) (agradecimientos al capitán obvio). En la mayoría de las tecnologías, la dirección MAC indica quien es el fabricante. Los drivers especialmente de wifi y tecnologías menos maduras que la clásica Ethernet tienen vulnerabilidades, algunas de ellas muy graves.
  • Puertos abiertos y cerrados. Simplemente observamos los intentos de establecer una conexión (SYN) y las respuestas (SYN-ACK/RST). Aunque podemos suponer que cada puerto se utiliza para lo que está reservado, mirando el tráfico se puede comprobar que el protocolo es el esperado.
  • Mensajes de broadcast. Otras aplicaciones o dispositivos que hacen anuncios a toda la red usando la dirección de broadcast y que pueden tener vulnerabilidades conocidas.
  • Mensajes a nivel de aplicación. Algunas aplicaciones dan información clara del sistema operativo, el software, la versión e incluso el tipo de procesador que utiliza una máquina en concreto. Ejemplo, banners de servidores ftp y ssh o el campo user-agent de los navegadores web entre otros
  • Si se establecen conexiones a servidores de actualizaciones puede obtenerse información de qué software y posiblemente qué versión se utiliza.

Lógicamente hay técnicas más complicadas. Las más conocidas se basan en estudiar las peculiaridades de los protocolos TCP (1, 2, 3 y otros) e IP (1) para intentar diferenciar entre sistemas operativos. En el estándar hay ciertos campos cuyos valores no están definidos en todas las situaciones o pueden tomar un valor dentro de un rango. Esto hace que cada implementación tenga pequeñas diferencias que son especialmente notables en las fases de establecimiento y finalización de la conexión. Hay varias herramientas que implementan esta idea. La más conocida seguramente sea p0f. Estos son los campos que resultan más útiles a la hora de identificar el sistema operativo cuando se está estableciendo una conexión:
  • Tamaño de la ventana. Suelen tomar un valor característico para cada sistema operativo que puede ser fijo, o un múltiplo entero del MTU (Maximum Transmission Unit) o del MSS (Maximum Segment Size).
  • TTL (Time To Live). Habitualmente cambia entre diferentes familias de sistemas operativos.
  • flag "do not fragment". Algunos sistemas operativos lo activan mientras que otros no. Su valor es indiferente al establecer una conexión.
  • Opciones TCP. Un segmento TCP puede incluir una gran variedad de opciones. Es aquí donde realmente se pueden apreciar grandes diferencias, tanto en qué opciones están presente como en qué orden y qué valores tienen. Algunas de las más importantes son, el tamaño máximo de segmento, el escalado de ventana, el timestamp y la opción que indica el soporte de ACKs selectivos.
  • Errores y comportamientos extraños. Si señores, desafiando toda lógica, hay errores en las implementaciones de los estándares. No significa que haya alguna vulnerabilidad sino que en algún momento es posible que no cumpla el estándar o que aún cumpliendo el estándar su comportamiento no es lógico. Uno de mis favoritos es una versión antigua del kernel de Linux, que en procesadores little-endian anunciaban un tamaño de ventana de 512 o 16384, mientras que en procesadores big-endian se convertía en 2 y 64 respectivamente (parece que alguien ha metido la pata, ejem, ejem...)

Aún hay más técnicas, algunas de ellas bastante complejas que nos dan información acerca del sistema a investigar.
  • Peculiaridades en protocolos comunes, como ICMP, NETBIOS, DNS. Por ejemplo, la respuesta a un ICMP de tipo timestamp de algunos sistemas operativos es little-endian cuando debería ser big-endian.
  • Particularidades en las cabeceras IP, como el uso de opciones o patrones detectables en el campo "identification".
  • Análisis del comportamiento de TCP. En los algoritmos que definen TCP hay ciertas decisiones que puede tomar el implementador y que varían de una pila a otra. Por ejemplo el tamaño inicial de la ventana de congestión puede ser de 1 o 2 segmentos, o distintos sistemas operativos pueden implementar diferentes versiones de fast-recovery u otros.
  • El campo timestamp en las opciones de TCP crece linealmente con el tiempo. Haciendo la regresión lineal con el tiempo de varios timestamp, se puede calcular cuantas veces se actualiza este valor por segundo, valor que varía de un sistema operativo a otro.

Como podéis ver, capturar y analizar el tráfico de red nos puede dar bastantes más pistas de a que nos enfrentamos de lo que parece. Además siempre es más divertido que pedir al administrador que nos diga que hay instalado.

Patxi Astiz
S21sec labs

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login