Apache, más y mejor: prevención de la falsificación de peticiones del lado del servidor mediante CVE-2021-40438

Información más importante:

• Esta vulnerabilidad de la versión 2.4.48 de Apache HTTP Server (httpd) puede dar lugar a la falsificación de peticiones del lado del servidor, y se puede aprovechar a distancia si un módulo concreto está habilitado (mod_proxy).

• Ya hay una revisión disponible en la versión 2.4.51, y las instancias de Apache HTTP Server alojadas en la nube son seguras, siempre y cuando estén relativamente actualizadas.

• Nuestros clientes del WAF de última generación están protegidos contra esta vulnerabilidad por una regla de plantilla.

CVE-2021-40438 es una vulnerabilidad de falsificación de peticiones del lado del servidor (SSRF) en las versiones 2.4.48 y anteriores de Apache HTTP Server. Al enviar una petición con una redacción específica, los atacantes pueden forzar al módulo mod_proxy (si está habilitado) a dirigir las conexiones a un servidor de origen que hayan elegido. Así, pueden conseguir filtrar secretos, como claves o metadatos de infraestructura, o bien acceder a otros servidores internos con menor protección que los externos. 

Impacto

Esta vulnerabilidad afecta a las versiones 2.4.48 y anteriores de Apache HTTP Server (también conocido como httpd). Sin embargo, el módulo mod_proxy debe estar activado para que el servidor sea vulnerable, por lo que los atacantes deben encontrar servidores que cumplan esas condiciones concretas para aprovechar la vulnerabilidad. 

Por desgracia, los datos de Shodan indican que hay más de 500 000 servidores que coinciden con esta versión, de modo que hay terreno abonado para que los atacantes aprovechen esta vulnerabilidad.

Interés

Como método de ataque, la SSRF (sobre la que ya hemos escrito) se ha vuelto popular en los últimos años, probablemente por la combinación de su eficacia, dificultad de detección y el aumento de puntos de conexión vulnerables, que es la desventaja de que el software se esté comiendo el mundo. En su ascenso al estrellato, la SSRF ha entrado en la lista de los 10 principales ataques según OWASP y se ha ganado la fama en varias violaciones de seguridad. Nos podemos imaginar a la SSRF como un proxy inverso maligno que los atacantes usan en sus operaciones.

También detectamos que una importante cantidad de usuarios que usan cPanel en CentOSrestauraron sus instalaciones de Apache a la versión 2.4.48 desde las versiones más nuevas 2.4.49 y 2.4.50 debido a otra vulnerabilidad reciente en Apache HTTP Server: CVE-2021-41773. Por desgracia, esta reversión deja a los usuarios en una posición de vulnerabilidad ante este ataque. Cambiar un ataque de cruce de directorio por una SSRF no es muy buena idea. 

Limitaciones

Se trata de una vulnerabilidad grave para organizaciones que usan una versión anterior de Apache HTTP Server, pero el vector de ataque más lucrativo es la nube, que es donde hay el botín más grande. Sin embargo, los proveedores de la nube, como Amazon Web Services (AWS), Microsoft Azure y Google Cloud Platform (GCP), han incorporado protección contra dicha vulnerabilidad. 

De este modo, es probable que el impacto se limite a organizaciones que funcionan con servidores propios de httpd. Las organizaciones con instancias de Apache HTTP Server autohospedadas deben incluir toda aplicación a la que pueda acceder el servidor de Apache (con peticiones GET) en el impacto potencial del incidente. 

Análisis en profundidad

El módulo mod_proxy implementa un proxy que se puede utilizar para redirigir conexiones en servidores de Apache HTTP. Se suele utilizar como puerta de enlace a servidores de aplicaciones, al ofrecer las ventajas típicas de los servidores proxy, como el equilibrio de carga. 

El commit relevante que corrige este problema es r1892814. En un servidor Apache ya revisado, el código que analiza la URL (el destino del proxy) solo se activará si la cadena unix: está al principio de la URL del proxy (como en [proxy:]unix:path|url). En un servidor sin revisar, la función de análisis busca unix: en toda la URL proporcionada por el usuario, en lugar de limitarse a analizar el principio de la cadena.

Asimismo, parece que el atacante puede controlar las variables que se pasan a la función ap_runtime_dir_relative y, conociendo el código C, esto introduce la posibilidad de desbordar el búfer o de dejar la función en estados inesperados. Los equipos de operaciones y seguridad lo pasan mal cada vez que hay la posibilidad de una caída o de que un atacante se haga con el control, por lo que este comportamiento no es de desear.  

Se puede aprovechar efectivamente esta posibilidad forzando al APR_PATH_MAX a devolver un código de error por longitud máxima (que es de 7701 caracteres). Para probarlo, puedes ejecutar el comando siguiente, en el que forzamos al servidor a lanzar un agónico «AAAAA» de socorro (mérito de @_mattata):

curl "http://localhost/?unix:$(python3 -c 'print("A"*7701, end="")')|http://backend_server1:8080/"

Para conocer paso a paso cómo aprovechar esta vulnerabilidad, recomendamos leer esta entrada de blog en la que se describe una prueba de concepto de la vulnerabilidad.

Qué hacer

Cualquier persona que ejecute Apache HTTP Server en su versión 2.4.48 (o anterior) debe corregir sus servidores con la versión 2.4.51, así como deshabilitar la ruta mod_proxy o bien asegurarse de que ya esté deshabilitada hasta aplicar la revisión.

Si eres un cliente y utilizas un servidor Apache HTTP, puedes seguir los pasos que encontrarás a continuación para activar la nueva regla de plantilla y protegerte de CVE-2021-40438.

Si eres cliente de nuestro WAF de última generación y ejecutas tu servidor Apache en AWS, también puedes habilitar la regla de plantilla de la SSRF en AWS para añadir más protección contra todos los tipos de ataque de SSRF en AWS.

Selecciona «Site and Site Rules» -> «Templated Rules»

Navega hasta CVE-2021-40438, selecciónala y elige «Configure». Habilita la regla para bloquear peticiones de una IP.

Confirma que la regla esté activada en la página de reglas de plantillas.