Header modification results in disclosure of Slack infra metadata to unauthorized parties

How it was found

I found files.slack.com domain will honor the X-Forwarded-Host header, instead of host header. Although file.slack.com has host validation to return 500 Internal server error when host is not files.slack.com, I can bypass the validation by appending @ at the end of host name. Also, the server will send request to the host in X-Forwarded-Host. And, we can see the server sent request is not the front end server (not from cloudfront.net), it is from the back end server(from amazonaws.com). So, with the blind SSRF vulnerability, the attackers can send arbitrary requests to the intranet, ex: port scanning by identifying the response delay time, to know 169.265.169.254:443 is closed, 169.265.169.254:80 is opened...and so on.

Reproduce steps:

1. upload a file onto the slack, find the original image path via Open original. Intercept this original path (i.e. https://files.slack.com/files-pri/TNXC4JD70-FPSL307RB/test.png) on burp suite

2. Send to repeater, make sure it works fine by clicking send directly

3. Add a header X-Forwarded-Host: xxx.com, make sure server returned 500 error {F623016}

4. Update header to X-Forwarded-Host: files.slack.com@YOUR_DOMAIN, make sure server response with 302, and the location is YOUR_DOMAIN/files-pri/.... {F623017}

5. Make sure the request did sent to your domain, and the server is from xxx.amazonaws.com

6. change YOUR_DOMAIN into intranet ip, ex: 169.254.169.254:PORT, change the port to check the response delay time.

Here's the demo video: https://youtu.be/j5_WicLwwC4

Impact

With the blind SSRF vulnerability, the attackers can send arbitrary requests to the intranet, ex: port scanning by identifying the response delay time. To mitigate it, the server should always honor the Host header, not others. Thank you.