Challenge Description: Still cool haxxorz only!!! Except this time I added in a reverse proxy for extra security. Nginx and the standard library proxy are waaaayyy too slow (amateurs). So I wrote my own :D
Challenge Author: Jordan Bertasso
Category: Web (Easy)
Source code: https://github.com/DownUnderCTF/Challenges_2023_Public/tree/main/web/actually-proxed
Basic Recon
Looking at the initial http request to connect to the challenge we see this:
This feels awfully similar to the Proxxed challenge where we needed to put in an “X-Forwarded-For” header. Also it seems to claim our IP address is localhost.
The challenge description hints that it uses a reverse proxy.
Source Code Review
Having a look through the source code we see a few points of interest:
It appears that it does indeed support the “X-Forwarded-For” headers and we need to change the IP to “31.33.33.37” again.
Exploit
Lets try the same thing as we did in Proxxed and add in the header just to see what happens.
As expected it does not work, however the IP address seems to have changed. But it does not match the one we provided in the header.
There must be some additional trick we need to overcome.
Lets consult the wikipedia page about this header.
The X-Forwarded-For header is added or edited by HTTP proxies when forwarding a request. The server appends the address of the client to an existing X-Forwarded-For header separated by a comma, or creates a new X-Forwarded-For header with the client address as the value.
Since it is easy to forge an X-Forwarded-For field the given information should be used with care. The right-most IP address is always the IP address that connects to the last proxy, which means it is the most reliable source of information. X-Forwarded-For data can be used in a forward or reverse proxy scenario. If the server is behind a trusted reverse proxy and only allows connections from that proxy, the header value can usually be assumed to be trustworthy.
Just logging the X-Forwarded-For field is not always enough as the last proxy IP address in a chain is not contained within the X-Forwarded-For field, it is in the actual IP header. A web server should log both the request’s source IP address and the X-Forwarded-For field information for completeness.
It seems the header can support multiple values separated by commas and multiple headers of the same type as well.
First we try have multiple values separated by commas.
No luck :(
Next we try multiple headers:
And that works!