Experimente el impacto de la vulnerabilidad de recorrido de rutas responsable de los recientes problemas de Apache

A principios de octubre, Apache lanzó la versión 2.4.49 para corregir una vulnerabilidad de recorrido de directorios y ejecución remota de código y, posteriormente, la 2.4.50 para solucionar el hecho de que la corrección en la 2.4.49 estaba incompleta. Quizás haya oído hablar en redes sociales sobre la importancia de actualizar a la última versión para evitar estos riesgos, dado que Apache impulsa el 25% de internet según algunas estimaciones. Pero, ¿cuál es el problema? ¿Qué nivel de riesgo existe realmente?

¿Por qué no lo prueba usted mismo?

Hemos creado una misión para demostrar los riesgos en un entorno real y la hemos hecho pública para que todos puedan probarla. En esta misión, le guiaremos a través de cómo la vulnerabilidad de recorrido de directorios puede afectar a su infraestructura y aplicaciones. Haga clic a continuación para empezar de inmediato, o siga leyendo para conocer más detalles sobre la vulnerabilidad.

Sobre la vulnerabilidad de recorrido de directorios 

La vulnerabilidad se introdujo en la versión 2.4.49 (debido a un cambio en la función de normalización de URL), donde se añadió una nueva función de normalización de rutas. Desafortunadamente, no logró normalizar correctamente las rutas codificadas en URL. Esto hace posible realizar un ataque de recorrido de directorios si no está presente la siguiente configuración:

Y si mod_cgi está habilitado, también puede aprovecharse para una vulnerabilidad de ejecución remota de código. Pero primero, profundicemos en la codificación de URL para entender mejor qué salió mal. 

Codificación de URL

En esencia, la vulnerabilidad ocurre debido a una falta de consideración hacia las URL con codificación. La nueva función de normalización de rutas no manejó completamente los casos en los que los puntos estaban codificados en URL. 

Recuerde que para realizar un ataque de recorrido de directorios, necesitará recorrer con la secuencia ../. Sin embargo, la función de normalización es lo suficientemente inteligente como para eliminarla. Entonces, ¿qué hacer? Puede codificar en URL un .(punto) como %2e, y usar una secuencia como .%2e/. Eso funcionaría en muchos casos contra Apache 2.4.40. Pero también puede ir un paso más allá y realizar una doble codificación. La versión codificada en URL de .%2e/ es .%252e/. Esto permitió eludir aún más la normalización intentada por Apache.

Pero hay un inconveniente

Si alguien quisiera intentar explotar esta vulnerabilidad directamente desde su navegador, no tendría éxito. Esto se debe a que los navegadores también intentan normalizar las URL que se envían a los servidores. Esto significa que incluso nuestra secuencia de doble codificación será eliminada. También significa que no podemos simplemente usar un navegador para demostrar esto.

Puede usar cURL para demostrarlo mediante el uso del parámetro --path-as-is , que evita que normalice la URL antes de enviarla:

Prevención y mitigación

Para prevenir completamente el problema, es importante mantenerse al día con los últimos parches de Apache. Específicamente, debería actualizar al menos a la versión 2.4.51. Pero es una buena práctica actualizar de forma regular para estar siempre al día.

Para mitigar este problema si está ejecutando la versión 2.4.49, asegúrese de haber incluido lo siguiente en su configuración de Apache:

Y para evitar la ejecución remota de código, deshabilite mod_cgi si no lo utiliza.

Compruebe el impacto usted mismo

¿Le interesa explorar qué sucedió exactamente y probarlo usted mismo? 

‍