10 cosas que puedes revisar en tu Apache

[LUK]

Apache sigue siendo el servidor web más extendido en Internet. En este artículo hemos querido recopilar en 10 puntos las cosas que puedes probar fácilmente en un servidor web de Apache para mejorar su seguridad que 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:

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 servidor.com: The Leading Server Site on the Net 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! @ Un informático en el lado del mal: 10 cosas que puedes revisar en tu Apache (1 de 2)

[LUK]

Continuando con las 10 cosas que puedes revisar en tu servidor web Apache, hoy os dejo otras 5 cosas más. No son éstas las únicas que se pueden mirar - por supuesto - pero son algunas que son fáciles de comprobar. Si quieres fortificar más Apache, puedes leerte las recomendaciones de fortificación que tienes también en la web del proyecto.

6) Consolas de administración y paneles de administración JBOSS

Hace poco salía a la luz los miles de servidores Apache con server-status abierto sin ninguna contraseña en el servidor - entre los que salían sitios como CISCO -, pero casi más peligroso es tener paneles de administración JBOSS en /web-console o /jnx-console sin password o con credenciales por defecto.

Figura 6: Panel de administración JBOSS

En cualquiera de los dos casos se está pidiendo a gritos un ataque que pueda terminar con la seguridad del sistema.

7) Servicios Proxy configurados en el servidor Apache

El servidor Apache puede funcionar como un servidor Proxy para dar conexión a una red interna que quiere salir a Internet o como un servidor Reverse Proxy que dé acceso a servidores de la Intranet desde Internet. En ambos casos, una mala configuración puede llevar a serios riesgos de seguridad. Para descubrir el servicio de Proxy en un servidor Apache primeramente se busca el módulo mod_proxy o mod_proxy_ajp - módulo de Apache para jserv que necesita usar mod_proxy - que puede aparecer directamente en el banner del servicio HTTP o en los mensajes de error. Se pueden encontrar haciendo hacking con buscadores en Shodan.

Figura 7: Servidores Apache con mod_proxy descubiertos por Shodan

Otra forma de descubrirse ese servicio es mediante el uso del método CONNECT por HTTP, que permite utilizar un servidor Proxy para realizar una conexión a otro servidor web, pero también se pude utilizar un servicio Proxy en modo transparente en donde se pide la URL completa en el método HTTP, por ejemplo GET http://servidor2.com/index.htm y utilizando en el encabezado HOST el nombre del servidor Proxy. FOCA realiza estas pruebas buscando servidores Proxy en las direcciones IP del dominio en los puertos 80, 443, 8080, 8081 y 3128 (Squid Proxy).

Figura 8: Búsqueda de servidores Proxy en FOCA

Si alguien puede conectarse a tu servidor Apache y usarlo como servidor Proxy podría realizar actos maliciosos desde tu dirección IP y lograr que te bloquearan el equipo. Además, podría navegar por la Intranet y hasta por localhost a través del servidor Proxy o conectarse a cualquier servidor de la Intranet incluso si está bien configurado, pero no está actualizado.


8) El soporte PHP de tu servidor

Si tienes instalado PHP en tu servidor Apache, lo primero y más inmediato que debes comprobar es que no sea vulnerable al bug que permite ejecutar comandos en Apache si PHP está en modo CGI. Para solucionarlo lo mejor es que tengas actualizado PHP a la última versión, antes de plantearte cualquier otra alternativa.

Figura 9: Ejecución de código en Apache a través del bug CVE-2012-1823

Después, puedes comprobar que no tienes un info.php en tu servidor, que no tienes Blind SQL Injection de libro en parámetros numéricos y que no tienes ningún bug de type conversion en las aplicaciones PHP.

9) Ataques D.O.S.

Si tienes una botnet atacando a tu servidor Apache la mejor forma de defenderse es tener el portal alojado en un proveedor en la nube que evite este tipo de ataques, pero si desde una única máquina se puede tirar abajo tu Apache, entonces sí hay problemas que pueden ser subsanados. Si revisas la tabla de CVEs de Apache HTTP Server, podrás ver que el número de bugs que permiten hacer una Denegación de Servicio es alto.

Figura 10: CVEs de Apache HTTP Server

No de todos hay herramientas públicas, pero algunas sí se hicieron muy populares, como la del ataque de Slowris que publicó RSnake y que tiene una aplicación para lanzarlo contra tu servidor y comprobar si es vulnerable o no.

Figura 11: OWASP HTTP Post Attack Tool

Otra herramienta que puedes probar para ver la resistencia contra ataques D.O.S. de tu servidor Apache es OWASP HTTP Post Tool. Si una sola máquina es capaz de tumbar tu servidor entonces debes revisar las actualizaciones de tu Apache, las propiedades de tu conexión y las configuraciones de seguridad que puedes aplicar para minimizarlo.

10) ¿Qué más hay allí? Los listeners

La última de las cosas que os voy a recomendar mirar es algo que hace FOCA automáticamente por cada nombre de dominio, y es revisar los listeners HTTP y HTTPs de tu dominio. Para ello conéctate a http://www.tudominio.com y https://www.tudominio.com. Luego consulta la dirección IP de tudominio.com y conéctate a http://tuIP y https://tuIP, a ver si sale todo lo que tu esperabas y no aparezca una página por defecto o un portal de administración de un router con una password por defecto.

Figura 12: Modificador IP en Bing

Si quieres analizar un poco más lo que hay allí, puedes usar el modificador IP de Bing para ver con qué otros sitios webs compartes dirección a ver si pudieras ser atacada por alguno de ellos, aunque eso exigiría que estuvieran en la misma máquina.

Saludos Malignos! @ Un informático en el lado del mal: 10 cosas que puedes revisar en tu Apache (2 de 2)

[clarinetista]

Buen post de Chema Alonso