Description

Via the /api/upload/upload-by-url endpoint is possible to upload an image via an URL provided by the user. The function that handles this upload, doesn't verify or validate the provided URL, allowing to fetch internal services.

Furthermore, after the resource is fetched, there is no MIME type validation, which would ensure that the resource is indeed an image. Then, the file is saved to a temporary directory, that can be retrieved via the /api/image/cover-upload API endpoint.

Finally, an attacker can manipulate the extension of the saved file, by adding the the hash sign # to the end of the URL and then an extension of its choice, for example.png .This in important because it doesn't modify the internal fetched resource, but allows to save the response to a valid file, that can be successfully retrieved via the /api/image/cover-upload endpoint.

Proof of Concept

For testing purposes, I started an internal-only HTTP server, listening at port 8000, along side the application.

1 - Login in the application.
2 - Send the following request, where the url attribute is the target resource, in this case will be the HTTP server at port 8000. 3 - Visit the /api/image/cover-upload?filename=<filename> URL, where the filename contains the above response filename.

Impact

An attacker can get sensitive information of any internal-only services running. For example, if the application is hosted on Amazon Web Services (AWS) plataform, its possible to fetch the AWS API endpoint, https://169.254.169.254, which returns API keys and other sensitive metadata.