Limited File Uploads
Hasta ahora, hemos trabajado principalmente con eludir filtros para obtener arbitrary file uploads a través de una aplicación web vulnerable, que es el enfoque principal de este módulo en este nivel. Mientras que los formularios de carga de archivos con filtros débiles pueden ser explotados para cargar archivos arbitrarios, algunos formularios de carga tienen filtros seguros que pueden no ser explotables con las técnicas que hemos discutido. Sin embargo, incluso si nos enfrentamos a un formulario de carga limitado (es decir, no arbitrario), que solo nos permite cargar tipos de archivos específicos, aún podríamos realizar ciertos ataques contra la aplicación web.
Algunos tipos de archivos, como SVG, HTML, XML, e incluso algunos archivos de imagen y documentos, pueden permitirnos introducir nuevas vulnerabilidades en la aplicación web al cargar versiones maliciosas de estos archivos. Por esta razón, realizar fuzzing de las extensiones de archivo permitidas es un ejercicio importante para cualquier ataque de carga de archivos, ya que nos permite explorar qué ataques podrían ser posibles en el servidor web. Vamos a explorar algunos de estos ataques.
XSS
Muchos tipos de archivos pueden permitirnos introducir una vulnerabilidad de Stored XSS en la aplicación web al cargar versiones maliciosamente diseñadas de los mismos.
El ejemplo más básico es cuando una aplicación web nos permite cargar archivos HTML. Aunque los archivos HTML no permiten ejecutar código (por ejemplo, PHP), aún sería posible implementar código JavaScript dentro de ellos para llevar a cabo un ataque XSS o CSRF contra quien visite la página HTML cargada. Si el objetivo ve un enlace desde un sitio web que confía y el sitio web es vulnerable a la carga de documentos HTML, es posible engañarlo para que visite el enlace y ejecutar el ataque en sus máquinas.
Otro ejemplo de ataques XSS son las aplicaciones web que muestran los metadatos de una imagen después de su carga. Para este tipo de aplicaciones, podemos incluir un payload XSS en uno de los parámetros de metadatos que aceptan texto en bruto, como los parámetros Comment o Artist, de la siguiente manera:
exiftool -Comment=' "><img src=1 onerror=alert(window.origin)>' HTB.jpg
exiftool HTB.jpg
...SNIP...
Comment : "><img src=1 onerror=alert(window.origin)>
Podemos ver que el parámetro Comment se actualizó con nuestro payload XSS. Cuando se muestran los metadatos de la imagen, el payload XSS debería activarse y ejecutar el código JavaScript para llevar a cabo el ataque XSS. Además, si cambiamos el MIME-Type de la imagen a text/html, algunas aplicaciones web podrían mostrarlo como un documento HTML en lugar de una imagen, en cuyo caso el payload XSS se activaría incluso si los metadatos no se mostraran directamente.
Finalmente, los ataques XSS también pueden realizarse con imágenes SVG, junto con varios otros ataques. Las imágenes Scalable Vector Graphics (SVG) están basadas en XML y describen gráficos vectoriales 2D, que el navegador renderiza en una imagen. Por esta razón, podemos modificar sus datos XML para incluir un payload XSS. Por ejemplo, podemos escribir lo siguiente en HTB.svg:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1" height="1">
<rect x="1" y="1" width="1" height="1" fill="green" stroke="black" />
<script type="text/javascript">alert(window.origin);</script>
</svg>
Una vez que carguemos la imagen en la aplicación web, el payload XSS se activará cada vez que se muestre la imagen.
Para más información sobre XSS, puedes consultar el módulo Cross-Site Scripting (XSS).
Ejercicio: Prueba los ataques anteriores con el ejercicio al final de esta sección y verifica si el payload XSS se activa y muestra la alerta.
XXE
Ataques similares pueden llevarse a cabo para explotar XXE. Con imágenes SVG, también podemos incluir datos XML maliciosos para filtrar el código fuente de la aplicación web y otros documentos internos dentro del servidor. El siguiente ejemplo puede usarse para una imagen SVG que filtre el contenido de (/etc/passwd):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<svg>&xxe;</svg>
Cuando se carga y visualiza la imagen SVG anterior, el documento XML se procesará, y deberíamos obtener la información de (/etc/passwd) impresa en la página o mostrada en el código fuente de la página. De manera similar, si la aplicación web permite la carga de documentos XML, entonces el mismo payload puede realizar el mismo ataque cuando se muestren los datos XML en la aplicación web.
Leer archivos del sistema como /etc/passwd puede ser muy útil para la enumeración del servidor y aún más beneficioso para el pentesting, ya que nos permite leer los archivos fuente de la aplicación web. Esto nos brinda acceso para encontrar más vulnerabilidades dentro de la aplicación a través de un Whitebox Penetration Testing. Para la explotación de File Upload, esto puede ayudarnos a localizar el directorio de carga, identificar extensiones permitidas o encontrar el esquema de nombres de archivos, que puede ser útil para explotaciones futuras.
Para leer el código fuente en aplicaciones web PHP, podemos usar el siguiente payload en nuestra imagen SVG:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [ <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>
<svg>&xxe;</svg>
Cuando se muestra la imagen SVG, deberíamos obtener el contenido de index.php codificado en base64, que podemos decodificar para leer el código fuente. Para más información sobre XXE, consulta el módulo Web Attacks.
El uso de datos XML no es exclusivo de las imágenes SVG, ya que también se utiliza en muchos tipos de documentos, como PDF, Word Documents, y PowerPoint Documents, entre otros. Estos documentos incluyen datos XML para especificar su formato y estructura. Si una aplicación web usa un visor de documentos vulnerable a XXE y permite la carga de cualquiera de estos documentos, podemos modificar sus datos XML para incluir elementos XXE maliciosos y realizar un ataque blind XXE en el servidor backend.
Otro ataque similar es un SSRF, que podría utilizarse para enumerar servicios internos o interactuar con APIs privadas. Para más información sobre SSRF, consulta el módulo Server-side Attacks.
DoS
Finalmente, muchas vulnerabilidades de carga de archivos pueden conducir a un ataque de Denial of Service (DoS) en el servidor web. Por ejemplo, podemos usar los payloads de XXE anteriores para lograr ataques DoS, como se explica en el módulo Web Attacks.
Además, podemos utilizar una Decompression Bomb con tipos de archivo que usan compresión de datos, como los archivos ZIP. Si una aplicación web descomprime automáticamente un archivo ZIP, es posible cargar un archivo malicioso que contenga archivos ZIP anidados dentro, lo que podría generar Petabytes de datos y provocar un colapso del servidor backend.
Otra posibilidad es un ataque de Pixel Flood con algunos archivos de imagen que utilizan compresión, como JPG o PNG. Podríamos crear cualquier archivo JPG con un tamaño (e.g., 500x500) y luego modificar manualmente sus datos de compresión para indicar un tamaño de (0xffff x 0xffff), resultando en una imagen con un tamaño percibido de 4 Gigapíxeles. Cuando la aplicación intente mostrar la imagen, intentará asignar toda su memoria a esta, causando un colapso en el servidor backend.
En adición a estos ataques, también podemos intentar otros métodos para provocar DoS en el servidor, como cargar un archivo excesivamente grande. Algunos formularios de carga no limitan el tamaño del archivo antes de subirlo, lo que podría llenar el disco duro del servidor y provocar un colapso o una ralentización significativa.
Si la función de carga es vulnerable a directory traversal, podríamos intentar cargar archivos en un directorio diferente (por ejemplo, ../../../etc/passwd), lo que también podría causar un colapso del servidor. Busca otros ejemplos de ataques DoS a través de vulnerabilidades de carga de archivos.