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).

 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.

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.

SSRF

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.

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.

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 vulnerabilidad CVE-2021-40438

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/"

 PoC:

 GET /?unix:testsocket|http://test/ HTTP/1.1

 Fuentes:
https://www.fastly.com/es/blog/apache-redux-preventing-server-side-request-forgery-via-cve-2021-40438

https://firzen.de/building-a-poc-for-cve-2021-40438