Http Fingerprinting

/.0x08 Http Fingerprinting

Debido a que los banners pueden ser spoofeables para ofuscar a los posibles atacantes,

es necesario recurrir a otro tipo de enumeración “más fiable” para poder saber con un 95% de

posibilidades ante qué tipo de servidor nos encontramos. Esta técnica es conocida como

fingerprinting (huella dactilar) y consiste en la ejecución de 4 tests (orden de campos al hacer un

HEAD, respuesta ante un DELETE, respuesta ante una versión del protocolo HTTP incorrecta, y

por último, la respuesta que da el servidor ante un protocolo erroneo).

Con los resultados de los mencionados cuatro tests, podremos diferenciar perfectamente

entre servidores Apache y los IIS, ya que de cada uno se extrae un resultado diferente ante cada

uno de los tests.

El primer test consiste en analizar una cabecera respuesta ante una petición de tipo HEAD

al servidor. Entre la respuesta que da un Apache y un ISS existen ciertas diferencias que se

observan de forma muy directa al comparar dos cabeceras:

Apache:

HTTP/1.1 200 OK

Date: Wed, 10 Sep 2008 14:41:01 GMT

Server: Apache

Last-Modified: Wed, 30 Jul 2008 19:10:35 GMT

ETag: "abe0d-13a-4534282d840c0"

Accept-Ranges: bytes

Content-Length: 314

Connection: close

Content-Type: text/html

IIS:

Podemos ver como en las cabeceras de respuesta de los servidores Apache, la

información primera que aparece es DATE, es decir la fecha, y debajo de ésta el banner.

Omitimos el banner dentro de las pruebas de fingerprinting porque como ya hemos dicho con

anterioridad, pueden estar spoofeados.

A diferencia de Apache, los servidores que corren con IIS, muestran como primera

información el banner, mientras que el campo Date queda en posiciones inferiores. Con esta

primera prueba ya podríamos vislumbrar ante qué servidor nos encontramos… pero ante la duda

es siempre preferible aplicar los otros tres tests.

El segundo tests se aprovecha de la respuesta de los servidores ante un método prohibido

(en la mayoría de los casos) como puede ser DELETE. Apache y IIS reaccionan ante una petición

DELETE de formas distintas, ya que mientras que Apache responde con un error 405 (Method not

Allowed), IIS lo hace con un 403 (Forbidden).

El siguiente consisten en mandar una petición (un GET por ejemplo) colocando una versión

inexistente de HTTP (3.0, 5.2, etc) para ver qué reacción toma el servidor:

Apache:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

MicrosoftOfficeWebServer: 5.0_Pub

X-Powered-By: ASP.NET

Content-Location: http://200.49.155.214/index.html

Date: Wed, 10 Sep 2008 14:39:53 GMT

Content-Type: text/html

Accept-Ranges: bytes

Last-Modified: Thu, 06 Dec 2007 03:28:15 GMT

ETag: "eab1b49b837c81:1669"

Content-Length: 66

HTTP/1.1 400 Bad Request

Date: Thu, 11 Sep 2008 09:30:17 GMT

Server: Apache/1.3.41 (Unix) PHP/5.2.6 mod_log_bytes/1.2

mod_bwlimited/1.4 mod_a

uth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31

OpenSSL/0.9.8b

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=iso-8859-1

IIS:

Podemos ver como la respuesta de un servidor Apache es un error 400 por mala petición

(Bad Request). Por el contrario, los servidores IIS responden con un código de OK (200)

admitiendo este error de versión de protocolo.

La reacción se invierte cuando la petición en vez de contener un error en la versión lo

contiene en el protocolo en sí, es decir, en vez de poner HTTP/1.X ponemos otras cosas como

FOS/1.X:

Apache:

IIS:

Como vemos, Apache responde un 200 mientras que IIS un error 400.

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

MicrosoftOfficeWebServer: 5.0_Pub

X-Powered-By: ASP.NET

Content-Location: http://200.49.155.214/index.html

Date: Thu, 11 Sep 2008 09:32:13 GMT

Content-Type: text/html

Accept-Ranges: bytes

Last-Modified: Thu, 06 Dec 2007 03:28:15 GMT

ETag: "eab1b49b837c81:1669"

Content-Length: 66

HTTP/1.1 400 Bad Request

Server: Microsoft-IIS/5.0

Date: Thu, 11 Sep 2008 09:38:07 GMT

Content-Type: text/html

Content-Length: 87

HTTP/1.1 200 OK

Date: Sun, 15 Jun 2003 17:17:47 GMT

Server: Apache/1.3.23

Last-Modified: Thu, 27 Feb 2003 03:48:19 GMT

ETag: "32417-c4-3e5d8a83"

Accept-Ranges: bytes

Content-Length: 196

Connection: close

Content-Type: text/html

A la luz de los resultados obtenidos tras realizar esta serie de tests, podemos diferenciar

con alto porcentaje de acierto ante qué tipo de servidor nos enfrentamos. Esta técnica debemos

de emplearla en la etapa de la enumeración, ya que si durante una auditoría de seguridad o

cuando vamos a “asaltar” un servidor, es necesario poder focalizar lo máximo posible nuestra

acción, es decir, podremos probar a explotar vulnerabilidades exclusivas de ese tipo de servidor y

descartar otras técnicas de ataque.