Introducción
La traducción al español de la palabra “Fingerprinting” no es ni más ni menos que “Huella Dactilar”. La verdad, es que el espíritu de esta palabra es bastante más amplio y generalmente se encuentra relacionado sobre todo con “algo que identifica”.
En el contexto de la seguridad informática en general y la evaluación de seguridad en particular, hablar de “Fingerprinting”, es hablar de diferentes técnicas mediante las cuales es posible identificar con mayor o menor grado de certeza, un dispositivo, host, sistema operativo, etc.
Como seguramente sabrás, la correcta identificación de sistemas operativos y servicios es un punto fundamental en todo proceso de auditoria o evaluación de seguridad. Una identificación incorrecta, podría eventualmente causar un retraso importante en los tiempos pactados para la tarea al estar intentando explotar vulnerabilidades no existentes en un sistema mal identificado, al margen de los inconvenientes que dichos intentos errores de explotación pueden llegar a generar.
De un modo u otro, y tal como mencionáramos en párrafos anteriores, las técnicas de fingerprinting han sido bastante discutidas en el pasado. Trabajos tales como el realizado por Fyodor (insecure.org), de nombre “Remote OS detection via TCP/IP Stack Fingerprinting”, han representado un gran avance en tal sentido, mientras que las técnicas en el mencionadas han sido implementadas con éxito en herramientas esenciales tales como nmap, por citar tan solo un ejemplo.
Pero este artículo, no tiene como propósito describir el trabajo realizado en torno a las técnicas de fingerprinting en base a la pila TCP/IP las cuales solemos utilizar con frecuencia como parte de nuestro explorador de puertos favorito, sino que por el contrario tiene por objeto presentar parte del magnifico trabajo realizado por Saumil Shah de “Net Square”, respecto de lo que se ha dado en llamar “HTTP Fingerprinting”.
HTTP Fingerprinting
Con algunas diferencias, el concepto detrás HTTP Fingerprinting es similar al utilizado al momento de realizar la detección de sistemas operativos por medio de la pila TCP/IP. El objetivo final en este caso es el de identificar servidores HTTP evaluando las diferencias en la implementación del propio protocolo HTTP en cada uno de ellos.
Un aspecto importante respecto de HTTP Fingerptinting, es que contrariamente a lo que ocurre con la pila TCP/IP en donde cambiar la forma en la que esta se comporta ante un requerimiento, requiere acceso al código de los servicios de networking a nivel de kernel, haciendo de esta posibilidad algo realmente difícil de implementar en la práctica; las respuestas brindadas por un servidor HTTP son relativamente sencillas de cambiar, haciendo que su detección sea mas complicada.
No obstante, el trabajo de investigación de Shah, nos brinda la oportunidad de conocer algunas de las técnicas y herramientas que se encuentran a nuestra disposición, al momento de llevar a cabo la identificación de servidores HTTP, con un porcentaje de éxito interesante.
Respuestas HTTP: Estudiando el Comportamiento
Si nos tomamos el trabajo de examinar la respuesta brindada por los servidores HTTP más importantes, frente al envío de requerimientos correctamente conformados, descubriremos que, en su gran mayoría, estos responderán acorde a lo especificado en los RFCs que los gobiernan. ¿Pero… que sucede cuando los requerimientos son malformados en forma premeditada? cual es la respuesta? es uniforme? acertaste… es allí donde comienzan las diferencias… y con ellas, la posibilidad de obtener huellas únicas mediante las cuales seamos capaces de distinguir un servidor de otro.
Pero vamos a llevar este concepto a la práctica haciendo nuestras propias pruebas, para ello nos valdremos únicamente de Netcat. Como hemos explicado en nuestro artículo “Seguridad en Aplicaciones Web”, el cual puedes encontrar en este mismo número, netcat nos permite entre otras tantas cosas, establecer un dialogo a nivel HTTP con el servidor objetivo. De este modo, intentaremos decir mediante netcat, decir las palabras correctas, a fin lograr obtener respuestas que puedan colaborar con nuestro objetivo final.
Una vez mas, siguiendo los pasos descriptos en el paper “An Introduction to HTTP fingerprinting” de Saumil Shah, intentaremos analizar las respuestas de los cuatro requerimientos mencionados en la “Tabla A”, limitando el alcance de nuestras pruebas a dos de los servidores web mas populares Apache e IIS (Internet Information Server).
Nota: Los ejemplos mostrados a continuación han sido recortados a efectos de optimizar el espacio y clarificar los aspectos que se intentan destacar en cada caso, dejando tan solo las primeras cuatro líneas involucradas en las respuestas.
Un resumen de lo mencionado podría ser que la seguridad perimetral habitualmente implementada, suele no ser una medida efectiva cuando nuestro objetivo es el de proteger nuestras aplicaciones web de su explotación.
Test Nro 1 – Encabezados
Test Nro 2: Delete
Test Nro 3: Versión de protocolo inválido
Test Nro 4: Especificación de protocolo inválido
Bien, lo que haremos ahora, será escribir los resultados en un cuadro y comparar las respuestas recibidas de cada servidor, para cada uno de los requerimientos y así poder encontrar diferencias:
Como verás, las respuestas recibidas por uno y otro server, difieren levemente. Cuando realizamos el requerimiento de HEAD, Apache respondió mostrando primero información de la fecha y luego el número de su versión mientras que IIS, hizo exactamente lo contrario. Por otra parte, cada uno de los requerimientos posteriores, ha arrojado distintas respuestas para cada uno de los servidores testeados.
Descarga el artículo completo para continuar leyendo:
Comentarios recientes