¿Eres vulnerable a un ataque de Directory Traversal? Aplicación de la OTG-AUTHZ-001 con OWASP ZAP

La vulnerabilidad de Directorio Transversal (más conocida por Directory o Path Traversal), ocurre cuando no hay una gestión correcta (validación, autorización) de los parámetros provenientes del lado del cliente, específicamente aquellas relacionadas con accesos a determinados archivos. Por tanto, un atacante puede manipular los puntos de entrada y construir rutas a través de las directivas de las shells  (por ejemplo «../») para saltarse el directorio raíz de la aplicación web y acceder, en su concepto más amplio, al sistema de archivos del sistema operativo.

¿Quién no hay visto una aplicación web cuyos parámetros en la URL contengan algo similar a …/index.php?page=usage-instructions.php? Estoy seguro que te has preguntado: ¿Que ocurriría si se sustituye el recurso asignado al parámetro por otro archivo? En otras palabras, si se hace un parameter tampering.

Si la validación en el esquema de autorización funciona como es debido, no podrás acceder a ningún recurso al que no estás autorizado y obtendrás de vuelta un código de respuesta HTTP 403 indicando que no tienes los permisos requeridos o un 404 mencionando que el recurso no existe.

En la figura 1 se muestra un ejemplo muy sencillo de código vulnerable en PHP, vemos como se espera incluir un determinado archivo según la opción que haya seleccionado el usuario:

Figura 1. Código vulnerable a un ataque de Directory Traversal (Script: prueba-concepto-dt.php).

En la figura 2 se realiza la explotación del código vulnerable utilizando la VM del proyecto OWASP BWA. En este caso, la cookie OPCION, es el punto de entrada vinculado a un archivo de la aplicación web. Como resultado del ataque, puede accederse al contenido de passwd mediante la construcción de la ruta «../../../../etc/passwd», por suerte este archivo ya no tiene la contraseña de los usuarios del SO, estas se almacenan encriptadas en etc/shadow, que por cierto: ¿se podrá acceder al contenido de shadow del mismo modo que hicimos con passwd?, ya sabes la respuesta: Si.

Figura 2. Exposición del contenido del archivo passwd mediante la explotación de la vulnerabilidad Directory Traversal.

Esta vulnerabilidad es más común de lo que puede esperarse. Una simple búsqueda en www.cvedetails.com(figura 3), reporta que pocos productos escapan de este problema, incluso hasta SAP TREX, el motor de búsqueda de SAP NetWeaver BI, tuvo su Directory Traversal en agosto pasado. Por ese motivo, es natural que la Guía de Pruebas de OWASP incluya una prueba de seguridad (OTG-AUTHZ-001) para determinar si la aplicación es vulnerable a un ataque Directory Traversal.

Figura 3. Sección de los resultados de búsqueda de http://www.cvedetails.com referente a la vulnerabilidad Directory Traversal.

La OTG-AUTHZ-001 propone iniciar con un reconocimiento o enumeración de todos los puntos de entradas relacionados con archivos. Para ello deben responderse las siguientes preguntas:

• ¿Qué parámetros pueden ser usados para realizar operaciones que involucren archivos?
• ¿Hay alguna extensión de archivos inusuales?
• ¿Existe alguna variable con algún nombre que sugiera que tiene alguna relación con archivos de la aplicación web?
• ¿Es posible identificar cookies que se utilicen para la generación de páginas o plantillas web?

Algunos ejemplos:

• …/getUserProfile.jsp?item=ikki.html
• …/index.php?file=content
• ../main.cgi?home=index.htm
• Cookie:ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1165568:S=3cFMKVMV:TEMPLATE=flower
• Cookie: USER=1826cc8f:PSTYLE=GreenDotRed

Una vez determinado los posibles puntos de entrada, se pasaría a probar combinaciones de rutas y codificaciones en estos puntos de entrada. Por ejemplo:

• %2e%2e%2f representa ../
• %2e%2e/ representa ../
• ..%2f representa ../
• %2e%2e%5c representa ..\
• %2e%2e\ representa ..\
• ..%5c representa ..\
• %252e%252e%255c representa ..\
• ..%255c representa ..\

En http://www.vulnerability-lab.com/resources/documents/587.txt, hay una extensa lista de rutas a probar, hacer esto a mano sería bastante épico, por ese motivo te muestro como sería su aplicación con OWASP ZAP:

Directory Traversal con OWASP ZAP en Modo Escaneo Activo

1. Comprueba que OWASP ZAP está configurado como Proxy de Intercepción.
2. Accede a la aplicación web mediante el navegador enlazado a OWASP ZAP .
3. Buscar el directorio que representa los accesos realizados a la aplicación web en OWASP ZAP y selecciona, mediante clic derecho, la opción Atacar (Attack) luego Active Scan (Activar Escaneo) (figura 4).
4. Al término de las pruebas de seguridad, debes comprobar si en la pestaña Alerts hay algun resultado de tipo Path o Directory Traversal. En la figura 5 se presenta un ejemplo. Cuando se accede al resultado de la prueba de seguridad, se muestra las peticiones y respuestas HTTP asociados a la explotación de esta vulnerabilidad.

Figura 4. Realizando un Ataque en modo Escaneo Activo con OWASP ZAP.

Figura 5. Resultado de un escaneo con OWASP ZAP con resultado positivo para Directory Traversal (Path Traversal).

Conclusiones

Siempre es importante incluir pruebas de seguridad relacionadas con la detección de vulnerabilidades de tipo Directory Traversal. Definitivamente es una mala práctica depender de referencias de nombres de archivos enviados como parámetros desde el agente de usuario  para la realización de operaciones en la aplicación web.

En el artículo ¿Cómo funciona una vulnerabilidad Local File Inclusion? se dan recomendaciones excelentes a los desarrolladores para evitar la presencia de esta vulnerabilidad. Recomiendo encarecidamente su lectura.

La comprobación de la existencia de vulnerabilidades de Directory Traversal con OWASP ZAP puede ser más exhaustiva si se utiliza la opción Fuzzer. En la entrada titulada Técnica Fuzzing con OWASP ZAP: Profundizando en el análisis de Directory Traversal y detectando en lote archivos por defecto, te enseño como hacerlo.

Espero que te haya resultado provechosa esta entrada y te ayude a mantener o mejorar la seguridad de tus aplicaciones web.

S4lud0s y h4st4 el próx1m0 p0st!!!