5. File upload vulnerabilities

File upload vulnerabilities

Este tipo de vulnerabilidad se centra en la mala configuración o nula existencia de filtros de seguridad en las entradas de subida de archivos, los que permiten al atacante alojar archivos maliciosos que alteren el comportamiento esperado de un sistema e incluso le permitan ganar el acceso total al sistema.

Causas

La causa principal es la debilidad en las políticas de subida de archivos, empleando escasas o nulas reglas para los archivos, existe una serie básica de filtros para garantizar la legitimidad del archivo que se intenta subir. Aún así, el desarrollador debe contemplar las múltiples formas de evadir dichos filtros para robustecer los filtros de seguridad. El atacante puede emplear largas listas de payloads o cargas útiles que buscan evadir los filtros presentes en un sistema, un recurso recurrente el el repositorio PayloadsAllTheThings de Swissky, que cuenta con colecciones amplias de wordlists para cada escenario, donde ya incluye payloads ofuscados para evitar los filtros, incluso algunos payloads cuentan con métodos de evasión anidados para mayor porcentaje de efectividad.

Filtros

Algunos de los filtros que se pueden implementar y a su vez probar su existencia en caso de un atacante son:

Filetype
Contenido
Tamaño
Nombre
Extensiones

Validación defectuosa

Cuando se manda un formulario HTML, el buscador normalmente envía el tipo de dato con el content type Header application/x-www-form-url-encoded. Usado para mandar un texto simple como un nombre o una dirección. Sin embargo no es eficiente para mandar una gran cantidad de datos binarios como es en el escenario de la subida de imágenes o archivos PDF. En este caso, el content type multipart/form-data es preferible. Considera un formulario el cual contiene campos para subir una imagen, proveyendo una descripción a esta e ingresando tu nombre de usuario. Mandando el formulario resulta en una petición que luce como esto:

POST /images HTTP/1.1
Host: normal-website.com 
Content-Length: 12345 
Content-Type: multipart/form-data; boundary=---------------------------012345678901234567890123456 ---------------------------012345678901234567890123456
Content-Disposition: form-data; name="image"; filename="example.jpg" Content-Type: image/jpeg 
[...binary content of example.jpg...] 
---------------------------012345678901234567890123456 
Content-Disposition: form-data; name="description" 
This is an interesting description of my image.
---------------------------012345678901234567890123456 
Content-Disposition: form-data; name="username" 
wiener 
---------------------------012345678901234567890123456--

Como puedes ver, el cuerpo del mensaje se divide en partes separadas por cada una de las entradas del formulario. Cada parte contiene un Content-Disposition que otorga información básica sobre la entrada relacionada. Cada parte individual puede también contener su propio Content-Type, que informa al servidor el tipo de MIME de los datos mandados. Una de las maneras en que un sitio web puede intentar validad la subida de archivos es mediante la validación del content type del campo mandado, esperando que coincida con el tipo de MIME esperado. Como puede ser que si espera solamente imágenes, solo acepte tipos como image/jpeg e image/png. Así se evita confiar de primera mando en los headers de los formularios, pues dichos headers pueden ser fácilmente manipulados con herramientas como Burpsuite que en caso de no tener una segunda validación a nivel back-end puede resultar en una evasión de seguridad.

Ejemplos

Explotando subidas de archivos sin filtros

Las entradas que esperan un archivo, sin ningún filtro de por medio, pueden ser vulneradas con un reverse shell el cual garantizaría el acceso remoto no deseado a cualquier atacante. Los tipos de archivos mayormente usados para este propósito son los archivos PHP, Java o Python, y que son configurados también para ejecutar código, lo que hace una tarea trivial para el atacante el crear su propio web shell en el servidor. La habilidad de ejecutar una web shell implica que el atacante tiene acceso al control completo del sistema hasta donde el usuario con el que se ejecuta el archivo se lo permita. Un ejemplo de código PHP malicioso que ayuda a filtrar información interna es el siguiente: <?php echo file_get_contents('/path/to/target/file'); ?> Una vez mandado el código, retornará el archivo del objetivo en la respuesta. Un ejemplo más versátil de un web shell podría lucir así: <?php echo system($_GET['command']); ?> El anterior script permite ejecutar de forma arbitraria comandos mediante el parámetro command como se muestra a continuación: GET /example/exploit.php?command=id HTTP/1.1 Lo que retornaría en la respuesta la salida del comando, que identifica el id del usuario que ejecuta los scripts de la página. Existe una extensa variedad de web shells para cada escenario, un atacante debe de conocer multiples formas para cada caso y en la actualidad existen herramientas que facilitan el armado de web shells, reverse shells como podría ser el caso de la página revshells que pertenece a Ryan Montgomery (aka. 0dayCTF)