10 cosas que puedes revisar en tu Apache (1 de 2)

Hace ya mucho tiempo escribí un artículo sobre cómo Fortificar Apache y desde ese tiempo he ido dedicando posts a detalles de seguridad, fallos de configuración o bugs descubiertos de este servidor web, que sigue siendo el más extendido en Internet.  En este artículo he querido recopilar en 10 puntos las cosas que puedes probar fácilmente en un servidor web de Apache para mejorar su seguridad que - junto con los 6 easy tests para revisar la seguridad de tu web - te permitan fácilmente saber si tu aplicación web es más o menos segura o necesita ir a una "revisión médica". Aquí van, pero si realmente tienes un Apache del que cuidar, acuérdate de fortificar el servidor Linux sobre el que corre también.

1) La versión del servidor web y actualización total

Conocer la versión exacta de un servidor web Apache no es tan trivial como puede parecer al inicio. Si se ha configurado el parámetro ServerSignature Off o el parámetro ServerTokens Prod en los ficheros de configuración httpd.conf o apache.conf el servidor web solo devolverá como versión del servidor un escueto valor "Apache". Si no se ha hecho esto, se podrá recoger la versión exacta del servidor web y se podrá ver si está actualizado a la última versión o no.

Si no está actualizado a la última versión, le afectarán todos los bugs descritos en el tracking de seguridad en Apache Web Server y no debería ser así. Para consultar el banner, basta con hacer una petición GET al servidor web y analizar las cabeceras en las respuestas.

Figura 1: Banner de un Apache modificado a Malignito

Si no sale la versión, las herramientas de fingerprinting pueden dar una versión aproximada del servidor, pero no es nada fácil hoy en día acertar con la versión exacta de Apache con ellas. Deberías seguir actualizando a la última versión, pero al menos no es tan evidente que te faltan parches. 

2) Las páginas de error en todos los frameworks

Los mensajes de error en un servidor web Apache pueden ser devueltos por el mismo servidor web o por cualquier framework que esté instalado sobre él. Conocer la información que puede obtenerse de las páginas de error puede hacerse generando errores 400, 404, 500, etc... con diferentes extensiones de ficheros, para analizar los frameworks. Es recomendable buscar los errores en frameworks JSP, ColdFusion, etc...

Figura 2: Error 400 en Apache pintando las cookies HTTPOnly en la respuesta

Hay que recordar que con un error 400 en Apache era posible robar las Cookies HTTPOnly aprovechándose del mensaje de error por defecto. Lo ideal es que todos los códigos de error en todos los frameworks que tienes instalados sobre tu Apache tengan el mismo ErrorDocumentHandler y en el propio servidor, estén controlados y devuelvan páginas de tratamiento de excepciones asépticas.

3) Multiple Choices: mod_negotiation

Uno de los módulos más peculiares que puede tener instalado el servidor Apache es el de Multiple Choices. Este módulo, llamado mod_negotiation, recomienda al usuario ficheros contenidos en el servidor Apache similares al pedido cuando el nombre del que se ha solicitado no se encuentra almacenado allí.

Figura 3: Multiple Choices en W3.org

Esto puede utilizarse para descubrir backups en el servidor y puede descubrirse fácilmente con un sencillo ..FOCA.

4) Directorios personales de usuarios: mod_user_dir

Uno de los módulos más antiguos de Apache es mod_user_dir, que permite llevar las carpetas personales de un sistema *NIX* directamente a la web. Estos directorios suelen publicarse como http://www.servidor.com/~usuario y si están mal configurados se publicarán todas las carpetas de todos los usuarios.

Figura 4: Web Fuzzer en FOCA PRO

Suele ser interesante hacer fuzzing al nombre del usuario con un diccionario generado con nombres de usuarios extraídos directamente desde la web o los propios metadatos de los documentos con FOCA. Para este tipo de cosas, entre otras, metimos el plugin de Web Fuzzer en FOCA PRO.

5) Los métodos HTTP inseguros

Los métodos HTTP que se pueden utilizar en un servidor web Apache deben estar restringidos para que sólo se usen aquellos que sean extrictamente necesarios. GET, POST y HEAD deberían ser más que suficientes para una web "normal". Si permites OPTIONS te van a poder examinar todos los métodos permitidos, si permites TRACE, te puedes encontrar con alguna situación como la de robar las cookies HTTPOnly.

Figura 5: Options en un servidor Apache con soporte para PUT, DELETE y TRACE

Si permites el método PUT o DELETE te puedes encontrar algún punto de la web en los que por fallos de los permisos te acaben metiendo una webshell - y que aparezcas en una búsqueda por Shodan en un ataque de hacking con buscadores -  o borrando ficheros.

Saludos Malignos!

************************************************************************************************
- 10 cosas que puedes revisar en tu Apache (1 de 2)
- 10 cosas que puedes revisar en tu Apache (2 de 2)
************************************************************************************************