Reporte Path Traversal
INTRODUCCIÓN
A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio File path traversal, validation of file extension with null byte bypass de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score, CVSS Vector y sus Componentes afectados. Sumado a ello, se especificarán las mitigaciones pertinentes, detalles técnicos del pentest y los links de referencias.
ANÁLISIS DE RIESGO
CWE-22 | Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) |
IMPACTO | MEDIO |
CVSS BASE SCORE | 5.3 |
CVSS 3.1 VECTOR | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
COMPONENTES AFECTADOS | https://LAB-Id.web-securtity-academy.net/image?filename=number.jpg |
EXPLICACIÓN | Existe una vulnerabilidad de inclusión de archivos locales a través de un ataque de Path Traversal. El origen del mismo radica en el parámetro filename donde, a través de una secuencia de caracteres, un atacante puede filtrar información de archivos locales del sistema. |
RECOMENDACIONES
1) Validar y Sanitizar las entradas correctamente: Se recomienda sanitizar todas las entradas de un usuario antes de usarlas para incluir archivos. Para ello, se pueden utilizar listas blancas para permitir solo caracteres o rutas específicas necesarias y rechazar cualquier entrada que no cumpla con esos criterios. Por ejemplo, el siguiente código PHP utiliza la función realpath para obtener la ruta real de un archivo:
$file = $_GET[‘archivo‘]; // Validación y normalización de la entrada if (validar_archivo($archivo)) { $ruta_real = realpath($directorio_base . ‘/’ . $file); // Verificación final antes de incluir el archivo if (strpos($ruta_real, $directorio_base) === 0) { include $ruta_real; } else { // La ruta no está permitida // Realizar acciones apropiadas, como registrar el intento de ataque } } else { // Entrada no válida // Realizar acciones apropiadas, como rechazar la solicitud } function validar_archivo($archivo) { // Implementar lógica de validación según tus requisitos // Devolver true si la entrada es válida, false de lo contrario } |
2) Limitar los permisos del sistema de archivo: Se recomienda asegurar que el proceso de la aplicación web (por ejemplo www-data de Apache) tenga los permisos justos y necesarios para acceder a archivos del sistema. Para ello
3) Monitoreo y registro de actividades sospechosas: Se recomienda Implementar registros detallados de la actividad del servidor y monitorear regularmente los mismos en busca de posibles intentos de LFI. Esto permitirá identificar y responder rápidamente a cualquier intento de explotación. Por ejemplo, se puede implementar la siguiente regla de suricata para la detección de intrusos:
/alert http $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:«Potential Local File Inclusion Attempt»; flow:to_server,established; content:«GET «; http_method; content:» HTTP/»; http_uri; pcre:«/\.\.\//»; sid:1000001😉 |
Esta regla se centra en la detección de solicitudes HTTP GET que contienen «../», que es una indicación común de intentos de LFI, ya que los atacantes a menudo intentan navegar hacia arriba en la estructura de directorios utilizando estos puntos suspensivos.
4) Actualizaciones del sistema: Se recomienda mantener la aplicación y sus componentes actualizados de forma constante. Para ello, es fundamental parchear cualquier vulnerabilidad conocida en el software utilizado y asegúrate de seguir las mejores prácticas de seguridad como llevar a cabo una correcta gestión de vulnerabilidades y Hardening en el sistema.
5) Implementar (WAF): Algunos motores de plantillas, como Jinja2 (hecha en Python), ofrecen contextos seguros que limitan las capacidades de ejecución de código.
6) Utilizar herramientas de seguridad conocidas: Se recomienda educar al personal y/o trabajadores en la seguridad de los datos con respecto a la confidencialidad, integridad y disponibilidad de los mismos a través de talleres o cursos pertinentes.
DETALLES TÉCNICOS
Una vez dentro de la aplicación web se pudo observar que la misma cuenta con distintos artículos y valoraciones de venta.
Por tanto, se procedió a analizar la forma en la que se envían los datos cuando se acceden a los mismos a través de la herramienta Burpsuit.
Como se observa en la captura anterior, cuando se accede a un artículo se carga una imagen la cual refiere al post en cuestión. Por tanto, se procedió a utilizar distintas formas y wrappers (especie de envoltura que le indica al Stream como actuar) en el parámetro filename.
Como se puede apreciar, la aplicación web es vulnerable a Local File Inclusion (LFI) a través del parámetro filename. Esto ocurre porque no se valida la entrada de datos y la extensión de los mismos. Es decir, cuando se quiere acceder al archivo “/etc/passwd” el sistema carga “/etc/passwd.jpg”. Entonces, haciendo uso de “../../” para retroceder al directorio raíz, y utilizando el wrapper Null Byte %00, la aplicación le “dice” al servidor que ignore todo caracter que esté por delante de dicha cadena.
De esta forma se puede incluir archivos locales del sistema, no solo /etc/passwd para conocer los usuarios activos e inactivos del sistema, sino también otros como /proc/self/environ como se observa en la siguiente captura.
Por lo tanto, en este reporte de path traversal se intenta demostrar que, aunque se puede incluir archivos locales del sistema, un atacante también puede buscar escalar el impacto de la misma. Por ejemplo, a través de la variable HTTP_USER_AGENT (en el caso que esté) dentro del archivo /proc/self/environ, se puede usar la cabecera User Agent para intentar ejecutar comandos de forma remota.
