Description

In the recipe edit page, is possible to upload an image directly or via an URL provided by the user. The function that handles the fetching and saving of the image via the URL doesn't have any URL verification, which allows to fetch internal services.

Furthermore, after the resource is fetch, there is no MIME type validation, which would ensure that the resource is indeed an image. After this, because there is no extension in the provided URL, the application will fallback to jpg, and original for the image name.

Then the result is saved to disk with the original.jpg name, that can be retrieved from the following URL: http://<domain>/api/media/recipes/<recipe-uid>/images/original.jpg. This file will contain the full response of the provided URL.

Proof of Concept

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

1 - Login and edit an existing recipe.

2 - Click in the Image button and insert an URL, in this case will be the target HTTP server: http://127.0.0.1:8000/

3 - Visit the http://localhost:9091/api/media/recipes/<recipe-uid>/images/original.jpg URL and get the internal HTTP server response.

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.