hackedrishi/ctf_writeups-tryhackme-cve-2021-41773-CTF_WRITEUPS/TryHackMe /CVE-2021-41773/
CTF_WRITEUPS/TryHackMe /CVE-2021-41773/
Una breve historia
El 5 de octubre de 2021, se publicó un CVE que detallaba un ataque de path traversal en Apache HTTP Server v2.4.49. Asignado con el número CVE-2021-41773, se publicó con la siguiente descripción:
Se encontró una falla en un cambio realizado en la normalización de rutas en Apache HTTP Server 2.4.49. Un atacante podría usar un ataque de path traversal para asignar URLs a archivos fuera del directorio raíz de documentos esperado. Si los archivos fuera del directorio raíz de documentos no están protegidos por "require all denied", estas solicitudes pueden tener éxito. Además (sic), esta falla podría filtrar el código fuente de archivos interpretados como scripts CGI. Se sabe que este problema se explota en la naturaleza. Este problema solo afecta a Apache 2.4.49 y no a versiones anteriores.
Analicemos esto y veamos qué significa realmente para nosotros:
Muchas correcciones después...
Entonces Apache corrigió este error y lanzó la v2.4.50. Fin de la historia, ¿verdad? Bueno, no exactamente. Solo 2 días después, el 7 de octubre, se publicó un nuevo CVE citando el anterior. Este menciona que la corrección del ataque de path traversal anterior era incompleta, y aún podíamos atravesar si la ruta en cuestión usaba una directiva alias para asignar sus URLs al sistema de archivos. El CVE fue asignado con el número CVE-2021-42013, con la siguiente descripción:
Se descubrió que la corrección para CVE-2021-41773 en Apache HTTP Server 2.4.50 era insuficiente. Un atacante podría usar un ataque de path traversal para asignar URLs a archivos fuera de los directorios configurados mediante directivas de tipo Alias. Si los archivos fuera de estos directorios no están protegidos por la configuración predeterminada habitual "require all denied", estas solicitudes pueden tener éxito. Si los scripts CGI también están habilitados para estas rutas alias (sic), esto podría permitir la ejecución remota de código. Este problema solo afecta a Apache 2.4.49 y Apache 2.4.50, y no a versiones anteriores.
Al igual que antes, podemos aprender algunas cosas aquí:
Mientras procesamos esta locura, veremos la configuración requerida en la siguiente tarea.
Responde las preguntas a continuación
Un poco de teoría
Un exploit de Path Traversal es un ataque que tiene como objetivo acceder a recursos que normalmente son inaccesibles abusando de fallos en la resolución y/o normalización de rutas. Generalmente explotamos este tipo de ataque viajando (también conocido como atravesando) hacia atrás más allá de la raíz supuesta usando la sintaxis ...
¿Normalización? ¿Qué?
Normalmente, cuando se proporciona una ruta para que algún código encuentre un archivo, es necesaria una ruta absoluta. Llamemos a esto la ruta canónica. Cuando se da una ruta relativa, debe normalizarse a una forma canónica para que las bibliotecas del sistema operativo que usan esa ruta puedan encontrar el recurso en cuestión. Esta es una simplificación excesiva, por supuesto, pero la esencia permanece.
En general, existen bibliotecas de plataforma que hacen esta normalización por nosotros, pero en C/C++ normalmente lo hacemos todo nosotros mismos. Si bien esto puede ofrecer cierta flexibilidad, también puede introducir fácilmente fallos si nuestra implementación no es perfecta.
Normalizando URLs
Un servidor HTTP tiene que traducir una URL a una ruta canónica en el sistema de archivos para encontrar el archivo correcto que servir. Si bien definitivamente hay algunos filtros para evitar poder atravesar más allá del directorio raíz de documentos, algunos casos de uso pueden pasarse por alto fácilmente. En este caso, el exploit aprovecha no solo la codificación de URL (llegaremos a eso en un momento), sino también una falla en la normalización de rutas del módulo Alias (supuestamente)
Un aparte sobre la codificación de URL
Definida en RFC 3986 Sección 2, la codificación de URL es un esquema utilizado para codificar caracteres especiales o reservados dentro de una URL. Por ejemplo, los espacios en una URL se codifican como un carácter + (notablemente en los parámetros de consulta). Si queremos codificar un signo más real, debemos codificarlo usando lo que se conoce como "codificación por porcentaje". Esto simplemente implica prefijar el código hexadecimal US-ASCII del carácter con un signo %. En nuestro ejemplo, el símbolo + se puede codificar como %2B.
Cualquier carácter se puede codificar en URL, y las URLs que están completamente codificadas en URL son funcionalmente equivalentes a la versión no codificada. Del RFC: Si dos URIs difieren solo en el caso de los dígitos hexadecimales utilizados en octetos codificados en porcentaje, son equivalentes.
¿Qué pasó con Apache?
Un cambio reciente en el módulo de normalización de rutas en el servidor Apache permitió que una URL especialmente diseñada eludiera los filtros y atravesara más allá del directorio raíz de documentos, permitiendo la lectura arbitraria de archivos en el sistema si la configuración lo permitía. Además, si el módulo CGI estaba habilitado, ¡también es posible la ejecución arbitraria de archivos!
Responde las preguntas a continuación
A) Incluir archivos remotos arbitrarios para ser procesados en el servidor. B) Incluir archivos locales arbitrarios para ser procesados en el servidor. C) Permitir que el servidor exponga archivos arbitrarios. D) Ninguna de las anteriores.
Hackeando Apache por diversión
