Reconocimiento de activos mediante herramientas pasivas (I)

Uno de los principales problemas que nos encontramos a la hora de implantar sondas de detección de intrusos a nivel de red, es la configuración correcta del entorno para evitar inclusiones o evasiones en nuestras sondas. Por ello nos interesa conocer que tipo de sistema operativo está corriendo en un cierto host así como que servicio está ofreciendo.

El objetivo de conocer que sistema operativo se encuentra en cierta IP, es para saber como el IDS debe tratar los paquetes a nivel de cabeceras del protocolo, y por tanto, de la pila. Ésto es debido a los huecos o distintas interpretaciones del estándar establecido en los RFC por los desarrolladores de los SSOO. Por ello no es lo mismo la implementación de la pila IP en un Windows, que en una Solaris, BSD o en un Linux.

Ésto hecho se aprecia cuando recibimos paquetes fragmentados donde en una misma posición puede existir más de un dato, lo que se conoce como overlapping, un entorno Windows siempre se quedará con el fragmento que ha llegado primero, un BSD con el que tenga un offset menor y a igual ofsset se quedará con el primero, por otro lado Linux funciona igual que BSD pero a igual ofsset se quedará con el que ha llegado el último. El IDS debe conocer como ensamblará los paquetes fragmentados el host para poder detectar posibles ataques.

Este hecho se puede aplicar también en paquetes fragmentados donde antes de tener el paquete completo, y por tanto todos los fragmentos, nos llega al menos dos paquetes con un “Not More Fragments” con distinto ofsset o tamaño. Solaris aceptará el último paquete que nos llegue con ese valor, en cambio otros sistemas operativos solo aceptarán el primero que llego. A este fenómeno se conoce como inclusión y evasión en los IDS. Tenéis una explicación más extensa en ésta entrada.

Así mismo, es importante conocer que servicios están corriendo en el servidor para indicar al IDS la existencia de dichos servicios y como debe procesar los paquetes relacionados con dicho servicio.

Por ejemplo, si nos encontramos con un FTP sabemos que por cada carácter introducido por el cliente, éste es enviado al servidor, por ello si se quiere detectar la autenticación del usuario “anonymous” hay que indicar al preprocesador que en cierto puerto hay un servicio tipo FTP o Telnet y que debe juntar el payload del TCP hasta que llegue el “salto de línea”, y ésa suma de caracteres corresponde a un comando, y en este caso, corresponderá al usuario introducido.

Otro ejemplo serían los punteros de los DNS, si nosotros tenemos un puntero de DNS y por tanto si en la zona de petición o respuesta de una consulta DNS detectamos que empieza por el valor hexadecimal “C” (los dos bits del nibble alto a 1), en vez de identificar con un valor de 63 o inferior los caracteres que vamos a leer a continuación, sabemos que se trata de un puntero. Si éste apunta a otro puntero el cual apunta al puntero anterior, estamos ante un bucle recursivo que podría generar una denegación de servicio del servidor DNS. Por ello el IDS debe  ser consciente de como tratar los datos el servicio para detectar un ataque de este tipo.

También es importante conocer exactamente que aplicación está corriendo en ese puerto, y no únicamente saber que en el puerto 80 corre un servidor Web, puesto que dependiendo del servidor Web este acepta una serie de codificaciones y las interpreta de forma distinta.

Para que se entienda el problema veremos un ejemplo que leí hace poco en Twitter donde se indicaba que “Nintendo.com” fue atacada por un path transversal. Los atacantes codificaron el “..” como “%252e%252e”, es decir que el “.” fue codificado como “%252e”, ¿y que es esto? Pues fue un double decoding de ASCII a hexadecimal, es decir, cuando pasamos un valor ASCII a hexadecimal se traduce con %XX donde X corresponde al valor hexadecimal del carácter. En este caso “.” es “%2e”. A continuación se vuelve a realizar esa conversión (por eso el double) del valor hexadecimal “%2e” de forma parcial (como fue el caso de Nintendo) o total. En el ejemplo que estamos viendo se paso de ASCII a Hexadecimal el carácter “%” cuyo valor era “%25” dando lugar al “%252e”. Un entrada más detallada sobre lo expuesto en este párrafo lo podéis leer aquí.

Por tanto es necesario configurar el IDS indicándole el sistema operativo y los servicios de los paquetes que leen las sondas. Para ello se debe disponer de una CMDB actualizada donde se aporte toda esta información, algo prácticamente imposible en entornos grandes. La otra posibilidad sería mediante reconocimiento activo de la red, lo que implicaría tener que abrir todos los puertos a cierto host o una serie de hosts, algo que va en contra de cualquier política de seguridad. Por ello la única solución viable es el reconocimiento mediante herramientas pasivas, que leyendo el trafico de red sean capaces de obtener dicha información.

Pero esto en la próxima entrada.