# SSRF to Envoy Admin Page

Here's a cool vulnerability that I found. When creating an image, the application sends the URL of the image to the server and returns a hash. When we send a get request to the hash, the server makes a request to the specified URL that was sent earlier.

This makes it vulnerable to SSRF because we could change the URL to anything we want, including localhost to send requests to the internal server.

It took me awhile to figure out a successful vector of attack, as there were many technologies present such as Envoy, Kubernetes, and Istio. Eventually I found an SSRF to the admin page at `http://localhost:15000` which allowed me to interact with the Envoy server, performing actions like shutting it down or modifying it's runtime values. The list of ports can be found here: <https://istio.io/latest/docs/ops/deployment/requirements/>

Below is the redacted and modified report that was accepted as a high severity vulnerability.

### Summary:

When uploading an image to an account at `https://<REDACTED>/edit`, we can hijack the call to `https://<REDACTED>/image`to change the `URL`to `localhost` or our own server.

When we send a `GET` request to `https://<REDACTED>/get/image?hash=<hash>` the server will then make a request to the specified URL on our behalf.

Exploiting this, we can access the envoy admin page for the media server, and run admin commands that modifies configuration, or shut the server down.

### Steps To Reproduce:

1. Login as a user, and go to `Edit Media`
2. Click on `Add Photos`, upload a photo, and intercept the calls when clicking save
3. Intercept the calls to `https://<REDACTED>/image` and modify the `URL`. In this case, we send the request to a URL created on `https://webhook.site/`, which is able to tell us information about the request
4. Using the hash value returned earlier, send a `GET` request to `https://<REDACTED>/get/image?hash=<hash>`
5. Going to `https://webhook.site/`, we can see the request from the server, including data in the Enovy headers

The key pieces of information are:

* `x-envoy-decorator-operation`, which tells us the local domain used in the internal server `http://<REDACTED>.svc.cluster.local:8001`
* `x-envoy-peer-metadata`, which when base64 decoded gives us data about the infrastructure such as `gcp_gke_cluster_url` and `INSTANCE_IPS`

1. We can access the enovy admin portal by creating a link to `http://localhost:15000`
2. Looking at the commands we can run, we can read a wealth of information of the Enovy server, modify values, or even stop the server with `http://localhost:15000/quitquitquit`

### Impact

By exploiting the SSRF, we can get the infrastructure information from the envoy headers.

We can also access the envoy admin portal for the media server to modify runtime values via `http://localhost:15000/runtime_modify` and shut the server down via `http://localhost:15000/quitquitquit` causing a denial of service

This violates Confidentiality (leaking infra info), Integrity (able to modify values in the envoy server), and Availability (able to shut down the envoy server)
