Bypass IP Whitelist Restrictions

Question

I have an internal application that only allow whitelisted IP address to consume the API. I have tried: X-Forwarded-For, X-Originating-IP etc. in the headers. None of them work. However, with header Host: and not giving IP and some random values. I get 302, 400 and 401 Errors, which are interesting.

Are there any other better ways to bypass the restriction?

Answer 1

You're trying to skip IP allowlisting? I don't think you're going to be able to do this if the allowlist is well-implemented.

If you pretend to be someone else with the Host header, the receiving application can tell that it doesn't match the actual connecting IP and should reject the request. (And if you change your connecting IP to one you don't own, the protocol can't connect anyway: You're not at the other end when it "calls" you at the spoofed IP.)

Playing with X-Forwarded-For is a neat idea, but Wade Hilmo has a blog post about how Microsoft checks allowlisted IPs for dynamic restriction rules:

But how can you trust data from the client?

[…]

A proxy server is considered safe only if its IP address is registered in the Allowed IP Address list. The logic works like this:

1. A new request arrives at the server. We get the IP address of the client from the network stack. This address is trusted, since it came from the local machine’s network software and not from the HTTP request.

2. If that IP address is on the Allowed list, we then know that it was the last entity to touch the X-Forwarded-For header and we consider the last entry on X-Forwarded-For to be a valid client IP address. If the network stack IP address is not on the Allowed list, then we consider the client IP address to be the value from the network stack and will use it. Otherwise, we go on to step 3.

3. We know that the last entry on X-Forwarded-For is valid, so we then check to see if it is on the Allowed list. If it is, then we know that the next-to-last entry on X-Forwarded-For was put there by a trusted proxy and we consider it valid. If the last entry is not on the Allowed list, then we consider it to be the IP address and use it.

We keep working our way from the end of X-Forwarded-For, towards the beginning until we reach an IP address that is not on the Allowed list. In this way, we know which entries to trust because of the proxy servers listed in the Allowed IP List.

Wade goes on to show some examples, the last of which is equivalent to how you're trying to exploit the allowlist.

Finally, let’s look at a more complicated scenario, with a malicious client that is using your internet facing IP address in a fraudulent X-Forwarded-For header. This is a clever thing to do because it assumes that your internet facing server is a proxy. And let’s say that this assumption is correct. To complete the scenario, let’s say that they are going through 2 proxies, both of which are trusted by inclusion on then Allowed IP Address list and have the addresses 2.2.2.2 and 1.1.1.1. The X-Forwarded-For header now looks like this:

X-Forwarded-For: 2.2.2.2, 23.34.45.56, 2.2.2.2

When the request arrives at our server, we can see that it came directly from the proxy with the IP address 1.1.1.1. Since that IP address is on the Allowed list, we know that the last entry appended to X-Forwarded-For was put there by our trusted proxy.

So now we know that the last entry on X-Forwarded-For can be trusted. This entry is 2.2.2.2. We look up this value in the Allowed IP Address list and find it there.

We now know that the entry just before the previous one can be considered valid. This entry is 23.34.45.56. When we look it up on the Allowed IP Address list, we do not find it. We Therefore use 23.34.45.56 as the IP address for dynamic IP restrictions.

Obviously, I don't know what your internal resource is running or whether it can be exploited. But if it's well-designed, your attempts to bypass the restrictions are not going to work.