Scanning Internal Networks Through Exposed Proxies

Proxies are a really cool idea. They provide us with a way to get to places we couldn't before. A way to hide our true identities from the outside world or in some cases a way to hide our true identity from an inside world. Some networks of interest have such a proxy and it should pique your curiosity about what it provides the outside world when looking in.

This was discovered by looking at a homepage which links to some internally available service. The web server providing the exposed proxy looks typical:

http://some.network.com/

And contains an image from a web cam that has a source that looks like this:

http://some.network.com/proxy/10.1.1.2/jpg/fullsize.jpg

Fascinating, IP addresses starting with 10 are defined in RFC1918 (section 3) as being private. So does this mean we can make a web request to some.network.com/proxy/[desired content] and it'll just pass it along? Lets give it a try, load up a browser and load:

http://some.network.com/proxy/www.google.com/

The results are not only as expected, but exciting! Google appears to be the web page served. But how far can this proxy really go? I wonder...

http://some.network.com/proxy/some.othernetwork.com:84/

Now a more interesting result. Choosing another network which I am aware has a web server running on the non-standard port of 84 we see the slightly less expected result that the proxy actually forms a connection anyway. This means its not confined to web services on port 80 or 443! This is interesting but not exactly as useful as the title implies. We're really just bouncing off the proxy to get back to the Internet from the Internet. But we still have the internal IP address lingering in that source attribute, so if it works one way, surely it works the other way?

http://some.network.com/proxy/10.1.1.2:443/jpg/fullsize.jpg

Praying for an SSL service. "Service is currently unavailable" I think this means "No Dice." This error was received after a significant delay, which means the proxy itself must have been waiting for the TCP/IP connection timeout before actually responding. That's good, since it means it tried and as expected did not rewrite the port to 80. Maybe another host would be more interesting?

http://some.network.com/proxy/10.1.1.3/ --Nope

http://some.network.com/proxy/10.1.1.4/ --Nope

http://some.network.com/proxy/10.1.1.5/ --Nope

http://some.network.com/proxy/10.1.1.6/ --DING!

Awesome, another web server. Contains miscellaneous content of no consequence, but it also has some content that leads us to believe there could be another service running. Lets give it another try...

http://some.network.com/proxy/10.1.1.6:1/ --Nope

http://some.network.com/proxy/10.1.1.6:2/ --Nope

...

http://some.network.com/proxy/10.1.1.6:22/ --Nope

http://some.network.com/proxy/10.1.1.6:23/ --DING!

No way, really? Port 23 is for Telnet, convenient and very interesting. The result is we're served with a 'file' which we go ahead and download it into RAM, since we'll probably be throwing it away, and what do we see?

[Telnet Stuffs]

[System Banner]

Enter Password > 

   ERROR - Timeout

Awesome, it is a telnet server, we've got a nice little banner in there too for the type of system it is running on. We can't go much further than this on that one host (nor would we want to), but as you can see we can easily scan for services of interest on the internal network from the Internet at large.

What is one of the most interesting questions here is: what about firewalls? What are the expected trust boundaries and how do they compare with the actual trust boundaries? Depending on the different web services available and of course other configuration issues, this proxy is likely side stepping a firewall and could be putting a huge chink in the perimeter of the owning network.