An old feature of ISA Server/Forefront TMG 2010, which if memory helps created over the time a few sparks within the community, is the forward web proxy’s ability to “not limit the ports to which the Web proxy may forward requests”. [1][2]
Personal I’m not a fan of such an “ability”.
Recently, during a security audit, I’ve put to “work” this ability to scan/fingerprint TCP ports/services through Forefront TMG 2010 while TMG provided network separation.
Since we can actually issue “HTTP requests” to “web sites” on virtually almost any ports, little stops us to issue requests to other services like SMTP, IMAP, POP3, FTP, RDP, etc.; all we need is to have allowed HTTP to the required destination.
Key parts of this scanning method are the default error codes/messages/pages returned by the web proxy, errors which should be pretty clear and helpful since they are normally used for troubleshooting purposes.
Also there are some fortunate cases in which the actual response of the server might be allowed through by TMG, cases which enable us to find valuable information about the services running on the scanned ports.
Imagine a server isolated on a TMG network, we only have HTTP and HTTPS access to it, but we can actually attempt to discover the services available on that server(assuming a host firewall is not blocking us) using TMG’s web proxy abilities.
A simple example of a fortunate case that you can experiment yourself is smtp.live.com, below I’m only allowing HTTP+HTTPS through TMG from the clients(we don’t care too much for the moment about HTTPS since we need to issue a CONNECT method to a different port than 443 which is not permitted by default on TMG); URL filtering is on with the default blocked list of dangerous sites in place.
Basically, by firewall rules, we’re allowed only to access HTTP and HTTPS on that server.
Say I Telnet to TMG’s proxy IP address and port then issue some mambo jambo command(note that NIS protocol anomaly block is not enabled by default, that’s why I’ve typed what came through my mind).
Here is how it looks on the client side within a Wireshark trace the request made and the response received, note that TMG “spits” back server’s response(which would be seen on the telnet console), that’s why I said it may be a fortunate case(apparently TMG’s web proxy isn’t so strict about server responses):
Here is the associated Wireshark trace on the “outside” network, note that TMG connects to the SMTP service port although we are not supposed to do that, issues the invalid SMTP command, it gets back a nice response about the server’s capabilities, response which, as we saw above, would be forwarded to the client.
Here is the associated log on TMG when the connection was initiated, one more time note that basically we have virtually access for probing almost all services on remote hosts through TMG by default like so in our test scenario:
So we found out that the port is opened, and that the SMTP service uses STARTTLS.
A similar example for POP3, but not a fortunate one this time since TMG will block the server’s response.
The Wireshark trace on the client, we get a 502 proxy error from TMG, and the error page has some extra data:
Here is what TMG did(note the server’s response) and the associated log, looks like the Malware Inspection was enabled and blocked the response(if this would not have been enabled we would had received the response on the client side):
Now although we did not get back the response, based on the proxy error code + error page received on the client side, we know the port may be actually opened.
Another open port example, this time the server will not respond with any message or so.
As usual we issue the mambo jambo command, but this time the server simple just TCP AKCs our message; based on the server’s settings the TCP connection will be kept open a while, then the server will RST the connection.
Looking at TMG’s logs, first we notice TMG opening a TCP connection to the destination port, than a log for the failed “HTTP” attempt will be present, note the error code.
On the client side we have a 502 proxy error code coupled with a useful error page, so looks like the port is opened.
So after we saw what we get from TMG when a port is open, what about closed ports or filtered ones ?
Typically we say a port is closed when the connection(initial SYN segment) is RST-ed.
Say we attempt that.
On TMG’s logs we can spot the connection attempt:
On the client side, we have the 502 proxy error code and the usual useful error page from which we can assume that the port was closed:
For a filtered port, usually we send a SYN segment and we will not receive the SYN|ACK from the server.
On TMG this will be logged for our attempt:
On the client side, we get a 504 proxy timeout error code and again an useful error page, combining these two we may reckon the port is filtered:
So, although, not particularly quite exact science and while results would vary due to the difficulty of scanning(rules requiring authentication, strict whitelist destinations, network layout, etc), we might be able like so to get the picture about the (common) services running on a server, services that we are not supposed to access or know about.
References
[1] Internet Security and Acceleration Server 2004/2006 SDK: About Web Proxy Clients
http://msdn.microsoft.com/en-us/library/ms812560.aspx
[2] Forefront Threat Management Gateway: About Web Proxy Clients
http://msdn.microsoft.com/en-us/library/ff823926(v=vs.85).aspx