WebBrowsing Fingerprinting con códigos de estado HTTP

De la reciente DEFCON 21, una de las charlas que más me ha gustado  - y que, además, tiene relación con lo publicado en este blog recientemente sobre el Web Browser Fingerprinting y con algo que me ha interesado a mí personalmente desde hace tiempo - ha sido la que ha dado Chris John Riley con el título “Defense by numbers: Making Problems for Script Kiddies and Scanner Monkeys”.

Figura 1: Defense by numbers: Making Problems for Script Kiddies and Scanner Monkeys

Su estudio, realizado sobre los tres navegadores más utilizados - Microsoft Internet Explorer, Mozilla Firefox y Google Chrome -  analiza que tipo de comportamiento tienen estos ante diferentes códigos de respuesta HTTP, esto es, qué hace un navegador cuando recibe una respuesta que no es 200 OK. Los servidores web pueden responder con distintos códigos a los clientes para informarles de las consecuencias que han tenido sus peticiones, siendo los más frecuentes:

• 200 OK
• 304 Not Modified (cuando solicitamos un fichero que ya tenemos en la cache de nuestro navegador)
• 404 Not Found
• 500 Internal Server Error

Pero hay muchos más, ¡muchísimos! Podéis ver una lista bastante completa en la página de la Wikipedia sobre códigos de respuesta HTTP.

Lo que este hombre ha probado y testeado es la forma de actuar de estos navegadores ante páginas que devuelven códigos HTTP distintos de los esperados. Además ha probado esto con distintos elementos HTML como iframes, imágenes o ficheros JavaScript remotos, y a la conclusión a la que ha llegado es que, ante la mayoría de los códigos de respuesta, los navegadores actúan como si el código fuera 200 OK (es decir, muestran la página sin mostrar ningún tipo de mensaje de error)

Figura 2: Respuesta en base a los códigos HTTP enviados por el servidor

Como se puede ver en la tabla anterior, distintos navegadores para distintos códigos producen distintos resultados. Una de las aplicaciones en las que se puede usar esta diferencia de respuestas es en el fingerprinting de navegadores web, algo muy útil para la industria de la seguridad. De su análisis concluye, entre otras cosas, que:

• Mozilla Firefox: No carga ficheros JavaScript si el código es 300 Multiple Choices, IE y Chrome si lo hacen
• Google Chrome: Carga ficheros JavaScript si el código es 307 Temporary Redirect, Firefox e IE no lo hacen
• Microsoft Internet Explorer: Carga ficheros JavaScript si el código es 205 Reset Content, Chrome y Firefox no lo hacen

Con estas pequeñas diferencias ha puesto a disposición de todos un pequeño POC en Internet e incluso el código fuente disponible en su repositorio de github.

Figura 3: Detección de Mozilla Firefox con WB Fingerprinting usando códigos HTTP

Esta técnica y este estudio son una gran base de información para entender mejor cómo funcionan los navegadores, además de, como en su objetivo original, penalizar a las herramientas automáticas que confían en el código de respuesta del servidor para reconocer el éxito o fracaso de un intentando de ataque.

Por supuesto, uno de los objetivos principales de las técnicas de WebBrowsing fingerprinting es la de poder luchar contra el Fraude Online en Internet. Supongamos que un usuario se conecta a su cuenta bancaria habitualmente desde el equipo de su casa, donde utiliza para entrar en la web de su banco MS Internet Explorer 9 y un día sus credenciales bancarias son robadas por un malware. Si el banco ha generado una huella digital de la conexión a sus servicios online y un tiempo después se intenta hacer una transferencia desde un equipo en el que se está usando otro navegador o en el que se detecta que se está haciendo un spoofing del USER-AGENT, entonces probablemente sea una transferencia fraudulenta.

Saludos!

Autor: Pedro Laguna (@p_laguna)