SSRF to Envoy Admin Page

Don't let users send what links to open!

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>/imageto change the URLto 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)