[14329] in bugtraq
Re: Extending the FTP "ALG" vulnerability to any FTP client
daemon@ATHENA.MIT.EDU (Darren Reed)
Fri Mar 17 06:36:44 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <200003150031.LAA17946@cairo.anu.edu.au>
Date: Wed, 15 Mar 2000 11:31:35 +1100
Reply-To: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
X-To: mitch@SFGOTH.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000311160847.C56685@sfgoth.com> from "Mitchell Blank Jr" at
Mar 11, 2000 04:08:47 PM
In some mail from Mitchell Blank Jr, sie said:
>
> Mikael Olsson wrote:
> > * Send an email to the address in question containing an img
> > src ftp://ftp.rooted.com:23456 and hope that the firewall
> > won't realise that port 23456 is FTP.
>
> It would be nice if the browsers had a "disallow FTP to non-
> standard ports" checkbox.
>
> > That would help against the above attack, but not if we
> > modify it a wee bit:
> >
> > src="ftp://ftp.rooted.com/aaaaaaa%0a%0dPORT 1,2,3,4,0,139"
>
> Actually, on some firewalls you might be able to skip
> all the aaaaaaa's then, since PORT is now legitamately another
> command.
If ftp.rooted.com is an evil ftp server, your options are very limited.
You can dump all ports < 1024, but what about 2049/tcp and 6000/tcp ?
And what about others, such a oracle, etc ?
I don't need to use a bad hyperlink in HTML to do the above, I can
equally use Java.
In this case, it does not matter if an application proxy or packet
filter job. By the time the web browser sends "CWD /aaaaaaa", it
has done a login already so sending "PORT" next is as one would
expect from the ftp proxy.
The worst case scenario that I'm aware of, in so far as ftp clients
to proxy, is "links" which packs USER/PASS/CWD/PORT/GET all into
one long string to send to the ftp server.
In comparison, I don't see nearly as many problems with passive ftp.
Darren
