Subject: Re: ftp-gw

From: Scott McEachern <[email-masked]>
Date: Tue, 13 Feb 2001 09:54:21 -0500

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

Robin Swale wrote:

> I have just had an issue where I have updated my wu-ftpd server
> which
> lives outside my FWTK firewall and now I cannot create a new
> directory
> in the anonymous area although I have set up ftpaccess  with an
> appropriate "upload ........ dirs" directive. It turns out that my
> NT
> command line ftp client sends an "XMKD" directive to the server but
> ftp-gw only likes an "MKD" directive. XMKD seems to be an extended
> MKD
> and is mentioned in one of the FTP RFC's. Other FTP clients work
> okay.
> I assume that ftp-gw needs a patch to handle XMKD.
> I'd be pleased to hear an explanation of MKD and XMKD and why they
> are
> not both handled - they both seem to have been around for a long
> time!
>
> Robin Swale

    I'm using the ftp-gw with the plug-to patch applied, and I'm
trying to plug an NT box to another NT machine (running the WFTPD.)
Perhaps my NT ftp is also using XMKD.  I'm really just trying to nail
down what's not playing nice, and if it were NT I wouldn't be
shocked.  I logged into the WFTPD box and I could do a MKD but not
XMKD, so this is leading me to believe that NT is the bad guy.
    Also, I did a lookup in the RFC's for details on this.  The
regular mkd stuff comes from RFC 959 (1985) and the ``experimental''
commands are in RFC 1123 (Oct. 89.)  The gotcha however is that 1123
only states that FTP servers ``should'' implement the experimental
stuff, not _must_.
    I have also contacted Texas Imperial Software to confirm that
their 2.30 client does not accept the X stuff.  To be honest I'd be
surprised if they reply.

--
R. Scott McEachern, Network Administrator
J&A Media Services, Inc.
300 John St., Suite 500, Thornhill, ON, CA  L3T 5W4
tel:905-881-6902  fax:905-881-6945

---

From: Kees van Veen <[email-masked]>
Date: Thu, 22 Feb 2001 12:36:56 +0100

I'm running the fwtk for quite a while now and was looking into
tunneling through http proxies when I discovered that my firewall wasn't
as safe as I thought.

I have users on the Intranet connected to the outside through http-gw.
I allow people from the outside to connect to one internal destination
(called xxxx) with the netperm-table line:

http-gw:  ... all internal hosts ...
http-gw:  permit-hosts * -dest xxxx -httpd xxxx -java -javascript -deny
exec

Now on machine 'xxxx' I also have telnetd listening on port 23 and to MY
SURPRISE I could FROM THE OUTSIDE connect to http-gw with:

	telnet firewall 80

and then type

	CONNECT xxxx:23 HTTP/1.0

and get the login prompt (!?!).

Seems like the -dest flag in the http-gw nerperm-table options only
checks on destination host/address, but not on the port. My naive
assumption was that http-gw would only forward port 80.

I don't know of other ways to protect this, so I wrote a patch to
http-gw that would check on the portnumber as well, if I would have a
netperm-table line like:

http-gw:  permit-hosts * -dest xxxx:80 -httpd xxxx -java -javascript
-deny exec

so the hosts after the -dest flag may be specified with portnumber which
would be checked if specified (without it only the hostname is checked).

If anyone knows another way of protecting for this with http-gw
(plug-gw), I would be interested in it. Also are there other protocols
like ftp, etc. that allow for such a tunnel ?

I've included the patch for 'hmain.c' of http-gw.

Regards,
Kees

---

From: Kees van Veen <[email-masked]>
Date: Thu, 22 Feb 2001 14:35:56 +0100

> I've included the patch for 'hmain.c' of http-gw.

I posted the patch a little too soon, here's a slight modification in the case
that the remote port is equal to zero.

Regards,
Kees

---

From: David Lang <[email-masked]>
Date: Thu, 22 Feb 2001 10:14:16 -0800 (PST)

the problem is that it's not a valid assumption that all webservers in the
world will run on port 80.

for that matter the usual use of connect is to port 443 (for SSL traffic)

almost every firewall out there has this vunerability. some try to address
it by outlawing connections to 'known ports' like 23, but the only one
that I think really addresses the issue is the Raptor 6.5 proxy that
watches what happens after the connect and if it's not a SSL negotiation
(or I think they allow another connect, they should anyway) the proxy
closes the connection.

I haven't taken the time to figure out how to identify the start of SSL or
I would be working on a patch for http-gw to add that capability.

David Lang

 On Thu, 22 Feb 2001, Kees van Veen wrote:

> Date: Thu, 22 Feb 2001 12:36:56 +0100
> From: Kees van Veen <[email-masked]>
> To: [email-masked]
> Subject: Telnet (HOLE) through http-gw (!) with CONNECT ???
>

---

From: Rick Murphy <[email-masked]>
Date: Thu, 22 Feb 2001 20:08:49 -0500

>tunneling through http proxies when I discovered that my firewall wasn't

This is a FAQ. I've said this hundreds of times.
DO NOT use http-gw to front-end your web server.
Now you know why.

Use a plug-gw to allow outside access to your web server, or eviscerate the 
CONNECT code and use http-gw's "forward" directive. Plug-gw is a better 
choice - it's going to be more efficient and can't be exploited to connect 
where you don't intend.
         -Rick

---

From: Kees van Veen <[email-masked]>
Date: Fri, 23 Feb 2001 10:03:32 +0100

> DO NOT use http-gw to front-end your web server.

I'll look before I post next time.

Kees

---

From: Rick Murphy <[email-masked]>
Date: Fri, 23 Feb 2001 08:38:11 -0500

>I'll look before I post next time.

I'd like to figure out a way to make this more obvious; http-gw has many 
different ways it can be exploited if it's used inbound ("CONNECT" is just 
one of them.)
Using a plug-gw to do this is the right thing to do because it allows you 
to limit the target to just one IP address and just one port. Of course, 
neither http-gw or plug-gw protect you from someone exploiting a 
vulnerability on the web server that uses port 80 for the exploit.
         -Rick